OpenCart Community

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

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.

Nope, it trims. https://github.com/vqmod/vqmod/blob/mas ... #L915-L918

rph wrote:Nope, it trims. https://github.com/vqmod/vqmod/blob/mas ... #L915-L918

You are right, it's only OCmod which doesn't appear to trim regex search expr.

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.

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.

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.

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.

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

@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.

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.

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.

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.

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.

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.

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

I think the idea is to prevent same ocmod installed repeatedly

qahar wrote:I think the idea is to prevent same ocmod installed repeatedly

Correct.
And a side note: if is not present, the extension is not installable.

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

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. 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.