Twenty Fifteen - Genericons

Hey Guys

In view of this reported vulnerability regarding the TwentyFifteen theme, I went to update my Bedrock installations. Of course TwentyFifteen is pulled in when WP is composer installed and even though it’s not in use, its directory is still a valid URL.

Updating composer locally and then deploying has no update effect since the default theme directory is git ignored anyway. When the remote composer pulls in WP on a remote deploy, it doesn’t touch TwentyFifteen which it grabs from the composer cache.

So, unless there’s another solution, I think I’m left with manual intervention via SSH across multiple sites unless there’s a better way I haven’t considered.

It may be worth considering defining the WordPress package manually and using the no-content version:

To do that though, you’d have to disable the Register Theme Directory mu-plugin and manually update the composer.json for each installation. I’m also not sure whether the installer would work by including the zip file as a package. As a temporary measure I’ve wp-cli updated the themes although I know the next deploy will revert this.

I’m going to ponder the best way of stopping direct requests to any of the standard default themes installed at web/wp/wp-content/themes.

I’m considering opening an issue on the Bedrock repo about this. I’m thinking that in the same way that plugins should be installed via Composer, stock themes should as well, for reasons such as this. That would mean though either reverting back to creating our own WP composer repo that points to a zip file, or just hooking in after a composer install or update and deleting all folders in web/wp/wp-content/themes and plugins.

For my sites, I’m going to add a trellis post_build_command to delete the default wp themes after each composer install:

   - cmd: composer install --no-ansi --no-dev --no-interaction --no-progress --optimize-autoloader --no-scripts
+  - path: web/wp/wp-content/themes
+    cmd: /bin/sh -c 'rm -rf */'

We’ll see how that goes.