Standardize Workflow from Development to Pipeline to Testsite

[TangibleMark]

@eliot-akira I wasn't sure where to chat about this. I posted this in our slack dev channel recently:

Hello backend team.
I am curious about everyone's development set ups. Primarily how do you set up a new environment for plugin development. How do you get:

• Plugin Dependenies
• Necesssary data.

For example, in the Membersync plugin you will need an environment with LearnDash, WooCommerce (and a bunch of Woocommerce add-ons). Then you'll want courses and products to have been created, teams to have been made etc.

This is a lot of set-up, and it wouldn't even make sense for a developer to go build realistic courses. I find for this reason many developers on our team will download a production site and try to use it locally. But this results in a very slow development environment because your local isn't meant to run these clunky production sites.

To make matters more confusing, when you do your PHP unit tests, now you start with a blank database and have to reproduce the ideal testing environment all over again.

Finally when you go install your plugin on a new blank TXP test site, you'd again have to re-produce all the conditions a 3rd time for your plugin to work.

So I want to hear about your experience and how you tackle these challenges, to see if someone has a better solution, or if maybe we should be looking for one.

Unfortunately no one from the team responded. I was wondering what our current workflow looks like when dealing with these issues. I've been looking for a unified solution after getting inspired watching some WordCamp videos. I suppose there is also a use case where you are building a specific customization for a specific client in which case you may want to just port over as much of that site as possible to your local.

Any thoughts or information would be much appreciated.

[eliot-akira]

looking for a unified solution after getting inspired watching some WordCamp videos

Curious to hear more about this, if they have any recommended tools or workflows.

how do you set up a new environment for plugin development

For WordPress sites I use Docker, wp-env, and WP-CLI to install plugins, create users, etc. Everything is self-contained, independent of the local system, and reproducible every time on any host platform. With no/minimal dependecies on external services or manual setup outside the project.

These tools are scriptable/programmable, so you can define the entire dev/test/production environment as code, or configuration like YAML.

---

For third-party plugins, what comes to mind is the current setup for Fields Pro and Blocks Pro, for example:

• https://github.com/TangibleInc/fields-pro/blob/main/tangible.config.js#L62-L74
• https://github.com/TangibleInc/blocks-pro/blob/main/tangible.config.js#L126-L168

They install ACF, LearnDash, WooCommerce, etc., needed for tests and local development. There's room for improvement, such as what to do about proprietary plugins like LearnDash add-ons with no public URL. This is one way to solve it, there are various other possible solutions.

Necesssary data

It'd be useful if projects could provide demo/test data to optionally install for local dev purpose. It can be generated, for example, from JSON or WXR (WordPress eXtended RSS) file, with a Bash, Node, or PHP script.

---

unit tests start with a blank database and have to reproduce the ideal testing environment all over again

I'd say this is actually a good thing, it's best practice to have an automated solution for test setup starting from an empty site. Perhaps some steps can be useful for local site setup also.

when you go install your plugin on a new blank TXP test site, you'd again have to re-produce all the conditions a 3rd time

So you're seeking a unified solution for:

• local dev site setup,
• test setup (local or CI like GitHub Actions),
• and initial setup for a production site.

The first two can (and often do) share steps, scripts, demo data. To make it useful for the third context, where the user may not have access to the server directly, an admin screen for this purpose may be practical, like one-click install of demo data to get started.

---

download a production site and try to use it locally. But this results in a very slow development environment because your local isn't meant to run these clunky production sites.

Production sites that are difficult to run locally are problematic in itself already, I think. Similar to servers and services, sites should be treated like a commodity, easy to copy, clone, set up new ones on different machines. Ideally it'd be a single command to export its database (wp db export > db.sql) and copy/sync it to a local or remote machine (like with rsync or rclone).

But I understand in reality sites get bigger, older, and tend to become unique snowflakes that are hard to replicate; or as exotic orchids require sensitive conditions and delicate care to transplant; or as complex behemoths that everyone is afraid to move. To prevent this situation, it's best to regularly create and run copies on other machines, and to automate the environment setup in code as much as possible.

---

From a UX/DX perspective, the ideal is to git clone a project, run a command or two and have everything set up.

git clone https://github.com/TangibleInc/example-project
cd example-project
npm install
npm run start # or test

That would start an empty WordPress site. We could add a command before start, like npm run setup for optional third-party plugins and demo data. Wouldn't that be nice? How to achieve it is an open question.

[TangibleMark]

The WordCamp Video is here: https://wordpress.tv/2025/11/10/automating-quality-inside-an-agencys-devops-pipeline-for-wordpress/
But I wouldn't recommend checking it out because while the content is really interesting the audio/video quality is abysmal.

This video and another one from the same WordCamp about testing using Cypress both used Ddev. Ddev seems to be somewhere in between your the GUI WordPress set up tools that do all the docker things for you behind the scenes, and doing the docker things yourself. Because it has commands you can run that will just let you get started right away, but it also exposes it's docker files and config.yaml so you can easily configure things differently as you choose.

The company in the video then controls everything in Composer. They install WordPress through composer using this repo: https://github.com/johnpbloch/wordpress-core

Then they use WPackagist for public WordPress plugins https://wpackagist.org/.
They use private packages for installing proprietary plugins (I don't really understand how this works but I've seen this done here: https://github.com/cedaro/satispress).

Now to me the trade off here, is I see two different repos emerging. One for your plugin environment and another for your actual plugin. I'm not a big fan of that, but I do think it makes sense to handle the environment and creation somewhere outside of your plugin repo so maybe it makes sense.

I get the impression the people in the video are handling the site from end-to-end so they can have their pipeline and re-use whatever they want from composer in their pipeline tests and then deploy straight from their repo. This isn't really the same direction we'd want as we rarely git deploy sites, and often build plugins that we want to make widely available.

I think most of the things you've suggested above sound good, it's just about finding a way people can use them easily and/or creating examples people can follow.

That would start an empty WordPress site. We could add a command before start, like npm run setup for optional third-party plugins and demo data. Wouldn't that be nice? How to achieve it is an open question. (:

Yea, no one really likes to take charge on making decisions for the whole development team. So now I've collected the senior developers to meet once a week so we can try to standardize practices. When we create tools or documentation standardizing things it really helps the more junior developers to be feel more empowered.

I'll try to keep you updated on the conversations here, and hopefully I'll get others to chime in as well. Also I'm working on a ddev setup with the environment in composer, so hopefully I'll commit that to Github one day soon and let you know my thoughts and feelings after trying it out.

[eliot-akira]

we rarely git deploy sites

Curious, how is it done currently? I'd guess through plugin/theme updates, or UI to update from staging to production. Git or SSH for deploying a site is a nice workflow though, a single command to push changes; or better yet, Git push through a CI pipeline so the site goes through tests before being deployed.

Cypress .. Ddev .. johnpbloch/wordpress-core .. WPackagist

Well, the choice of tools and setup is not only a technical decision but a subjective one where developers often have strong opinions/emotions for and against. What's important is that everyone agrees on a set of decisions as a group concensus and compromise. That said, in my opinion:

• Cypress -> Prefer Playwright (Prior context: Consider Playwright for E2E testing WordPress/wordpress-playground#885)
• Ddev -> Prefer using the underlying tools directly in the terminal; GUI or higher level abstraction should be optional
• johnpbloch -> Prefer going to the source directly, not depend on a middle-person
• WPackagist -> Prefer not to introduce another external service as a dependency; but this one is popular so may be worth it for the convenience

create tools or documentation standardizing things

I've tried but failed to get any traction with: create, docs, example-plugin. These were made for my own workflow, so people are free to take it or leave it - including this framework. The team can develop or decide on equivalent tools for:

• Scaffolding new projects with the same standard setup, such as a command to create a new plugin, theme, or site
• Documenting necessary info about the full lifecycle of website and plugin development, integration with third-party services, server management
• Examples that demonstrate common features

Also establish a consistent standard across projects, such as:

• Git repository naming convention: lowercase, without prefix tangible-. Example: https://github.com/adobe/
• Folders and file structure: https://developer.wordpress.org/plugins/plugin-basics/best-practices/#file-organization
• Syntax for changelog: https://keepachangelog.com/
• Commit messages: https://github.com/conventional-changelog/commitlint
• Adopt good ideas from https://phptherightway.com/
• Use wp-env for environment setup and tests (PHPUnit and end-to-end tests with Playwright) on supported PHP versions and OSes, that can run locally and in CI pipeline. See:
  • https://github.com/WordPress/gutenberg/blob/trunk/.github/workflows/unit-test.yml
  • https://github.com/WordPress/gutenberg/blob/trunk/.github/workflows/end2end-test.yml

What's needed for consistency is an opinionated set of decisions that everyone can agree to follow, even if they may disagree on some details. Best if the tooling enforces those decisions, such as linter, formatter, build tool, Git commit hooks, etc.

It'd be useful to refer to what is the most common workflow in the WordPress/PHP ecosystem. What's popular may not always be the best technically, but it would have social authority and validation of the majority, for which people are usually willing to set aside their personal preferences for the greater good.

[TangibleMark]

Curious, how is it done currently?

Currently you're right, when a new feature is done the updated plugin is uploaded and any necessary set-up is done on the site. In theory a project manager or a QA (we have one person who does QA sometimes for some things) has tested it first. Also in theory PHP Tests have been written and been passed, but this seems to be less and less common which is a bit of a worry.

I agree with you that there should be flexibility in the specific tools and setup used, but I think there should be a recommended core set of tools that work on all platforms. Most new developers who join us are looking for these recommendations and are greatly sped up when we can give them some. It also lets us document the workflow completely, but your right it requires being opinionated. This is why I'm gathering all the senior developers to try to come to a consensus of what opinionated
choices we can make that everyone can live with.

I think many of the tools you've chosen and the docs you've made have been largely useful. The framework especially as it's used in every project, and tangible\log() is probably the most used debugging tool in the company. It also enforces decent file structure out of the box which has been really great. I was asking about Playwright, (which I have no problem using over Cypress), but it seems like no one in the company uses it. I don't know if that's because they don't know how/when or they just find it as overkill for their projects. One thing that's always hard, is that backend developers are somewhat lone wolves by nature, so they tend to be a little shy and not very talkative. So sometimes it's hard to know which things they prefer and not.

We have been trying to lean into what the larger WP community is doing more and more. I know in my projects I've started to adopt more and more the WP way of coding even if it's not my favorite (I prefer a syntax closer to what Laravel uses). I feel like OOP is often favored for the same reason, it tends to be what people already know and what the wider community uses. I know it was a struggle for many devs when they first joined because we were not very object oriented. Now I see projects slowly becoming more object oriented with lots of classes emerging (possibly too many). This tends to be how they've learned to organize/design their code, and what they'll find if they look in other plugins for guidance. I think people don't like WordPress because it doesn't follow the MVC model which also tends to be what people know. For that reason I was wondering if we could adopt an MVC approach like this company did: https://wordpress.tv/2024/11/25/leveraging-the-mvc-pattern-for-enterprise-wordpress-development/
But after further examination I don't think it maps well onto our use cases. Titus adopted a DDD approach in tangible-cred and was going to create us some kind of DDD scaffolding we could re-use but that seems to be on hold. When I talked to our junior devs they didn't really know what DDD was and found his code confusing. I don't think that means we can't use an advanced approach like DDD, but that we have to settle on one approach that we can document and teach so people don't learn all the crazy lingo of DDD for one project and then encounter completely different tech jargon in someone else's.

Anyhow as I said, we're going to be starting talks to slowly standardize some things to hopefully make everyone's live easier. I think we're starting with UI as that seems to be the biggest bottleneck for projects currently. More and more I feel like which decisions we take are less important than that we actually take them. I'll keep you in the loop with the conversations and of course you're more than welcome to join them. Although my understanding is you'd prefer not to, which is fine, you are still very much appreciated.

[eliot-akira]

you are still very much appreciated.

Thank you kindly, your appreciation is much appreciated.

As mentioned in #18, this framework is being deprecated in favor of a new base/core module designed and developed by the team. Here's the project repository with temporary name.

• https://github.com/TangibleInc/object

So far it contains @zinigor's proposal of data object model.

[GabrielGallagher]

I feel like one of the things the framework did uniquely well, that I don't think I've seen other devs figure out, is solve the problem of loading shared dependencies only once with minimal issues. Feels like if the base module is almost exclusively a port of that functionality, and everything else is an independent package, that might be a good way to handle things?