Wordpress: Add WordPress custom directory options

[cnasikas]

It would be very useful to have the option to define your own custom directory structure.

Example:

/var/www/html:
    admin:
        ---- wp-admin
        ---- wp-content
        ---- wp-includes
        ---- etc
    app:
        ---- plugins
        ---- themes
        ---- index.php
    index.php
    wp-config.php
    .htaccess

Inside wp-config.php:

if (!defined('WP_SITEURL')) {
    define('WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/admin');
}
if (!defined('WP_HOME')) {
    define('WP_HOME',    'http://' . $_SERVER['SERVER_NAME'] . '');
}
if (!defined('WP_CONTENT_DIR')) {
    define('WP_CONTENT_DIR', dirname(__FILE__) . '/app');
}
if (!defined('WP_CONTENT_URL')) {
    define('WP_CONTENT_URL', 'http://' . $_SERVER['SERVER_NAME'] . '/app');
}

Inside index.php (root)

/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . '/admin/wp-blog-header.php' );

Reference: https://github.com/wesleytodd/YeoPress/tree/master/app/templates
Related to #133 , #131

[tianon]

Is this actually something upstream recommends doing? I can see that it's technically possible (and at least supported to some extent, given the existence of these defines), but I've never seen a real deployment use a structure like that before now, nor have I seen anything from upstream recommending that folks do so.

[cnasikas]

What do you mean by upstream ? I do not recall any recommendation but in my opinion is cleaner and organized. Personally, I don't like having all the files in the root directory and I think is better to separate the logic of an application, CMS functionality, from the content. It doesn't really make sense to have the content and wp-config.php along with wordpress core files especially if they are inside a sub-directory. Personally I used this structure to a lot of small sites without any problem and I use this structure for all my wp projects.

Some references: #1, #2, #3

[tianon]

By upstream, I mean WordPress upstream: https://wordpress.org/

https://codex.wordpress.org/Determining_Plugin_and_Content_Directories seems semi-promising, but it's just documentation of the feature.

The current image deploys WordPress in the stock manner described by https://codex.wordpress.org/Installing_WordPress, which is especially useful for ensuring their auto-update functionality works properly (as they recommend).

There's nothing particular to this image that should prevent you from making a derivative image (or even just a one-off deployment) which uses the structure you describe.

[cnasikas]

I know I could make a derivative image from this one but it is a great image and would be a very useful optional feature.

Thanks a lot!

[jerturowetz]

I'll be asking upstream about this in the wp-core slack group and see what they say as I'm curious.

Is there any concern that the only way (I can think) to accomplish this request (in addition to having an argument about what to call the folders) is to, likely manually, adjust docker-entrypoint.sh for each of the 3 non wpcli images per version of php of which there are also 4?

[jerturowetz]

@cnasikas if you're not going to modify the wp core files, you can just let the docker manage the WordPress install location and then mount the local folders are specific to your project. This keeps things clean and can be modified to suit a number of project structures without requiring a roll-your-own docker image or hacking up wp-config.php & index.php (which we're so used to doing by now we want it as a core feature ;) ).

Here's an example docker-compose.yml:

version: '3.1'
services:

  # DB, Adminer & whatever else
  # ...

  wordpress:
    image: wordpress
    volumes:
      - ./app/plugins:/var/www/html/wp-content/plugins
      - ./app/themes/sometheme:/var/www/html/wp-content/themes/sometheme
      - ./app/uploads:/var/www/html/wp-content/uploads
    ports:
      - <whatever>
    environment:
      <whatever>
      <whatever>

What do you think?

[cnasikas]

Hi. Thanks a lot for your research and response.

I'll be asking upstream about this in the wp-core slack group and see what they say as I'm curious.

I am also curious. Did they say anything on the matter ?

Is there any concern that the only way (I can think) to accomplish this request (in addition to having an argument about what to call the folders) is to, likely manually, adjust docker-entrypoint.sh for each of the 3 non wpcli images per version of php of which there are also 4?

In my opinion, modifying the images is not an option. Extending the image is better. In the derivative image you can move the folders, edit wp-config.php, etc

if you're not going to modify the wp core files...

Modifying the wp core files is a sin :)

...mount the local folders are specific to your project... What do you think?

It is a good solution. It is clean as Docker keeps things hidden and you only concern about your structure. What about custom URLs like site.com/admin and site.com/app ?

Thanks a lot for your effort!

[jerturowetz]

I haven't brought it up with core yet but, and I'm speculating, as users have the option to mount host folders freely, they'll lean to the _shouldn't-be-an-official-feature_ side, at least in the case of the official WordPress docker images.

(An aside: the wp core group is open to everyone & with questions like these you should join! Feel free to join the slack group.)

As for custom paths, using volumes, you're currently able to set up paths for anything on the container _except_ the core installation folder (which is managed by docker-entrypoint.sh). Of course, you'll still need to modify wp-config.php if you mount stuff in non-default locations but you can probably use the cli image to manage these changes without needing to hack up the WordPress docker image.

Moving the core application folder container-side is a different matter. Despite the suggested folder structure appealing to me personally (it's very similar to the way I build non-docker WordPress sites), the standard way of accomplishing this is to hack together an install script.

This kind of feels out of scope for the official WordPress docker image and generally feels like a non-docker way to do things (too many options is a vagrant thing ;) ).

My main complaints are:

• We already have the freedom to organize our project folders however we wish on the host end
• It adds overhead to accommodate a non-standard project structure
• We'll likely have to accommodate a number of variations on the structure (the Bedrock project standard) for example)
• The use case is mainly aesthetic

That last point is the sticking one for me, unless you can think up a use case that isn't security-through-obscurity or aesthetic.

[dambrogia]

+1 for the bedrock comment in this request.

[tianon]

Our directory structure is an entirely stock, default upstream WordPress
installation, so I'm not sure I understand what we would document here?

[bjorn-ali-goransson]

Well we shouldn't add a parameter to change the target directory.

But there should be an ENV for bluntly disabling the actual extracting operation.

Then, there should be an ENV for a "custom start script" where you can put all your own logic for extracting and whatnot. Like a really powerful extension point.

I think implementing those two suggestions would solve most of the requests people have.

[tianon]

Closing, since this isn't something we're going to implement (and is something that this image does support if you do the legwork of making the desired modifications before/after starting the image).

---

But there _should_ be an ENV for bluntly disabling the actual extracting operation.

Then, there should be an ENV for a "custom start script" where you can put all your own logic for extracting and whatnot. Like a really powerful extension point.

... that's --entrypoint on docker run (or entrypoint: in your docker-compose.yml). :sweat_smile: