WordCamp Joburg 2017 Composer Workshop

Composer has been around for a little while now and it has made the lives of thousands of PHP developers around the world just a little better (OK, quite a lot better).

Using Composer in your theme and/or plugin will allow you to add a range of great features and libraries that are available to the general PHP community without having to worry about actually managing those libraries (Composer does that for you).

In this workshop, we will look at:

  • how Composer works from a very high level;
  • start a very simple plugin and including composer in it;
  • and use some of the really cool packages out there to make our plugin awesome.

You can find the repo for the workshop on GitHub: https://github.com/seagyn/wcjhb-composer-workshop


Get Custom Post Type by Slug

I recently had a case where I needed to get the post object for a custom post type in WordPress – I had to do this by a slug that the user passed in. There is a function ( get_page_by_path) which I initially thought was to only find the post object for pages but it actually goes deeper.

The function takes 3 arguments:

  1. The path/slug that you’re looking for.
  2. How you want the post to be returned – basically as an array or object.
  3. The post type(s) you want to search through.

So to get the post object (let’s call my custom post type ‘book’) I can just do the following:

Now that I have the object I can reference it as I would any post object in WordPress:

For more information, you can visit the get_page_by_path function reference on WordPress.

What is continuous integration and what does it have to do with WordPress?


This is the first part of a 6-part series of posts about continuous integration with WordPress. You can find out more information about why I’m doing this here.

  1. What is continuous integration and what does it have to do with WordPress?
  2. Using Github and Travis CI to begin your continuous integration journey
  3. What is the difference between unit tests and integration tests?
  4. Writing unit tests to improve your code
  5. Writing integration tests and making your code robust (everywhere)
  6. Additional tests you can do for your WordPress projects
  7. Continuous integration with WordPress resources

So, what is continuous integration?

Continuous integration (CI) is a practice that requires developers (especially teams of developers) to integrate their code multiple times a day or as often as possible into a single repository. Every commit into this central repository will trigger an automated build that will check and verify that the code still works.

To verify the code, you usually run a number of tests. There are a couple of tests that you can run including the testing of coding standards. Coding standards may not affect your code working in production but it does allow for teams work more efficiently with each other – one purpose of continuous integration.

The main tests you want to run are called unit tests and integration tests. I’ll describe the differences of each in part 3.

Further Reading:

Why do I need continuous integration?

There are so many reasons why CI is important for you, your team, your business and / or your open source project. It’s essentially a process that will level up your entire workflow and allow you build projects more efficiently. Here are some of the benefits that I think are key:

  • Smaller regular commits allow for you to find out when an issue was introduced and allow you to fix it quickly.
  • Automated builds mean that testing becomes a non-event (basically your team can’t forget to have tested the software as it is done for them).
  • Testing in different environments makes sure your code is working as expected in as many places that you can think of.
  • Bugs are found and communicated early on which means you can fix them quickly.
  • Bugs are generally found before they go into production.
  • Troubleshoot less and code more – my personal favourite.

To me, it’s quite clear that continuous integration is key to every project and that moving teams of people onto a CI workflow will literally take your project to the next level.

How can WordPress plugin and theme developers benefit from continuous integration?

Having spent some time with this over the last couple of months the benefits are so clear to me. The benefits of CI far outweigh the implementation of it and your end-users will thank you for it (by buying more, thanking you more or using your software more). Here are some of the benefits:

  • Your code will work most of the time as you’ve tried to break it with unit tests.
  • Your code quality generally improves especially if your tests check for coding standards.
  • If your plugin / theme relies on other plugins or themes you’re able to verify that your code works with different versions of their code. This includes new releases.
  • You’re able to verify that your code works in different software environments (think PHP versions).
  • The most important benefit is that you’re able to test that your code works with different versions of WordPress. You can even check your code works with WordPress in different environments as well.
  • You can test a future version of WordPress before it’s launched so that your plugin / theme is ready when it is released.

What next?

I hope this has helped understand the clear benefits of using continuous integration with your WordPress project. In the next part, we will be setting up a quick project and then will implement continuous with GitHub and Travis CI. I’m a big fan of doing practical learning and so you’ll get your hands dirty from the start.