Category Archives: 05 – Integrations

000GIT, 05 - Integrations

Dolibarr Github Integration

Welcome to the NZRT Wiki Podcast. Today we’re looking at 💼 Dolibarr GitHub Integration.

So, what is this integration all about? At NZRT, Dolibarr is the ERP system — the business backbone — and GitHub is where all the code lives. This integration ties the two together in several important ways. You get automatic code deployment from GitHub straight to the Dolibarr server, product and customer data syncing between WordPress and Dolibarr, a feature flag system that lets GitHub Actions turn Dolibarr features on or off, and a full audit trail so every sync event gets logged.

Let’s start with the module structure. The custom Dolibarr code lives in a folder called dolibarr-custom. Inside that, you have a source folder containing a modules directory with three submodules. The first is wp-sync, which handles the WordPress synchronisation and contains class files for products and webhooks, an admin setup file, a triggers file, and the main module file. The second is nzrt-audit, which handles audit logging through a class called AuditLog. The third is nzrt-reports for reporting. Alongside the modules, there’s a shared functions file, a dot-env file for environment variables, and a GitHub Actions workflow file for deployment automation.

Now let’s talk about how WordPress and Dolibarr actually talk to each other. When a product is updated in WordPress, WordPress sends a webhook — essentially a POST request — to a specific endpoint on the Dolibarr server. That request carries a payload containing the event type, the product ID, the product name, the price, the SKU, any image URLs, and a sync key to verify the request is legitimate.

On the Dolibarr side, there’s a PHP handler that receives that incoming data. It reads the raw request body, decodes the JSON payload, and then verifies the request is authentic by computing a cryptographic signature using a secret key and comparing it to the signature sent in the request header. If those don’t match, the handler rejects the request immediately with an unauthorised response. If they do match, it hands the event off to the product sync class, which does the actual synchronisation work, and returns a success or failure response.

Next up is the GitHub Actions deployment workflow. This is what makes sure that whenever you push code to the main branch on GitHub, your Dolibarr customisations get deployed automatically. The workflow runs on a Linux environment and goes through several steps. First it checks out your code, then it sets up PHP version 8.1 with the MySQL, curl, and JSON extensions. After that it installs any Composer dependencies, excluding development ones, and runs your test suite. Once tests pass, it handles the actual deployment. It sets up an SSH key stored as a GitHub secret, scans the Dolibarr host to verify its fingerprint, and then copies the module files from your source folder directly to the custom modules directory on the Dolibarr server. After deploying, it clears the Dolibarr cache by removing temporary cache files over SSH. Finally, regardless of whether the deployment succeeded or failed, it sends a Slack notification so your team knows the outcome straight away.

The last piece to understand is the feature flag system. This is a lightweight way to turn functionality on or off without changing code. There’s a helper function that reads an environment variable called FEATURE FLAGS, which contains a JSON object — a simple list of feature names paired with true or false values. The function looks up any feature by name and returns whether it’s active. For example, the environment variable might have advanced reporting set to false, audit log set to true, and custom export set to false. In practice, code throughout the Dolibarr modules can call that function before loading a feature, so you can safely ship code that’s switched off until you’re ready.

Pulling it all together — you have GitHub as your source of truth for code, an automated pipeline that deploys and tests on every push, a webhook bridge keeping your product data in sync between WordPress and Dolibarr, and a feature flag layer giving you fine-grained control over what’s live at any given time. It’s a clean, auditable setup that keeps your ERP and your codebase tightly coordinated.

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

000GIT, 05 - Integrations

WordPress Github Integration

Welcome to the NZRT Wiki Podcast. Today we’re looking at WordPress GitHub Integration.

So let’s start with the big picture. When it comes to the NZRT setup, WordPress and GitHub work together through a combination of webhooks, REST APIs, and GitHub Actions. The key thing to understand is that there are two separate sources of truth here. Code lives in GitHub, and content lives in the WordPress database. Those two responsibilities never cross over, and keeping that distinction clear makes the whole system much easier to reason about.

When you push code, it flows from GitHub through a GitHub Actions pipeline and lands on the WordPress server via SSH. If product data changes in WordPress, a webhook can fire and sync that change over to Dolibarr through its API. Theme files, plugin code, and configuration are all version controlled in git. And you’ve got two environments to work with: the develop branch deploys to staging, and the main branch, via a release tag, deploys to production.

Now let’s talk about how the code itself is organised in the repository. Picture a root folder called dolibarr-custom. Inside that you’ve got a wp-content folder, which contains a plugins folder and a themes folder. Under plugins, there’s a plugin called wp-sync-core, and inside that you’ll find a src folder with three sub-folders for Admin, Frontend, and API logic. Alongside src there are folders for templates, and assets which holds CSS and JavaScript. The plugin’s main entry file sits at the root of that plugin folder, along with a composer.json for PHP dependencies. Back in wp-content, the themes folder holds the nzrt-theme, which contains template parts, assets, a functions file, and a stylesheet. At the very root of the repository you’ll also find the main WordPress config file, an environment variables file, a Docker Compose file for local development, and a readme.

Let’s walk through the product sync flow, because this is where a lot of the integration magic happens. When you edit a product in the WordPress admin, WordPress fires a REST API hook. The wp-sync-core plugin picks up that event and prepares a request for Dolibarr. That request packages up the product name, SKU, price, category, images, and any relevant metadata. It then sends a POST request to the Dolibarr products endpoint to either create or update the record. Once Dolibarr responds, WordPress stores the Dolibarr product ID and a timestamp in its own post metadata, so you always know when a product was last synced and what its Dolibarr identifier is. Finally, the event gets written to an audit trail for traceability.

The PHP code that handles this lives in a class called DolibarrSync inside the API folder of the plugin. It reads the Dolibarr API URL and your API key from the environment, then defines a method that accepts a WordPress product ID. It fetches the product details, builds a payload with the label, price, tax rate, and status, then sends that payload to Dolibarr using WordPress’s built-in HTTP helper. If the request fails, the error gets logged. If it succeeds, the returned Dolibarr ID gets saved back into WordPress meta. Clean, self-contained, and auditable.

Now for the deployment pipeline. The GitHub Actions workflow triggers whenever you push to either the develop or main branch. It starts by checking out the code on a fresh Ubuntu runner, then sets up PHP version eight point one. Next it installs Composer dependencies without the dev packages, then runs a PHP lint check across every PHP file in wp-content to catch any syntax errors before anything hits a server. The deploy step then reads your deploy key from GitHub secrets, writes it to a temporary SSH key file, locks down its permissions, adds the target host to the known hosts file, and finally SSH’s in to run a git pull on the server. The target host is determined automatically: main branch points to production, any other branch points to staging.

For local development, you’re using a Docker Compose setup with two services. One runs the latest WordPress image connected to a MySQL database, maps port eighty through to your host, and mounts your repository folder directly into the web root so changes are instant. The other service runs MySQL eight, creates the dolibarr-custom database on startup, and exposes port three three zero six for direct database access.

That’s the full picture: code in GitHub, content in WordPress, syncing to Dolibarr via the plugin, deployed automatically through Actions, and reproducible locally with Docker.

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