Shell scripts layered on DDEV for editor integration and Drupal sync workflows, shared across multiple projects.
A set of shell scripts layered on top of DDEV, shared across Drupal projects (both client work and personal sites) plus a Laravel app and this portfolio's Slim backend. Some solve an editor-integration problem common to every PHP project; others are standard parts of the Drupal deployment workflow.
run-php, run-phpcs, run-phpcbf)The phpsab VS Code extension runs phpcs/phpcbf against files using their local, host-machine path. DDEV's tools live inside the container, where that path doesn't exist. These wrappers translate the incoming path to its container equivalent, invoke the right binary via ddev exec, and hand the real exit code back to the extension — ddev exec itself always exits 0/1 regardless of what ran inside it, so without this the extension can't tell a lint failure from a clean pass.
Present, in some form, on every PHP project: this portfolio's Slim API, several Drupal sites, and a Laravel app. Each project's copy is tuned to where its code actually lives (e.g. this project's phpcs.xml is scoped to api/, whereas the Drupal/Laravel projects run from the repo root).
dsync, usync)Standard across Drupal projects: dsync pulls the database and files (public and private) down from a remote environment via drush sql-sync and drush rsync; usync pushes local data back up the same way, with an explicit warning since it overwrites the remote. Both take a Drush site-alias argument (e.g. ddev dsync kci.prod), so switching between staging and production is a one-word change. One project also has a dsyncall host-side wrapper that runs dsync across every site in a multisite install in one pass.
DDEV's ddev pull/ddev push commands need a provider config telling them how to reach the remote environment. One project (Kellett Lighthouse, on Laravel) defines kci-prod/kci-stage provider files for its hosting platform, so pulling a fresh copy of the production or staging database/files is a single command rather than a manual export/import.
None of this is a single reusable add-on — it's tooling shaped by whatever a given project's CMS, hosting platform, or editor integration actually needs. The run-php* wrappers are the one constant across every project, since they all hit the same editor/container path mismatch.