Conflicting OpenCart contributions

We used to discuss this in the past, but never came up with a working solution.

Problem:

There are 2 addons which were independently from each other created for OpenCart. In addition to providing new classes, they also happen to modify some of the same OpenCart core classes.

For example, both the Export/Import addon and the CMS addon modify the core files

admin/controller/common/header.php
admin/language/english/common/header.php
admin/view/template/common/header.tpl

Solution wanted:

At the the moment we are forced to manually merge the changes from each add-on to the core classes.

Ideally, I'd like to be able to keep an automatic track of all the add-ons in the form of a simple list stored e.g. as separate overwrite directories, and the core class is extended dynamically from that list.

For example, using a cascading overwrite directory named overwrite/<contrib-name>/ :

overwrite/export/admin/controller/common/header.php extends
overwrite/cms/admin/controller/common/header.php which in turn extends the core
/admin/controller/common/header.php

But how would I be able to have a PHP class whose parent class is dynamic? The language doesn't allow for such a feature, or at least I haven't found a solution yet for this.

Any ideas or suggestions are welcome.

yes there have been a few discussions about this, and I think it's going to be looked at closer in 1.5.0 or maybe 2.0 timeframe when it comes around to making major changes again, but I agree it would be nice to have some sort of solution to the admin header files sooner rather than later, as any contribution that wants to add a menu item will have to modify those three files.

I've got this partially working in my dev

Basically its multiple parts:
1. Goto the Admin and choose "Package Manager" - DONE
2. Upload a zip file that contains a mod and it extracts to a temp folder - DONE
3. Copy all files to the correct path structure, making backups of any file that gets replaced to a backup folder. - DONE

After files are copied, there are cases like menus that can be file edited just like SMF and PHPBB do for their mods.
Using SMF's same xml syntax, you can find/replace code automatically. I have this working but have to add error handling. It also handles backups of edited files.

After all files copied and edits made, it zips all the backups and stores them in the backup folder.

To Do:
- Generate a list of files that are changing
- Pre-test the files to ensure they can be modded (i.e. find all the points of entry in existing file)
- Generate a list of installed mods and offer "rollback" options for them

There is also the idea of extending a class. I tried this once but there aren't enough dynamic hook points in the code to check for extended versions of files. This would take a bit more work and I'm still not sure that if we had
class cmsHeader extends ControllerCatalogHeader {

if 2 of the same functions were overridden by 2 different mods, it would still have a problem.

The SMF way seems to handle multiple mods by automatic file edit.

For now, the answer is to simply add a few manual edits to the readme. That is how I handle the CMS mod.. its 2 lines of code that need to be added to the header.tpl file

yeah it's just a shame Daniel didn't want the dynamic admin menu's as it seems crazy to ask users who may not know what a text editor is to modify three files just to add an entry in the menu.

Well I managed to make an automatic installer with Options Plus that handles all the modifies and it has surprisingly excellent and error-free results with the customers that have used it. So if I can get this standardized and working with all mods, then we should have fewer problems with that

Using SMF's same xml syntax, you can find/replace code automatically. I have this working but have to add error handling. It also handles backups of edited files.

Does this mean that SMF is capable of merging the code changes to core classes from different contributions fully automatically? Can it cope with different contributions trying to modify the sane core class, maybe even in the same method?

Well SMF & PHPBB simply use a file edit method with a backup. It is just triggered by an xml script.

Example (this script adds a require_once config2.php to the index.php file) So the file "index.php"
gets backed up to "index.php_20100503_config2mod"
then a new index.php file is written with the new line added
Resulting in the new index file showing: Then if another person makes a config3mod. The same process happens to the new index.php file.
a backup is made to "index.php_20100503_config3mod"

Resulting in the final index file showing: Then uninstalls would simply replace the newly created file with the backed up version.

Qphoria wrote: Then uninstalls would simply replace the newly created file with the backed up version.

while that would be better than what we have now you would have to uninstall everything in the order you installed it, unless I'm missing something.

Also, the XML scripts with the change instructions would have to be created by the contributor, and he wouldn't even be aware of the fact that someone else might have done some changes to the same core-class, too.

So, I don't think Q's solution would work.

Well i dunno. it works for SMF and I've never had a problem there. Actually in SMF they have an uninstall script rather than simply restoring the backup file. Then it wouldn't have the problem that xsecrets mentioned.

Qphoria wrote:Well i dunno. it works for SMF and I've never had a problem there.

I had problems with it in SMF and sometimes had to manually build in some of the mods.

SHUT UP!