Welcome to the NZRT Wiki Podcast. Today we’re looking at 📁 Repository Structure.

If you’ve ever opened a project folder and had no idea where anything lives, you’ll know why this matters. At NZRT, all repositories follow consistent directory patterns so that whether you’re navigating a WordPress project or a Dolibarr customisation, you always know where to look. Let’s walk through what that looks like.

Every NZRT repository starts with a set of root-level files. At the very top of any repo, you’ll find things like a README, a dot-gitignore file, and a license. These sit right at the base of the project — they’re the first things you see when you open the folder, and they tell you what the project is, what files Git should ignore, and how the code is licensed.

From there, the structure branches out depending on what the project does. Source code lives in a dedicated directory — usually called “src”, though for WordPress projects you’ll find it under “wp-content”, which then splits into a “plugins” folder and a “themes” folder. That’s the WordPress way of organising things, and NZRT follows it.

Documentation has its own home too — a “docs” folder at the project root. This is where you’d put architecture notes, API specs, anything that explains how the project works rather than being the project itself. Tests sit in a “tests” or “test” folder, covering unit tests, integration tests, and end-to-end tests. Configuration files — environment configs, deployment configs, CI/CD pipelines — are also kept in clearly named locations so you’re never hunting for them.

For assets like images and static media, there are designated folders depending on the project type. And dependency files sit right at the root: for PHP projects that’s a “composer dot json” file, for Node projects it’s “package dot json”, and for Python it’s “requirements dot txt”.

Now let’s look at what this means in practice for the two main NZRT repository layouts.

The first is the WordPress and Dolibarr sync repository. When you open that folder, at the top level you’ll see a README file, a dot-git folder which is Git’s internal data, and a dot-gitignore. The main working folder is “wp-content”, and inside that you’ll find two subfolders: one called “plugins” containing a plugin called “wp-sync-core”, and another called “themes” containing the NZRT theme. There’s also a “docs” folder at the top level for project documentation.

The second layout is for Dolibarr customisations specifically. This one follows a slightly different pattern. At the top level you’ve got a “src” folder, a “tests” folder, a “docs” folder, a “composer dot json” for PHP dependencies, a dot-env-dot-example file which is a template for your local environment variables, and a dot-gitignore. Inside the “src” folder you’ll find three subfolders: “modules” for custom Dolibarr modules, “includes” for shared PHP includes, and “htdocs” for any web-facing files.

So to summarise the difference: the WordPress sync repo is organised around WordPress conventions, with the “wp-content” folder as the main container. The Dolibarr customisations repo is more of a traditional PHP project structure, with source code under “src” and a clear separation between code, tests, and docs.

In terms of NZRT context, “dolibarr-custom” is the primary repository. All custom code lives in those “src” directories we just talked about. Development happens locally in the Laragon environment first, and then gets pushed up to GitHub once it’s ready.

If you want to go deeper on any of this, the wiki links out to three related topics: Git Overview, which covers the basics of how Git works at NZRT; Branching Strategy, which explains how branches are named and used; and dot-gitignore Templates, which gives you ready-made ignore files for different project types.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.