Overriding
When modifying the behavior of CE Phoenix, it is preferred to avoid editing the files that come with the install. Such files may be updated with any release and applying the update would then revert your modifications. So it is better to override the default behaviors, which can be done in multiple ways.
Modules can be modified by making a copy of the module files (the module itself, its language file, and its template if it has one). The new files need to be edited with the new naming scheme. Then it can be modified and installed normally.
Catalog classes can be overridden by copying the original into includes/system/override and editing it there. Note that you may have to create that directory as it does not come with the default install.
Classes in admin/includes/classes may be overridden by copying the original into admin/includes/classes/override and editing it there.
Note that admin is also capable of using catalog files. But in admin, the preference is for
- admin/includes/classes/override
- admin/includes/classes
- includes/system/override
- includes/system/versioned (latest)
- includes/classes
Note that if a file exists in admin/includes/classes, it takes precedence over any catalog file. The presumption there is that there must be some admin-specific behavior for that file.
Templates can be overridden by adding the file to the override template (assuming that is the template that you are using) in the appropriate location. For files that exist in the default template, it is simply the same location under override. That includes components, ext, and pages. Note that the directory path may need to be created.
Some files may not exist in the default template. These include module templates. The default locations for those are in the modules directory (for historical reasons and to allow new modules to be installed more easily). A file named includes/modules/group/sub/templates/tpl_whatever.php should be copied to templates/override/includes/modules/group/sub/tpl_whatever.php to be overridden. Note that not all groups have subgroups. Also note that the templates part of the path moves from near the end to the beginning.
Changing the language files works the same way as for templates. Because language files can contain HTML, they need to overridable per template. And so we also get the ability to override language files by copying them into the templates. E.g. under templates/override/includes/languages/english -- the path should be the same just with templates/override/ at the beginning.
Database hooks may simply be edited in the database.
Template hooks take precedence over those of the templates from which they inherit. So templates/override/includes/hooks/shop/siteWide/foo.php will override templates/default/includes/hooks/shop/
You can also use hooks in general to override behaviors. For example, if someone is inserting a product, you can use the listener prior to the action switch to catch the insertion action and either block it (e.g. by redirecting before it gets to the point of processing the action) or replace it (by duplicating the necessary behavior and then blocking further processing). And of course it's easy to use hooks to add behavior.