24 Hours On WordPress

The last 24 hours or more I have been on WordPress. A template part has been made. In the evening, and night I participated in WordPress Slack. Today the categories were organized in the entire site.

The Aquarelle template part

In Web Developer 258:50 pp. there’s a lovely tutorial on a watercolorlike animation for a web page. I just had to try it out. Here’s the result ( as allways it’s a rough draft, but it was fun to make it ). Functions.php needed a few additional scripts. The partial held the markup, and the javascript. Now the Aquarelle partial may be used on a costum page or similar.

The theme_review meeting

In the evening I participated in two Slack sessions. The first one was the theme review group. Nine or ten active developers participated during the one hour long session. A question was asked:

  • Should we allow iframes?

A heated debate followed. There were utterances, somewhat like:

“I hate iframes …”

More than often there was no argumentation at all, at least from a philosophical point of view. Hating a phenomena is a pathetic argument. Literally speaking! After a while I could see, that these theme reviewers had a point.

Who knows what kind of stuff such iframes link to?

The iframe is not allowed if you want to publish a WordPress theme on the WP repos. So the debate was perhaps just for the hell of it. In the end there was a referendum. Should WP whitelist some urls, like YouTube. The answer was no.

I entered the group because a point on the agenda was a mentor solution for new theme reviewers.

Training

An hour later or so the training group met. The climate was very cosy. The participants suggested new learning modules. Talked about the intended target group: not students but teachers.

I suggested a module on Coding Best Practises. And guess what. I became the first editor. One of the sysops made me editor on the spot. And so the module will come to life wery soon.

Later on one of the group officials helped med to activate an editor account. Now I can edit the text(s). And even look foreward to give some help here and there, if I can. I felt at home and among human beings. So training was a very good experience.

Working on a minimal viable theme

Minimum viable WordPress theme (petj-mvp)
Minimum viable WordPress theme (petj-mvp)

The concept “minimal viable production” is a common concept in agile projects. I’m working on a minimal viable WordPress theme. The rules are:

  • The theme must validate according to WordPress Standards.
  • The design is not important.

So it’s all about function then. You can follow the development of the theme here (petj-mvp).

The design is inspired by the first WordPress theme: Kubrick.

Theme Development Process

The theme development process
The theme development process (Do you want a bigger picture? Click on the image.)
Process notes:
How to make and debug a WordPress theme
Toolbox

Automation (Nodejs)

Nodejs is a must in rapid development. Here are some essential tools.

SASS

Much template work is tweaking the CSS. A stylesheet preprocessor is a nice-to-have. Here’s how to use SASS:

sass --watch input.scss:style.css
Bower

Bower is a nice package manager.  Install libraries, e.g.:

bower install jquery bootstrap jquery-ui --save

The libraries are saved in the bower_components directory. The –save option will save dependencies in bower.json. If you download a repo without dependencies, they’re installed in this way:

bower install

Yep, that’s it.

Bower is installed via npm (part of Nodejs):

npm install -g bower

Version Control

Github

Here’s a link to (my work-in-progress) theme:

Github is made for group work. Code may be forked into branches, and versions merged to a mutual production.

Projects will give the group a nice kanban for work organization. Users may rise Issues.

Ready for Upload

When all is ready you can upload the theme for review on WordPress. Delete whatever files and directories that you don’t need.

Hidden files and directories must be removed.

If you use minfied scripts and css a non-minified version should be available. The files in the WordPress theme pool should be in clear text.

Then you can try to upload the theme for review.

Challenge: Write a Theme

One thing is to review themes. Another is to get it through the needle’s eye. Here’s the quest.

  • Hack a theme that’ll meet all requirements and WordPress standards.
  • The aim of the theme is to teach how to write a theme.

In this way the theme will be usefull not only for me, but for anyone who wants to learn how to make a theme.

Development environment

The core-WordPress themes don’t use preprocessors and similar. They want a clear and easy to read code. The aim of the core themes is to teach the art of theming.

I’m working on a LAMP server. So the code and methods will be easy to follow for any *NIX user. But we should not forget Windows users. Here’s a challenge. I don’t use Windows any more.

Nodejs

However in the business rapid development is often used. My approach is to develop a theme with Nodejs tools, such as:

  • Bower (package manager)
  • Sass (CSS preprocessor)
  • Gulp (compiling, automatic test)
  • Github will play a major role for versioning.
WordPress standards

The theme is an attempt to follow WordPress coding standards. Theme review tools, such as debugger plugins and code sniffers will be used. So will the theme debugger plugin. And of course the debugging features in WordPress must be activated. Edit these lines in wp-config.php:

 // Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

// Disable display of errors and warnings 
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define( 'SCRIPT_DEBUG', true );
Brainstorm

Multimedia designers tend to love animations. I’ll make a theme with many creative features, such as:

  • Animated splash frontpage (demonstrate costum pages).
  • CSS and JavaScript libraries (demonstrate how to implement external scripts and libraries). Such as:
    • Jquery, Jquery-ui (styling GUI elements).
    • Bootstrap (responsive grid, and menu)
    • Tweenjs or perhaps Wagerfield’s cool Parallax library

Something along these lines. You know: floating goblins, fairies, and creatures out of norse legends of old. That kind of stuff.

The Role as WP Theme-reviewer

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

phpcs for WordPress

PHP Code sniffer is a code validator. In the tutorial: “Using PHP CodeSniffer With WordPress: Installing and Using the WordPress Rules” Tom McFarlin explains how to install the codesniffer with WordPress-specific sniffs.

Then Tom McFarlin gives a demo on a phpcs on the plugin Hello Dolly:


phpcs --standard=WordPress hello-dolly

I have installed the sniffer following the suggestions in McFarlin’s tutorial on a LAMP server with WordPress. So the tool’s in the box.

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.