Ability to override "sites_directory" path in templates

[slaFFik]

In my ~/Projects directory, I have subdirs for personal projects, work-related projects, experiments, etc.

So for testing, I may need to spin up a site in ~/Projects/work/example-one/ or ~/Projects/personal/example-two/ depending on the template (work-related or personal one).

So here is what I would like to have:

return [
    'sites_directory' => '$HOME/Projects/random',
    'templates' => [
        [
            'name'              => 'Work Test Site,
            'sites_directory'   => '$HOME/Projects/work`,
            'wordpress_version' => '6.0',
            'plugins'           => [
                'wpforms-lite',
            ],
            'theme' => 'twentytwentyfour'
        ],
        [
            'name'              => 'Personal Test Site,
            'sites_directory'   => '$HOME/Projects/personal`,
            'wordpress_version' => 'latest',
            'plugins'           => [
                'commentswp',
            ],
            'theme' => 'ollie'
        ],
    ],
];

Is that something that is possible with your tool?

[andrewjmead]

Love it. I'll get this in the next release.

[andrewjmead]

I'm thinking of removing sites_directory as a top-level property.

Instead, it'll work like all other options where there is a default and then templates can choose to override that default. It'll be site_directory.

[slaFFik]

@andrewjmead Sounds good!

[slaFFik]

@andrewjmead Over the weekend I started tinkering with this task.

I think to preserve backward compat, the package should have a fallback logic as follows:

1. if there is a templates.0.site_directory key - use it as a path where to install the site that uses this template.
2. if there is no templates.0.site_directory - fallback to defaults.site_directory.
3. if there is no defaults.site_directory - fallback to sites_directory.

This way all current users will continue using the top-level sites_direcory without changes while everyone will be able to reconfigure using the new templates.0.site_directory key.

Technically, you can mark sites_directory as deprecated and ping users about that in the cli when they manage their sites, so they can move that key value from sites_directory to defaults.site_directory or further down into templates if needed.

What do you think?

[andrewjmead]

I agree with the fallback logic. It makes sense to me!

I worked on implementing this feature a few weeks ago. For reference, here's that commit.

I don't remember any issues with the initial changes to the template or the create command. The problem was that everything else got more complex as the project was really designed for the initial sites folder to be set and never changed.

As an example, imagine you have a template that has site_directory set to a. Then you create a site. No problems there. Then you want to create a new site in a different folder. So you change a to b in the template and make the new site. No problems there either. Then you run wpsites destroy and you only see a single site. That's a problem. The templates site_directory value is the only place that a was ever defined in, so WPSites has no way of knowing that it should also be scanning a when looking for sites.

There are ways around this. You could create a new template where sites_directory is set to b instead of changing the existing template.

In general, I don't like the idea that changes to my templates could have an impact on sites that are already created. Templates shouldn't be (in my mind) tied to a site directory.

What if we took this in a different direction?

What if we leave sites_directory as a top-level config option, but we allow it to be defined as a string (single site directory) or an array of strings (multiple site directories). Then WPSites will always know what to scan to find sites and templates won't be attached to a specific site directory.

In this case, there would be an additional prompt when creating a site if you have sites_directory set to an array of sites. It would ask which directory you want to use.

This would still solve your original issue, correct? You'd be able to set up sites_directory with an array of two directories and then create works sites in one and person sites in another.

[slaFFik]

That approach will work for me too, actually.

I don't mind wpsites losing the knowledge of the site location when the template was modified - this is a user-space decision. Cover it in the docs and call it a day. But that's just me.

But I see your point and totally fine with your suggestion. You will also be able to ship it faster because of that :)

[andrewjmead]

Excellent. Yeah, I'll get that in. It's a nice approach. This is the PR that will eventually add the feature.

[andrewjmead]

I've got a question for you @slaFFik:

For WordPress sites, are you using the same database server for ~/Projects/work and ~/Projects/personal?

[slaFFik]

Yes, DB server is the same (via dbngin), I differentiate DBs via DB name prefixes if needed. So connection details are always the same.

[andrewjmead]

@slaFFik I just published 1.9.0-beta2 which supports this. Can you test it out and make sure it works for you?

All you need to do is update sites_directory to an array of directories:

 // 'sites_directory' => '$HOME/Herd',
 'sites_directory' => [
     '$HOME/Herd',
     '$HOME/Sites',
 ],

Then you can try creating, destroying, etc sites to see how it all works.

You can install the beta using:

composer global require andrewmead/wpsites:1.9.0-beta2

[slaFFik]

It works great!

[andrewjmead]

Great! I'll publish the release in a couple days.

[andrewjmead]

Released!