Laravel/CodeCanyon — Handbook

The why behind the workflows

You bought a CodeCanyon Laravel app. It works today. The problem starts when the author ships version 2 — every file you edited is now a merge conflict, and a two-minute update turns into a two-hour archaeology dig.

These four chapters are the mental models that prevent that. They are explanatory, not step-by-step — read them once and the build playbooks stop feeling like arbitrary rules. Each idea answers the same question from a different angle: how do I change a vendor’s app without losing my work every time they update it?

The four ideas

1 · ZajModules vs customizations The core split: when a change is a new module, when it's a vendor customization, and when it's a schema extension — and why that split keeps you update-safe.

2 · The three-tier admin model Where your ops files live: Admin-Local (in git), Admin-Domain (per-domain runtime), Admin-Server (shared across the account).

3 · Schema management Extending vendor tables safely: additive _zaj migrations, zajm_ tables, additive-only changes, and never editing a vendor migration.

4 · Version management SemVer for your fork versus the vendor's author-vX.X.X line, and the CHANGELOG discipline that keeps upgrades calm.

How they connect

All four ideas share one root principle: keep a clean seam between the vendor’s code and yours. Chapter 1 draws that seam in your code, chapter 3 draws it in your database, chapter 4 draws it in your version numbers, and chapter 2 decides where the ops files that manage all of it live.

Tip

New here? Read them in order — chapter 1 sets up the vocabulary the other three reuse.