Implement Customizations
Workflow 3 of 5. How to change a CodeCanyon app you don’t own the source of — so your work survives every vendor update. This is the most valuable workflow: it encodes the customization methodology refined across real projects.
The problem it solves is simple. When you edit a vendor file directly, the next CodeCanyon release overwrites it (or collides with it), and you spend hours re-applying and debugging your changes. This playbook gives you three update-safe places to put your work, and a rule for choosing between them.
The core idea
Section titled “The core idea”Never edit vendor files in place if you can avoid it. Instead, route every change to one of three update-safe homes, picked by what kind of change it is.
flowchart TD Q{What are you<br/>changing?} Q -->|Editing an existing<br/>vendor file| V[Vendor Customization<br/>resources/vendor-customizations/] Q -->|Adding brand-new<br/>functionality| Z[ZajModule package<br/>packages/ZajModules/] Q -->|Adding columns to<br/>a vendor table| M[_zaj migration<br/>adds the columns]- New feature → build it as a self-contained ZajModule package. The vendor never knows it exists, so updates pass through cleanly.
- Edit an existing vendor file (because no event hook can do it) → put the edited copy in the vendor-customizations overlay and re-apply it after every
composer install. - New data on a vendor table → add the column directly via an additive
_zajmigration (never edit the vendor’s migration); genuinely new data goes in azajm_table.
The four steps
Section titled “The four steps”Ready to start? The first decision drives everything else: