Release 2.4.0 : Improve WordPress site support in slic here

[defunctl]

The main reason for these changes is to make slic here work properly with actual WordPress site repositories.

Previously slic assumed WordPress lived directly in the mounted directory and that content always lived in wp-content/. This doesn't work very well for projects that install WordPress in wp/, use content/, or need the full project available inside the container.

Main Changes

• slic here now mounts the entire WordPress project into /var/www/html, including projects that install WordPress in wp/.
• Adds support for projects using either content/ or wp-content/.
• Plugin, theme and mu-plugin paths now use the detected content directory instead of assuming /var/www/html/wp-content.
• Site projects automatically disable subdirectory mode, while normal plugin and theme projects continue to use it.
• Stops slic from creating an unused wp-content/ directory when a project uses content/ due to docker mounts.
• Fixes airplane mode to create and use the configured mu-plugin directory.
• Updates the xdebug path mapping output to use the configured content directory.
• Updates the documentation and bumps slic to 2.4.0.
• Updates the release documentation to use release/x.x.x branches and GitHub Releases.

Previously slic would actually delete the project's object-cache.php before running tests. This is especially dangerous with site mode because that can be a real file in the repository.

The object cache drop-in is now disabled inside the containers using a PHP prepend file. This leaves the host project's file completely untouched.

Testing

I tested this using the software.liquidweb.com project, which has WordPress installed in wp/ and uses content/ instead of wp-content/. I also tested on another of other projects/plugins.

• Confirmed the full project is mounted at /var/www/html.
• Confirmed plugins, themes and mu-plugins use /var/www/html/content.
• Confirmed an existing object-cache.php is not changed or removed.
• Confirmed slic does not create an object-cache.php when one does not exist.
• Built the PHP 8.3 slic and WordPress images locally.
• Had AI search for all our projects using slic and verify this would not break on those.

I used this branch/images here: https://github.com/stellarwp/software.liquidweb.com/actions/runs/31132177214/job/92723444428?pr=326

[shvlv]

I tried locally and got the following error for plugin that works good with 2.3.0:

In WPLoader.php line 507:
                                                                
  lucatume\WPBrowser\Module\WPLoader module is not configured!  
                                                                
  The WordPress installation is already configured.             
                                                                

In Scaffolded.php line 43:
                                                     
  The WordPress installation is already configured.  

Do we have a migration guide?

[shvlv]

Nice usage of preinitialized hooks!

[defunctl]

I tried locally and got the following error for plugin that works good with 2.3.0:

In WPLoader.php line 507:
                                                                
  lucatume\WPBrowser\Module\WPLoader module is not configured!  
                                                                
  The WordPress installation is already configured.             
                                                                

In Scaffolded.php line 43:
                                                     
  The WordPress installation is already configured.  

Do we have a migration guide?

Thanks for testing. We shouldn't need a guide. Which plugin so I can test and see what's going on?

Edit: it asked you to upgrade and download the new containers right?

[shvlv]

Edit: it asked you to upgrade and download the new containers right?

yes

[defunctl]

@shvlv can you try these updates 17a98fb ?