Towards version 3

[gmazzap]

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/

[schlessera]

PHP version

I share your feeling about devs and 5.5, however I would nevertheless try to match the Composer requirement unless there's a substantial advantage to bumping it.

"Content" development

There's one other option that seems valid: https://github.com/blazersix/satispress
This allows you to have a "dev/testing" server where you install and test individual plugins, and then have Composer pull them from there for a deploy.

WP Starter scripts

Having each of the steps provide hooks would be great. So, the current wp-starter would be the default configuration, but each of the steps can be modified/overridden by custom scripts.

<far-fetched-idea> Also, I would love it if we could bring a WordPress install closer to mirroring a hexagonal architecture. A step in that direction would be to have wp-cli be tightly integrated, and wrap it with wp-starter code. This would allow one to get all sorts of information directly from the command-line. For stuff that wp-starter is not responsible, it would pass it on to wp-cli. Something like having a wp script be a Decorator around the wp-cli binary. This would automate fetching wp-cli configuration, and it would be aware of the stuff surrounding the WP install, for which the wp-cli has no clue. </far-fetched-idea>

Improve translations download

I'm not sure how custom-installer support for this is atm, but this can also easily be solved through a custom Composer plugin you can require.

[gmazzap]

Regarding languages probably its better just forget about it and suggest the usage https://wp-languages.github.io/.

Even if a custom installer could be done easily for core languages, with more and more plugins/themes shipping translation to translate.wordpress.org I think we need a simple way to download those translations.

Even if https://wp-languages.github.io workflow is not very straightforward, it probably does not worth to put effort into different solution since it works.

Yes, it's another possible failure point, but... we have what we have.

[kraftner]

Unfortunately https://wp-languages.github.io/ isn't complete. In contrast to http://wpackagist.org/ it doesn't mirror everything but just core and some selected themes and plugins. So this is at most a duct-tape solution. Don't really know what to do instead though. 😞

[gmazzap]

@kraftner yes... my mainly concern is core, which can be translated with https://wp-languages.github.io/. And at the moment is enough for me... I don't want this as a blocker for v3, we can always improve what we have later...

[franz-josef-kaiser]

Main question about l18n now is: Can we write & host a replacement by ourself?

[kraftner]

I've just created #44 so me don't mess up this issue.

[gmazzap]

This issue is too broad. I'm going to close it and open better focused issues.