Anthropological field study II: experiences from the role as a theme-reviewer on make.wordpress.org

It’s the next logical step

To me the next logical step is to engage in themes. Since 2010 or so I have dabbled with themes. Testing themes is a challenge. Doing so will give valuable skills. That’s why I try out this role. The standards for WordPress themes are well defined. Working with review gives:

• Knowledge about WordPress coding standards.
• Experience with the role as reviewer and giving feedback to developers.
• Experience with code validation. Not just the good old W3 validation services. It’s codesniffing with automation tools, such as phpcs.

Here bash commands, such as grep, is a great help too. It’s relatively easy to find lines, styles, classes, get_header, and so on. Testing themes is more than:

phpcs --standard=WordPress /wp-content/themes/themeName

Knowing the role

I guess that anyone starting out in a new role is bound to make errors here and there. Trying to engage in the open source community isn’t easy at all. By now I see two classes of theme-reviewers:

• Theme reviewers: they determin whether a theme is mature for publication.
• When the theme is approved, it’s passed to key-theme-reviewers.
• They give the final judgement.

There are two layers of control here.

Enviromment

The theme reviewers meet on Slack.  Here they chat and help each others with day-to-day problems.

The themes are reviewed on Trac. Getting into the WordPress repositories is not easy at all. I saw one theme, that tried to get in for 5 months or so.

Impact on classes

This knowledge is valuable for the business academies. We need knowledge about the coding standards in the business. But we also have to be pragmatic.

I guess that sometimes it’s important to get the feeling of “IT WORKS!”. Validating the code according to the stern standards of professional WordPress developers would be a didactic suicide in the classroom.

At least I think that’s the case where I teach.

Our students should be able to code a child theme or a theme from scratch. You can say that they work with frontend.

Linux Mint

I use Linux Mint on Virtual Box as the theme-review platform. Doing a total review is somewhat time consuming. Even with codesniffers. I developed a template in markdown for the review, and went trough the list of theme requirements.

Here’s the list of requirements:

Required

• The recommended plugins for theme reviewing are installed on a localhost/wordpress/
• The PHP codesniffer is ready too

So basicly everything is ready in order to enter the phase of the anthropological field study:

The theme review quest.

 

Meeting with participants from the theme_review crew. The theme reviewers test whether submitted themes live up to the WordPress standards. If a new theme is accepted, it’s added to the WordPress repo. Then it’s available to millions of users.

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.

• See: The Theme Review Process.

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:

 

• Theme Check
• Debug Bar
• Log Deprecated Notices
• Monster Widget
• WordPress Beta Tester
• Regenerate Thumbnails

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:

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.