Multimusen.dk

Per's Multimedia Tutorials

Theme Review

Reflections on experiences in the theme_review group.

Methods: anthropology and reflective practise.

  • 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

  • Theme Review Platform

    Theme Review Platform
    Theme Review Platform
    • 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.

     

  • 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.

  • January Review Shinding

    In this shinding the gives a live demo of the phpcs (php code sniffer) and a discussion of several theme-check-tools.

  • Theme Reviewer (ex) “Live Stream”

    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.

  • 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

  • WordPress Beta Tester Plugin

    WP Beta Test
    WP Beta Test

    If you want to try the new version of WordPress the Beta Tester Plugin is a must. However, don’t run it on a production server! After all a tester isn’t stable.

Enable Notifications OK No thanks

We use cookies - more information

Multimusen.dk will set a few cookies from Doubleclick, Google and the Social Media plugins they ay set some cookies. Some of my pages use APIs - such as YouTube, LinkedIn, Google Fonts, Google Maps, Mapbox, Spotify, Jetpack, Twitter, Facebook &c.. Such plugins may set the odd cookie.

Close