WordCamp’s are community organised events, that happen the world over, all throughout the year. They are a great place to meet other WordPress developers and users and to watch some great presentations about everything WordPress.
Whilst both days were packed with great presentations, from start to finish, I would like to highlight a couple of presentation that I, as technical lead and developer, found particularly interesting and the takeaways I got from them.
Accessible Design with Maja Benke
Maja’s presentation offered great insight into accessibility and why accessibility on a website is not only good for people with a disability but for everyone using the site. She explained that every fifth person in the world has some sort of disability, so ignoring them when building a website is excluding a large audience. Also, by making your website accessible it will make it easier for everyone to use, so it is a win, win situation. Maja had an excellent quote from an old IBM training manual at the beginning of her presentation, which for me said it all:
“For people without disabilities, technology makes things easier. For people with disabilities, technology makes things possible.”
So by making your website accessible, you are making it possible for someone with a disability to do something, which otherwise they might not be able to do.
After explaining why accessibility is important, Maja then stepped us through many of the common mistakes people make in design and what the best practice for these common mistakes are, to make your website design accessible. Most of this was common sense, but it is surprising how often making something “beautiful” trumps making it accessible. So let’s take a look:
Mistake: Colour as a single indicator of information. Best Practice: Add additional style beside colour.
Mistake: Low colour contract Best Practice: Hight colour contract
Mistake: Hard-to-read typography Best Practice: Easy-to-read typography
Mistake: Over designed text style Best Practice: Natural text style
Mistake: Unstructured text Best Practice: Use of text elements
Mistake: Messy structure Best Practice: Clear site structure
Mistake: Random use of HTML elements Best Practice: Semantic markup
Mistake: Useless link label Best Practice: Clear and meaningful link labels
Mistake: Single content format Best Practice: Mix of content formats
Mistake: No choice for users Best Practice: User controls the behaviour of elements
Mistake: Long form content with important information hidden within it. Best Practice: Keep it short with important information at the beginning.
Maja gave examples of each of these, showing the bad and the good, and you can see these example in her slide deck. Maja also gave links to excellent resources to help with accessible design as follows:
Contrast Checker – A tool to check with accessibility standards the colour contrast of your website elements meets.
Sketch WCAG – A plugin for the Sketch design tool to check the accessibility of your design elements.
The A to Z of WordPress Multisite with John Blackbourn
WordPress Multisite is a built-in core function that by default is switched “off”, but when enabled allows you to run multiple individual websites from a single WordPress instance. John explained this concept from the very beginning and demonstrated how to set up your “network” of sites. He explained that WordPress.com, which hosts approximately 50% of all WordPress site, runs from multisite, just on a much larger scale than most people will ever use it for, so it definitely “production ready”.
With multisite enabled, you get an extra option added to the WP Admin titled “My Sites”, which gives you access to the Network Admin (if you are a super admin user) as well as the various “sites” you are a user of. Each site has its own WP Admin and changes within this admin affect that particular site. Changes made to the Network Admin affect the whole network.
Users can be assigned to one or more sites and the list of users is stored at the network level, however, users can only access the resources they have been given permission to, so whilst the users are all kept at the network level, if a user is only assigned as the “editor” of one particular site, then they can only login to that sites WP Admin and only perform the tasks that an editor can perform at that level. Multisite also adds a new type of user, a Super Admin user, which has access to the whole network and the Network Admin, so that they can make changes to the network.
Themes and plugins are centrally managed from within the Network Admin and can be either “Network Enabled”, meaning they are available to every site on the network, or enabled / disabled, on a site by site basis. Unlike with a standard WordPress installation, the administrator user(s) on individual sites cannot install themes and plugins.
WordPress, theme and plugin updates are also centrally managed, so only a super admin can perform this task and updating any of these affects the whole network.
John also explained a few little things you need to be aware of when using multisite, these are:
By default, it creates a permalink structure starting with the word “blog” so all pages on the site will be pre-prepended with /blog/, but you just need to go the site admin and remove this from the permalink structure. This is a legacy hang-over from its original use which has never been changed.
Most multisite specific plugins exist on Github and not in the WordPress plugin directory.
If you use https (SSL), then either use it for all sites or don’t use it at all, you will have issues if you try to mix-and-match.
Database sharding – DON’T EVEN THINK ABOUT IT
The multisite code is old, with stable, so if you want to contribute to it, be aware of this.
John’s explanation of multisite was extremely good and helpful as it is not a part of WordPress I had ever looked at before, so it is good to know it exists, what it does and how it could be used.
Thomas started off his presentation by explaining some basics about security, who is potentially attacking your site, why they would be, even it is just a “small blog”, what consequences this could have for you and your site what the goal of website security is.
He then explained that while there are many good security plugins for WordPress, that simply installing one or more “security” plugins is not the be-all and end-all of security. This is because WordPress itself is not the only component involved in the security of your website. There are many parts of your WordPress install to your web server software to your hosting provider and so on. A WordPress plugin can only deal with the security of WordPress and some only deal with specific parts of WordPress. There are vulnerabilities, threats, and risks outside of WordPress that you need to make sure you cover as well, hence it is a process and not a plugin.
Thomas then stepped through some security principles that are best practice to follow, these are:
Manage Security Risks – Know about vulnerabilities, threats, and risks.
Be reluctant to trust – Implement a “trust boundary” and be cautious of things from outside this boundary.
Practice defence in depth – secure all levels from the network level to the WordPress core.
Stay up to date – at all levels, not just WordPress.
Secure the weakest link – people are the weakest link, so educate users and implement good security practices and policies.
Gutenberg was the buzz of WordCamp London this year. It is the new editing experience that will be being introduced in WordPress version 5 and has been in development for over a year. Zac is well known in the WordPress community as an educator and has developed a Gutenberg Development course to educate developers about the new editing experience and how they can take advantage of it and customise it to their needs.
The Gutenberg editor is based on “blocks”, which are fundamental elements of the page and Zac assumed some knowledge of this already as he wanted to cover the development process for new blocks.
Gutenberg is Javascript based, so Zac started by explaining the Javascript libraries used and that everything you need to develop new blocks is held within this library, which is an abstraction of React
Zac then spoke about the tooling used, which include Babel, Webpack and <NPM and how the enqueues for CSS and JS work for Gutenberg.
Zac then spoke through the architecture of a block, how to register a new block and the settings that are required, along with a couple of demos.
It was very helpful to see this, as all my previous experience of Gutenberg was only from using it from the editor interface, and seeing it from the development point-of-view help me to understand it better and the thought process put into the way it works.
While I would like to have covered every presentation I attended, I think the ones above were the most important. I would, however, like to give a special mention to a few more, these are:
Anatomy of Blocks with Tammie Lister, who is an Experience Designer with Automattic and is part of the team, which gave a good introduction to the concept of blocks in Gutenberg.
Uncommon (Ab)Uses of Composer with Alain Schlesser, who is the lead developer of the WP CLI project. Alain introduced Composer, which is a package manager for PHP and how you can use it with a WordPress project, like developing a plugin.
Content Security Policies: Let’s Break Stuff with Matt Brunt. Matt gave an excellent introduction to CSP’s and then explained how to implement them correctly, with the ability to test them both enforcing them and getting reporting from them using something like https://report-uri.com/, something which I wasn’t aware previously was possible.
Starting from scratch – my journey to becoming a developer with Georgia Cottle. This was a lightning talk, so only around 10 minutes, but Georgia did an excellent job of explaining her journey to becoming a web developer with Pragmatic, a large WordPress agency based in Brighton. Given this was Georgia’s first time speaking at a conference, she did an excellent job.
Overall, WordCamp London was an excellent, well organised and enjoyable conference and was more than worth the £40 entry fee. I’m looking forward to hopefully attending again next year.
If you liked reading this article you may also like: