Daniel Auener

New Side Project - Re:Do Workouts App. Plan, train and track your routines

Tue, 17 Mar 2026 07:40:05 GMT

I started training Shotokan karate about four years ago.

A big part of our training is simple bodyweight workouts. Our sensei comes up with great exercises, but, as in many dojos, there isn’t really a written program you can follow at home. So when I trained outside the dojo, I constantly ran into the same problems:

Which exercises did we do last week?
What should I train today?
What was that variation again?

I looked for an app to just write down exercises and run through them during training. But most fitness apps tried to coach me, motivate me, or sell me programs. Lots of perfect bodies, lots of promises, but not much help if you already know what you want to train.

So I built Re:Do. It’s basically a simple tool to:

add exercises (often just a title is enough)
plan workouts across the week
start a workout and follow it while training
track what you actually did

No muscles on the screen. No fitness industry nonsense. Just your exercises and your training.

I’d love to hear what you think, especially if you do bodyweight training, martial arts, or similar disciplines.

The WordPresser’s Guide to the Fediverse

Sat, 17 Dec 2022 15:55:15 GMT

“Far Out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the galaxy lies a small unregarded yellow sun.”
– Douglas Adams, The Hitchhikers Guide to the Galaxy

A little solar system, far away, insignificant and quite an odd place to be. That’s how one of my favorite books describes where we all live. I think, despite the current rise in users, Mastodon and the Fediverse still look that way to many people.

My impression is that this is true for a significant part of my favorite community as well. Chris Wiegman wrote a powerful text on why WordPress should embrace the Fediverse, so that is covered. I want to focus more on how to migrate and not the “why”.

For everyone in the WordPress community who is just one last step away from leaving the commercialized and in many ways poisoned corporate social networks behind. Here is my guide to finding our little WordPress place on Mastodon in this huge collection of instances, blogs and applications we call the Fediverse.

Find an Instance

Mastodon is a decentralized network of instances (running the free Mastodon software) independently hosted, driven and funded by individuals with a wide range of intentions, goals and approaches. Sound familiar? Precisely! Working with WordPress or within the WordPress community, you should feel right at home. The WordPress blogging community and the Mastodon tooting community share much of the same foundation.

Take the same approach for finding an instance as for finding a blog you follow and ask yourself:

What is the instance about?
Who is running it?
What are the moderation rules?
Who else is here?

WordPress Mastodon Instances

If you want to consume a lot of WordPress content and/or intend to post some WordPress stuff yourself, a WordPress-related instance might be a good choice. The chances of finding a like-minded community and meaningful discourse are good. I host the WordPress instance wptoots.social; you’re welcome to join, but there are some other good choices:

wpbuilds.social (currently 47 active users) – hosted by Nathan Wrigley (@nathan@wpbuilds.social) maker of the WP Builds Podcast
dewp.space (currently 30 active users) – seems like a good choice if you feel at home in the German WordPress community
wp-social.net (currently 33 active users) – hosted by a WordPress hosting service
wptoots.social (currently 46 active users) – hosted by me
fosstodon.org (currently 26k active users) – if your interests are more about free software in general and you want a bigger instance
phpc.social (currently 2.1k active users) – if you see things more from the PHP side

To make your decision, I recommend starting by looking at the local timeline of an instance, if available without registration. That tells you what instance members have been up to. It also shows what you can expect regarding topics, posting frequency and tone of conversation. Take a look at the profile directory of each instance as well. And, of course, read the rules on the about page.

Many instances have more detailed community guides as well. These are interesting to learn more about how moderation works and what the instance’s members expect from you. For wptoots.social you can find our guide at community.wptoots.social.

Moving to another instance

A few words about moving to another instance. Perhaps you started on a more general instance and want to move to a WordPress-specific one. There is a documented process for moving, which works quite well. Moving works as follows:

You keep your followers even on the new instance
You can export a list of people you follow and re-follow all of them easily from the new instance
Old posts stay on your old instance
After you have moved, the old account from your previous instance (don’t delete it) will redirect to the new account

All in all, I think you can move without risks, especially if you don’t have a very large account.

Find people to follow

You’ve chosen your Fediverse home! Now you have to find people to follow and build a following. That can be tricky, because of the decentralized nature of Mastodon. The search function on your instance is limited to the content your instance “knows” about. That basically means what you can find in the federated timeline, which includes:

Content and users on your instance
Users followed by people on your instance, and their posts. These are the accounts they are are following
Posts and users from relayed instances

So if you search for WordPress, be aware that the search doesn’t show every WordPress post from across the entire Fediverse.

The WordPress community on Mastodon

If you are looking for WordPress folks to follow, I’ve got just the right thing for you. I’m curating a list of WordPress community members on Mastodon. Everyone on the list has at least one community badge on profiles.wordpress.org.

I’m always looking for new list members. There is a description of how to get onto the list on the website. Sharing is appreciated.

Follow #Hashtags

Additionally, another good way of keeping track of specific topics is following hashtags. First search for a hashtag on your instance (e.g. #wordpress). Then, follow by clicking the small follow icon to the right, above the hashtag content.

Find posts from users on unconnected instances

Every now and then (actually more and more) someone shares a Mastodon post or user with me in a chat or something. The problem is that following that link directs me to the user’s instance (not my own). So boosting, following and liking don’t work directly, because I don’t have an account on that instance. However, clicking on the boost icon of a post shows the following dialog:

Now, you only have to copy the value in the “On a different server” input field and paste it to your instance’s (or app’s) search field. The same works for following a user. Now you will see the post or user via your instance and can follow, boost, like and answer.

Find bots to fill your timeline with interesting things

If you are like me and use your social timeline as a source of news, blog-posts etc, you might be interested in finding some bots that post relevant content. Bots can be a really great way to keep track of new content, but clearly they can be very annoying as well. On wptoots.social we run a WordPress bot, watching sources curated by the community on GitHub, which I think is a great addition to my timeline!

Engage with the community

Now, you know how to do things, you just have to start doing them! The first step should be to set up a nice profile. You know the drill from every other social platform. Try to make it unique and ensure it says something about you. Write a short, informative bio and use hashtags in it to show your topics.

A nice way to make a statement and catch the eye of potential followers is an emoji in your nickname (where the birdsite’s verification badge is). On WordPress-related servers you might have a WordPress icon available. Here is an example on my profile:

Above you see that you can even use emojis in your bio, where we have a really special treat on wptoots.social. For every existing badge on profiles.wordpress.org we have a corresponding emoji. So I can integrate the icons from my WordPress profile page (and only those) in my Mastodon bio and show everyone what I stand for:

If you’re looking for real verification (not a blue verification icon everyone can use), you might want to verify your blog or website, as you can see in my Mastodon profile above. There are quite a few manuals for doing that, and some plugins as well.

Join the WordPress Community on Mastodon and the Fediverse

Finishing our small journey through the Fediverse for WordPress folks, I can only say: Please join us, it’s incredibly fun. In one Mastodon month I have connected and talked with more WordPress people than in several birdsite years. Concluding with Douglas Adams, of course:

The chances of finding out what’s really going on in the universe are so remote, the only thing to do is hang the sense of it and keep yourself occupied.
– The Hitchhikers Guide to the Galaxy

10 Reasons a Mastodon Migration Makes Sense for the WordPress Community (and others)

Thu, 08 Dec 2022 22:12:16 GMT

Mastodon, a decentralized social media/microblogging platform, has become quite popular over the past weeks and months. There are many good reasons to consider a Mastodon migration, but for free software enthusiasts or WordPress lovers (like me), there are even more specific reasons to give Mastodon a try. I hope you find my reasons compelling, even if I’m biased because I run the WordPress-centered Mastodon instance wptoots.social.

1. You can choose a Mastodon instance relevant to the topics you are most interested in

Mastodon is decentralized and there are thousands of instances to choose from. So pick a home to start your Mastodon journey carefully! If you are specifically interested in WordPress, sign up on a WordPress-centered instance and become a part of its WordPress-centered community. You will instantly find people with the same interests!

Also take into account that little instances are more at risk of shutting down, while big instances can be hit by so many users that they might get slow at times. You can move your account, including followers, to another instance at any time (your posts will be left on the “old” instance, though).

2. The local timeline

On Mastodon you have three timelines. A home, local and federated timeline.

If you have chosen a Mastodon instance, related to a topic you’re interested in, the local timeline might be the most interesting for you. Here you only see posts from users of your instance and, at least for the WordPress instances, they are right on topic most of the time. The home and federated timelines are a broader look into what’s going on with the people you follow and the people users on your instance follow.

3. Instance rules let you post, share and discuss in a safe environment

Every instance has its own rules. Everyone signing up agrees to them, and anyone violating them gets suspended (if moderators do their job, which they do in almost every case). So unlike many other platforms, you know what you’re signing up for and what you can expect. If you want to discuss WordPress professionally, you’ll just have to find an instance with a matching set of rules.

There is an argument that instances, and users choosing instances, can contribute to even stronger discourse and opinion bubbles. I think it’s too early to say if that’s true. But my hope is that there is a big difference between actively and consciously picking a community – and being influenced by an algorithm that makes you believe the whole world thinks like you.

4. Your content is not monetized

Content you produce and thoughts that you share shouldn’t be monetized without your active approval and only with the methods you have agreed to. Period.

5. Your content is not ranked by an algorithm optimized for engagement

Engagement, likes, shares and clicks are the daily bread and butter of commercial social media platforms. Of course their algorithms are optimized to encourage engagement which often favors polarized opinions and heated discussions.

They are not optimized, though, to favor more complex professional thoughts, balanced argumentation or input that broadens your professional point of view. But that’s what we can get on Mastodon with our WordPress postings.

6. Mastodon is built, owned, funded and driven by its community

The Mastodon Community is running Mastodon. It’s actually amazing that that’s working, if you think about it. But there are other examples, aren’t there? The WordPress project comes to mind and all the other FOSS projects! It would seem like there is no better fit for the WordPress Community than a Community-driven social network …

7. Mastodon is Free Software

You can’t argue with that one, can you?

8. Mastodon can’t be bought

Another obvious one, but there is more to it. Even if Mastodon could be bought (and single instances surely can), every admin in the community decides independently when to upgrade. If you don’t like the direction Mastodon is taking, you can fork it and run your own version. There is great power in that: Nothing can be changed without the explicit approval of the community. Democracy by design. And guess which other community can’t be bought either? You guessed right.

9. Most communities on Mastodon are actually nice

That might be changing over time, but for now I think this is true: Big parts of the community are positive, inclusive, accepting and open. Most people migrating are tired of the vibe of the big commercial platforms and actively working toward more constructive behavior on their new platform. And who knows? Maybe community-driven social networks are just nicer!

10. Meaningful exchange seems to be the rule not the exception on Mastodon

That’s more of a personal experience over the last weeks on my own instance. Everything I put out there (especially the WordPress and/or community-relevant stuff) is followed by meaningful comments, some good discussions, cheering and sharing. I’ve really learned a lot and find the response from my social network on Mastodon to be quite uplifting and enlightening. I’ve never felt that on the birdsite, to be honest.

Start your Mastodon migration

Convinced? Here are some starting points for your Mastodon migration:

Find an instance! If you’re looking for the WordPress community you are welcome to wptoots.social. Or try one of the other WordPress instances (I know of) wpbuilds.social or wp-social.net. If you are not only into WordPress, a bigger instance like fosstodon.org might be the right thing for you.

Find your community! That is incredibly difficult in the beginning and motivated me to make a list. Everyone on it has at least one community badge on profiles.wordpress.org and has agreed to be listed.

Enjoy!

Share!

Mastodon WordPress Instance

Sat, 19 Nov 2022 06:36:40 GMT

While I’m at it, I thought a Mastodon WordPress instance for community members looking for a home on Mastodon would be cool.

https://wptoots.social

Mastodon as a decentralized social network seems like the perfect fit for a group as diverse and strong as the WordPress community. The instance should be able to handle a couple of hundred users, is actively maintained and has daily backups.

There is even a curated list of the WordPress Community on Mastodon.

And I promise: The instance will run indefinitely!

As a little extra you can add a WordPress badge in your nickname (like Twitter’s verified icon) and show the entire fediverse what you stand for.

I hope everyone out there who loves WordPress will share this and join! And follow me if you like:

@danielauener@wptoots.social

Mastodon Instance for Kalmar started

Sun, 13 Nov 2022 11:13:34 GMT

This might even become a reboot for this sleepy blog! I’ve started a new Mastodon instance for my hometown, Kalmar:

https://kalmar.social

Aside from the technical stuff, decentralization really sparked my interest and might be something to write about in the future!

Drop me a note if you have any insights, people to follow or texts to read.

Photo by Laurenz Heymann on Unsplash

WordPress REST API extensions for going headless WP

Tue, 14 May 2019 21:04:54 GMT

Current WordPress REST API extension list

Front-page endpoint
Menu endpoint
Taxonomy filter attribute
Integrating ACF meta fields
Integrating Yoast meta fields
Slug endpoint for posts and pages

If you want to have all the endpoints as a plugin, there is one in the plugin directory: WUXT Headless WordPress API Extensions

I love the WordPress REST API and am switching more and more from theme development to a headless WP approach, with a nice front-end framework. Right now I’m favoring Nuxt.js, which is built on Vue.js (check out wuxt, my very own dockerized nuxt/wp development environment).

To use WordPress’s full potential with the REST API I’ve collected and built a useful snippet library with WordPress REST API extensions. I’ll try to maintain the following list as development goes on. All of the following extensions can be embedded in the functions.php file. If you’re wondering about the wuxt_ prefix, I’ve got the code from my Wuxt project and the prefix is as good as any other.

Front-page extension

Everything starts with a nice front-page, but there is no obvious way to get the WordPress front-page via the REST API. To read the settings, you have to be authorized, which makes things unnecessarily complicated. So here is a custom endpoint for getting the front-page.

GET: /wp-json/wp/v2/front-page

<?php

/**
 * Adds a front-page endpoint for generell front-page settings in the
 * Front-end
 */
add_action( 'rest_api_init', 'wuxt_front_page_route' );


function wuxt_front_page_route() {
    register_rest_route( 'wp', '/v2/front-page', array(
        'methods'  => 'GET',
        'callback' => 'wuxt_get_front_page'
    ) );
}


function wuxt_get_front_page( $object ) {

    $request  = new WP_REST_Request( 'GET', '/wp/v2/posts' );

    $frontpage_id = get_option( 'page_on_front' );
    if ( $frontpage_id ) {
      $request  = new WP_REST_Request( 'GET', '/wp/v2/pages/' . $frontpage_id );
    }

    $response = rest_do_request( $request );
    if ($response->is_error()) {
        return new WP_Error( 'wuxt_request_error', __( 'Request Error' ), array( 'status' => 500 ) );
    }

    $embed = $object->get_param( '_embed' ) !== NULL;
    $data = rest_get_server()->response_to_data( $response, $embed );

    return $data;

}

?>

Right now, there is no way I know of for getting menus from the WordPress REST API. I’m not sure if it’s the most effective way, but here is my WordPress REST API custom endpoint for menus. It also registers a standard ‘main’ menu as default if no location is requested.

Note: Most of the work for this snippet is done by the menu-class of Michael Cox, you have to include it to get the endpoint to work.

GET: /wp-json/wp/v2/menu?location=<location>

<?php

/**
 * Adds a menu endpoint
 */
require_once('/path/to/Menu.php');

add_action('init', 'wuxt_register_menu');
add_action('rest_api_init', 'wuxt_route_menu');

function wuxt_register_menu()
{
    register_nav_menu('main', __('Main meny'));
}

function wuxt_route_menu()
{
    register_rest_route('wp', '/v2/menu', array(
        'methods' => 'GET',
        'callback' => 'wuxt_get_menu',
    ));
}

function wuxt_get_menu($params)
{
    $params = $params->get_params();
    $theme_locations = get_nav_menu_locations();

    if (!isset($params['location'])) {
        $params['location'] = 'main';
    }

    if ( ! isset( $theme_locations[$params['location']] ) ) {
        return new WP_Error( 'wuxt_menu_error', __( 'Menu location does not exist' ), array( 'status' => 404 ) );
    }

    $menu_obj = get_term( $theme_locations[$params['location']], 'nav_menu' );
    $menu_name = $menu_obj->name;
    $menu = new Menu( $menu_name );
    return $menu->getTree();
}

?>

Filtering Categories and taxonomies

When filtering taxonomies with a REST API request, you are stuck with OR-queries, because the category endpoint doesn’t give you the full complexity of a tax_query. That means you can get posts which are either in category A or B. The following adjustment doesn’t give you the full complexity either, but it lets you switch all tax_queries to an AND-relation, so that you can select posts which are both in category A and B.

GET: /wp-json/wp/v2/posts/?categories=1,2&and=true

<?php

  /**
   * Ads AND relation on rest category filter queries
   */
  add_action( 'pre_get_posts', 'wuxt_override_relation' );

  function wuxt_override_relation( $query ) {

    // bail early when not a rest request
  	if ( ! defined( 'REST_REQUEST' ) || ! REST_REQUEST ) {
  		return;
  	}

    // check if we want to force an "and" relation
    if ( ! isset( $_GET['and'] ) || !$_GET['and'] || 'false' === $_GET['and'] || !is_array( $tax_query = $query->get( 'tax_query' ) ) ) {
  		return;
  	}

    foreach ( $tax_query as $index => $tax ) {
      $tax_query[$index]['operator'] = 'AND';
    }

  	$query->set( 'tax_query', $tax_query );

  }

?>

Loading ACF Meta-fields

Integrating meta-fields from the Advanced-Custom-Fields plugin into the REST API responses can be done with this plugin. If you need a simpler solution (only integrating meta fields into post-objects, not writing them), or simply a bit more control, the following snippet can get you started. It sets all ACF-fields to show_in_rest, which lets them appear in the post-objects meta-section:

<?php

    /**
     * Register meta fields from ACF
     */
    add_action( 'init', 'wuxt_register_acf_meta' );

    function wuxt_register_acf_meta() {

        if( function_exists( 'acf_get_field_groups' ) ){
            $result = array();
            $acf_field_groups = acf_get_field_groups();
            foreach( $acf_field_groups as $acf_field_group) {
                foreach($acf_field_group['location'] as $group_locations) {
                    foreach($group_locations as $rule) {
                        foreach(acf_get_fields( $acf_field_group ) as $field) {
                            register_meta( 'post', $field['name'], array( 'show_in_rest' => true ) );
                        }
                    }

                }

            }
        }

    }

?>

SEO-Data

The register_meta trick is handy, even for other plugins. If you want to integrate data from our favorite SEO add-on, Yoast WordPress SEO, into the post objects, you can do it like that:

<?php

    /**
     * Register meta fields for WordPress SEO
     */
    add_action( 'init', 'wuxt_register_yoast_meta' );

    function wuxt_register_yoast_meta() {
      if(in_array('wordpress-seo/wp-seo.php', apply_filters('active_plugins', get_option('active_plugins')))){

          $allowed_yoast_keywords = array(
              '_yoast_wpseo_title',
              '_yoast_wpseo_bctitle',
              '_yoast_wpseo_metadesc',
              '_yoast_wpseo_focuskw',
              '_yoast_wpseo_meta-robots-noindex',
              '_yoast_wpseo_meta-robots-nofollow',
              '_yoast_wpseo_meta-robots-adv',
              '_yoast_wpseo_canonical',
              '_yoast_wpseo_redirect',
              '_yoast_wpseo_opengraph-description',
          );

          foreach( $allowed_yoast_keywords as $field) {
              register_meta( 'post', $field, array( 'show_in_rest' => true ) );
          }

      }
    }

?>

Building URLs

If you are building a front-end app on top of WordPress, you have to think about how to structure your URLs. WordPress has two default post-types (posts & pages) and the URLs do not distinguish which type you are requesting, so http://wp-site.expl/something might lead to a page or a post, dependent on the type of the object with the slug something.

That means that if you want to mirror that behaviour in your app, you have to do two requests for each URL, one searching pages, one searching posts. To make that one request, use the following.

GET: /wp-json/wp/v2/slug/<post-or-page-slug>

<?php

/**
 * Adds a slug endpoint for getting the page or post for a given slug
 */
add_action('rest_api_init', 'wuxt_slug_route');


function wuxt_slug_route()
{
    register_rest_route('wp', '/v2/slug/(?P<slug>\S+)', array(
        'methods'  => 'GET',
        'callback' => 'wuxt_get_slug'
    ));
}


function wuxt_get_slug($object)
{

    $slug = $object->get_param('slug');

    $request = new WP_REST_Request('GET', '/wp/v2/posts');
    $request->set_param('slug', $slug);

    $response = rest_do_request($request);

    if (!$response->data) {

        $request = new WP_REST_Request('GET', '/wp/v2/pages');
        $request->set_param('slug', $slug);

        $response = rest_do_request($request);
    }

    if (!$response->data) {
        return new WP_Error('wuxt_no_such_slug', __('Slug does not exist'), array('status' => 404));
    }

    $embed = $object->get_param('_embed') !== NULL;
    $data = rest_get_server()->response_to_data($response, $embed);

    return $data[0];
}

?>

More to come …

I hope you found some of the code above useful. Send me your extensions in the comments and I will happily integrate them!

WP-CLI inside Docker via Gulp

Sat, 11 May 2019 14:38:21 GMT

When I’m running WordPress inside a Docker container, I usually only mirror the wp-content directory from the container to the host. You shouldn’t change anything in the other WordPress directories anyway and you avoid many volume syncs. The problem with this approach is that you can’t run the wp-command from the host; you have to run WP-CLI inside Docker. That means logging in to the container, running the commands and logging out again. Assuming your container is called wp-container the following commands would do that:

  
docker exec -ti wp-container bash
wp plugin list
exit

It’s just a little inconvenience, but why not save some commands when we can?

I’m using Gulp as a task manager for most of my projects, and have added a task which forwards all commands to WP-CLI inside Docker. It even checks if the container is running and if WP-CLI is installed inside the container. If not, it will be automatically installed.

var gulp = require('gulp');
var spawn = require('child_process').spawn;

var checkContainers = function(names, done) {
  var exec = require('child_process').exec;
  exec('docker ps --format {{.Names}}', function(error, stdout, stderr) {
    done(names.map(function(name) {
      return stdout.split("\n").indexOf(name) >= 0;
    }).reduce(function(running, next) {
      return running && next;
    }, true));
  });
};

var checkWPCli = function(container, done) {
  var exec = require('child_process').exec;
  exec('docker exec ' + container + ' bash -c \'wp\'', function(error, stdout, stderr) {}).on('exit', function(code) {
    done(127 !== code);
  });
};

var installWPCli = function(container, done) {
  var exec = require('child_process').exec;
  exec('docker exec ' + container + ' bash -c \'apt-get update && apt-get install -y less && curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && chmod +x wp-cli.phar && mv wp-cli.phar /usr/local/bin/wp && wp --allow-root cli\'', function(error, stdout, stderr) {}).on('exit', function(code) {
    done(0 === code);
  });
};

var runWPCli = function(container, done) {
  var command = process.argv.slice(process.argv.indexOf('-c') + 1);

  if (!command.length) {
    console.log('ERROR: Provide a valid wp-cli command!');
    return done();
  }

  var exec = require('child_process').exec;
  exec('docker exec ' + container + ' bash -c \'wp --allow-root ' + command.join(' ') + '\'', function(error, stdout, stderr) {
    console.log(stdout);
  }).on('exit', function(code) {
    done();
  });
};

gulp.task( 'wp', function(done) {

  checkContainers(['wp-container'], function(containerRunning) {

    if (!containerRunning) {
      console.log('ERROR: wp-container container is not running. Try "docker-compose up -d"')
      return done();
    }

    checkWPCli('wp-container', function(wpCliRunning) {
      if (!wpCliRunning) {

        console.log('WARNING: wp cli not installed, trying auto install ...');

        installWPCli('wp-container', function(wpCliRunning) {

          console.log('SUCCESS: wp cli installed!');
          runWPCli('wp-container', done);

        });
      } else {

        runWPCli('wp-container', done);

      }
    });
  });

});

So, with that gulp task in place, you will be able to run the following commands and every other WP-CLI command as well:

gulp wp -c "plugin list"
gulp wp -c "plugin install advanced-custom-fields"

What do you think?

Is that too much hassle for running some wp-commands or would you use the gulp forward in your daily work? Let me know!

Nuxt.js + WordPress = WUXT

Wed, 08 May 2019 21:47:18 GMT

In the last couple of months I’ve worked a great deal with WordPress as a backend system, providing data to a JavaScript frontend via the REST API. As I couldn’t find a complete solution for my favorite frontend-framework, my “getting started” process always repeated the following steps

set up a WordPress development environment (docker)
integrate JavaScript frontend in the code
set up an environment for the frontend (docker)
make the two environments talk to each other (not always as easy as you think)
set up a simple JavaScript framework to query the WordPress API from the frontend

As that procedure eats up a whole lot of project hours, the time was right for an easier solution. So, together with my colleague Oliwer at Northosts and much appreciated input and testing from my friend Samuel, I started working on a WordPress/Nuxt.js hybrid development environment. Our goal was to provide a one-command-installation, which makes you ready to go in 5 minutes.

Now we are finally ready for our first release, so say hello to WUXT!

WUXT Components

WUXT combines a couple of components you almost certainly already know from other projects, adds some convenient new functionality and solves a handful of configuration problems. Here is a short overview of all components

Docker containers: To provide a consistent development experience on all platforms, we use Docker (what else?). Three containers are needed, one for the WordPress database (mysql.wuxt), one for WordPress (wp.wuxt) and one for nuxt.js (front.wuxt). Everything is set up with docker-compose. We were extra careful to base everything on the official images (mysql, wordpress and node) and skip custom docker-files, which should make it a lot easier to upgrade the environment. The relevant files from the container are mirrored to the host with volumes, which makes the database persistent (_db folder), lets you access everything important in WordPress (wp-content directory) and nuxt.js (nuxt folder).

WordPress REST API extensions: The WordPress API is awesome, but to use WordPress’s full potential in our nuxt.js frontend, we needed some additional functionality. Activating our WUXT-theme adds endpoints for menus, the front-page settings, getting pages and posts by slug and includes meta-data from well known plugins. We are constantly adding new endpoints to support even more use-cases.

WordPress connector in nuxt.js: It’s not difficult to set up some requests to the WordPress API from nuxt.js, but we wanted a standardized way. That’s why we included the wpapi node module into our nuxt application (you always have access via the $wp object). Here, too, we made some adjustments, to make sure the connection to the WordPress REST API can be established both from the nuxt-container to the wp-container and from the client application to the wp-container. Of course, we also added some shortcuts to support our new endpoints for menus, front-page, custom post types etc.

Development tools: Docker is so great, but sometimes it makes developers’ lives a little bit more difficult. Logging in to the container to run a WP-CLI command can be a hassle, file permissions when working with volumes might be another. To make that a little easier we added gulp tasks to give you access to WP-CLI or let you install new node-modules inside the container, without accessing it. We even provide a post-type generator for gulp, which lets you create automatically loaded, API-ready post-types in seconds.

None of the above is rocket-science, but I think the combination and packaging into one, complete environment should make a difference for everyone developing with WordPress and nuxt.js. Please try it out and give us feedback, issues or some of your spare-time to make WUXT better.

Getting started

First clone the repository to a directory you want, then change to that directory and simply start your containers (you need to have a running Docker installation of course):

docker-compose up -d

That starts the following containers:

MySQL (mysql.wuxt)
WordPress (wp.wuxt)
nuxt.js (front.wuxt)

Your containers are available at

Frontend: http://localhost:3000
Backend: http://localhost:3080, http://localhost:3080/wp-admin
Database: docker exec -ti mysql.wuxt bash

Set up WordPress

After starting the containers for the first time you have to do a standard WordPress installation at http://localhost:3080/install.php. Then log in to wp-admin and select the wuxt theme to activate all the API extensions. Additionally you might want to activate the ACF plugin to make your meta work easier. Last but not least you have to set the permalink structure to “Post Name” in the WordPress settings.

To check if everything is running, visit http://localhost:3080 and verify that the WUXT info screen is showing.

Then check that the REST API at http://localhost:3080/wp-json is returning a JSON-object and you are good to go.

Set up nuxt.js

Nuxt should have been started automatically inside the docker container. The command we use for running the nuxt.js server is yarn dev. Check if the frontend is running by opening http://localhost:3000. You should be greeted by the Wuxt intro-screen.

Finally check if BrowserSync is running, by making a minor change to the front-page. The change should directly be visible on the front-page as well.

Feedback

Please let us know what you think about WUXT, what you did with it and what you couldn’t do. Please clone, fork, open issues, comment or contribute, it’s much appreciated.

Activate Gutenberg block-editor on specific pages or posts, or Gutenberg migration the client-friendly way

Thu, 31 Jan 2019 23:08:01 GMT

Since WordPress 5.0, the Gutenberg block-editor is here and it seems like curiosity about what you can do with it slowly surpasses the panic about what Gutenberg could do to all your beloved projects. To get the block-editor into one of your existing projects, there are some hurdles to overcome:

getting to know Gutenberg’s editing experience
building at least one block-ready template
deactivating the Classic Editor (not really a hurdle)
and … convincing your client

Say you tackled all these problems and your Gutenberg migration project is good to go: how do you start?

Step by Step: Gutenberg for specific posts or pages

In my (very humble) experience of one finished and one ongoing block-editor migration project, if you can’t start from scratch, you should do it step by step, post by post and page by page. First group your posts and pages by special features and make a plan about how you can build them in Gutenberg. Which blocks do you need, can you apply your own color scheme, what about forms, custom fields and short-codes etc.

With that plan in place, you can now get to one pilot post and start to shape it in the Gutenberg-way. At the same time you don’t want to interfere with your client’s possible changes to other posts and you want to give them the chance to get to know the block-editor in a limited playground. So now you have to do some coding.

Deactivate Gutenberg everywhere. I know, you just activated it. But remember, you basically want to preserve the classic experience on the entire site, so that has to be the default. This time, we don’t use the plugin, though. We use this line of code in the functions.php file:
```
   
  
// Disable Gutenberg for all posts
add_filter('use_block_editor_for_post', '__return_false', 5);
  
```

Next step is to activate the Gutenberg block-editor for specific posts and pages. I think the best way is to use a special meta field, which I called use_gutenberg. If that field is true, you just activate the Gutenberg block-editor with the appropriate filter (use_block_editor_for_post).

 
  
function theme_enable_gutenberg_post_meta($can_edit, $post) {

	if (empty($post->ID)) return $can_edit;

	if (get_post_meta($post->ID, 'use_gutenberg', true)) return true;

	return $can_edit;

}
add_filter('use_block_editor_for_post', 'theme_enable_gutenberg_post_meta', 10, 2);

If you add the meta-field with ACF, like I did, it might look like this:

Now you can transfer the group of pages and finally the entire site to Gutenberg in a very controlled and fail-safe way. Your clients will thank you!

If you have thoughts about Gutenberg migrations or experience with adding the block editor to existing sites, please let me know in the comments.

WordPress-blogging, always a step ahead

Thu, 31 Jan 2019 20:25:00 GMT

Today it’s my special honor to introduce a new WordPress-blog of a friend of mine: wpahead.com. Its main focus is WP front-end building and I know there is a ton of expertise behind these well-written tips, articles and tutorials.

I’ve got a lot of great ideas from the tutorial about building Gutenberg-blocks with the new Advanced Custom Fields beta-version, and I’ll use that setup in many of my future projects.

Good luck to our new star in the WordPress blogging community!

My Talk about Elasticsearch and WordPress at WordCamp Stockholm 2017

Sat, 25 Nov 2017 13:36:31 GMT

A few days ago I proudly gave my first WordCamp talk about Elasticsearch and how to integrate it into WordPress. It’s in Swedish (with a slightly embarrassing German accent) and I think it’s worth listening to. Here is the video:

For those of you who don’t understand Swedish, there are some code-slides about ElasticPress features and integration of WP-Query. Check out all slides here.

Thanks to my very supportive “hejarklack” from Wilson Creative: @pixelcrook, @sofievingstedt, @wilsonrobin and Martin Carstedt. Many thanks also to Andreas Ek (@elseifab) for a much appreciated pep talk (Andreas gave a really interesting talk about MVC in WordPress as well!).

Last but not least, thanks to everyone who made this awesome WordCamp happen!

Slow WooCommerce with Many Products

Sun, 05 Mar 2017 20:33:10 GMT

WooCommerce is the most used webshop system in the world and it’s awesome! However, using WordPress as its application framework has some drawbacks. In particular, you might get a very slow WooCommerce with many products. When I point that out in client meetings, I inevitably get the same questions: How many products exactly result in a slow WooCommerce frontend/backend etc – and what can you do about it?

Despite all the knowledge I have about server architecture, clean theming and WordPress coding, that question isn’t so easy to answer. That’s why I set up my own little test app.

Recommendation: Many slow WooCommerce sites just don’t have the right type of hosting. A good WordPress/WooCommerce hosting service with great support and performance-optimizing technical add-ons like Redis and Elasticsearch is Kinsta. Read more about their WooCommerce hosting here.

Slow WooCommerce with Many Products – The Test Environment

I’ve done all of the following tests on my local computer. It’s a Dell XPS 13 with the following hardware:

Intel Core i7-7500U
8GB LPDDR3 1866MHz
256GB PCIe Solid State Drive

Operating System and services:

Ubuntu 14.04
Apache 2.4.7
MySQL 5.5.54
PHP 7.0.16

The WordPress installation I’m testing with is a clean install of:

WordPress 4.7.2
WooCommerce 2.6.14
Twenty Seventeen Theme

No other plugins or code adjustments.

Furthermore, I wrote a small npm application, which incrementally adds products to WooCommerce by using the API. After each insertion of data, the application pauses five seconds, to give garbage collection and MySQL a break and then performs some tests, like reading products from the WooCommerce API or requesting the “Shop”-page from the front-end, while measuring both request-time and the average of the MySQL cpu and memory usage.

The inserted products are simple WooCommerce products, with auto-generated lorem-ipsum titles, descriptions and a random price.

Check out the test application on GitHub, feedback and contributions very welcome:

https://github.com/danielauener/slow-woocommerce-tests

After cloning, go to the app folder and run

npm install

Then adjust the configuration parameters in index.js to your environment and run the application with a simple

npm start

After completing the test cycle, the test data is written to a benchmark csv file in the benchmark directory of the app directory.

What’s tested

There are three questions I wanted to answer.

Is WooCommerce really getting slower with many products and how much?
Is it WooCommerce slowing down the performance or is it actually WordPress, which is slow?
If we can confirm a slow WooCommerce with many products, why is that happening?

Besides these general questions, I was interested in two use-cases. The obvious one was request times for the WooCommerce front-end, because that’s impacting conversions and sales. The second one was the insertion speed of new products with a big database. That one is important, because most shops with around 10000 products and more, most likely have some kind of import process, which might add load to the entire server. Since we’re talking about imports, which can go on for hours, that’s quite relevant.

Slow WooCommerce performance with 50 000 Products?

In my first test I wanted to check a really huge product database, so I could get a full picture of what’s happening. After some tries and time calculations, I decided to run with 50 000 products, starting my test tool with the following environment variables (MySQL and WP configuration in the index.js file).


MYSQL_PID=4333 ITERATIONS=500 POST_INSERT_CHUNK=100 npm start

CPU and Meta Table

After a good night’s sleep, the test was finally through. What I could say from how my computer behaved during the test (noisy and warm), there had to be some CPU-usage, which you can see in the first image. The other two lines in the chart are the number of added posts in each step (confirming the test went as planned) and the size of the wp_postmeta-table.

As you can see, the size of the meta-table (yellow) is rising much faster than the size of the products-table (green), which we will discuss later. The CPU-usage seems to increase logarithmically, slowly approaching 100%.

Just to clarify: the CPU-usage is measured only when the requests are done, not during the insert product calls.

Requests

The next chart I’ve created, shows, how the CPU-usage affects the front-end request times. After every product insertion cycle, test requests were made to the shop-page, which is listing the first ten products and a single product page.

The overall development of the chart shows, that all the time, the single product page loading times are quite stable. The shop pages loading times increase directly from the beginning though. That’s what I would expect, because the shop-page queries the entire products table and needs to load meta data for at least ten products, while the single product page only needs to do that once.

Furthermore, we can see two quite obvious changes in the chart. Around 15 000 products (step 150) the CPU approaches 50%, and we get a bigger variation in the loading times. Nonetheless, the single product times seem to be quite stable, but the shop-page times clearly increase. The same happens again, when the CPU-usage passes 70%, around 35 000 products.

Insertion Speed

The time needed to add new products obviously increases with the number of products, which is expected. I didn’t expect such an increase, though. I would have thought, that you have to operate WooCommerce with many more products, to get from around 4 seconds per 100 products to much more than a minute.

For the last dip in insertion time around 45 000 products I have no explanation. It might be that some resources were freed on my computer, not really sure, though.

Slow WooCommerce performance with 10 000 Products?

To double-check the previous results, I ran the same tests with only 10 000 products. I both wanted to see, if the test with fewer products would lead to the same conclusions and decrease test-time for further runs. Before this new test, I restored the initial database, from before the other test, then ran the following command:


MYSQL_PID=4333 ITERATIONS=100 POST_INSERT_CHUNK=100 npm start

CPU

The CPU-usage is rising, even with 10 000 products. It goes up to about 30%, which matches the 10 000 product value of the previous test. Meta-table and product count behave as expected.

Requests

Even the requests show the same picture. The shop-page request time seems to rise in line with the CPU-usage, which was the same in the 50 000 test, below the 15 000 products mark. The single product page loads steadily between 100 and 150ms.

Insertion Speed

The same goes for insertion speed, which shows a similar picture as above.

What Causes a Slow WooCommerce with Many Products

Now, one of my questions was, what causes slow WooCommerce queries and if the problem actually is related to WooCommerce? From experience with prior projects, I knew the answer already and had a quite good idea what the reason was. However, it’s always nice to confirm your assumptions with data.

Big Meta Table = Long Loading Times

My experience was, that WooCommerce performance problems with many posts are mainly related to the size of the meta table. As we have seen above, the table is growing quite fast when you add more products. After adding 50 000 products, it contained around 650 000 rows. To test if the meta-table assumption was accurate, I added a function to my application, which removes all WooCommerce meta-fields after each product insertion cycle. The following command runs the 10 000 test with that addition.


MYSQL_PID=4333 ITERATIONS=500 POST_INSERT_CHUNK=100 npm start

CPU

The CPU-chart already shows, that the idea seems to be correct. Without the big meta-table, the CPU-usage is slightly increasing, but almost stable, compared to before.

Requests

The requests-chart gives us the same impression. The shop-page request time follows the usage values and is stable between 80 and 100 milliseconds.

Insertion Speed

Only the insertion speed is painting another picture. Here we have no performance advantage at all, removing the meta-fields. I’ve added the grey line of insertion times from the previous test and it actually is almost identical. That was surprise, I have to admit. I thought there would be at least some difference.

Conclusions

So, that was fun. But is there something we can do about it? Shouldn’t we use WooCommerce for more than 15 000 products?

Yes, you should use WooCommerce, even for many products. But with the knowledge we gathered here, we are able to make some decisions early on, when building a shop, which should help us along the road.

Some tips to avoid slow WooCommerce:

Check before you start building, how many products the shop will be selling, now and in the future.
Avoid more meta-fields than absolutely necessary, that includes meta-fields on other post-types as well.
As much as we love Advanced Custom Fields: for a big shop, you might want to skip on it. For every field you add to a product with ACF, you get 2 meta-fields in the database.
Think about an eventual import process very early and test it several times, while building the shop. You need to know how much time it will take.
Inform everyone about potentially long import sessions and the extra load on the servers they are causing.
Use a good caching-plugin, which takes load off your server and frees resources for other stuff.

Even if you do everything right, at some point all precautions won’t help. Then you have to think about expanding your infrastructure. There are some tools which can help, like Elasticsearch or Redis, and there are surely a hundred ways to code your way around WooCommerce limitations (e. g. two of my workarounds for the admin panel). And, last but not least, there is always the possibility of a bigger server or a more advanced architecture.

Redis with Node.js: Compress to Use Redis Memory Efficiently

Fri, 10 Feb 2017 13:00:47 GMT

In one of my bigger projects, we are using Redis with Node.js, as a buffer for large sets of monitoring data.

When we deployed that from a test-case, with just one data-sending instance to about 150 instances, Redis ran out of memory quite fast. Depending on versions, operating system and some other things, that leads to either a crash of the Redis node or a significant performance decrease.

Redis with Node.js, when zipping is appropriate

It is important to know that Redis’s storage capacity is limited by its server’s memory. Basically that’s what’s making Redis so fast. That’s what the Redis FAQ tells us:

Redis is an in-memory but persistent on disk database, so it represents a different trade off where very high write and read speed is achieved with the limitation of data sets that can’t be larger than memory. (Source Redis FAQ)

However, for large data sets, like ours, that leaves you with a difficult decision: Buy more expensive memory for your server or use CPU-power on your client to reduce the data-size by compressing. Which way is the right one for your specific setup, is something you have to sort out. First of all, a good starting point is this study about a similar problem:

On the other hand, it seems that when we have an application that uses Redis mostly for reading stuff from it, we might think about compressing the input data. However as I mentioned before – try not to overdo it and implement such a mechanism only when you really need it.

Now, did you make your decision? Read on if you want to know how to implement this with Node.js.

Compress Data for Redis with Node.js

The implementation is built on the following Node.js modules:

redis
zlib

Here is how you write zipped data to redis:

var zlib = require('zlib'),
  redis = require('redis'),
  client = redis.createClient();

client.on("error", function (err) {
  console.log("Error " + err);
});

var redisKey = 'add_your_key_here';
var redisValue = 'Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim   ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.';

zlib.deflate(redisValue, function (err, zippedValue) {

  if (err) {
    console.log('Error deflating!');
    return;
  }

  // you have to encode the binary zip-data to base64 to be able to read it
  // later
  client.set(redisKey, zippedValue.toString('base64'), function (err) {

    if (err) {
      console.log('Error saving to redis!');
      return;
    }

    console.log('Zipped value saved!');

  });
});

And that’s how you read it:

var zlib = require('zlib'),
  redis = require('redis'),
  client = redis.createClient();

client.on("error", function (err) {
  console.log("Error " + err);
});

var redisKey = 'add_your_key_here';

client.get(redisKey, function (err, zippedValue) {

  if (err) {
    console.log('Error reading from redis!');
    return;
  }

  // you have to decode the base64 binary zip-data to base64
  zlib.inflate(new Buffer(zippedValue, 'base64'), function (err, redisValue) {

    if (err) {
      console.log('Error inflating!');
      return;
    }

    console.log(redisValue);

  });
});

Be aware of the base64 encoding. That’s required so you are able to write and read binary zipped data in JavaScript. More information for example here.

ElasticPress & WooCommerce: Deactivate Product Search Fuzziness

Wed, 08 Feb 2017 20:57:04 GMT

I am a great fan of Elasticsearch, the ElasticPress plugin and the ElasticPress WooCommerce module. The other day, when I was working on a client’s WooCommerce shop, it was the first time I wasn’t satisfied with the quality of the search results, though.

After some digging with the Debug bar and its ElasticPress extension, I could narrow down the problem to a combination of many similar titles in our database and the Elasticsearch fuzziness parameter. Of course the fantastic folks at 10up provide a filter for that in their ElasticPress plugin.

So here is how to disable fuzziness in the search:

function themeslug_deactivate_ep_fuzziness( $fuzz ) {
    return 0;
}
add_filter( 'ep_fuzziness_arg', 'themeslug_deactivate_ep_fuzziness' );

Of course you can even raise the fuzziness with the same method. If you want to adjust fuzziness depending on other search parameters, the filter provides two more arguments, $search_fields and $args, which might help.

Recommendation: If you want to use WordPress with Elasticsearch, you can get both with Kinsta. Read more on how to speed up WordPress with their Elasticsearch solution on the Kinsta blog.

WooCommerce with Thousands of Products: Workarounds for Slow Admin Panel

Wed, 25 Jan 2017 09:41:12 GMT

It’s the WordPress plugin for webshops, without question. For a shop that is not running WooCommerce with thousands of products, it performs very well, too. However there are limitations and drawbacks running WooCommerce with many products. That’s mostly because it is built upon the WordPress database schema, which forces WooCommerce to save much data in the wp_postmeta table.

For a shop that is not running WooCommerce with thousands of products, it has a very nice performance, too.

In my current installation, WooCommerce creates 26 meta-fields for each product, so the product related meta-table rows would grow beyond a million for more than 38 461 products. Adding other theme and plugin related fields, you might cross that mark much earlier. Depending on your server architecture, such a big meta-table, can make some database queries really slow.

… product related meta-table rows would grow beyond a million for more than 38 461 products.

Running such a big shop should make you think about your server architecture. The odds are high that you can’t avoid an upgrade in the long run. However, sometimes a quick workaround is the only way to get things running again. Here are two quick and dirty fixes to make your admin panel faster, when running WooCommerce with thousands of products.

WooCommerce Status Dashboard

With WooCommerce activated, you see an admin dashboard widget, that sums up your WooCommerce status, with sales per month, most sold product, order status and stock status. As it turns out, the stock status queries are very slow, depending on the meta-table size. Here is how to turn them off in your functions.php file:

function themeslug_deactivate_stock_reports($from) {
 global $wpdb;
 return "FROM {$wpdb-&amp;amp;amp;gt;posts} as posts WHERE 1=0";
}
add_filter( 'woocommerce_report_low_in_stock_query_from', 'themeslug_deactivate_stock_reports' );
add_filter( 'woocommerce_report_out_of_stock_query_from', 'themeslug_deactivate_stock_reports' );

Note, that turning off these reports will result in 0-values in your dashboard!

Slow Edit WooCommerce Product for WordPress >= 4.4.0

Another effect of a big meta-table is the product edit page in wp-admin (it affects even the edit page of posts and pages). Since WordPress 4.4.0 an extra query is made to the meta-table, which might cause long loading times. And of course there is a hook to disable it. Place the following code in your functions.php file.


function themeslug_postmeta_form_keys() {
 return false;
}
add_filter('postmeta_form_keys', 'themeslug_postmeta_form_keys');

Be aware that this fix not only makes the edit page faster, it also turns off functionality in the meta-field box!

Other measures

There is much more you can do, to make WooCommerce with thousands of products faster, like optimizing your server architecture or using tools like Elasticsearch or Redis Cache. If you need to use the above workarounds, you always should consider some of these measures in the long run!

Yeah, finally loading Sidebars/Widgets with the WordPress REST API

Wed, 13 Jan 2016 09:00:30 GMT

Loading sidebars and widgets via the WordPress REST API is not supported yet, but if you need a quick workaround, the WP REST API Sidebars Plugin looks quite promising!

Manual reviews of handpicked WordPress themes

Thu, 05 Mar 2015 05:10:18 GMT

Starting today, I will be reviewing themes at bestthemesfor.com.

Coding workflows: why Grunt changes our way of working

Sun, 26 Jan 2014 00:55:29 GMT

A couple of months ago, I first heard about Grunt. I wasn’t that impressed. It seemed to be like a more advanced CodeKit, which was compiling my SASS and JS at the time. So I forgot about it, proving once again, that I’m just not an early bird :/ Of course the buzz got too big to ignore and now I am all into Grunt, Yeoman and even Gulp like everyone else.

Using Grunt for some time now, I’m beginning to realize that it not only improved my workflow, but changed it. So this article is not about learning Grunt, there already are some of them out there. It is about why I think Grunt, or more generally task managers like Grunt will really make a difference in how web developers do their work.

A platform-independent foundation

But first some basics. One of the most important things about Grunt is that it is based on node.js and really runs independently of the platform. Also with node.js comes its community, producing an impressive amount of functionality. All the node modules they are developing, from 100% javascripted ssh-clients to complete test frameworks, can be used with Grunt.

Then there is npm, the node.js package manager. It lets you easily define all dependencies on a per-project basis. If you have to use the compass mixin library in one project and want to use bourbon in another, one line in your projects packages.js and a npm install fixes it.

Last but not least the node.js world is all JavaScript. That is so important because all web developers, despite their back-end programming language preferences, know JavaScript. For a web developer there are basically no hurdles to getting started with Grunt.

All in all node.js is a stable, well used and tested development foundation, with a living community and a huge amount of functionality packed in modules ready to download. Everything you need for your development workflow is already there. Grunt just helps you to bundle it all together.

Coding workflows

So, why is this such a big change? Before Grunt I already had a workflow. Or a kind of workflow that stayed pretty much the same for every project I was working on, but not entirely the same. This workflow even had multiple phases, like development, testing, bug-fixing and deployment and every one of them had different tasks. To remember all these at the right time can be impossible sometimes. I don’t know how many times I’ve forgotten to merge and compress CSS for deployment or to do a last coding standards check.

Grunt is helping with these tasks, by just letting you write them down and executing them automatically when you need them. That’s what a task-manager should do. But Grunt, and that’s my point, is doing something more. It doesn’t only automate the tasks you have done before, it makes you build, rethink and structure them consciously. You have to think about what your workflow should look like in the beginning of a project and you have to refactor your workflow as the project evolves.

What I mean is: with Grunt we have begun to code our coding workflows. Just as we code our tests when we do unit testing. You might think that’s no big deal, nothing a couple of Bash scripts couldn’t solve. I agree, technically it is nothing revolutionary. Yet, I think Grunt will change a lot for web developers, because it is so well suited for sharing.

Sharing and evolving workflows

A Google search on gist “gruntfile.js” returns more than 5000 hits. So it seems that we are not just coding workflows with Grunt, we’ve even started to share them. I’m convinced that’s because of the facts about node.js I’ve named before and that every web developer is able to write some JavaScript tasks in no time. That is the good thing with coding workflows. We are so incredibly good at improving our code. We already have a huge community, doing nothing else than improving code all the time. So, now our workflows have become formalized code, we can improve them the same way. We can share them on GitHub, ask about them on Stack Overflow, discuss them in our blogs or compare them to others’ workflows.

So I think, over time, this will change a lot about how web developers work. That said, the perfect finish to this article seems to be my own gruntfile.js, defining my current WordPress theme workflow:

module.exports = function(grunt) {

	grunt.initConfig({

		pkg: grunt.file.readJSON('package.json'),

		// chech our JS
		jshint: {
			options: {
				"bitwise": true,
				"browser": true,
				"curly": true,
				"eqeqeq": true,
				"eqnull": true,
				"esnext": true,
				"immed": true,
				"jquery": true,
				"latedef": true,
				"newcap": true,
				"noarg": true,
				"node": true,
				"strict": false,
				"trailing": true,
				"undef": true,
				"globals": {
					"jQuery": true,
					"alert": true
				}
			},
			all: [
				'gruntfile.js',
				'../js/scripts.js'
			]
		},

		// concat and minify our JS
		uglify: {
			dist: {
				files: {
					'../js/scripts.min.js': [
						'../js/scripts.js'
					]
				}
			}
		},

		// compile your sass
		sass: {
			dev: {
				options: {
					style: 'expanded'
				},
				src: ['../scss/style.scss'],
				dest: '../style.css'
			},
			prod: {
				options: {
					style: 'compressed'
				},
				src: ['../scss/style.scss'],
				dest: '../style.css'
			},
			editorstyles: {
				options: {
					style: 'expanded'
				},
				src: ['../scss/wp-editor-style.scss'],
				dest: '../css/wp-editor-style.css'
			}
		},

		// watch for changes
		watch: {
			scss: {
				files: ['../scss/**/*.scss'],
				tasks: [
					'sass:dev',
					'sass:editorstyles',
					'notify:scss'
				]
			},
			js: {
				files: [
					'<%= jshintTag %>'
				],
				tasks: [
					'jshint',
					'uglify',
					'notify:js'
				]
			}
		},

		// check your php
		phpcs: {
			application: {
				dir: '../*.php'
			},
			options: {
				bin: '/usr/bin/phpcs'
			}
		},

		// notify cross-OS
		notify: {
			scss: {
				options: {
					title: 'Grunt, grunt!',
					message: 'SCSS is all gravy'
				}
			},
			js: {
				options: {
					title: 'Grunt, grunt!',
					message: 'JS is all good'
				}
			},
			dist: {
				options: {
					title: 'Grunt, grunt!',
					message: 'Theme ready for production'
				}
			}
		},

		clean: {
			dist: {
				src: ['../dist'],
				options: {
					force: true
				}
			}
		},

		copyto: {
			dist: {
				files: [
					{cwd: '../', src: ['**/*'], dest: '../dist/'}
				],
				options: {
					ignore: [
						'../dist{,/**/*}',
						'../doc{,/**/*}',
						'../grunt{,/**/*}',
						'../scss{,/**/*}'
					]
				}
			}
		}
	});

	// Load NPM's via matchdep
	require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks);

	// Development task
	grunt.registerTask('default', [
		'jshint',
		'uglify',
		'sass:dev',
		'sass:editorstyles'
	]);

	// Production task
	grunt.registerTask('dist', function() {
		grunt.task.run([
			'jshint',
			'uglify',
			'sass:prod',
			'sass:editorstyles',
			'clean:dist',
			'copyto:dist',
			'notify:dist'
		]);
	});
};

SASS color schemes with grunt

Thu, 16 Jan 2014 15:18:26 GMT

SASS/SCSS and Grunt are fantastic tools to organize and automate CSS development. With some easy adjustments you can even make Grunt compile your CSS for multiple color schemes.

Build your base SASS color scheme

The easiest way to prepare your files for auto-compiling SASS color schemes is to create a color variable for every color you want to change in your schemes. You should do that in a separate section of your code, so you can easily copy all color variables and create a new color scheme. The only thing you have to think of is to add the default-attribute to the variables, so they can be overridden. I usually end up with a section like that in my styles:


/*
 * Default colors
 */

$light: #fafaf9 !default;
$dark: #111111 !default;

$color-1: #ef4f47 !default;
$color-2: #75d9c6 !default;
$color-3: #ffe851 !default;

Preparing additional SASS color schemes

The next step is to create all color scheme files. Create a folder called schemes or something like that, and put a file with the name color-scheme-1.scss in it. This file should define your color variables again (without the default-attribute) and include all other styles after the variables.

/*
 * Color scheme 1
 */
$light: #efefef;
$dark: #222;

$color-1: red;
$color-2: green;
$color-3: blue;

@import "../style";

Now you can create as many SASS color scheme files as you want, just repeat this pattern in every scheme.

Automated SASS color scheme Grunt task

Finally, it’s time to set up your Grunt tasks. I assume you know how to compile SASS/SCSS via grunt, so the only thing to do is to add a sass-task for every scheme in your Grunt file:


sass: {
    dev: {
        src: 'scss/style.scss',
        dest: 'style.css'
    },
    'color-scheme-1': {
        src: 'scss/schemes/color-scheme-1.scss',
        dest: 'css/color-scheme-1.css'
    },
    'color-scheme-2': {
        src: 'scss/schemes/color-scheme-2.scss',
        dest: 'css/color-scheme-2.css'
    }
},

Now run

grunt sass:color-scheme-1

and you get a color-scheme-1.css file in your css-directory. If you include this file instead of your default style.css, you will get your layout in the scheme’s colors. Auto generate all schemes with

grunt sass

Yeoman WordPress theme generator - kickstart a grunting SCSS theme

Mon, 06 Jan 2014 08:08:18 GMT

This post describes a super simple and time-saving Yeoman workflow to build WordPress themes. To make this post work for you, you should have a basic understanding of nodejs, Node’s package manager npm, Yeoman workflows, Grunt and SASS/SCSS. Once you have everything up and running, you will create a Yeoman WordPress starter theme in no time. But it is not only a theme; it comes with a bunch of features:

A fully functional WordPress theme with a working grunt development environment.
The generated theme is tested against the Theme check and Theme Forest check plugins and runs without errors, warnings or recommendations, is visually tested with Testdata for the theme unit test, runs without errors or warnings in debug mode and follows the WordPress coding standards completely
A pre-filled HTML documentation

Getting started

Getting started with nodejs, npm and Yeoman is well described elsewhere, so instead of repeating all of it you will get some links that worked for me. To go on, you should have the current version of nodejs, npm and yeoman running. Then you can easily install our generator from the npm registry. Note that on some setups you will have to run this command with super-user permissions:

npm install -g generator-wp-theme

Now you have installed the generator you can generate your first starter theme. As you might want to test it in your WordPress development environment, you should go to a running WordPress installation’s themes directory and run:

yo wp-theme

That’s it! Just answer some simple questions in the terminal and the installation should run through without errors, installing the theme plus all needed local node modules.

Developing with the Yeoman WordPress theme

First of all the generated starter theme provides you with a solid base of WordPress theme templates, following among others WordPress theme directory and ThemeForest standard requirements. The functions.php file sets your theme up to support all required functions like a custom header and background. All should be ready to make your adjustments to build a perfect theme.

SASS/SCSS setup

The theme’s style.css file is compiled from a bunch of SCSS-files. To get a layout grid and some nice mixins the bourbon and neat libraries are built in. The SCSS-file names should be self-explanatory, however a short overview in inclusion order follows:

vendor/normalize: Includes the normalizing css.
vendor/bourbon/bourbon: Includes the great bourbon mixin library.
_base.scss: Defines the main colors of the themes and basic HTML-element styling.
_grid-settings.scss: Defines and includes the base setup for the themes grid. The default grid is bourbons neat.
_typography.scss: Defines all fonts, typography related mixins and HTML-element styles. Defines even some font-size variables.
_components.scss: Place the basic mixins and placeholders for the theme.
_wp-base.scss: Defines some basic WordPress classes, like sticky, alignleft or bypostauthor.
_header.scss: Contains the header styles.
_navigation.scss: Contains the navigation styles.
_content.scss: Contains the basic content styles for posts and pages.
_post-formats.scss: Extends the content styling with styling for multiple WordPress post formats.
_footer.scss: Contains the footer styles.

Grunt tasks

The generated Yeoman WordPress theme provides a working Grunt configuration. All Grunt related assets like the gruntfile.js and the package.js are placed in the grunt directory. The Yeoman generator has already set up Grunt for the theme and installed all node modules in grunt/node_modules. If you want to install manually, go to the grunt directory and run

npm install --save-dev

All Grunt tasks are called from the grunt directory. You can manage the following available tasks, by running these commands:

grunt: Is running the default task-list, which is the same as running grunt jshint, grunt uglify and grunt sass.
grunt jshint: Checks the JavaScript files and gives you some hints.
grunt uglify: Takes the JavaScript files and concatenates and minifies them into one file: js/scripts.min.js, which is included in the theme.
grunt sass:dev: Is compiling all the scss files to one expanded style.css in the theme’s root directory.
grunt sass:prod: Is compiling all the scss files to one compressed style.css in the theme’s root directory.
grunt watch: Watches the scss and js files for changes and runs the above tasks automatically, plus giving you a cross-OS desktop notice on success.
grunt dist: Runs grunt uglify and grunt sass:prod, takes all the production relevant theme files and places them in the dist directory under the theme’s root. Now the dist directory contains a production ready theme, which can be uploaded to a live server.
grunt phpcs: Requires PHP CodeSniffer with WordPress standard installed in the development environment.
Checks the theme’s PHP files against the WordPress coding standards.

Documentation

In case you want to upload your theme to some marketplace or theme directory, Yeoman WordPress theme generator even creates HTML documentation for you. The documentation is based on the Theme forrest documentation template It’s located in the doc directory and already covers some base information about your theme. You just have to complete it with your specific information and your theme is documented as well.

Now, make themes!

With the Yeoman WordPress theme generator (generator-wp-grunted-theme), you should get everything you need, to build great themes. Be welcome to let me know if you have done so, or even better if you want to add an important task, find a bug or have an improvement idea.

Use echo inside a PHP one-line if statement

Tue, 03 Dec 2013 11:55:41 GMT

I got some great answers on my latest Stack Overflow question on why echo doesn’t work inside a one-line if statement in PHP.

http://stackoverflow.com/questions/20346451/use-echo-inside-php-one-line-if-statement

WordPress history

Thu, 21 Nov 2013 19:59:37 GMT

Can’t wait to read the rest: great preview of an upcoming book about the history of WordPress.
http://wordpress.org/about/history/chapter3.pdf
#wordpress #history

Shaun Andrews on improving WordPress Widgets

Tue, 12 Nov 2013 10:58:16 GMT

Some great thoughts on improving WordPress Widgets. The admin-UI changes are totally convincing. I’d like to see some thoughts on how to solve the “How do I install widgets” problem. The comments, too, on widgets per post are absolutely worth reading.

http://www.shaunandrews.com/wordpress-widgets-initial-thoughts/

Great Grunt, goodbye CodeKit.

Thu, 07 Nov 2013 18:44:24 GMT

I’m into Grunt now. Goodbye, CodeKit. #grunt #codekit

WordPress register with email only, using Gravity Forms and User Registration add-on

Thu, 07 Nov 2013 18:33:01 GMT

<?php

/**
 * WordPress register with email only, make it possible to register with email 
 * as username in a multisite installation
 * @param  Array $result Result array of the wpmu_validate_user_signup-function
 * @return Array         Altered result array
 */
function custom_register_with_email($result) {

	if ( $result['user_name'] != '' && is_email( $result['user_name'] ) ) {

		unset( $result['errors']->errors['user_name'] );

	}

	return $result;
}
add_filter('wpmu_validate_user_signup','custom_register_with_email');

?>

The snippet’s story

A few days ago, I implemented a custom user registration with WordPress. I used Gravity Forms with the User Registration add-on, which worked fine when the user had to choose a username manually. But we also wanted a quick-registration option on the homepage, which we wanted to work with only one form-field asking for an email-address. So I built a Gravity Form with just an email field and added a User Registration with the email-field linked both as the required user’s email and username.

This works fine with a single install, but with a multi-site installation the wpmu_validate_user_signup-function is used and we got an “Only lowercase letters (a-z) and numbers are allowed.” error-message. The above filter fixes this issue by undoing this validation error and forcing WordPress to accept an email address as username.

Polyfill alternative with SASS

Mon, 21 Oct 2013 11:47:11 GMT

When polyfills just don’t feel right: automatically build your IE-fix CSS with SASS. http://t.co/cbnrMg5UDZ and http://t.co/KLpM1eNKtC #ie8 #css #sass

Build a fully customized WordPress login: Those annoying redirects

Thu, 17 Oct 2013 11:07:22 GMT

I’ve built quite a few custom login-forms in WordPress. There are, as always, a lot of ways to realize that, but nearly all the clients I worked with, had similar requirements: On the one hand they wanted to preserve the usual WordPress login-form to let administrators, editors and authors sign in to wp-admin. On the other hand they wanted another usergroup to sign in to their site via a fully customized WordPress login-screen, to download protected documents or whatever.

Customized WordPress login-form

Generally the problem is solved fairly easily, using the WordPress-API. You can print out a standard login-form by using wp_login_form wherever in your theme you want it. There is even a way to specify the page, the user should be redirected to after a successful login. Here is an example, redirecting you to the home page:

<?php
    wp_login_form( array(
        'redirect' => get_bloginfo('url'), 
        'form_id' => 'sign-in',
        'label_log_in' => __( 'Sign in' ),
    ) );
?>

If you need to adjust the HTML-output, you can build your own sign in form markup by saving a file named searchform.php in your theme folder. Then you are just a few stylesheet-rules away from your customized form, with working login.

Handling login-fails

The problems begin when you fail to log in, because writing in a wrong username and/or password doesn’t redirect you to your customized form, it redirects you to the wp-admin site. Since the signing-in user is not supposed to log in to wp-admin, this redirect doesn’t make any sense. But again we find a straightforward solution in the WordPress-API. Add these lines to your functions.php:

function custom_login_failed( $username ) {
    $referrer = $_SERVER['HTTP_REFERER'];

    if ( !empty($referrer) && !strstr($referrer,'wp-login') && !strstr($referrer,'wp-admin') ) {
	
        // redirect to your login page, you might want to add a parameter login_failed
        // to show an error message or something like that
        wp_redirect( ... );
	exit;
    }
}
add_action( 'wp_login_failed', 'custom_login_failed' );

You might think that’s all, but not so fast …

Handling empty logins

There is yet another way to get redirected to the wp-admin login form, and that is when you just don’t enter anything. Submit the form with an empty username and password field and you are on wp-admin again. That is because the wp_authenticate function, which handles redirection, ignores empty_username and empty_password as error codes and that is why our wp_login_failed action never fires. The solution is to change these error codes, if the user logs in from another site than wp-admin or wp-login.php. This is done by the following filter function (note the filter priority, which is important here).

function custom_authenticate( $user, $username, $password ) {

    if ( is_wp_error( $user ) && isset( $_SERVER[ 'HTTP_REFERER' ] ) && !strpos( $_SERVER[ 'HTTP_REFERER' ], 'wp-admin' ) && !strpos( $_SERVER[ 'HTTP_REFERER' ], 'wp-login.php' ) ) {
    	$referrer = $_SERVER[ 'HTTP_REFERER' ];
    	foreach ( $user->errors as $key => $error ) {
    		if ( in_array( $key, array( 'empty_password', 'empty_username') ) ) {
    			unset( $user->errors[ $key ] );
    			$user->errors[ 'custom_'.$key ] = $error;
    		}
    	}
    }

    return $user;
}
add_filter('authenticate','custom_authenticate', 31, 3);

Other ways?

I know of one alternative to the above code: Since wp_authenticate is a pluggable function, you could simply overwrite it. But you can only do this with a plugin, so you have to add a plugin to your site and activate it, which I think is a bit more hassle.

Is there another way you know of? Please let me know in the comments.

Problems we don't have?

Tue, 15 Oct 2013 19:35:34 GMT

Inspiring read on how much we should struggle to support outdated browsers. Favorite quote: “Problem 3: IE6 and 7 … what are you doing?”

» Stop solving problems you don’t yet have

New blog layout

Sun, 13 Oct 2013 14:15:11 GMT

My blog just got back from a trip in a flying DeLorean, and finally landed in 2013 – @pixelcrook, you are my hero. http://www.danielauener.com

WordPress pagination: Simple and reusable without a plugin

Wed, 22 May 2013 19:34:13 GMT

Pagination might be one of the most common UI patterns on the web. The concept of showing just a limited number of articles, posts or whatever and making the reader click through the rest, comes in quite a few variations. Google’s search results come to mind or more advanced infinite scroll solutions. Naturally, WordPress implements this concept and I have to admit that, for some time, I found it quite difficult to use, especially with custom queries.

As is so often the case, the difficulties weren’t caused by the API-implementation or documentation, but by my not reading it. So, after realizing that, there was nothing left to do but work it out and here is the solution I use in my starter-theme. It contains a file named pagination.php, with the following content.

<?php 
     
     global $paginated_query;
     global $wp_query;

     if ( !$paginated_query ):
     	$paginated_query = $wp_query;
     endif;

     if ( $paginated_query->max_num_pages > 1 ) : ?>
          <div class="pagination">
              if ( !$current_page = get_query_var('paged') ) :
                  $current_page = 1;
              endif;

              echo paginate_links(array(
                  'base' => get_pagenum_link(1) . '%_%',
                  'current' => $current_page,
                  'total' => $total    
              )); ?>
          </div><?php
     endif;

?>

The great thing is that the paginate_links function does all the page-logic for you, if you just provide it with a current page number and the total number of pages. So if you want to paginate your main loop, all you have to do is to include this file. Since we don’t define a $paginated_query, the parameters will be taken from the global $wp_query.

<?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
...
<?php endwhile; endif; ?>
<?php get_template_part("pagination); ?>

But it’s quite easy, even with a custom query. Here you have to define the $paginated_query variable, before including pagination.php and giving the paged param to the WP_Query-object, so the requested page can be queried.

<?php 
    $custom_query = new WP_Query( array(
        'post_type' => 'page',
        'posts_per_page' => 3,
        'paged' => ( !$current_page = get_query_var('paged') ) ? 1 : $current_page
    ) );
?>
<?php if ( $custom_query->have_posts() ) : while ( $custom_query->have_posts() ) : $custom_query->the_post(); ?>
...
<?php endwhile; endif; ?>
<?php 
    $paginated_query = $custom_query;
    get_template_part("pagination); 
?>

That’s how I do it, but I’m always interested in other solutions.

Please comment if you have a better or alternative solution!

Extend WP_Query with custom parameters

Thu, 02 May 2013 20:44:55 GMT

function check_custom_query_param( $query ) {
    if ( isset($query->query_vars['custom_param']) && $query->query_vars['custom_param']) {
        $query->custom_param = true;
    }
}
add_action( 'pre_get_posts', 'check_custom_query_param' );


function change_where_query( $where, &$wp_query ) {
    global $wpdb;	
    if ( property_exists ( $wp_query , 'custom_query' ) && $wp_query->custom_query ) {
    	// change the where query
    }
    return $where;
}
add_filter('posts_where', 'change_where_query', 10, 2);

The snippet’s story

A few weeks ago I wanted to pass a custom parameter to the WP_Query object to change the where-query if the param was true. The problem was that to extend WP_Query with a parameter, you have to circumvent the filtering of the query options. I solved this by hooking into the pre_get_posts action. There the custom parameter is still available and we can easily add it to the filtered query object.

Simply Related Posts 1.2: plugin update

Thu, 02 May 2013 20:17:24 GMT

Update: Simply Related Posts 1.3 comes with a Serbian translation! Thanks to Borisa Djuraskovic from http://www.webhostinghub.com!

I’ve just released Simply Related Posts 1.2, a new version of my Simply Related Posts plugin. Now it supports pages, attachment-pages and custom post-types, which makes it a lot more flexible. Additionally I’ve added a filter to the related post-title, so you can add thumbnails, excerpts or anything else you can think of.

Test Simply Related Posts 1.2 now, download it from the plugin directory.

As always, post your questions, feedback etc. here below in the comments section!

WordPress as a CMS - Ways of organizing your content to achieve multi-level navigation for static-page websites.

Sun, 07 Apr 2013 14:10:19 GMT

If you are using WordPress as a blog, organizing your content is quite straightforward. You categorize and tag your posts, create nav-menus, to link the most important categories, use archive or calendar widgets and order your posts by publishing date (which is the default). Using WordPress as a CMS for a common website and building the navigation, often requires a bit more structural planning. The thing is that there are multiple strategies, which might be right or wrong depending on your demands. In this article I want to present a list of the approaches I use.

Inbuilt and custom post types

But first some words about the standard post types built into WordPress. When I build a website with WordPress, I naturally use pages for all static content, but in the beginning I even tried to use the standard posts post type for all continuously updated content like news sections, upcoming events and so on.

However, after some time I realized that posts really only should be used for blog content and nothing else. All the other stuff should be implemented as a custom post type. There are two simple reasons: Your client might decide to integrate a blog with the website in the future and by that time the posts section is bloated with other content. Secondly, my experience is that custom post types for events or newsfeeds are just more usable and purposeful than the standard posts, especially when there is some extra functionality needed, like start/end-date for an event.

So, when you are implementing one of the following strategies, make sure that you choose your post types well.

One-level menu

The easiest variant of content structure is just a bunch of pages without any hierarchy. Typically you would create a menu, under Appearance->Menus in the admin interface, and add all relevant pages to it. Here is an example of how to embed a simple menu into a theme:

wp_nav_menu( array( 'theme_location' => 'main-menu' ) );

For many small businesses this content structure is appropriate. Often it is quite easy to determine the few sections of content the website’s user will be interested in, e.g. “General information”, “References” and “Contact information”. You will both get an easily navigated site and a very simple backend.

When not to use it: There aren’t any drawbacks. If the content structure stays as simple as described above, there will be no problems.

Multi-level menu

Now, not every website works with a simple structure and not every client is satisfied with only telling the stuff visitors want to know. Sometimes clients want their websites to present the whole company structure and in these cases you need a hierarchical navigation, perhaps with a dropdown menu.

The good thing is that there is support for multi-level menus in WordPress and implementing them, can be quite simple. In the back-end it is as easy as doing some drag&drop actions to create a hierarchical menu of your pages and the simplest way to implement it in your theme is just the same as with one-level menus. You might add a depth parameter, to limit the number of levels in your navigation.

wp_nav_menu( array(
    'theme_location' => 'main-menu',
    'depth' => 2
) );

This would print a nested list representing your hierarchical menu and with some suckerfish magic you make it a dropdown in minutes. You can even build a nested navigation where every page contains a submenu with pages on the same level, by printing the whole menu on every page and hiding the irrelevant portions of the menu with CSS.

But there are drawbacks. The big problem I see with multi-level menus is, that your menu doesn’t organize your content. Even if you have built a well structured menu, your pages section in the admin-interface isn’t organized at all, it’s just a very long list of pages. I see this as a real usability issue for our clients and there are only two (suboptimal) solutions I can see. The first is telling your client to use the search field, because the structure shown on the website is not represented in the pages section. The other is to hierarchically organize your pages the same way you did it with the menu and mirroring all changes in future, which could be a big amount of extra work.

When not to use it: If there are many pages and you don’t want your client to do the extra work of organizing both menus and pages. Or if you want to implement submenus/breadcrumbs without printing the irrelevant parts and hiding them with CSS.

Multi-level pages

If multi-level menus don’t work for you, you could abandon menus and only organize by page hierarchy. Compared to the really easy way you drag and drop menus, it is a somewhat clumsy method, to enter the editor of every page and choose a parent, but it works. Here is how to create a menu just from the page structure:

<ul>
    <?php
        wp_list_pages( array(
            'title_li' => null
        ) );
    ?>
</ul>

The advantage over menus is that you directly can access the page’s parents and children and thus know on which menu level you are operating with your page template. This makes it possible to build all kinds of custom navigation elements like submenus or breadcrumbs. Here is the code to print a submenu with links to pages on the same level as the current page.

<ul>
    <?php
        wp_list_pages( array(
            'title_li' => null,
            'child_of' => get_post( get_the_ID() )->post_parent
        ) );
    ?>
</ul>

One thing to remember is that you can’t add one page in multiple places like you can with menus, because you are generating the menu directly from the page hierarchy. In case you need, say a contact page, in two places on the menu you have to create two contact pages.

When not to use it: If your client doesn’t feel comfortable with the way you structure pages or you want to link pages in multiple places in your menu this approach isn’t the best.

Integrate categories with pages and menus

You can even use categories to organize your pages. You could use the built in categories, but I think it’s better to create your own taxonomy, mostly because of the reasons discussed above, why you shouldn’t use posts for something else than blogging. Here is some code to add a custom taxonomy to categorize pages, to include in the functions.php:

add_action( 'init', 'add_page_categories' );

function add_page_categories() {
   register_taxonomy(
      'page-category',
      'page',
      array(
         'label' => 'Page Category',
         'rewrite' => array( 'slug' => 'page_cat' ),
         'hierarchical' => true
      )
   );
}

Now you can select the categories for every page and add them to a (multi-level) menu. The advantage over simple multi-level menus is that the categories add some structure to the pages section, even if you don’t get the whole hierarchy. In my opinion the checkbox to select the category is slightly more usable than the child/parent selection lists, which are building the page hierarchy.

And there is another thing about this way of building a menu: you can list multiple pages under one menu-item, which is kind of sabotaging the static content thought. However, it can make sense in some situations, for example a contact page which is intended to list all employees and you add one page for everyone instead of listing them in one page’s content block.

When not to use it: If your client isn’t familiar with the WordPress UI it might be one more hurdle to learn not only page editing and building menus, but also using the category checkboxes.

One-level menu plus page-hierarchy

This last approach to multi-level navigation uses both menus and page hierarchy. The idea is to only use a menu for the first navigation level, so you can easily rearrange and fully control your main menu. Then, all the pages linked in your main menu are used as parents for subpages, so the multiple levels get implemented by the page hierarchy. The next two pieces of code show how to print the main navigation with the wp_nav_menu function and how to output a submenu by using wp_list_pages.

<!-- main-menu, only add parents -->
<?php
    wp_nav_menu( array(
        'theme_location' => 'main-menu',
        'depth' => 1
    ) );
?>
<!-- end main-menu -->
...
<!-- sub-menu -->
<ul>
    <?php
        wp_list_pages( array(
            'title_li' => null,
            'child_of' => get_post( get_the_ID() )->post_parent
        ) );
    ?>
</ul>
<!-- end sub-menu -->

I use this solution a lot because it solves a whole bunch of problems I discussed earlier in this article:

you get the flexibility of menus for your main navigation
you get the structural advantages of hierarchical pages
you don’t have to build the hierarchy two times
you can present a clean and logical structure to your clients

When not to use it: If you want to build a simple dropdown-menu and can be sure that there won’t be any more complicated navigation requirements, multi-level menus would be the better choice.

Bottom line

WordPress as a CMS has quite a few possibilities to organize your content and build a navigation. Of all approaches I’ve shown I think I would prefer the last one, main menu plus page hierarchy, in most cases where a multi-level navigation is needed. It uses both the strengths of menus and page hierarchy, is easy to implement with the WordPress API and extendable if new navigation functionality is needed. From a usability point of view it makes use of the WordPress UI in the most common and intuitive way.

Provide WordPress theme color schemes as a feature of your theme

Fri, 05 Apr 2013 20:15:12 GMT

WordPress themes are amazing and since WordPress 3.4 there is an inbuilt customizer to make individual changes as easy as possible. One commonly used feature of the customizer is changing the background color or other basic colors of the theme. That is really great, but I like to think that there are a lot of bloggers like me out there, without any talent regarding colors or design. For all of us, manual color customization tends to produce ugly blogs. So I think it would be great to have preconfigured WordPress theme color schemes.

My “Color Scheme every Theme” plugin is built to help us to customize the colors of our blogs. It makes it easy to extract the colors of every theme (if it is built with css) and to change them from the admin interface. So, if you want to ask one of your designer friends for help, he or she doesn’t have to go through hundreds of lines of css, it’s enough to change the extracted color scheme via the admin interface, no coding involved.

Embedding preconfigured color schemes in the themes you are selling

I think that’s a really nice feature, but I think even more important is the possibility to embed as many preconfigured color schemes as you want in a theme. So, if you are a theme developer, generate some perfectly matching color schemes before you upload your theme to a marketplace of your choice, make a light and dark variant, a greyscaled and colored one or a variant for all four seasons. Then, embed those in your theme and make it even more valuable for your customers.

Color Scheme every Theme 2.0: Plugin Update

Sun, 24 Mar 2013 10:18:17 GMT

Color Scheme every Theme 2.0 (read about v1.0 here) makes it even easier to create color schemes for WordPress themes.

Get version 2.0 on wordpress.org

After the release of version 1.0, some bug-fixing and the release of two minor versions I had got so much feedback that I thought it was time to implement the two feature requests most users suggested:

Editing color schemes directly in the admin interface, instead of having to add code in the functions.php
An option to make the css for all schemes available in the theme, to make it possible to change the scheme not only via the admin interface, but even on the front-end.

This resulted in a completely new options page, see a screenshot below:

Here you have the option to edit the scheme directly in the admin interface. Just click on a color and change it in the Change color input field, hit enter, pick the next color you want to change. Don’t forget to save the schemes when you are done.

If you want to use the Dynamic theme colors option and used version 1.0 of the plugin, you have to regenerate the schemes.

There is still the possibility to permanently add a scheme to your theme by copying it to the functions.php of that theme. If you want to do that, just create the new theme via the admin interface, save and click on the < embed in theme > link, which opens a textarea with the code you have to add in it.

WordPress color scheme plugin: Color Scheme every Theme

Mon, 25 Feb 2013 22:10:15 GMT

Download on wordpress.org: Color Scheme every Theme

WordPress 3.4 gave us a tool for theme customization, and I really like the idea. Changing the background color or adding a header image makes even the most downloaded theme on the internet unique. So I had this idea of not only changing the background color, but changing the whole color scheme of a theme and thus building for example a green, red and blue variant of a theme or a dark and a light version. A WordPress color scheme plugin, that would both be great for users, to adjust their downloaded themes, and for theme developers, to provide their themes with multiple color schemes.

Three simple steps to make your own color scheme

Generating the css – The first step, after installing and activating the plugin, is scanning your current theme for color-relevant css. Go to the plugin’s settings page under Settings -> Color scheme every theme and click the generate button. This will scan all the css files in your current theme for colors, generate code to overwrite the default colors and provide you with a color scheme template to add to your functions.php. After clicking the generate button you will see two textfields. The first with the color scheme template …
```
if ( function_exists( 'cset_add_color_scheme' ) ) {
	cset_add_color_scheme( 'scheme-name', array(
		'$color-1' =&gt; '#111111',
		'$color-2' =&gt; '#111111',
		'$color-3' =&gt; '#111111',
		'$color-4' =&gt; '#111111',
		'$color-5' =&gt; '#111111',
		'$color-6' =&gt; '#111111',
	) );
}
```
… and the second with the default colors, found in your theme.
```
/**
 * Default colors
 *
 * $color-1: #efefef;
 * $color-2: rgba(0,0,0,0.5);
 * $color-3: rgba(0,0,0,0);
 * $color-4: #fff;
 * $color-5: #000;
 * $color-6: #222;
 */
```
Adding a scheme to the functions.php – Now you only have to add one or more color schemes to your themes functions.php. Just copy and paste the first code-snippet and change the colors as you like. Allowed are all valid css color definitions, including rgb/rgba and hsl/hsla.
Choosing a scheme – It’s almost done, the last step is going to the customize section of your theme and choosing the color scheme. Click in the admin menu on Appearance -> Themes and then on the Customize link of the current theme.
Now you should see the schemes you created in the Color Schemes section, choose one and see a live preview to the right and save if you want to publish the new scheme.

Next development steps

This plugin is really not much more than a working prototype. I have some ideas, to make it really great.

Making the generator work for other themes than the currently activated (even parent/child themes).
Saving color schemes in the options, so there are no changes to the functions.php needed.
Generating random color schemes or automatically making the default scheme ‘warmer’ or ‘colder’.
Testing, bugfixing and discussing

Troubleshooting

If there is something not working, you are welcome to contact me via the comment section of this article or twitter. But check some things first, to make it easier for me to locate the problem:

Check if your WordPress version is 3.4 or higher and if your PHP version is 4.3.0 or higher.
To overwrite the color scheme of your theme, the plugin does save a file in the wp-content/uploads/ directory. So this directory must have write permissions set.
Set the WP_DEBUG constant in your wp-config.php file to true and see if there are any errors shown when you use the plugin.
Try to deactivate all other plugins. If the problem disappears I have to know which plugins you use, to help.
Give me as much information about your system as possible, when you contact me.

What do you think?

Of course I want to hear what your thoughts and experiences are. Is this plugin usable for you, would you like to see some features it doesn’t have at the moment or do you have some color schemes, you want to share? Please comment or contact me on twitter and let me know what you think!

WordPress custom image size crop: How to fix it

Wed, 30 Jan 2013 19:40:37 GMT

if (function_exists('add_image_size')) {
   add_image_size( 'dummy-1', 940, 450, true );
   add_image_size( 'dummy-2', 480, 0 );
}

global $_wp_additional_image_sizes;
foreach ( $_wp_additional_image_sizes as $name => $image_size ){
    update_option( $name."_size_w", $image_size['width'] );
    update_option( $name."_size_h", $image_size['height'] );
    update_option( $name."_crop", $image_size['crop'] );
}

add_filter( 'intermediate_image_sizes', 'regenerate_custom_image_sizes' );
function regenerate_custom_image_sizes( $sizes ){
    global $_wp_additional_image_sizes;
    foreach ( $_wp_additional_image_sizes as $name => $size ){
        $sizes[] = $name;
    }
    return $sizes;
}

WordPress custom image size crop: The snippet’s story

If you are using custom image sizes in your WordPress theme you likely know the problem. Cropping, rotating or flipping an image via the WordPress image editor works only on the original. After editing, the image is not available in your custom sizes anymore, all you get in your theme is the edited version in original size.

I thought that there has to be a simple solution to this problem, because it is pretty basic after all. But a quick Google search only turned up code that didn’t work. Finally I found some code on pastebin that pointed me in the right direction.

Copy and paste the above code into your functions.php, adjust the image sizes and even your cropped images should be available in your custom sizes.

HTML5 wp_nav_menu without using a list in WordPress

Wed, 30 Jan 2013 12:14:17 GMT

$menuParameters = array(
    'echo' => false,
    'items_wrap' => '<nav>%3$s</nav>',
);
echo strip_tags(wp_nav_menu( $menuParameters ), '<a><nav>' );

Result:

<nav>
    <a href="...">...</a>
    <a href="...">...</a>
    <a href="...">...</a>
</nav>

Source: Remove LI Elements From Output of wp_nav_menu

HTML5 wp_nav_menu: The snippet’s story

This is how you build HTML5 navigation without lists in WordPress. I slightly changed the code I found on CSS-Tricks. I had to post this after today’s reading of “Navigation in Lists: To Be or Not To Be” by Chris Coyier.

WordPress plugin best practices, my three golden Rules

Fri, 25 Jan 2013 09:19:33 GMT

“A man must have a code” – Bunk in The Wire

I recently uploaded my first plugin to the WordPress Plugin Directory, wrote some plugins at work and most importantly used a lot of the plugins out there. So I thought the time has come, to step back and think of what I’ve learned about plugin development and I came up with my personal WordPress plugin best practices, my three golden rules:

WordPress plugin best practices no. 1: Do not try to improve the UI

The first rule is simple, don’t touch the standard WordPress UI. There might be ways of doing things better, there might be nicer looking checkboxes and coloring up things would surely give the admin interface a friendlier touch. But, there are better ways to communicate your ideas than just making up new UI-styles in your plugin. I think one reason why WordPress is as big as it is, is consistent UI-design, don’t mess with it.

WordPress plugin best practices no. 2: Leave theme developers in control

Whatever your plugin is doing, it is probably affecting the current theme in some way. And that makes you the theme developer’s friend – or most hated enemy. Theme developers want to control all of their theme, HTML output, css-classes, javascripts, language and so on. They don’t want a plugin to inject uncontrollable bits of code into their theme.

So treat them as grown-ups and let them be responsible for their theme. Give them hooks, filters and functions to control the output, admin options to let them deactivate automatically enqueued scripts and styles, prepare for localization and anything else you can think of.

WordPress plugin best practices no. 3: A plugin does what it has to do, nothing more

Keep your plugin as simple as possible, do not bloat it with functionality just because you can. Every plugin adds complexity to the admin interface and every plugin has to get along with other plugins. Therefore “as simple as possible” even means fewer bugs, fewer confused users and less support.

Ask yourself questions like these: Does my nice little widget really need your own stats section or global settings? Are custom database tables really necessary? Am I using the plugin API as much as possible? Is there really no way around these custom database queries? And so on …

Keep these WordPress plugin best practices in mind when writing your next plugin and I’m sure it will be a success.

Simply Related Posts, a WordPress Widget Plugin to relate Posts by taxonomy the easy way

Tue, 15 Jan 2013 19:05:04 GMT

I know, there are a lot of widgets out there, to print related posts, but none of them I tested really suited my needs. First of all I think a widget shouldn’t have a whole bunch of global settings, rather no global settings at all, I mean, it’s just a widget. But, even if I don’t like a huge settings page, just to run a little widget, there has to be some flexibility to let me adjust every widget-instance to my needs.

The Simply Related Posts Widget

In the case of related posts I couldn’t find a widget that really did what I wanted so I built my own. There are no global settings, but every widget instance has four options:

The title of the widget (default: Related Posts). It is similar to all other widget titles and gets printed before the widget-content.
The taxonomy whose terms relate the posts (default: Tags). A post is related to another post, as soon as they share one or more terms of a taxonomy. This can be the standard taxonomies Tags and Categories, or Custom taxonomies. Here youchoose which taxonomy is the relating one.
How many related posts to show (default 5). Quite simple, put the maximal number of related posts you want to be visible here.
Terms to exclude (default: none). Sometimes there are terms in a taxonomy, which are related to almost every post. The tag wordpress in my blog is such an example. If you have such tags you should exclude them, because they relate basically all posts, which would make the widget quite useless

Installing

Download the plugin from the directory: Simply Related Posts
Unpack and upload the simply-related-posts folder to the /wp-content/plugins/directory
Activate the plugin through the ‘Plugins’ menu in WordPress
Go to the ‘Appearance/Widgets’ area, add the ‘Simply Related Posts’ widget to a widget area.
Configure your settings

Feedback

Of course I want your feedback: Bugs or feature requests are welcome in the comments of this post or via twitter and I appreciate every review.

For now the code is available via svn from the plugin directory:
http://plugins.svn.wordpress.org/simply-related-posts/

Now, there is even a github repository:
http://github.com/danielauener/wp-simply-related-posts

Setting up Gravity Forms Analytics Goals

Sun, 16 Dec 2012 14:52:42 GMT

When we deployed our new site at Internetavdelningen last week, one of our goals was to get better at measuring conversions. Naturally, one of the main goals of the site is to convince potential clients to get in contact with us. Because our contact form is powered by the (absolutely awesome) Gravity Forms WordPress-plugin, we had to find a way to set up Gravity Forms Analytics Goals.

The easy way – a separate confirmation page

If that suits your page design and structure, it is easiest to just configure your Gravity form with a confirmation page. See the form settings screenshot below. You just have to create a page, which thanks visitors for their submission or something like that and choose this page in the form settings.

Now it’s only left to add the page as a goal to your Google Analytics profile. Click on the “Admin” item in the top menu on the right side and then on your profile in the Profiles tab, in your profile, choose the “Goals” tab and add a goal in one of the sets. Name and activate the goal, choose “URL Destination” and copy the permalink of your confirmation site into the “Goal URL” field. Now, after a few hours (or max one day) your conversion statistics should appear under “Conversions” in the “Standard Reporting” section.

How to do it without a confirmation page

As usual the easy way might not be working in your situation. So it was for us, we wanted to use the text confirmation method (see screenshot below) and hadn’t a clue how to implement that with analytics goals.

The solution was the somewhat unintuitive goal-type called “Event”. You select it instead of “URL Destination” in the goal settings.

Fortunately there is a great generator to do almost all the work for you. If you follow all the steps, including the described goal settings, the only task left is to add the generated tracking code to the submit button. That’s quite easily done with the Gform-submit-button-filter, provided by Gravity Forms.

Here is the code snippet that adds the tracking code with an onclick-handler to the submit button of the form with id=1. Add it to your theme’s functions.php.

EDIT: There seems to be a Gravity Forms upgrade that breaks the original code. That is because there is already an onclick-event on the submit-button in the new version. So we just have to append our tracking code to the onclick-event. Note that onclick is written in all non-capital letters, in the original version of my snippet it was onClick, which confused the HTML-parser. Thanks to @MrPeyler for sending me a note and helping me test.

add_filter("gform_submit_button_1", "add_conversion_tracking_code", 10, 2);
function add_conversion_tracking_code($button, $form) {
    $dom = new DOMDocument();
    $dom->loadHTML($button);
    $input = $dom->getElementsByTagName('input')->item(0);
    if ($input->hasAttribute('onclick')) {
        $input->setAttribute("onclick","_gaq.push(['_trackEvent', 'Contact', 'Information Request', 'Contact Form',, false]);".$input->getAttribute("onclick"));
    } else {
        $input->setAttribute("onclick","_gaq.push(['_trackEvent', 'Contact', 'Information Request', 'Contact Form',, false]);");
    }
    return $dom->saveHtml();
}

And here is the original WordPress filter, which doesn’t work with newer Gravity Forms versions:

add_filter("gform_submit_button_1", "add_conversion_tracking_code", 10, 2);
function add_conversion_tracking_code($button, $form) {
    $dom = new DOMDocument();
    $dom->loadHTML($button);
    $input = $dom->getElementsByTagName('input')->item(0);
    $input->setAttribute("onClick","_gaq.push(['_trackEvent', 'Contact', 'Information Request', 'Contactform',, false]);");
    return $dom->saveHtml();
}

Happy conversion tracking, with your Gravity Forms Analytics Goals!

Finally, enabled comments, looking forward to your feedback

Wed, 12 Dec 2012 18:46:34 GMT

Happy birthday to me: I enabled comments on all posts and am hoping for a lot of feedback. I will do my very best to approve and respond to all incoming comments as fast as I can.

Please ask what you want and let me know what you think!

Get class hierarchy in PHP

Tue, 11 Dec 2012 16:59:26 GMT

function walk_up_hierarchy($object,$method) {
    $values = array();
    $class = get_class($object);
    do {
        array_unshift($values,$class::$method());
    } while (($class = get_parent_class($class)) !== false);
    return $values;
}

Get class hierarchy in PHP: The snippet’s story

Yesterday I tried to call a function for every parent class of an object and get the results in an array. I didn’t find the solution instantly, so I thought that’s something for the snippets section.

The function above takes an instance of a class and a class method’s name. Then it calls the function on the object, storing the result as an array-item. Next it calls the method of the parent class of the object, storing the result in the beginning of the result-array and so on.

Apparently the method has to be defined in all parent classes, if that is not guaranteed you have to take further precautions.

WordPress MVC: Easily add a touch of MVC to plugins

Wed, 05 Dec 2012 21:23:45 GMT

Building web-apps for some years now, I’ve worked a lot with multiple MVC-frameworks. Most recently with CakePHP, which is great. As a WordPress plugin developer I sometimes miss that strictly structured way of coding, a WordPress MVC pattern. While the code of a lot of plugins I see, is organised very well generally, I really don’t like the way many developers mix HTML-output with their plugin functions and classes. Here is an example, from the Hello Dolly plugin.

// This just echoes the chosen line, we'll position it later
function hello_dolly() {
    $chosen = hello_dolly_get_lyric();
    echo "<p id='dolly'>$chosen</p>";
}

Another one from the akismet plugin, included in a standard WordPress installation:

function akismet_stats_display() {
    global $akismet_api_host, $akismet_api_port, $wpcom_api_key;
    $blog = urlencode( get_bloginfo('url') );

    $url = 'http://';
    if ( is_ssl() )
        $url = 'https://';

    $url .= 'akismet.com/web/1.0/user-stats.php';
    $url .= "?blog={$blog}&api_key=" . akismet_get_key();
    ?>
    <div class="wrap">
    <iframe src="<?php echo $url; ?>" width="100%" height="100%" frameborder="0" id="akismet-stats-frame"></iframe>
    </div>
    <?php
}

Even if I don’t think that is a big deal, I see at least a readability issue. That’s why I prefer to store my HTML in separate files, just as you would do in every MVC-framework. It just needs a little view-class and this gets really easy. It has three logical parts: The first one is to locate the file, containing the HTML-view, the second one makes it possible to set variables in the view’s context and the last one renders the view.

WordPress MVC – The view’s location

I like to store my views in a folder called views in my plugin directory and I even add the fact that it is a view to the filename. Thus, in my plugins a settings view would be located in plugins/my-plugin/views/settings.view.php. Now, creating an instance of that view in one of my plugin-functions, I don’t want to add the complete path, the relevant part “settings” should do, and the view-class does the rest in the constructor:

public function __construct($view) {
    $path = $plugin_path."/views/".$view.".view.php";
    if (file_exists($path")) {
        $this->view = $path;
    } else {
        wp_die(__("View ".$path." not found"));
    }	
}

WordPress MVC – Setting variables to use in the view

Having the location of the file, we can now add data, that we want to render the view with. Take the Hello Dolly snippet as an example, the content of our view file would look like:

<p id="dolly">
    <?php echo $chosen; ?>
</p>

Now we have to set the variable $chosen in the view’s context. Therefore we use an array called vars containing all data coming in via the set-function of the view-class.

public function set($name,$value) {
    $this->vars[$name] = $value;
}

WordPress MVC – Rendering the view

Finally we need a function to print out the view. It just registers the variables set in the vars-array and uses the output-buffering-functions of php to include and echo the view:

public function render() {
    extract($this->vars,EXTR_SKIP);
    ob_start();
    include $this->view;
    echo ob_get_clean();
}

WordPress MVC – The view class

Putting it all together in a view class (for copy and paste use, see github-link below), enables you to cleanly separate your views from your plugin-code. So, in a plugin, we can instantiate the view, set variables and render it, like this:

include "classes/MyView.class.php";
$view = new My_view("dolly-example");
$view->set("chosen","Lorem ipsum");
$view->render();

Current wp_nav_menu item in WordPress

Fri, 23 Nov 2012 12:26:50 GMT

$menu = wp_get_nav_menu_items($menu_id,array(
   'posts_per_page' => -1,
   'meta_key' => '_menu_item_object_id',
   'meta_value' => $post->ID // the currently displayed post
));
var_dump($menu[0]->ID);

Current wp_nav_menu item: The snippet’s story

I needed to retrieve the current wp_nav_menu item connected to the currently requested page/post in WordPress. I found some solutions going through the whole menu tree, comparing each item’s object ID with the current post-id. But, since menu items are post-types, you are able to use all the WP-Query-params with wp_get_nav_menu_items, even a meta-query. The code above selects all menu_items which are connected to the current post, from the menu you specify via $menu_id.

The only drawback is that two menu-items, linked to the same post, would both be returned without you knowing which was actually clicked. However, that’s the same with all the other solutions I found.

WordPress post to post relationships, without altering the Database

Sat, 10 Nov 2012 12:26:28 GMT

Using WordPress as a framework for a web app, often requires some creativity when applying your desired data model to the standard WordPress database setup. This article wants to explore possible ways of creating WordPress Post-to-Post relationships. But, be warned, it is not about best practices, performance or perfect database modelling. It’s more of an attempt to list some options to consider before adding custom tables and queries and working around all the secure and tested WordPress API functions.

Consider the enhanced entity relationship (ERR) diagram below. It shows some simple relationships of an exemplary author database. There is a many-to-many (n:m) relation of authors and books and in addition a one-to-many relation of publishers and authors.

There are several ways to implement such a data-model without adding any custom tables to the WordPress database. The one thing you have to do in any case is to add appropriate custom post types, extended with suitable meta data.

Implementing custom post types and fields

WordPress gives us custom post types and fields to build our own data-structures into the database. In our example, custom post types correspond to the three main tables (authors, books and publishers). Following our model, we would define three post types, named author, book and publisher, like the one in this, somewhat generic, code example:

register_post_type('author',
	array(
		'labels' => array(
			'name' => 'Author',
		),
		'public' => true,
		'has_archive' => true,
		'supports' => array('title','editor','custom-fields')
	)
);

That would provide us with the extra post types in the admin main menu. Posts of these new types have a title field and an editor field by default and you are able to add whichever meta-data you like, through custom fields.

Relating Posts

That was the easy part, but now it gets more tricky. How do we relate posts of the custom post types, just by using the WordPress API and no custom tables? There are some candidates among all the WordPress components that might work.

hierarchical posts: WordPress posts, and so posts of custom post types, are already designed to have a relation, if you want them to. It is a simple parent-child relationship that you might know from WordPress pages. Thus, all of our custom posts can have one parent and, luckily, it doesn’t have to be the same post type.
meta data: As you read above, we can use post meta data to add any kind of information to a post. It could be an ISBN number to a book, but it could as well be information about relations between one post and another. As you will see we can realize all significant relation-types with metadata.
custom taxonomies: In contrast to posts, which are holding content, taxonomies are organizing it. You already know the two default taxonomies WordPress provides: categories and tags. Even taxonomies can be used to establish relations, but as I think meta-data is the cleaner way, there will be no example in this article.

Let’s have a look at a simplified WordPress data model and see how these components are built. Hierarchical posts are realized by a post_parent column in the wp_posts table, which can be set to the ID of any post. Post-metadata is implemented through the wp_postmeta table, which is able to hold multiple metadata rows for each post.

Now, what we want to do, is to utilize the existing database schema, to get the relations between posts of varied types to work. But, our goal is to do this only by using the API, so we can’t just start to hack SQL-queries. Let’s go through the types of relations we want to build one by one and take a look at how it can be done.

Implementing a one-to-many Relation, using the post_parent-column

Now, how to implement a one-to-many relation, like the one between publishers and authors in our example model? The section on hierarchical posts might have given you the idea. A 1:n relation is nothing more than a parent-child relationship. One parent post can have multiple children, but one child post can only have one parent. So, let’s say, we are inserting an author-post, the only thing we have to do is to set the post_parent property and we are done.

$publishers_id = 22; // insert the real id of a publisher-post here
$author = array(
   'post_parent'    => $publishers_id,
   'post_status'    => 'publish',
   'post_title'     => 'This is an example author',
   'post_type'      => 'author'
);
wp_insert_post( $author );

Retrieving parent posts is equally simple. Just use a custom WP_Query object for getting all the authors related to a publisher:

   $args = array(
      'post_type' => 'author',
      'post_parent' => $publishers_id
   );
   $authors = new WP_Query($args);

The drawback of this method is that you aren’t able to relate a post to more than one parent, because all the posts are in one table. Thus you can only build a parent-child relation between one post type and another and not one post type and multiple others. If you have a more complex model than ours, chances are high that you have more than one 1:n relation on some post types. For example, if we wanted to add labor unions to the model. That would mean that you had to set both a publisher and an authors union as parent, which isn’t possible.

Multiple one-to-many Relations, using post-metadata

If you look at the WordPress database schema above, you can see that one post can be related to multiple wp_postmeta rows. The idea is now, to use this existing relation in the database for our relation of multiple post types – we want, in our concrete case, to relate some authors to both a publisher and a union. Our implementation is basically a variation of the post_parent method, as we will just create additional post_parent-meta-data for every post type we are relating.

// insert the real post ids here
$publishers_id = 1;
$unions_id = 2;
$author_1_id = 3;
$author_2_id = 4;

// add relations, author 1 has only a publisher, author 2 has both publisher and union
add_post_meta($author_1_id, 'publisher_id', $publishers_id);
add_post_meta($author_2_id, 'publisher_id', $publishers_id);
add_post_meta($author_2_id, 'unions_id', $unions_id);

Even retrieving the posts again is only slightly different from the post_parent-method we used above. Instead of querying the posts by post_parent we have to query them by meta_key.

   // getting a publishers authors
   $args = array(
      'post_type' => 'author',
      'meta_key' => 'publisher_id'
      'meta_value' => $publishers_id
   );
   $authors = new WP_Query($args);

   // getting a unions authors
   $args = array(
      'post_type' => 'author',
      'meta_key' => 'union_id'
      'meta_value' => $unions_id
   );
   $authors = new WP_Query($args);

A note on 1:1 relations: Implementing one to one relations is basically the same as implementing one-to-many relations. The only difference is that you manually have to set a constraint, limiting the application to relate not more than one post to another, so that a post can’t be set as a parent if it already is the parent of another post.

Many-to-many relations, using post-metadata

Many-to-many relations can’t be created with the parent_post-method. They are usually created by using a junction table, which holds the keys of two related posts in each row. In the author database model at the beginning of this article, you can see a junction table between authors and books, which physically enables a n:m-relation via two 1:n relations to the junction table. Now, take a look at the simplified WordPress database schema and the wp_posts/wp_postmeta relation. There is a one-to-many relationship between them, but, since we are relating author-posts to book-posts, stored in the same table, there actually are two one-to-many relations and the wp_postmeta table is working precisely as a junction table. The only thing we have to do, is to adjust the meta-data example above, to save multiple related post ids, instead of one. Luckily, the WordPress API enables us to do that.

// insert the real post ids here
$book_1_id = 1;
$book_2_id = 2;
$author_1_id = 3;
$author_2_id = 4;

// add relations, author 1 has only a publisher, author 2 has both publisher and union
add_post_meta($author_1_id, 'authors_books', $book_1_id);
add_post_meta($author_2_id, 'authors_books', $book_1_id);
add_post_meta($author_2_id, 'authors_books', $book_2_id);

That was all. Retrieving the ids of the books of an author is as simple as reading the authors_books-meta-data of an author post. If the author is related to multiple books, you will get an array of ids, which you can use to read the book-posts. Getting all the authors of a book requires a custom WP_Query with meta_key-option, just as the one we used on 1:n relations.

   // getting a books authors
   $args = array(
      'post_type' => 'author',
      'meta_key' => 'authors_books'
      'meta_value' => $book_id
   );
   $authors = new WP_Query($args);

Many-to-many relations with additional relationship information

Sometimes you need to add a piece of information to the relationship itself. How many chapters of the book are written by each of its authors, would be an (uninspired) example. Usually you just add columns to the junction table, but that’s not possible in our case, because we don’t want to change the database setup.

Since the only way to dynamically add custom data is through custom post types, we have to create one, just to store the relation-data. Let’s call it author_book. Now, when we create a relation between an author-post and a book-post, we even have to create an author_book-post, store some data in it and connect it to the relation itself. We are doing this, again, with post-metadata.

// post ids, of authors and books
$author = 1;
$book = 2;

// insert relationship post
$author_book = array(
   'post_status'    => 'publish',
   'post_title'     => 'Information about the relation between author and book',
   'post_type'      => 'author_book'
);
author_book_id = wp_insert_post( $author_book );

// relate posts
add_post_meta($author_book_id,'author',$author);
add_post_meta($author_book_id,'book',$book);

The author_book-post is now related to both, the author– and the book-post. Retrieving the data, has to be done in several steps now, which might be ineffective – but, as I said before, this article is not about finding the most performant solution.

// retrieve authors of a book, plus information post
$book_id = 1;

$args = array(
   'post_type' => 'author_book',
   'meta_key' => 'book'
   'meta_value' => $book_id
);
$author_books = get_posts($args);

foreach ($author_books as $author_book) {
   $author = get_post(get_post_meta($author_book->ID));
   // do sth with the author
}

Conclusion

Relating posts of different posts types is one of the key features for using WordPress as a web-application framework. Using post-metadata and some API functions, it is possible to implement 1:n, 1:1, n:m and even data-holding n:m relations. The pros are, that you can rely on the reliable, tested and continuously bug-fixed WordPress API. The cons are that you might run into performance problems, not using an optimized database. However, I think the discussed solutions for one-to-many, one-to-one and many-to-many relations are at least considerable and could be used in production. While the last case of simulating a junction-table with content columns was more of a showcase of what’s possible.

How to use array_map on associative arrays to change values and keys

Fri, 09 Nov 2012 19:52:26 GMT

$assoc_arr = array_reduce($arr, function ($result, $item) {
    $result[$item['text']] = $item['id'];
    return $result;
}, array());

Recommendation: If you are interested in fast PHP for your WordPress site, check out this great PHP/WP benchmark-post from Kinsta, where you can get great managed WordPress hosting with the best support and performance-optimizing technical add-ons like Redis and Elasticsearch.

The snippet’s story

I just ran into a problem using array_map on associative arrays, like the following one:

$arr = array(
   array(
      'id' => 22,
      'text' => 'Lorem'
   ),
   array(
      'id' => 25,
      'text' => 'ipsum'
   ),
);

From this array, I wanted to create another, associative array, with the following structure:

$assoc_arr = array(
   'Lorem' => 22,
   'ipsum' => 25
);

My first guess was the array_map function, but I had to realize that there is no way to manipulate the keys of the resulting array. After some googling, I discovered that it is array_reduce you have to use to simulate array_map on associative arrays.

P.S. I know, a simple foreach would have done the trick, but once on the path of functional programming, I didn’t want to leave it so quickly 🙂

WordPress as a Framework for Web Apps - Building a simple Recipe Database

Sun, 04 Nov 2012 20:06:18 GMT

In the past WordPress has grown from a powerful blog-system to a powerful CMS and, more recently, to a powerful framework for web applications. In fact, using WordPress customization features and the WordPress API, there are not many applications I can think of, you couldn’t build with WordPress as a framework. However, there are a lot of applications you shouldn’t build with WordPress. Choosing which framework to use (or choosing not to use one) is balancing between many pros and cons affecting architecture, performance, security, scalability and so on.

I found WordPress extremely useful as a base for medium-sized web apps, without too much traffic. Building a small application, for example a restaurant table booking system, from scratch or even with a framework like Rails or CakePHP, would involve thinking about database schema, controller structure, authentication, user interfaces etc. WordPress already does much of this: you already have rough user management, a working admin interface and you only have to think about how to map your data-model to the already existing WordPress database structure.

Our use case: A recipe database

Now, I want to show you how to implement a simple recipe database with WordPress as a framework. Requirements are really basic:

Allows adding recipes and editing them just like ordinary posts or pages
Allows categorizing recipes in hierarchical categories like Healthy -> Chicken -> Marinated Chicken Breasts
Allows adding ingredients to a recipe and finding recipes by ingredients
Allows adding quantities to ingredients of a recipe, e.g. 500ml milk, 20g sugar, 3 tablespoons olive oil

I will focus on how to customize WordPress to adjust it to your data model, mainly by showing you how to use the essentials to build every WordPress powered web app:

Custom post types
Custom taxonomies
Custom fields

Set up custom post type for recipes

In WordPress the base of every content holding entity is a post. The two post types you surely are familiar with are posts and pages. For our recipe database we will create a new type: recipes.

register_post_type('recdb_recipe',
	array(
		'labels' => array(
			'name' => 'Recipes',
		),
		'public' => true,
		'has_archive' => true,
		'supports' => array('title','editor','custom-fields')
	)
);

The new post type will show up in the admin interface along with posts and pages. It supplies a field for the recipe title and an editor field which is meant for the recipe’s description part. We even added support for custom fields, which will be necessary later on.

Set up custom taxonomies for recipe categories and ingredients

In WordPress, taxonomies are not for holding content, like posts, they are for organizing it. You should be used to the two default taxonomies: categories (hierarchical) and tags (not hierarchical). However, like with post types, you can add your own kinds of taxonomies. For our recipes database you could use categories and tags, but they are meant to be used for posts really, so we create our own recipe categories and link them to the recipe post type:

register_taxonomy(
	'recdb_categories',
	array('recdb_recipe'),
	array(
		'label' => 'Recipe categories',
		'sort' => true,
		'rewrite' => array('slug' => 'recipe-categories'),
		'hierarchical' => true,
		'show_in_nav_menus' => true
	)
);

In the admin interface they will show up under the recipes-menu and furthermore there will be a checkbox-list on every recipe to sort it into categories. The same way we want it with ingredients, but with a slight difference: they don’t have to be hierarchical, because every recipe will have just a plain list of ingredients. Here is how to create an ingredients-taxonomy, that will work just like ordinary tags. You can manage it from your admin interface and add it to any recipe:

register_taxonomy(
	'recdb_categories',
	array('recdb_recipe'),
	array(
		'label' => 'Recipe categories',
		'sort' => true,
		'rewrite' => array('slug' => 'recipe-categories'),
		'hierarchical' => true,
		'show_in_nav_menus' => true
	)
);

Set up custom fields for ingredient units

For now we can create new recipes, categorize them and add ingredients. The last missing feature is to add some sort of quantities to the ingredients, because the information that you will need milk, while cooking your dinner, is useless if you don’t know how much. Here is where custom fields come into the picture. For all ingredient-tags you are adding to a recipe, you have to add a custom filed as well. The name of the field is always quantities, that will allow us to read them as an array later on. The value has to be formatted like this: taxonomy-term-slug:string. Here are some concrete examples for the custom fields on our recipes:

quantities -> water:100ml
quantities -> milk:200ml
quantities -> sugar:20g

Embedding recipes in your theme

I am assuming you have a working theme and now want to add special templates for recipes. Begin with adding recipe-categories to your menus. If you are using custom menus, they will show up in the menu editor just like ordinary categories (you might have to activate them in your screen options panel). Now you should be able to navigate to the added recipe categories on your website. The recipes in those categories are displayed with your index.php or another matching template.

The next step is to build a custom loop for recipes. We will generally build quite an ordinary loop, including the_title and the_content template tags. Building the ingredients list is a bit special, though. For this, we first have to get the quantities meta-value, using get_post_meta. Then we are looping through the quantities, reading both the quantity and the ingredient and finally we provide an ingredient link, which leads to a site listing recipes with the same ingredient. Create a file called loop-recipes.php in your template directory and add the following loop:

<?php if (have_posts()): while (have_posts()): the_post(); ?>
	<div class="recipe">
		<h2><?php the_title(); ?></h2>
		<ul class='ingredients'>
			<?php
				if (is_single()):
					$quantities = get_post_meta(get_the_ID(),'quantities');
					foreach ($quantities as $quantity):
						$quantity = explode(':',$quantity); ?>
						<li>
							<?php echo $quantity[1]; ?> <a href='<?php echo get_term_link($quantity[0],'recdb_ingredients'); ?>'>
								<?php echo $quantity[0]; ?>
							</a>
						</li><?php
					endforeach;
				endif;
			?>
		</ul>
		<?php
			if (is_single()):
				the_content();
			else:
				the_excerpt();
				?><a href="<?php the_permalink(); ?>">Read recipe</a><?php
			endif; ?>
	</div>
<?php endwhile; endif; ?>

Now it is only left to embed the loop in the template files for recdb_categories and recdb_ingredients and adding a template to show a full recipe. Create three files called taxonomy-recdb_categories.php, taxonomy-recdb_ingredients.php and single-recdb_recipe.php in your template directory. The following code goes into the category-template:

<?php get_header(); ?>
<h1>Category: <?php single_cat_title(); ?></h1>
<p>List of recipes in category <?php single_cat_title(); ?></p>
<?php get_template_part('loop','recipes'); ?>
<?php get_footer(); ?>

Here is the code for the ingredients-template:

<?php get_header(); ?>
<h1><?php single_cat_title(); ?></h1>
<p>List of recipes, which use <?php single_cat_title(); ?></p>
<?php get_template_part('loop','recipes'); ?>
<?php get_footer(); ?>

And finally the single recipe template:

<?php get_header(); ?>
<?php get_template_part('loop','recipes'); ?>
<?php get_footer(); ?>

WordPress as a framework for web-apps: Conclusion

If you followed all the steps, you should have a really basic, but working recipe database running. Of course, the way to add ingredients is really horrifying, from a user’s point of view, but this tutorial isn’t about usability. It is a starting point for one who wants to take WordPress as a framework for web apps that aren’t blogs or ordinary websites. The vital point, I think, is to really understand the WordPress customization abilities and learn to map them to your own use-case.

Surely there are quite some drawbacks using WordPress for your web-app and you shouldn’t ignore them. However, once you have decided to go the WordPress way, you get a lot of cool features to defeat the disadvantages.

Strip scripts and styles from WP-ecommerce themes

Sat, 03 Nov 2012 07:46:18 GMT

I had to implement some WP-ecommerce themes (download WP-ecommerce), a couple of weeks ago. The admin interface happens to be quite good and simple, but I wanted to build my theme from scratch, controlling 100% of the code. So all the JavaScript and css stuff, that automatically gets included, was just a lot of overhead for me.

It took a while to find all the scripts and styles, so I thought sharing them here could help someone with the same problem. Just add the following lines to your functions.php.

add_action('wp_print_styles','deregister_styles',100);
function deregister_styles() {
	if (!is_admin()) {
		wp_deregister_style('wpsc-thickbox');
		wp_deregister_style('wpsc-theme-css');
		wp_deregister_style('wpsc-theme-css-compatibility');
		wp_deregister_style('wp-e-commerce-dynamic');
	}
}

add_action('wp_print_scripts','deregister_script',100);
function deregister_script() {
	if (!is_admin()) {
		wp_deregister_script('jQuery');
		wp_deregister_script('wp-e-commerce');
		wp_deregister_script('infieldlabel');
		wp_deregister_script('wp-e-commerce-ajax-legacy');
		wp_deregister_script('wp-e-commerce-legacy');
		wp_deregister_script('wp-e-commerce-dynamic');
		wp_deregister_script('livequery');
		wp_deregister_script('wpsc-thickbox');
	}
}

All done. Now we just have to load our own styles and can begin to work on our cleaned up WP-ecommerce themes.

Daniel Auener

New Side Project - Re:Do Workouts App. Plan, train and track your routines

The WordPresser’s Guide to the Fediverse

Find an Instance

WordPress Mastodon Instances

Moving to another instance

Find people to follow

The WordPress community on Mastodon

Follow #Hashtags

Find posts from users on unconnected instances

Find bots to fill your timeline with interesting things

Engage with the community

Join the WordPress Community on Mastodon and the Fediverse

10 Reasons a Mastodon Migration Makes Sense for the WordPress Community (and others)

1. You can choose a Mastodon instance relevant to the topics you are most interested in

2. The local timeline

3. Instance rules let you post, share and discuss in a safe environment

4. Your content is not monetized

5. Your content is not ranked by an algorithm optimized for engagement

6. Mastodon is built, owned, funded and driven by its community

7. Mastodon is Free Software

8. Mastodon can’t be bought

9. Most communities on Mastodon are actually nice

10. Meaningful exchange seems to be the rule not the exception on Mastodon

Start your Mastodon migration

Mastodon WordPress Instance

Mastodon Instance for Kalmar started

WordPress REST API extensions for going headless WP

Front-page extension

Menus

Filtering Categories and taxonomies

Loading ACF Meta-fields

SEO-Data

Building URLs

More to come …

WP-CLI inside Docker via Gulp

What do you think?

Nuxt.js + WordPress = WUXT

WUXT Components

Getting started

Set up WordPress

Set up nuxt.js

Feedback

Activate Gutenberg block-editor on specific pages or posts, or Gutenberg migration the client-friendly way

Step by Step: Gutenberg for specific posts or pages

WordPress-blogging, always a step ahead

My Talk about Elasticsearch and WordPress at WordCamp Stockholm 2017

Slow WooCommerce with Many Products

Slow WooCommerce with Many Products – The Test Environment

What’s tested

Slow WooCommerce performance with 50 000 Products?

CPU and Meta Table

Requests

Insertion Speed

Slow WooCommerce performance with 10 000 Products?

CPU

Requests

Insertion Speed

What Causes a Slow WooCommerce with Many Products

Big Meta Table = Long Loading Times

CPU

Requests

Insertion Speed

Conclusions

Redis with Node.js: Compress to Use Redis Memory Efficiently

Redis with Node.js, when zipping is appropriate

Compress Data for Redis with Node.js

ElasticPress & WooCommerce: Deactivate Product Search Fuzziness

WooCommerce with Thousands of Products: Workarounds for Slow Admin Panel

For a shop that is not running WooCommerce with thousands of products, it has a very nice performance, too.

… product related meta-table rows would grow beyond a million for more than 38 461 products.

WooCommerce Status Dashboard

Slow Edit WooCommerce Product for WordPress >= 4.4.0

Other measures

Yeah, finally loading Sidebars/Widgets with the WordPress REST API

Manual reviews of handpicked WordPress themes

Coding workflows: why Grunt changes our way of working

A platform-independent foundation

Coding workflows

Sharing and evolving workflows