New, Simpler Override Idea

So my original idea for override was ok, but it could get confusing using an override folder per-template name. So instead I thought about just using a folder called "override"

I have this working great on my dev server.

Features
Why do we want this, what does it offer? With the override system:

• Contribs never touch core files since they are in their own "override" folder
• Core upgrades never overwrite the contrib files they are in their own "override" folder
• Code always has the corefile fallback
• Contribs are dynamic. If you remove or add a file, it will automatically revert to the core or use the contrib respectively
• Contrib code doesn't change, only the folder structure move to the override subfolder

Goals
And the goals that are achieved with this are:

• Upgrades do not break contribs (unless there is a major code change in the new version, but it would still be minimal (per-file))
• Contribs can be plug-n-play, and easily unplugged without hours of manual coding
• Admin can disable use of "override" globally with a single configuration option. Returning the store to the default core install
• Paves the way for a package (zip) installer by setting up a framework now that promotes the non-touching of core files

How does it work
Simple.
Each existing folder gets an override subfolder. For the example we will use the catalog/controller/product.php file:
Now, the core file is in: catalog/controller/product.php
The person making a contrib that modifies the product.php file would create it inside an override folder, that is one subfolder down.
So the new file would go in: catalog/controller/override/product.php

How major is the code change?
The only code change is in the library file for controller loading, which is found at:/library/application/controller.php

Simply do a file_exist check on the override location. If it doesn't exists, fallback to the core version:

Change:
[php]$file = $this->directory . basename($action['class']) . '.php';[/php]

To:
[php]$file = $this->directory . 'override/'. basename($action['class']) . '.php';
if (!file_exists($file)) {
    $file = $this->directory . basename($action['class']) . '.php';
}[/php]

Simple!

Do the same for the other loader files: language, template, and a few others. And we have a viable, yet simple override system in place for contributions.

Admin Control
Also, by adding an option to the admin area, and a slight adjustment to the conditional above, we can globally disable all contribs based on a single admin setting. This is good when you found a contrib that breaks something but you aren't sure which one it is yet and you just want to get your store working again, so you can revert back to the default store with no contribs.

Only One Potential Limitation
There is still one limitation. Which is that if I make a contrib that modifies product.php and someone else makes a contrib that modifies product.php, then there will be a conflict. But think about it:
- That is currently how it is now, plus you have to worry about the core file changing, so that is 3 files to maintain & merge.
- If 2 contribs modify the same file, it is likely that they are conflicting features anyway, so you'd likely not be using them together
- This is pretty rare already from the contribs I've seen. Most developers keep their files self-contained whenever possible (thank you:))

So the long list of pros outweigh the single unlikely con.

Kohana?
I know we've talked about Kohana before when thinking about overrides, but after looking into it, that image that keeps getting flashed around doesn't do what it looks like it does. That just shows how MVC framework works with the controller and all the controller files loading, which is what OC already does. So I don't think that is what we want. But I'm not sure.

This override method, on the other hand is simple, and usable now. But it needs to be widely accepted as it will govern the way contribs are packaged for the future.

Thoughts?

It may already have been mentioned when you first proposed this idea but what happens when two or more "overrides" override the same part of the core and hence clash with each other?

It pretty much leaves you back at hacking at the "core" to get the final result.

Thoughts anyone?

bruce wrote: It may already have been mentioned when you first proposed this idea but what happens when two or more "overrides" override the same part of the core and hence clash with each other?

It pretty much leaves you back at hacking at the "core" to get the final result.

Going to start a reading program in Australia 

Qphoria wrote: Only One Potential Limitation
There is still one limitation. Which is that if I make a contrib that modifies product.php and someone else makes a contrib that modifies product.php, then there will be a conflict. But think about it:
- That is currently how it is now, plus you have to worry about the core file changing, so that is 3 files to maintain & merge.
- If 2 contribs modify the same file, it is likely that they are conflicting features anyway, so you'd likely not be using them together
- This is pretty rare already from the contribs I've seen. Most developers keep their files self-contained whenever possible (thank you:))

So the long list of pros outweigh the single unlikely con.

And since it is already like that now, its not really even a con, since it only requires you to maintain 2 files instead of 3. It's still an improvement

I know we've talked about Kohana before when thinking about overrides, but after looking into it, that image that keeps getting flashed around doesn't do what it looks like it does. That just shows how MVC framework works with the controller and all the controller files loading, which is what OC already does. So I don't think that is what we want. But I'm not sure.

Actually, Kohana uses override folders on the top level: The system contains the core MVC classes and directories, the application directory can override any of system folders and files, and add new files or even directories. The modules directory does something similar, each of its top-level sub-dirs add more Kohana features (folder and files). There is a configuration file which lists the order of the main directories where to look for a controller, model, or view, starting with system then the modules, and finally the application.

Basically, it boils down to overriding whole files only, and only the last one in the chain (order specified in configuration) is actually used. In other words: The same issue there as we'd have with your OpenCart Override idea! I think the most common case were we'd expect more than one contribution to override a core file is the one from /admin/extension/module/menu.php.

So if Kohana boils down to the same end result as the Simple Override, then Simple Override wins

As far as I'm concerned the admin menu is a separate and a solved issue using the db-based admin menu. I've been using it on my live and demo stores and I find no flaws with its use. It's just a matter of switching over to be the official way everyone designs their contribs.

I've brought the idea to the enhancement list on the code site, and now I just need to get others to understand it and get on board with it for the next version.

Q's simple override proposal sounds pretty good to me.

However, if implemented, it should not make it any harder to incorporate non-commercial contributions into the core.  OpenCart will become a far more compelling product when its built-in features can boast some of the functionality now supplied by contribs.

I would like to see some kind of community process for voting a contribution into the core.  Before such a vote, the contribution would need to pass several hurdles -- a willing coder must volunteer to make the changes and submit the diffs, and several sites must demonstrate successful use of the contribution.

Also, when conflicts do occur in overrides, it is a pretty good indication that a core file should be rewritten to be driven from the database, rather than from static data;  the admin menu.php being the seminal example of this condition.

The admin menu I think should be addressed separately, as the override system won't help it.

It's a common file and the only way to fix it is to be dynamic, either by my db-based admin idea, or some sort of directory search where files are automatically "included" with the main menu. The db-way is just simpler IMO, and it's already done

The override system works for most other files because there are a lot of them, and you could have 10 contribs that affect 10 different files without conflict because there are a lot of files. In the rare cases you do have files that conflict, then it would be similar to the way it is today, where manual combining would be needed.

I do agree though that it should not be harder to incorporate. Which is why it's designed so simply based on location. There is no additional code needed to convert existing contribs to use the override method, only the location of the file would be in a subfolder called "override" now.

For moving contribs to the core, I like the vote idea, but that's also a separate issue.

I think first we need to get the dynamic admin menu in place, then try the override system, then we will have a more proper "contrib" system in place. Which can then lead to "zip packages" and such. Perhaps a mod like EasyMod for phpbb, but that would be the next gen of contrib and would require a lot more work from the developers of contribs.

For now, this method requires no more work, but yields a great deal of improvement and ease of upgrading, adding, & removing.