Skip to content
prod e051e98
Browse

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.

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 _zaj migration (never edit the vendor’s migration); genuinely new data goes in a zajm_ table.

Ready to start? The first decision drives everything else: