Post by rph » Fri Apr 17, 2015 7:24 am

Added bug for ocMod regex searches. Whitespace is never trimmed for search value.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by JNeuhoff » Fri Apr 17, 2015 10:10 pm

rph wrote:Added bug for ocMod regex searches. Whitespace is never trimmed for search value.
I think it never did. VQmod (ours and that of Qphoria/Jay) doesn't trim regex search values either.

MHC Web Design
Override Engine * Integrated VQMod * Unused Images Manager * Instant Option Price Calculator * TrustPilot Reviews * Google Rich Snippets * Google Tag Manager * Export/Import Tool * Template Switcher PHP/Twig


User avatar
Expert Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by rph » Fri Apr 17, 2015 11:44 pm


-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

User avatar
Expert Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by rph » Wed Apr 22, 2015 7:28 am

I've added a note for regex not accepting "before" or "after" positions like vQmod. ocMod will always perform a replace operation. This is noted in the documentation but it's buried.

ocMod is just similar enough to make you think conversion will be straightforward but different enough to waste hours doing it. The lack of decent logging forces you to spend a huge amount of time slogging through ControllerExtensionModification::refresh() to debug a script.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by MarketInSG » Sat May 02, 2015 10:35 pm

Pardon me if i'm on the wrong thread, but does OCmod scripts store to a file on the server, instead of to the database? It's a little hard to perform debugging if the scripts are all stored to the database.


User avatar
Guru Member

Posts

Joined
Wed Nov 16, 2011 11:53 am
Location - Singapore

Post by JNeuhoff » Sat May 02, 2015 11:31 pm

MarketInSG wrote:Pardon me if i'm on the wrong thread, but does OCmod scripts store to a file on the server, instead of to the database? It's a little hard to perform debugging if the scripts are all stored to the database.
They can be stored to a file on the server if you upload them (via FTP) to OpenCart's system folder, the same one which also contains the modification.xml file. The OCmod XML file name must still end with '.ocmod.xml'. And after the FTP upload, you still must go to Extensions > Modifications and hit the 'Refresh' button in order to rebuild the system/modification cache before testing your script.

MHC Web Design
Override Engine * Integrated VQMod * Unused Images Manager * Instant Option Price Calculator * TrustPilot Reviews * Google Rich Snippets * Google Tag Manager * Export/Import Tool * Template Switcher PHP/Twig


User avatar
Expert Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by MarketInSG » Sun May 03, 2015 1:15 pm

i'm referring to those customers who had uploaded files through the extension installer. Are those OCMod scripts stored anywhere other than the database? It makes debugging hard at times when they have OCMod and vQmod, and we cannot read the actual uploaded OCMod scripts other than through the database.


User avatar
Guru Member

Posts

Joined
Wed Nov 16, 2011 11:53 am
Location - Singapore

Post by rph » Sun May 03, 2015 5:16 pm

They're only in the database. Nothing with ocMod can be easy.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by RuslanBrest » Sun May 03, 2015 8:54 pm

@MarketInSG

In addition: if you need to debug extension and do it via `*.ocmod.xml` file in "system" folder, please remember that when you finish and extension will be uploaded via extension installer, execution order will be different. The `ocmod.xml` files will be executed first, before any extensions stored in "oc_modification" table. The ocMods stored in database will be executed in undefined sort order (they selected withoud any "order by ..." clause), usually in order of appearance in database.

This may cause additional errors when some modules conflict by modifying the same places in the file and conflict might be resolved by queueing ocmods in fixed order. You will know about those conflicts only when install ocMod via Extension installer and may don't know about them when debug your extension via XML file updated via FTP.

OCJ: OpencartJazz.com
http://rb.labtodo.com/category/opencart (lang: ru)


New member

Posts

Joined
Sat Nov 12, 2011 3:19 pm


Post by MarketInSG » Mon May 04, 2015 12:12 am

rph wrote:They're only in the database. Nothing with ocMod can be easy.
Wow...so it means we're stuck with the reading the database to know what those scripts are doing. And to debug would take 2x the time to do compared to vqmod.


User avatar
Guru Member

Posts

Joined
Wed Nov 16, 2011 11:53 am
Location - Singapore

Post by rph » Mon May 04, 2015 2:54 am

ocMod no fun to work with beyond the whole "coding in XML" part.

1. Useless error log.
2. No ocMod script dump.
3. No modified file dump.
4. No order sorting (scripts need a <priority> tag).
5. No ability for OpenCart minimum or maximum version enforcement. If you want to make a script or operation just for a specific OC version you can't.
6. Stand-alone ocMod scripts are in the form of *.ocmod.xml but extension zip packages requires them as install.xml.
7. Zip extensions can't accept multiple ocMod scripts. That means no separation, reuse, or sharing of subscripts. You get one giant god script.
9. No uninstall for zip extensions. Any file copies or database changes are forever.
10. Development means going in and refreshing a script constantly. It's even more tedious if you're developing it as a zip extension package.

I think it's fairly obvious the people developing the extension system don't use it.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by RuslanBrest » Mon May 04, 2015 5:10 am

What do you mean in (3)? Isn't "system/modification/*" the place containing modified files dumped?

It's fairly obvious the Opencart itself is full of such problems, but from the other point of view this gives us (developers) the room for endless improvements, including paid.

OCJ: OpencartJazz.com
http://rb.labtodo.com/category/opencart (lang: ru)


New member

Posts

Joined
Sat Nov 12, 2011 3:19 pm


Post by rph » Mon May 04, 2015 5:54 am

I meant through the UI. In vQmod Manager I have features for downloading the cache, *.xml files, and error log in zip files. That way store owners can send them off to the developer along with the OpenCart log for troubleshooting. It can save you from having to gain FTP access to do triage on an issue.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by qahar » Wed May 06, 2015 4:38 am

rph wrote: <name> - The name of the OCMod (<id> in vQmod).
<author> - OCMod developer.
<version> - OCMod version.
<link> - URL in the form of http://example.com. If http:// is omitted the link will be broken.
That is from OpenCart 2.0.0.0, but start from 2.0.1.0 tag <code> is required.
Without it extension install would fail because it's used to check if modification with same code is already installed.

Even tough at first I was expecting the <code> used as unique identifier belong to extension. Then compare the <version> if current loaded version from ocmod.xml is higher then install the mod. If lower then notice the user.

User avatar
Expert Member

Posts

Joined
Tue Jun 29, 2010 10:24 pm
Location - Indonesia

Post by rph » Wed May 06, 2015 5:28 am

Thanks. I've updated the post. As far as I can tell <code> does nothing useful. Just another feature to slow down developers. :bang:

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by qahar » Fri May 08, 2015 1:11 am

I think the idea is to prevent same ocmod installed repeatedly

User avatar
Expert Member

Posts

Joined
Tue Jun 29, 2010 10:24 pm
Location - Indonesia

Post by OSWorX » Fri May 08, 2015 1:21 am

qahar wrote:I think the idea is to prevent same ocmod installed repeatedly
Correct.
And a side note: if

Code: Select all

<code>someIDhere</code>
is not present, the extension is not installable.

Forum Rules [en]: viewtopic.php?f=176&t=200480
Forumregeln [de]: viewtopic.php?f=37&t=114208
Commercial Request: viewforum.php?f=88

Image Image Image


User avatar
Guru Member
Online

Posts

Joined
Mon Jan 11, 2010 10:52 pm
Location - Austria

Post by rph » Fri May 08, 2015 3:17 pm

I was fumbling at the idea that preventing users from reinstalling or upgrading a script is not a "feature". It's a hindrance.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by qahar » Fri May 08, 2015 5:44 pm

It would be good if <code> used as ocmod file identifier to insert or update.
If same code found then update, otherwise insert to database. It's imitate copy-replace at based file vqmod.

So even if user install it repeatedly it's just updating same ocmod data. The update process should not change the ocmod status. If the same <code> found is enabled, after the update should also keep it enabled. The same goes if it's disabled, no need to force enabled.

Then this will usefull for developer to programaticly rebuild the ocmod update.

Code: Select all

// rebuild automaticly clear cache
$this->load->controller('extension/modification/refresh');
In a way to increase user experience, refresh() method should have redirect arguments so rebuild cache not force redirect to modification page.
If it's update and bypass to extension with alert that the extension successfully updated.

Code: Select all

$this->load->controller('extension/modification/refresh', array('redirect' => 'myext/controller/succeed'));

User avatar
Expert Member

Posts

Joined
Tue Jun 29, 2010 10:24 pm
Location - Indonesia
Who is online

Users browsing this forum: Baidu [Spider] and 8 guests