wecodemore / wpstarter Goto Github PK

At the moment all the environment variables set in .env file are then defined as global contants during WordPress bootstrap.

For WordPress constants there is no choice, but other variables should, by default, just stay environment variables.

WPStarter defines the constant WP_CONTENT_URL in generated wp-config.php:

/**
 * Define content constants only if needed, or network install screen will complain for no reason
 */
if (realpath(dirname(__DIR__).'/public/wp-content') !== realpath(ABSPATH.'/wp-content')) {
    defined('WP_CONTENT_DIR') or define('WP_CONTENT_DIR', realpath(dirname(__DIR__).'/public/wp-content'));
    defined('WP_CONTENT_URL') or define('WP_CONTENT_URL', rtrim(WP_HOME, '/').'/wp-content');
}

My configuration is:

"extra": {
    "wordpress-install-dir": "public/wp",
    "wordpress-content-dir": "public/wp-content",
    "installer-paths": {
        "public/wp-content/plugins/{$name}/": [ "type:wordpress-plugin" ],
        "public/wp-content/themes/{$name}/": [ "type:wordpress-theme" ]
    },
    "wpstarter": {
        "register-theme-folder": false,
        "prevent-overwrite": [ ".gitignore" ]
    }
}

In case of multisite with different domains, this leads to issues with cross-origin policy. E.g. WP_HOME is set to http://site-a.tld. On site site-b.tld assets will get enqueued with the domain of site A. In my specific case the browser does not request font files that are referenced with a relative path from a style sheet. However It could be hot-fixed by adding a Access-Control header but that wouldn't solve the actual problem that WP_CONTENT_URL does not match the home_url().

From the code comment, this is only needed for the network install screen, so maybe we should define these constants only if MULTISTIE is not defined or false?

I'll test the suggested fix and provide a PR if appreciated.

So imagine you're creating some other application that needs to use WP data from the DB without loading WP. So this application also needs a lot of the stuff in wp-config.php. The easiest would be to just require wp-config.php, but there is a problem: the last line

require_once ABSPATH.'/wp-settings.php';

...which immediately continues with starting up WP which we might not need.

You have some options right now:

• Option 1: Roll your own wp-config.php which you commit in the repo and prevent-overwrite. But then you manually have to make sure to keep it in sync with wpstarter development.
• Option 2: Some of the constants could be defined in the .envfile, but then you lose some benefits like the automatic generation of keys and salts.
• Option 3: Duplicate all the settings in some other configuration for that other application.
• Option 4: Use SHORTINIT to only load the bare minimum of WP.

These are all valid options but what would be even greater would be something like adding WPSTARTER_SHORTINIT just before the require at the end of wp-config.php:

[...]
if ( WPSTARTER_SHORTINIT )
    return false;

 require_once ABSPATH.'/wp-settings.php';

Not really sure if this is in scope for WP Starter - happy about feedback!

I've created this issue so we don't mess up #29.

Quick summary of the status quo:

There is no complete composer based solution to get translations.
The only thing that comes close is https://wp-languages.github.io/ which unfortunately only supports core and a small selected number of themes and plugins.

Thoughts

When building a replacement ourselves that plays nice with wpstarter we actually have multiple problems to solve:

1. Actually getting translations at all. We'd probably get it from the API. I vaguely remember seeing a PHP client for it somewhere... We'd also need a custom installer, something like the installer that https://wp-languages.github.io/ uses.
2. If I remember correctly translations don't really have sane versioning. You just ask the API for the newest translations for a certain version of core/theme/plugin and get what they have. This may change without WP versions changing as translations get updated independently. At least that is what I remember. Correct me if I'm wrong. 😉
3. Translations are strongly tied to the WP version. Once we have composer packages for languages the most reasonable thing would be if they were dependencies of the core package itself, but that would mean convincing John of adding it. Otherwise you always have to keep versions in sync manually, right?

WP-CLI as an alternative

I see that there is some talk about some integration with WP-CLI in #33. Maybe to keep things simple we could just build a wpstarter step on top of wp core language update. I know that this is not an ideal solution as it relies on the internal workings of WP update, but on the other hand it may just work without much hassle. What do you think?

The current documentation shows a quick start and a complete example. Both show, how to configure WP-Starter to be the web root directory which exposes the .env file to the public.

It's easily possible to set up a structure like this, where the public/ directory is considered to be the web root:

public/
    wp/
    wp-content/
vendor/
composer.json
.env
.gitignore

I'm preparing a PR on that…

What do you think about deleting the wp-content directory inside the WordPress package automatically on install/update? It ships all the default themes and they are not directly under update control. So they might have potential security issues and I'm not sure whether they get updated on minor core updates.

Env class contain the list of WordPress variables to casted to interger or boolean.

WP_POST_REVISIONS is the only one that accepts both integers and boolean values.

However, due to a bug in Env class, currently it is always casted to a boolean.

There's the option to set platform requirements for Composer. As those are skippable, they do no harm, but might show a user how to set up an OS that is capable of delivering the full feature set that WordPress has under its hood.

Analysis of the packages that WP is able to use in core:

        Extension  Matches REF        EXT min/Max PHP min/Max     PHP all
        -----------------------------------------------------------------
        Core               Core                   4.0.0           5.3.0      
*       PDO                PDO        5.1.0       5.1.0                      
        Reflection         Reflection 5.0.0       5.0.0                      
        SimpleXML          SimpleXML  5.0.0       5.0.0           5.0.1      
     C  com_dotnet         user                   4.0.0                      
*       ctype              ctype      4.0.4       4.0.4                      
*       curl               curl       4.0.2       4.0.2           4.0.4      
        date               date       4.0.0       4.0.0           5.2.0      
*       dom                dom        5.0.0       5.0.0                      
°      ereg               ereg       4.0.0       4.0.0                      
*       exif               exif       4.2.0       4.2.0                      
~       fileinfo           fileinfo   1.0.5-dev   5.3.0                      
        filter             filter     0.9.4       4.0.0           5.0.0      
~    C  ftp                ftp        4.0.0       4.0.0           5.0.0      
*    C  gd                 gd         4.0.0       4.0.0           4.3.2      
*       gettext            gettext    4.0.0       4.0.0                      
        hash               hash       1.1         4.0.0           5.6.0beta1 
*       iconv              iconv      4.0.5       4.0.5           5.0.0      
*    C  imagick            user                   4.0.0           5.1.3      
*       intl               intl       2.0.0b1     5.2.4           5.4.0RC3   
*       json               json       5.3.0       5.3.0           5.5.0      
     C  libsodium          user                   4.0.0                      
*       libxml             libxml     5.2.11      5.2.11                     
        mbstring           mbstring   4.0.6       4.0.6           5.0.0      
*    C  mcrypt             user                   4.0.0                      
*       memcache           memcache   0.2         4.3.3                      
*    C  mysql              user                   4.0.0           5.2.3      
*    C  mysqli             user                   4.0.0           5.0.0      
*    C  openssl            user                   4.0.0           5.3.0      
     C  pcre               pcre       4.0.0       4.0.0           5.2.4      
*       posix              posix      4.0.0       4.0.0                      
*    C  sockets            user                   4.0.0           4.3.0      
        spl                spl        5.1.2       5.1.2           5.2.0      
*    C  ssh2               user                   4.0.0                      
        standard           standard   4.0.0       4.0.0 => 5.6.16 5.4.0      
        tokenizer          tokenizer  4.2.0       4.2.0                      
     C  xdiff              user                   4.0.0                      
*    C  xml                xml        4.0.0       4.0.0           4.0.5      
*    C  xmlreader          user                   4.0.0           5.0.0      
*       zip                zip        1.6.0       5.2.0                      
*    C  zlib               zlib       4.0.4       4.0.4           5.4.0
        -----------------------------------------------------------------
        Total [41]                                5.3.0 => 5.6.16 5.6.0beta1

During the Slack discussion with @Giuseppe-Mazzapica we found the following things that are worth documenting:

• Some libraries might be mandatory like gettext and intl for translations and locale information
• While some packages are bundled with PHP core, they might be needed to be set for running the configure process like enabling older MySQL drivers (PHP 5.4+ comes with mysqlnd while WP uses mysql, mysqli) or --enable-mbstring.

Examples

• ext-gd, ext-libjpeg-turbo, …
• lib-curl, lib-iconv, …

Could wp-config.example follow WPCS?

FORCE_SSL_LOGIN was deprecated in WP 4.0 in favour of FORCE_SSL_ADMIN. WPStarter contains both fields. Either the old one should be removed (new installs shouldn't even consider using it), or a note added to indicate that FORCE_SSL_ADMIN is the correct version to use.

When installing a website with WP Starter, WordPress folder can be confured by using wordpress-install-dir configuration in composer.json.

In the default configuration (as provided by documentation) we set that folder to public/wp.

That folder is then used to set ABSPATH WordPress constant in the loaded wp-config.php.

However, only relying on ABSPATH we have no clue about the "root" path of WP Starter (that is the path that contains the .env file).

Because it's true that with default configuration one can do dirname(dirname(ABSPATH)), but if the WordPress folder has been set to, for example, public/ that approach fails.

In my experience, is often useful to know to the root path of a website, because it is the place where one will commonly place different things that need to go outside standard WordPress folder.

The path is already recognized during installation process, so it's easy to put in the generated wp-config.php something that let us access the path from the rest of WordPress.

I think we have different options:

• define a constant: the most WordPressy way, it's easy, but do we want yet another global constant?
• set an environment variable, works well but it a bit "fragile": environemt variables can esily be overwritten. Moreover there's no namespace for env vars, so they are global by definition...
• write a function that return the path. Functions return value can't be overwitten, and it is also possible to namespace a function... however to do it we should place 2 namespaces in wp-config.php that is doable, but not very clean. And if we use the root namespace we have a global function instead of a global contsant... not much better.

For these reasons I would go with the WordPressy way, but open to hear different opinions.

In WP Starter docs and in pretty much all the documentation out there regarding usage of Composer + WordPress the wp-content folder is placed outside the WordPress root.

So the wp-content shipped with WordPress package is not used. WP Starter allows to:

• copy content from there to the actual wp-content folder
• register the themes path in there as additional theme root

There was discussion to also provide option to complete delete it (see #28).

So far, so good.

The problem is when someone want to use the wp-content folder shipped with WordPress as the actual wp-content folder, so install themes and plugins via Composer in it.

I don't really like this approach for different reason, to name one I dislike have packages inside other packages. However I found myself in the need to do it when migrating existing websites, that in great majority of the cases have wp-content inside WordPress folder.

There's a big issue with this, that is not really related to WP Starter, but in a broader way to Composer + WordPress.

Who develops plugin and themes for WP does not declare in them a dependency to WordPress package, for the reason that they can be installed with Composer in a website where Composer is not used to manage the entire website. In that case, declaring a dependency to WordPress package would mean to have a whole WordPress install inside plugin vendor folder...

Since plugins and themes does not declare dependency to WordPress, Composer has no clue that they depends on WordPress, and it is very possible that all or some plugin are installed before WordPress.

The issue here is that if the target installation folder for a package is already there when the package is going to be installed, Composer empties the package folder, than start package installation.

So if plugins/themes are setup to be installed in /wp-content subfolder of WordPress package, all the plugin/themes that are installed by Composer before WordPres are lost when WordPress package is installed.

If to install a package inside another is not a good idea, do that for packages that are not dependent, as much as Composer is concerned, is a very bad idea.

I already experimented different ways to solve this problem:

• do not install WordPress as a Composer package but using a Composer script to download from zip
• do not install WordPress as a Composer package but using WP CLI
• a Composer script that install plugin/themes into a different folder a move them int WP folder when installation is finished

all of them worked, somehow, and I was able to solve the problem at end, but none of them was ideal, as the next time I have the same problem again I will need to either copy and paste what I have in another project.

I could create a Composer plugin that takes one of the approaches above and makes it generally usable, but I am not very keen to do that.

Another approach I have not tried yet, but I think could be the proper solution (if it will work :)) is to "live" inject WordPress dependency to themes / plugin packages.

That could be implemented as Composer plugin that:

1. look at all the packages that Composer is going to install, to see if there's one or more packages of wordpress-core type. If no WP core packages foind, the plugin would do nothing, otherwise go to step 2.
2. look at all the packages that Composer is going to install, to see if there's one or more packages of wordpress-plugin, wordpress-muplugin and wordpress-theme types. If yes, dependency to wordpress-core package(s) is injected "on the fly" to all of them. This way Composer will always install core package(s) before plugin and themes, solving the issue.

The plugin will hook pre install and pre update events to perform these tasks.

The main problem with this approach is that I have no idea if that is possible at all :D

I'll try to write this as soon as I find the time, but if someone want to do it before I do, that wold be great.

If this plugin comes to life and is proven to work, maybe there could be room to integrate it into johnpbloch/wordpress-core-installer

The Codex article gives a very specific code snippet under point 9. of how to go about letting the site know about the subfolder WordPress is installed in.

Hosting providers like SiteGround rely on this line of code to detect whether WordPress was installed in a subfolder, and modify their system setup accordingly (for things like version detection, caching extensions, etc...).

WPStarter has changed this line to use realpath instead of the code that is recommended in the Codex, which breaks detection on these hosts.

Is there a specific reason why this was changed to use realpath? I'd like to investigate whether we could leave that particular file exactly as is recommended in the Codex, and solve whatever issue realpath was meant to solve in a different location.

If the .gitignore already correctly ignores .env and /wp-config.php, then this orange notice should be hidden, and an - OK .gitignore ignores .env and wp-config.php added to the bullet list.

The following line throws a notice if the 'extra' key is not set in the composer.json file:
https://github.com/wecodemore/wpstarter/blob/master/wpstarter/src/MuLoader/MuLoader.php#L211

The isset( ... ) correctly checks whether the key exists, but if it doesn't, it gets used nevertheless.

Can you make the path in wp-cli.yml relative. The problem is that i can access the project under linux and windows and they have different path. With a relative path i can use wp-cli on both without adding the --dir paramter.
Example: path: ./public/wp

As requested by @GaryJones in #12 here:

Probably related here, but I see that Dotenv supports passing in a file name.

My situation is that I've got a /var/www that contains directories for different sites. If I want to store multiple .env files, one for each site, above the public roots, I'll obviously need different filenames. Being able to pass through the file name as the second arg in the $env = WCM\WPStarter\Helpers::settings(__DIR__); call would be handy.

In templates, the variables should look like in Bash: ${VARIABLE} – see PHP Dotenv and "Nesting Variables". There's a typo with all of them: {$VARIABLE}. Example. That should get fixed.

• Contribution guidelines
• Pull request template
• Issue template
• Agree on commit rules
• Agree on contributing guidelines

If I setup a new installation without having any plugin defined as dependency, I get the following warning:

Warning: opendir(/var/www/public/wp-content/plugins): failed to open dir: No such file or directory in /var/www/public/wp/wp-admin/includes/plugin.php on line 259

The problem is, that there's no plugin directory, of course. Not sure how this can be handled. Maybe a post install script checking for the existence of this directory and creates it if necessary.

As Twitter did just go wild on that, we should consider adding one additional mu-plugin to the setup (or recommend installing it):

<?php
/**
 * Plugin Name: Updates Disabled
 * Description: Disable all automatic updates (for themes and plugins)
 * Plugin Author: wecodemore
 */

add_filter( 'automatic_updater_disabled', '__return_true' );

add_filter( 'auto_update_plugin', '__return_false' );
add_filter( 'auto_update_theme', '__return_false' );

add_filter( 'auto_update_core', '__return_false' );
add_filter( 'allow_dev_auto_core_updates', '__return_false' );
add_filter( 'allow_major_auto_core_updates', '__return_false' );
add_filter( 'allow_minor_auto_core_updates', '__return_false' );

Not sure if we should throw in all options and add an explanation, or simply just close everything off.

For a new site, I cloned the client's Bitbucket repo that had the initial files for WPStarter, and got the site up and running. All fine.

When I tried WP CLI though, I kept coming across errors like this:

@schlessera's conclusion was that the DB prefix was not recognised when WP-CLI parsed the config. My .env (edited with nano on the server, but I can't spot any line-ending issues when opening on my Mac) contained:

DB_TABLE_PREFIX=wpcwr_

Changing it to:

DB_TABLE_PREFIX=wpcwr_

didn't help.

Alain's solution was to hard code the prefix in wp-config.php:

And this worked - WP CLI could run as per normal with no errors.

So, why couldn't the.env table prefix be recognised before it got to this part of wp-config.php?

Wonder if this is possible somehow at this moment? We'd like to place the .gitignore created by WP Starter, in another subfolder instead of the root level from where composer is run, e.g. inside <root>/public/

Is this something currently achievable trough extra settings in the composer.json file?

In case is not, could be implemented for a future WP Starter release? Thinking about:

{
    "extra" : {
        "wpstarter" : {
            "gitignore-path" : "./public",
            "prevent-overwrite" : [
                ".gitignore"
            ],
        }
    }
} 

There are many tickets for that in the WP Trac, the most important one is probably #31288. The basic problem is that get_stylesheet_directory_uri() and other internal URL functions return HTTP URLs behind a load balancer.

We should be very conversative here, because HTTP_X_FORWARDED_PROTO could be sent by the client: do not allow to disable HTTPS, just enable it if it matches that exact value.

I'd like to have push-to-deploy for one repository that had a composer.json that included WordPress itself along with my own custom-built themes and plugins. (more likely one theme + potentially several custom plugins) They would be themes/plugins that would have no purpose outside of our own application (at least for now) and the idea would be that we'll be probably changing the site/feel (so the theme) more than the repo itself, so whatever we are changing and pushing should be causing the site to rebuild... I think that means that the themes/plugins should be a part of the WordPress repo itself, otherwise pushing to the theme (as an independent package) won't result in redeploying the site itself.

Edited 16/03/15

• "gitignore" and "env-example" also accept path of files, not only urls
• "gitignore.common" is false by default
• "env-example" is false by default
• "content-move" is renamed to "move-content" and set to false by default
• "force-gitignore" has been removed
• "prevent-overwrite" now allows fine-grained control using $files array
• "register-theme-folder" has been added

Edited 08/03/15

• renamed "force-content-move" to "content-move"
• deleted "prevent-overwrite-hard" and added support for "hard" value in "prevent-overwrite"
• added support for "ask" value in "prevent-overwrite"

I have the idea to make possible to configure some aspects of the way WP Starter works thanks to composer.json extra settings.

I think all those configuration can be made available using a single wpstarter object as property of extra root object.

{
    "extra" :
    {
       "wpstarter" : { }
    }
}

The configuration I plan to add are:

• "gitignore" with possible values:

  • true: installation process doesn't ask any question and add default .gitignore file
  • false: installation process doesn't ask nor add .gitignore file
  • "ask": installation process asks if to add .gitignore file or not. Default behaviour.
  • $url: (string) should be the url or the path (relative to composer.json) of a .gitignore file. This file will be downloaded/copied and placed in project root folder
  • $gitinore (object) when used, no question is asked, possible properties are:
    • "common": (bool) common unrelevant files are added to .gitignore file when true. Default false
    • "wp-content": (bool) wp-content folder is added to .gitignore file when true. Default true
    • "vendor": (bool) vendor folder is added to .gitignore file when true. Default true
    • "wp": (bool) WordPress package folder is added to .gitignore file when true. Default true
    • "custom": (array) additional entries to add to .gitignore file . Default empty array

• "env-example" with possible values:

  • true: installation process adds the default .env.example file
  • false: installation process doesn't add any .env.example file. Default behaviour.
  • "ask": installation process asks if add .env.example or not
  • $url (string): the url or the path (relative to composer.json) of a default .env.example file. This file will be downloaded and placed in project folder. This way is easy to have custom shared settings across projects

• "move-content" with possible values:

  • true: the wp-content folder contents are always moved from WP folder to project content folder, no question is asked during installation
  • false: the wp-content folder contents aren't moved and no question is asked during installation. Default behaviour.
  • "ask": installation process asks if to move contents or not

• "register-theme-folder" with possible values:

  • true: the WordPress package wp-content folder is registered as additional theme folder (see #2 ) Default behaviour.
  • false: the WordPress package wp-content folder is registered as additional theme folder.
  • "ask": installation process asks if to register WP wp-content folder as additional theme folder.

  Note that "register-theme-folder" and "move-content" are incompatible settings. To allow wp-content folder movement "move-content" must be set to true and "register-theme-folder" to false.

• "prevent-overwrite" with possible values:

  • true: if any of target file exists it is not overwritten, a notice is printed to console.
  • false: installation process doesn't care if target files already exist, just overwrite them (actually this is not default behavior for .gitignore file so it will be overwritten if "force-gitignore" is true)
  • "hard": if a wp-config.php file exists in project folder, installation process ends immedialy, just printing a notice
  • "ask": if a file exists in target folder, installation process asks to overwrite it
  • $files: (array) array of files that should not be overwritten if found. is possible to use jolly characters to define files, e.g. "*.php". The default settings is [ ".gitignore" ] it means .gitignore file by default is not overwritten if found.

• "verbosity" with possible values:

  • 0: no notice is printed by installation process. All questions just take default behavior if a specific setting is not set
  • 1: questions, warnings and errors are printed, all the rest (comments and informations) is skipped
  • 2: current and default behavior, everything is printed to console

Opinions?

I noticed .env is in the same directory as index.php Many hosting services by default will display .env, and .git/ and other files and directories you would normally expect to be hidden.

Some protection can be put in using .htaccess, but I'm wondering what other measures are taken, planned or recommended?

As mentioned by @Giuseppe-Mazzapica in #12 here, there's a newer version of PHP Dotenv available.

WPLANG has been deprecated since WP 4.0, which is four major releases ago. New installs with WPStarter shouldn't even consider using this, so I suggest it is removed.

WPStarter loads MU plugins in sub directories via the WCM\WPStarter\MuLoader\MuLoader that acts on the action muplugins_loaded. This leads to a problem when a mu plugin registers itself an action listener to muplugins_loaded. So instead of handling MU plugins on runtime, what about dealing with them on build-time?

WPStarter could add an additional step that crawls the MU plugin main files and places a file for each directly to the MU plugins directory. This file just contains the plugin header and includes the original mu-plugin file in its sub directory.

Here's an example:

The WPStarter project requires the package acme/acme-mu-plugin which is of type wordpress-muplugin. Composer installer moves the package to wp-content/mu-plugins/acme-mu-plugin/. Now WPStarter creates a wp-content/mu-plugins/acme-mu-plugin.php with the following content:

<?php

/**
 * Plugin Header parsed from acme-mu-plugin/acme-mu-plugin.php
 */

require_once "/absolute/path/to/wp-content/mu-plugins/acme-mu-plugin/acme-mu-plugin.php";

In line 65 of the src/MuLoader/PluginAsMuLoader.php file, the get_option() returns a single value in some circumstances.

This throws a warning in line 79 of the same file, because it expects an array in array_key_exists():

Warning: array_key_exists() expects parameter 2 to be array, string given in <site>/wp-content/vendor/wecodemore/wpstarter/wpstarter/src/MuLoader/PluginAsMuLoader.php on line 79

Hey,

get an error after answering the second question, resp. when the script actually runs ( i guess)

[ErrorException]       
  Undefined index: root 

Exception trace:
 () at /var/www/ck3x/content/vendor/wecodemore/wpstarter/src/Builder.php:330
 Composer\Util\ErrorHandler::handle() at /var/www/ck3x/content/vendor/wecodemore/wpstarter/src/Builder.php:330
 WCM\WPStarter\Builder->buildFile() at /var/www/ck3x/content/vendor/wecodemore/wpstarter/src/Builder.php:193
 WCM\WPStarter\Builder->buildGitIgnore() at /var/www/ck3x/content/vendor/wecodemore/wpstarter/src/Builder.php:91
 WCM\WPStarter\Builder->build() at /var/www/ck3x/content/vendor/wecodemore/wpstarter/src/Setup.php:100
 WCM\WPStarter\Setup->install() at /var/www/ck3x/content/vendor/wecodemore/wpstarter/src/Setup.php:41
 WCM\WPStarter\Setup::run() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:207
 Composer\EventDispatcher\EventDispatcher->executeEventPhpScript() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:175
 Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:121
 Composer\EventDispatcher\EventDispatcher->dispatchCommandEvent() at phar:///usr/local/bin/composer/src/Composer/Installer.php:336
 Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/InstallCommand.php:131
 Composer\Command\InstallCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:252
 Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:874
 Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:146
 Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:83
 Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:43
 require() at /usr/local/bin/composer:25

So, had not much time to come up with some useful code, commenting out that line did it for now.

Hi, it appears that the starter breaks if database is accessed without password, which is quite often for local development.

In Helpers::addHook() method, directly access global $wp_filter.

Considering the WP 4.7 changes in hooks handling (see https://make.wordpress.org/core/2016/09/08/wp_hook-next-generation-actions-and-filters/) we should give some care on this.

This is not anything urgent, because we touch the global variable before WordPress environment is loaded and any content of $wp_filter that is there when WP is loaded is converted to the new format by using WP_Hook::build_preinitialized_hooks().

However, since Helpers::addHook() is available for anyone to be used, we should make it fallback to core function when possible. Moreover, since 4.7 is also possible to load wp-includes/plugins.php early (before WordPress is loaded) and we should do that in Helpers::addHook() when possible, relying global $wp_filter only for older WP versions, when that is the only possible thing to do.

Now I'm using WP Starter in all my work and personal projects since about 1 year, everything works very well and I'm happy, but I feel there are things that we can improve in the next major version.

This issue is just for preliminary discussion, and include different topics, each topic will probably have own issue if we decide to go on with it.

PHP version

Currently we support PHP 5.3+. Even if that version is still very popular among WordPress users, there's no doubt that who use WP Starter is a developer, not just an user. A developer who knows about Composer and pretty advanced WordPress development. A developer who won't use a version of PHP less than PHP 5.5 these days. This is my feeling, at least.

"Content" Development

The most "natural" way to use WP Starter is to pull themes and plugins as Composer packages.

However, very often I found myself in the need to have some plugin or mu-plugins only for the website I'm working on. An example could be a MU plugin used to store configurations...

Considering that one hardly wants to create a package for that kind of things, there are, at least, 2 ways to do this.

• Create Gists, and set up a Composer repository for them. An example of doing this is even included in current WP Starter documentation. However this is not a very good approach, since it is hard keep in sync local with remote
• Include the package in the main repository, the one that contains the main composer.json.

This is valid for plugins, MU plugins and even for themes. When a package is developed just for the website and will never be used in any other place, it makes perfectly sense keep under the same repository of the website stack.

This has been discussed in #23

In my projects I'm currently using an approach where I have a content-dev folder, with plugins, themes and mu-plugins subfolders. On install / update all of these folders are symlinked in the related "wp-content" folder, so WordPress recognize them.

This way I can keep under version control plugin and themes without keep under version control the content folder, that contains 3rd party plugin and themes.

I found this approach works very well, and I think it worth to be more integrated in WP Starter.

WP Starter scripts

Using WP Starter I found myself writing custom Composer scripts for different purposes.

In those scripts I often find the need to access WP Starter configuration. I think that would be useful to add some sort of "WP Starter scripts", very similar to Composer scripts, but that accepts only PHP scripts and pass to them a WP Starter API object that makes access to WP Starter configuration and maybe some helpers.

Instead of relying on Composer events, we could use specific WP Starter events, e.g. before / after each WP Starter step, or just after WP starter completed installation.

Improve translations download

WordPress core translations have to be downloaded to languages folder inside content folder.
Same goes for plugins that use "language packs" and have their translations hosted in https://translate.wordpress.org/.

We should find a way to ease the process of getting these translations via Composer.

We can start by exploring https://wp-languages.github.io/

When I set "prevent-overwrite" to "ask" and run composer install, the post-install-cmd script doesn't run automatically.

I can fix this by setting the command to WCM\\WPStarter\\Setup::run instead of the runAsRoot, then the script does run for me.

The most "natural" way to use WP Starter is to pull themes and plugins as Composer packages.

However, very often I found myself in the need to have some plugin or mu-plugins only for the website I'm working on. An example could be a MU plugin used to store configurations...

Considering that one hardly wants to create a package for that kind of things, there are, at least, 2 ways to do this.

• Create Gists, and set up a Composer repository for them. An example of doing this is even included in current WP Starter documentation. However this is not a very good approach, since it is hard keep in sync local with remote
• Include the package in the main repository, the one that contains the main composer.json.

This is valid for plugins, MU plugins and even for themes. When a package is developed just for the website and will never be used in any other place, it makes perfectly sense keep under the same repository of the website stack.

This has been discussed in #23

In my projects I'm currently using an approach where I have a content-dev folder, with plugins, themes and mu-plugins subfolders. On install / update all of these folders are symlinked in the related "wp-content" folder, so WordPress recognize them.

This way I can keep under version control plugin and themes without keep under version control the content folder, that contains 3rd party plugin and themes.

I found this approach works very well, and I think it worth to be more integrated in WP Starter.

Using WP Starter I found myself writing custom Composer scripts for different purposes.

In those scripts I often find the need to access WP Starter configuration. I think that would be useful to introduce custom WP Starter "steps" (that may be added, or even replace, default "steps").

This means that we need a way to:

• enable/disable/replace default steps
• allow custom steps to be added
• provide a way to share WP Starter configuration among steps
• provide something that allow to manage the "order" of steps. Probably some sort of event-based system

1. WP_HOME, if manually set, is not imported.
   Seems to be fixed when added to the static $isString array in Env.php
2. If WP_HOME is not set (which currently is the default case), the script in wp-config.php around LINE 116 may fail under certain conditions when php runs as cgi.
   See this SO question, which links to filter_input() on php.net

So fixing 1. would at least help to avoid 2.

Currently there's the WCM\WPStarter\Env::load( $path ); method where the class itself extends the Dotenv class. Trying to import the WPTest XML, I get the following error

$ wp import wptest.xml --authors=create --path=/var/www/dev/public/wp
PHP Strict standards:  Declaration of WCM\WPStarter\Env::load() should be compatible with Dotenv::load($path, $file = '.env') in /var/www/dev/vendor/wecodemore/wpstarter/wpstarter/src/Env.php on line 23

We should use $file = '' as second argument.

With WP core inside /wp/, the admin URLs become prefixed with /wp/. While this could be changed to /app/or /admin/, is there a way to just hide it altogether? Perhaps include steps for .htaccess rewrite?

Currently we distribute a lot with the whole package. The export actually also contains /docs if I am not mistaken. Composer per default uses --prefer-dist (unless told to fetch from source) and therefore uses git archives. Now the size of an archive can be reduced by introducing a .gitattributes file and ignoring specific non-distribution files.

Edit: As I was just looking around, I found this mess in a GitHub repo. We can avoid that.

A recent commit adjusted a whole load of code, for the purposes of code standards, but there is no suggestion as to what the code standard to be followed is.

I'd suggest a phpcs.xml file in the root of the project, that allows for programatic testing (i.e, pre-commit hooks) of the standards, and an agreement on which standards should be used.

There's consensus among contributors here that we are going to raise min required version for PHP for version 3.

We still need to choose which version.

I will add comments to this issue an we can vote on the version, then make a decision.

Feel free to comment your vote...

Sometimes this error appear when using WP Starter:

Fatal error: Uncaught RuntimeException: DB_NAME, DB_USER, DB_PASSWORD environment variables are required.

As of now, this bug has been reproduced in Windows + Apache systems.

It has been reported by different users, however the bug is always very inconsistent: it just appear on "some" requests, even if nothing changed between not working and working requests.

@danielhuesken reported that the problem disappeared if immutable option in Loader was set to true and that the offending line is https://github.com/wecodemore/wpstarter/blob/master/wpstarter/src/Env/Loader.php#L34-L36.

If that is confirmed, means that the bug can be tracked down to $this->getEnvironmentVariable($name) (where $this is an instance of Dotenv\Loader) returning something not null, at the start of the request, but only "sometimes" and only in Windows + Apache systems.

I can confirm that restarting Apache immediately and always make bug disappear (when it is there).

Add Unit tests for the current version-3 branch.

As the composer.json will normally be located in the web root, the accompanying .env file will also be located there.

As this file contains all sorts of credentials, it would be preferable to pull it out of the web root (into its parent folder).

So I suggest adding this functionality to the Loader extension, and letting people opt-in to this behaviour through Composer extra information, to not introduce BC issues.

I will prepare a PR with how I would implement this, but any feedback is welcome.

Current version of WP Starter asks to move default wp-content directory from WordPress package folder to project content folder.

Reason is that way WordPress is ready-to use just immediately after is WP Starter finished its work, without having to require default themes in composer.json that are already shipped with WordPress package.

The downside of this is that composer update will update themes inside WP package folder, but not the moved themes.

Move again theme on update is surely possible, but there is a simpler and probably better solution.

WordPress allows the presence of more directories where to look for themes, in fact, theme directories can be added via register_theme_directory() function.

If we add that function to the generated wp-config.php we don't need to move themes and in case of update default themes will stay updated as well.

As a bonus, without moving themes we can remove a question from installation routine (less complexity) and speed of entire process increase as well.

We probably should raise main version of the package if this feature is implemented, because backward compatibility breaks.

Opinions?

I'm finding that I'm adding the .editorconfig file to each install of WPStarter (next to .env). Any chance of getting this added to the default?

# This file is for unifying the coding style for different editors and IDEs
# editorconfig.org

# WordPress Coding Standards
# http://make.wordpress.org/core/handbook/coding-standards/

root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true
indent_style = tab

[{.bowerrc,.jscsrc,.jshintrc,*.json,*.yml}]
indent_style = space
indent_size = 2

[*.txt]
end_of_line = crlf

[*.md]
trim_trailing_whitespace = false

The second block could also have an eslint selector too.

What do you think about creating a wp-cli.yml in the project root to specify the path to WP core. The content would just look like that:

path: <wordpress-install-dir>

It would allow to use WP-CLI from the same working directory as one would use composer from. Otherwise you have to change directory to the WP root or specify a parameter on each command.

Edit: The local copy of this file should then go to the .gitignore: wp-cli.local.yml