I'm about to release my first extension for OC, but I have a doubt about handling its features and, especially, about its VQMod files. This extension interacts with several Core files, and it makes extensive use of VQMod. However, I can't figure out how an Admin could turn off the extension, if he wishes, and, especially, how to handle the VQMod files in such case. My understanding is that VQMod files are loaded and processed as soon as they are found, but, since they add changes that rely on the extension, if its classes were not found, a fatal error would be raised.
In short, question is: can an extension be disabled? If yes, how are VQMod files "disabled" as well?
Also, are there functions to Uninstall (i.e. physically remove) an extension from OC? I spotted the Install/Uninstall in Extensions/Modules, but I'm not sure if they relate to modules only (where module is different from extension) and, as far as I could see, they don't really "uninstall" modules, but merely disable them.
Sorry for the (possibly) basic questions, I'm at the beginning and I have a lot to learn.
Thanks in advance for the answers.
In short, question is: can an extension be disabled? If yes, how are VQMod files "disabled" as well?
Also, are there functions to Uninstall (i.e. physically remove) an extension from OC? I spotted the Install/Uninstall in Extensions/Modules, but I'm not sure if they relate to modules only (where module is different from extension) and, as far as I could see, they don't really "uninstall" modules, but merely disable them.
Sorry for the (possibly) basic questions, I'm at the beginning and I have a lot to learn.
Thanks in advance for the answers.
My personal blog - My blog about Software Development - My profile on StackOverflow
The install and uninstall for OpenCart extensions (modules, shipping, payment, feeds, order totals) by default only add or remove them from the database. The files themselves always remain on the server.
Some extensions may modify the database, in which case it is useful to write an install or uninstall method for the specific extension to deal with the DB modififications or other resources.
Opencart core file modifictions, when implemented as a VQmod XML script, can be un-installed by merely removing the VQmod XML script, after which the affected core files revert to their normal programming logic.
Opencart extensions, as discussed above, have a well defined interface.
Quite often we also have to deal with more general addons which tend to modify OpenCart core files, and may also modify the database. For these there is no proper uninstaller yet. You can remove the VQmod XML file, but changes done by the modification to other resources, e.g. database, additional files, etc, are left unchanged after the removal of a VQmod XML script.
Some extensions may modify the database, in which case it is useful to write an install or uninstall method for the specific extension to deal with the DB modififications or other resources.
Opencart core file modifictions, when implemented as a VQmod XML script, can be un-installed by merely removing the VQmod XML script, after which the affected core files revert to their normal programming logic.
Opencart extensions, as discussed above, have a well defined interface.
Quite often we also have to deal with more general addons which tend to modify OpenCart core files, and may also modify the database. For these there is no proper uninstaller yet. You can remove the VQmod XML file, but changes done by the modification to other resources, e.g. database, additional files, etc, are left unchanged after the removal of a VQmod XML script.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Is there an Admin interface for this, or would the Admin have to do it manually? In the second case, I would not be very concerned (as the Admin copies/deletes/moves files by himself), but, in the first, I think I'd have to handle some "Uninstall" event and delete the VQMod myself. The thing that confuses me is that, due to the way extensions are structured, they may contain vqmod/xml and, if I got it right, by copying the VQMod in place, it becomes functional, hence no "Install" event occurred.JNeuhoff wrote:Opencart core file modifictions, when implemented as a VQmod XML script, can be un-installed by merely removing the VQmod XML script, after which the affected core files revert to their normal programming logic.
My personal blog - My blog about Software Development - My profile on StackOverflow
Just to avoid confusion about the terminology used here:
An well programmed OpenCart extension (modules, shipping, payment, feeds, order totals) does not need VQmod XML scripts, and it has proper install and uninstall functions, except that actual PHP files remain on the server after an uninstall. The uninstall only removes the extension from a DB table called 'extension', and as a result, the files won't get invoked.
An OpenCart addon is more general, and often includes VQmod XML files, too.
Daniel has started to write an extension manager for the OpenCart 1.5.5.x admin backend (yet to be released). It uploads a zipped file to the OpenCart server, unzips the files, and then uses FTP to load the unzipped files to the final OpenCart target. His extension manager also seems to work just fine with general addons.
What we really need is an addon manager, with proper install and uninstalls, and proper tracking of the files to be uploaded or removed.
I have written a new OpenCart override engine which allows addons to use normal class extensions in an object oriented programming technique, no need for VQmod. As a next step, I plan to write up an admin addon manager for this. I might use a modified version of Daniels new extension manager for this.
An well programmed OpenCart extension (modules, shipping, payment, feeds, order totals) does not need VQmod XML scripts, and it has proper install and uninstall functions, except that actual PHP files remain on the server after an uninstall. The uninstall only removes the extension from a DB table called 'extension', and as a result, the files won't get invoked.
An OpenCart addon is more general, and often includes VQmod XML files, too.
Daniel has started to write an extension manager for the OpenCart 1.5.5.x admin backend (yet to be released). It uploads a zipped file to the OpenCart server, unzips the files, and then uses FTP to load the unzipped files to the final OpenCart target. His extension manager also seems to work just fine with general addons.
What we really need is an addon manager, with proper install and uninstalls, and proper tracking of the files to be uploaded or removed.
I have written a new OpenCart override engine which allows addons to use normal class extensions in an object oriented programming technique, no need for VQmod. As a next step, I plan to write up an admin addon manager for this. I might use a modified version of Daniels new extension manager for this.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
Thanks for the clarification. At the end, I spent a day developing a Plugin Manager, which allows to add Plugins (which can contain extensions (modules, shipping, payment, feeds, order totals) and don't necessarily need to rely on VQmod. The plugin manager adds events to several Controllers and Models, and extends the base Controller and Model classes to allow them to fire and handle events. Ideally, once the necessary Events have been injected into OpenCart core classes, most Plugins won't have to implement VQMod at all.
The reason why I implemented a Plugin Manager is that, initially, I just spent half a day coding an Event Manager. It injected events in OC classes, and any OC Controller or Model could handle them. However, Controllers and Models are loaded only when needed, while an Event Handler should run every time the event fires. Therefore, I needed something that would be loaded at startup or, at least, loaded when needed. It's still rough, but it seems to be doing what I need.
One question that I already got asked is "why adding Plugins, when there are Extensions?". The reason is that Extensions, as far I could see, implement Modules, and Modules are loaded in specific circumstances and render something on a page. I needed something that gets loaded every time and doesn't render anything. Perhaps there are cleaner ways, but mine works for the moment.
The reason why I implemented a Plugin Manager is that, initially, I just spent half a day coding an Event Manager. It injected events in OC classes, and any OC Controller or Model could handle them. However, Controllers and Models are loaded only when needed, while an Event Handler should run every time the event fires. Therefore, I needed something that would be loaded at startup or, at least, loaded when needed. It's still rough, but it seems to be doing what I need.

One question that I already got asked is "why adding Plugins, when there are Extensions?". The reason is that Extensions, as far I could see, implement Modules, and Modules are loaded in specific circumstances and render something on a page. I needed something that gets loaded every time and doesn't render anything. Perhaps there are cleaner ways, but mine works for the moment.

My personal blog - My blog about Software Development - My profile on StackOverflow
Neuhoff: thank you very much.
--- please reply only with verified data, that is: no 'I think', 'maybe' etc. ---
Who is online
Users browsing this forum: No registered users and 2 guests