I think it never did. VQmod (ours and that of Qphoria/Jay) doesn't trim regex search values either.rph wrote:Added bug for ocMod regex searches. Whitespace is never trimmed for search value.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
You are right, it's only OCmod which doesn't appear to trim regex search expr.rph wrote:Nope, it trims. https://github.com/vqmod/vqmod/blob/mas ... #L915-L918
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
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.
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
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.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.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
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.
@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.
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.
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.rph wrote:They're only in the database. Nothing with ocMod can be easy.
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.
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
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.
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.
-Ryan
That is from OpenCart 2.0.0.0, but start from 2.0.1.0 tag <code> is required.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.
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.
Correct.qahar wrote:I think the idea is to prevent same ocmod installed repeatedly
And a side note: if
Code: Select all
<code>someIDhere</code>
Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.
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.
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');
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'));
Who is online
Users browsing this forum: No registered users and 94 guests