search

svandragt / wmm

Sane WordPress local environment
0 stars 0 forks source link

composer workflow support #6

Closed svandragt closed 1 year ago

svandragt commented 2 years ago

Not convinced, maybe spinning up a nicely configured wordpress is enough for now. If you're working on a specific wordpress project (theme / plugin combo) then one requires control over the wordpress version, the default plugins and themes etc. So for project work composer workflow support is needed.

Adding this could make it more challenging to spin up a quick WP local install.

Only implementing this if there is a usecase

svandragt commented 1 year ago

I do have a project idea that could use this. I'm wanting to keep this simple though. Perhaps we can detect a composer.json file and if it exists switch to composer "mode". It means testing future changes in two ways though which I am not super happy with, as I'm trying to keep it simple. Perhaps the composer mode could be a "patch" that transforms a non-composer project, then it's using both at the same time.

svandragt commented 1 year ago

Requesting creative thinking of @cameronterry

cameronterry commented 1 year ago

One way - which might help retain the simplicity - is to do a basic check on the directory with the project's files. If it's empty, then use WP CLI to spin up a simple environment. If it's not empty, then assume the developer is handling it. Another version would be to check for a composer.json and assume it's WP/composer based.

My thinking here is that if you are hosting on a platform such as Kinsta or WordPress.com VIP, then composer controlled WP is kind of an oddity for your local environment. So at least by doing the basic check, you kind of support both setups ...

Another approach that could work would be a configuration file, like JSON/YAML, which has an option such as type: single|multisite|composer. More complicated for WMM to manage but a bit simpler and more specific for the developer using WMM.

Not sure if this is an option with WMM at the moment, sorry, but I think you'll possibly need the ability to control the Caddy configuration to support wp-content/ and wp/ being in different places, which is a common when WordPress versions are controlled with Composer. I've been on a few projects where this necessitates some bespoke configuration - for NGINX - to get it working.

svandragt commented 1 year ago

Good points. I was also thinking if the composer.json file does not yet exist, one can spin up a composer based wordpress, this doesn't stop a developer dumping one or more plugin projects in the plugins folders, they're just then not managed by composer. But it would make it easier to start a composer.json wp project at a later date, by adding those plugins to a working install.

Also does this mean WMM must support all existing composer.json workflows. As tthe developer is free to change scripts, for example if nginx is needed instead of caddy, then it's support-ready (similar to HD-ready TVs)

svandragt commented 1 year ago

It does also highlight the fact that a number of files are added to your project directory if you check or instance WMM. I could see at some point moving most of the folder structure to a .wmm or equivalent folder.

cameronterry commented 1 year ago

But it would make it easier to start a composer.json wp project at a later date, by adding those plugins to a working install.

The transition from non-Composer to Composer would be a benefit. Not sure how often that would be the case, but anything to simplify that would help.

I guess it depends whether you want to offload the responsibility for managing WP versions from WMM to Composer (and the developer using WMM) after the initial setup? So basically keeping WMM as a thin layer to provide you an server-like environment with a thin layer for Caddy/NGINX, PHP, Object Cache, and database.

Also does this mean WMM must support all existing composer.json workflows.

Yeah this could be problematic from the Caddy/NGINX perspective as well, depends on how compatible the configuration is between different software like say ... Drupal/Grav/WordPress.

I could see at some point moving most of the folder structure to a .wmm or equivalent folder.

Something like this is probably going to be needed once you start getting more and more towards making things configurable.