wplib / better-wp-config

A better way to bootstrap WordPress

WPLib

A PHP Library plus Conventions for Building Complex Custom WordPress Apps

WPLib was designed for use by teams who build custom sites and need professional workflow. The library is a thin layer that provides a simple Module System and a lightweight Model+View architecture.

WPLib is for those professionals who want their custom-developed WordPress sites to be both robust and easy to manage and maintain as site complexity grows.

Documentation

You will find documentation in its current state on the wiki.

better-wp-config's Issues

Provide sample configuration files for multi-tenancy

Move better-wp-config.php to wp-includes?

Seems like a good convention is that the only files in the root directory are files that are intended to be accessed from the outside. As better-wp-config.php is not intended to be accessed from the outside, wp-includes might be a better place for it.

Consider moving better-wp-config.php to subdirectory one level below web root

In order to better support Composer, it appears to me that it would be better to have a subdirectory one level off the web root where this repo could be cloned rather than to store better-wp-config.php in the root and thus making "composing" this project (next to?) impossible. Potential subdirectory names:

• /.bootstrap
• /wp-bootstrap
• Developer's choice, or
• Something else?

Would like to get feedback on this before I do. This would mean that that index.php and wp-config.php would be changed to have it's require_once() look like this:

require_once( __DIR__ . '/subdir/better-wp-config.php' );

Instead of what it currently looks like:

require_once( __DIR__ . '/better-wp-config.php' );

This would mean wp-bootstrap.php would still be located in the web root and maintained by the project developer.

Add in a config.secrets.* file

There is likely to be a need for a file with a single name that can be ignored by .gitignore that can contain passwords or API keys or whatever else that the site owner/developer feels should never be committed to version control.

The open question is, should secrets be loaded before environment overrides or should secrets override the environment config?

Update WP_Bootstrap to allow multiple wp-bootstrap.com to contain only a single value for 'config'

For example:

<?php
return array(
	'config' => '/app/config',
);

And:

<?php
return array(
	'config' => '/content/config',
);

And (although this would be redundant since it is the default):

<?php
return array(
	'config' => '/wp-content/config',
);

Ensure we work with WP CLI

Ensure better-wp-config works with Roots/Bedrock

Break out classes in better-wp-config.php into a /src directory

Given #4 we can break classes out into individual files.

This will require registering a custom autoloader, but that autoloader should be unregistered in function wp_config() just before WP_Config::release_memory() is run.

config directory should probably be .config

Since it is placed in the wp-content directory which is exposed to the web it should be easily identified as something for which access is denied. At least in calmPress by the default .htaccess is going to block access to all . (dot) files and directories

Enable support for WPEngine

Update so `wp-bootstrap.php` if only required for non-default locations

Update WP_Bootstrap to allow multiple environment-specific options for 'file_format' and 'provider'

Add method for 3rd parties to add to list of available config options for their own plugin/theme/etc. configuration

Basically this means to adding a bootstrap class similar to WP_DB_Bootstrap but for the options needed for a plugin/theme/etc.

Current thoughts are to look for an optional more_options field in wp-bootstrap.php that could have the following format:

'more_options' => array(
    'Automattic\\Akismet_' => '{plugins}/akismet'
    'Yoast\\YoastSEO_Config_Loader' => '{plugins}/wordpress-seo'
    'ACME_Theme_' => '{themes}/acme'
);

In the above example:

1. Akismet is namespaced and there is a class named Automattic\Akismet_Boostrap in '{plugins}/akismet/better-wp-config.php'.
2. Yoast SEO is namespaced and there is a class named Yoast\YoastSEO_Config_Loader in '{plugins}/wordpress-seo/better-wp-config.php'.
3. ACME Theme is not namespaced and there is a class named ACME_Theme_Bootstrap in '{themes}/acme/better-wp-config.php'.

But that's just a firstt draft. Open to any and all feedback that allows for developers to add their own configuration files for 3rd party code, that allows 3rd parties to add their own support for Better WP-Config, that is simple and easy for developers to find and use the 3rd party support, and that makes extensions fully available via the bootstrap process.

Select a coding standard

Raising the issue because it is likely to have an impact on file structure.

Both the WordPress coding standard and the PSR require one class per file which is not how the code is structured right now. I would prefer going with the wordpress one, but it is not critical.

In a any case this probably means that the relevant files need to be in a directory

Add a "Platform" config file

Given the new forks, ClassicPress and CalmPress it makes sense that they might have different defaults.

The question would then be, how do we recognize the default? I can envision these as potential approaches:

1. Add a define( 'PRESS_PLATFORM', '...' ); at top of index.php and top of wp-config.php. But we want to get away from define()s, so this is going against that, but it might be okay given the context?

2. Assign $_ENV['PRESS_PLATFORM'], $_SERVER['PRESS_PLATFORM'], and/or call putenv('PRESS_PLATFORM','...') at top of index.php and top of wp-config.php.

3. Just load config.platform.php and let the platform define itself and don't worry about having different names (but that will make it harder to include multiple samples in our own repo):

    <?php
    /**
     * config.platform.php
     */
   
    return array(
    	'environment[platform]'  => 'wordpress',
    //	'environment[platform]'  => 'classicpress',
    //	'environment[platform]'  => 'calmpress',
    );
   

4. Some other approach that has not occurred to me?

---

NOTE: In the short term I have actually committed option #3 but want to hear the opinions of @nylen from ClassicPress and @markkap from CalmPress before finalizing on a solution.

PHP 5.2 is dead even in WP, namespaces can be used everywhere :)

:)