Theme Review Virtual Environment

Virtualbox
Virtualbox: a virtual Mint running on Mint.

Setting up the recommended theme review environment in Virtual Box on Linux Mint. The hardest part was setting up the PHP code sniffer. WordPress reviewers use several plugins for theme reviews.

Do you want to publish a theme on WordPress? In that case a team of reviewers will check the theme for errors. The code must follow the WordPress standards and policies. If the theme doesn’t meet the standards the theme is rejected.

The theme review team recommended to test the themes on a virtual system. I installed Virtualbox via apt. Found and downloaded a Linux Mint .iso via Torrents.  Booted the system and installed Linux on the virtual disk. So far so good.

The LAMP server

Set up a LAMP server via the Ubuntu meta-package:

sudo apt-get install lamp-server^

An then WordPress was installed manually. Noproblemo here.

Set up WordPress as Reviewer

Testing is a major subject in WordPress. Several tools are recommended:

 

Codesniffer

Then the codesniffer was installed. My first experiments were more or less “trial and error”. If worked, but pretty it wasn’t (later I found Tom McFarlin’s excellent tutorial.).

This blog is a research tool. So I’m saving my fumblings with the code:

 2011 pear
 2013 sudo pear channel-update pear.php.net
 2014 pear upgrade-all
 2016 pear install wordpress
 2018 sudo apt-get install composer
 2019 composer create-project \
 wp-coding-standards/wpcs:dev-master --no-dev
 2020 phpcs --standard=WordPress wp-config.php
 2021 phpcs --config-set installed_paths wpcs
 2022 sudo phpcs --config-set installed_paths wpcs
 2023 phpcs -i
 2024 phpcs --standard=WordPress /foo/bar.php

Lo and behold: the sniffer worked. Via wildcards it’s possible to scan all files in the theme directory:

phpcs --standard=WordPress pathToTheme/*/*.php

The sniffer will print errors and warnings – and so the debugging process may begin. Here’s a sample:

Sniffing PHP errors
Sniffing PHP errors

Note the wildcard result. Several files are checked.  Errors and linenumbers are displayed. That’s a handy tool.

 

Avoid “Pig Latin”

In a package of test tools I found the pig latin. Don’t use that silly plug in. It will redesign your Dashboard and add all kinds of silly pig latin words all over the plugin.  Joke or not – it’s a complete waste of time.

Theme Testing Environment Ready

Now the virtual theme testing environment is up and running. If there are grave errors in the theme, no damage will come to the test pc.

The next step is a real life theme review.

Code Sniffer

Entered the theme review theme on make.wordpress.org. Today a lot of software was installed:

  • Virtualbox (for a linux sandbox for WordPress)
  • Installed the recommended bugtragging plugins in the sandbox.

Then I read the extensive documentation on coding standards, and the things a theme reviewer should look at.

The codesniffer gave some problems. The recipe found here worked.  The documentation in a zip-file on Slack missed many practical details. And so did the page on Github with the codesniffer code.

First phpcs was installed via apt-get. The next steps are contained in this shell history dump:

2010  phpcs --standard=WordPress wp-config.php
 2011  pear
 2012  phpcs --standard=WordPress wp-config.php
 2013  sudo pear channel-update pear.php.net
 2014  pear upgrade-all
 2015  phpcs --standard=WordPress wp-config.php
 2016  pear install wordpress
 2017  composer create-project wp-coding-standards/wpcs:dev-master --no-dev
 2018  sudo apt-get install composer
 2019  composer create-project wp-coding-standards/wpcs:dev-master --no-dev
 2020  phpcs --standard=WordPress wp-config.php
 2021  phpcs --config-set installed_paths wpcs
 2022  sudo phpcs --config-set installed_paths wpcs
 2023  phpcs -i
 2024  phpcs --standard=WordPress wp-config.php

Matt Mullenweg on the future of WordPress

Yesterday Matt Mullenweg wrote:

“There are three main focuses this year: the REST API, the editor, and the customizer.

For the REST API we’re going to work on getting first party wp-admin usage of the new endpoints, and hopefully replace all of the core places where we still use admin-ajax.

The editor will endeavour to create a new page and post building experience that makes writing rich posts effortless, and has “blocks” to make it easy what today might take shortcodes, custom HTML, or “mystery meat” embed discovery.

The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.” (Matt Mullenweg, 2017-01-04)