The WordPress Cambridge Meetup is a monthly get together for developers and users of WordPress, held at The Boathouse usually on the second, or third Monday of the month.
You can usually expect to see 2-3 talks and an open Q&A session, followed by drinks in the pub.
Find out more about WordPress, whether you’re trying to decide if you should use it, or if you’re an expert that wants to keep on top of the latest features, or anywhere in between – everyone is welcome.
So come along to see how WordPress can benefit your organisation, and get specific advise on any WordPress questions you may have.
If you think April is too soon to start using Gutenberg, install the Classic Editor Plugin now – will make sure that old editor will continue to be used.
Next step: Gutenberg-based site optimisation
Blocks to lay out the whole site.
Next year’s focuses
Q&A (See 1:02.00 in video)
Note these are just my scribbled notes of the Q and A, not a verbatim account. Please see the video for the exact exchanges. – Ben Attenborough
Q: Question about page builders and is Gutenberg unfair to creators of page builder plugins as it will replace their functionality
MM: Lots of different page builder plugins, which shows how much demand there is for page building functionality
But problem is it is hard for plugins to work with page builders because each builder works differently. If Gutenberg presents a standard way for building posts and pages it makes it much easier for plugin developers to build applications that work in the expected way.
Will create opportunities for devs.
Q: Fields API – Will it be necessary to continue to have a fields API
MM: Gutenberg will cover a lot of bases for fields, but not everything so a fields API will still be necessary.
Question about WYSIWYG
MM: Will be editing on dashboard not literally on front end. But it will be a lot closer to a true WYSIWYG experience.
Q: Could we get a split community where some people will be on classic mode and some on Gutenberg. How will we get beyond these two worlds?
MM: You really do need to develop for Gutenberg and I’m okay if you drop support for Classic.
Q: Concern that users may find Gutenberg harder to use.
MM: We are building for people new to publishing and websites
Structure will be more intuitive. Ever have an image which is right aligned and you try to move it and move it inside a link and it’s a bit of a mess? Gutenberg is trying to fix that.
Q: If I’m creating sites for clients, I’m putting onus on users to design. What would be great is if I can add certain blocks to a CPT and say that’s it.
MM: Yes, it will be possible to lock down which block types a user will have access to.
Q: Front end responsive issue. There are circumstances where things have to change on different screens. So if the user specifies a 80px font size for a heading, it is not going to be 80px on a mobile phone. How are you going to control this?
MM: We are going to err on the side of letting people do stuff. Including being able to mess it up, but allow themes and plugins to bring in the guard rails a lot more.
Q: Concerned about changes Gutenberg will force on to customers.
MM: Today there is an opt-in plugin. New plugin will give a specific opt out. Trying to provide a gradual ramp. Trying to learn from Gutenberg because going to make big changes in the future.
Q: Are you concerned about React?
MM: Think that React is the future and can fork from the GPL version of React if future React version introduce bad things.
Cross compiling from other language possible.
Gutenberg is happening, and although there will be ways to continue with the old TinyMCE editor it is clearly the direction of travel.
At 1:10.55 Matt gets a question about the danger of “two worlds” one where people use Gutenberg and one where people use classic. Matt responds by saying that over time users will expect everything to work with Gutenberg and demand for classic will fall away.
It was interesting to me that Matt Mullenweg actually says “at some point” he will be fine with plugin developers dropping support for the pre-Gutenberg world (See around 1:14.00). Once plugin start dropping support for classic, people are going to have to either stay still or move ahead under Gutenberg.
It certainly feels like Gutenberg is the future and developers and users will not be able to ignore it, or at least not for long.
Furthermore it seems that the Gutenberg philosophy of using content “blocks” will also be extended into designing pages. It looks like a page building system, like ones such as Beaver Builder, will eventually be part of WordPress core. What will this mean for existing sites built with a page builder system? Will they need to be redesigned using the Gutenberg builder?
This will be controversial, but I’m optimistic that eventually this will be a good thing for users, as it will give them more access to design their own pages and posts without having to code. Hopefully it will also be good news for developers, as they will be able to build sites which give users more customisation options without having to introduce a slew of plugins or custom code.
WordPress 4.9 will introduce saving theme customizations as draft. Now when you make changes to a theme using the customizer, you will have an option to save your changes as a draft instead of making them live.
This new feature will also allow you to share the preview of changes with a url. You can send this URL to any user, and they will be able to see your website with the changes made in that particular draft.
Want to publish your theme changes at a specific time? WordPress 4.9 will also allow you to schedule changes.
It is now possible to manage capabilities for activating and deactivating plugins more granularly through the following new capabilities:
activate_plugin checks whether a user can activate a specific plugin. When checking the capability, it gets passed the plugin file (such as current_user_can( ‘activate_plugin’, ‘my-plugin/my-plugin.php’ )).
deactivate_plugin works similar to activate_plugin, but checks whether a user can deactivate a specific plugin as the name indicates.
deactivate_plugins allows to check whether a user can generally deactivate plugins
WordPress 4.9 Protects Users From Fatal Errors Created in the Theme and Plugin Editors
Over the years, there have been many discussions and debates on whether or not WordPress should have a built-in file editor for themes and plugins. The file editors, while convenient, allow users to easily trigger fatal errors that can be difficult to fix, especially if they don’t have FTP access.
Instead of removing the editors from core, the WordPress development team has enhanced them by adding fatal error protection in WordPress 4.9. When a user accesses the theme or plugin editor for the first time, they’re presented with warnings.
If you try to save changes to a file and WordPress detects a fatal error, the change is not saved and a warning message is displayed that explains where the error occurred
Better mapping for widget areas when switching between themes
Sometimes widget areas and even menus could become ‘lost’ when switching themes, because different themes have different names for menus and widget areas. 4.9 tries to fix this by trying to match up widget and menu areas from one theme to another.
GDPR for WordPress Project Seeks to Provide a Standard for Plugin Compliance
WordCamp Denmark organizer Kåre Mulvad Steffensen and WP Pusher creator Peter Suhm are working on a GDPR for WordPress project that aims to provide an industry standard for getting plugins compliant with EU General Data Protection Regulation (GDPR) legislation. The deadline for compliance is May 28, 2018, approximately 200 days from now.
Up until the release on October 24, Gutenberg did not support the meta boxes that so many WordPress content creators rely on. The new editor now has initial support for meta boxes as well as a host of other critical features for content creation.
WordPress 4.8.3 Security Release
At the end of October, WordPress 4.8.3 was released containing an important security fix for all previous versions of WordPress. If your WordPress installation has not updated automatically, please update it now to protect your site.
Tim is the platform lead at 34SP.com for their Managed WordPress product in addition to being the company’s Developer Advocate.
Tim’s presentation managed to be both scary and reassuring about security: making it clear that security is everyone’s responsibility but also that there are plenty of things we can do to make our sites secure.
Tim pointed out that sites are as likely to be hacked if they’re running a security plugin as they are if they’re not! This underlines the fact that plugins only really fix one small part of a larger security process which includes making sure the server is set up correctly, that people are sensible with the way they use passwords, and that site administrators set up users correctly.
It’s important to make sure that users are only given the permissions that they need and that sites have as few administrators as possible. Some site owners have two accounts – an editor and an administrator – and purposefully change their administrator password to something ridiculous so it’s impossible to log in with it unless it’s reset using the site’s database. Others add alerts to their sites which make it really clear when logged in as an administrator and they may have too much power!
In terms of passwords, most have been leaked at some point so it’s important to change them regularly and never use the same password for multiple sites.
Whether you use a password manager or not (see Keypass and Keeweb, password length is far more important that complexity (i.e. combinations of letters, numbers and special characters) so an increasingly popular way of handling passwords is to use pass phrases
Two factor authentication (using a phone app to provide a special login key every time you log in) is another great way to increase your site’s security. There are several plugins which add two-factor authentication to your site. Just make sure you print (and keep safe) your backup codes! The best method is to combine a long pass phrase and two-factor authentication.
Keeping everything up to date is also vitally important – core WordPress, plugins and themes (even if they’re not active) and don’t pirate themes which might not be updateable. Using child themes, as ever, is strongly recommended. Tim pointed out it’s worth updating even if it breaks little things – it’s better to have a secure site.
Site monitoring is a handy tip Tim gave us: use visual regression testing, which takes a visual snapshot of your site (or part of your site) and warns you if it looks different. Visualping.io is one example of a visual regression testing service. Testing backups when you take them is also really important – and it’s handy to automate this as much as you can, if you know how!
Finally, use HTTPS on everything! We’ll be covering HTTPS in more depth in a future meetup but in the mean time it’s worth checking the sort of HTTPS/SSL certificate your hosting service can provide you with. You shouldn’t need to pay – there are plenty of free services available now, inlcuding Amazon.
We were very fortunate to be able to welcome Mario Prelorentsos of JDJ Creative to talk to us about graphic design – in particular the use of colour.
In addition to a number of great points of interest (green is the colour of the year 2017, for example!) Mario provided us a number of links to handy sites for stock photography and other design resources:
In a change to the planned presentation, we ran a “goldfish bowl” group discussion around graphic design – so no slides to share! Thanks to everyone who contributed and we’ll be running more goldfish bowls later in the year.
We were very lucky in February to welcome Eric Swain of Equinet Media for an in-depth discussion of Hubspot, the inbound marketing platform.
Hubspot was founded in 2006 in Boston, Mass. and has since gone public. They have around 20,000 customers in 100+ countries, making them an important player in web content and marketing.
Hubspot isn’t primarily a content management system, although it does include one (although they call it a “content optimisation system”). Instead, it’s a series of tools for tracking and identifying potential leads – so, for example, someone who visits your site from a link in an email can be tracked across all their interactions with you as they move from suspect through prospect to customer. As the user visits the site, they’re asked to fill in forms to get hold of more content (white papers and so on).
This tracking allows Hubspot to create a progressive profile of your customers and to present them the content they want to see.
This is the main difference between Hubspot and WordPress is that WordPress is a blogging platform which has evolved into more, while Hubspot is a CRM system which has evolved in to more.
The first meetup of 2017 covered the workflow of various developers.
Chris O’Dell uses Microsoft’s Visual Studio with a PHP plugin and Team Foundation Server as a code repository. Chris doesn’t version control his WP core files, and is meticulous in keeping version notes and his check in routines.
Jonathan Whiteland has rather an esoteric setup working between three different desktop machines, using BBedit for code editing and Git (GitHub) as an analogue of Dropbox – storing working files in Git and deploying to dev and then live as needed.
Ben Attenborough uses DesktopServer as a local dev server with Bitbucket for Git storage. Ben also uses Gulp for running tasks like concatenation, SASS pre-processing and so on. Ben pushes changes through Git, rather than FTP. Ben also introduced us to Kint and Whoops, two excellent ways to make PHP var dumps and error messages more useful.
Adam Maltpress shared some of the software he uses for work and sanity, including the NetBeans IDE. Adam uses either Git or SVN for version control, and tries to build sites as database agnostically as possible – they should work as well with test content as with real content!
Simon Bragg uses Xampp, the Duplicator WordPress plugin, and FileZilla as well as the NetBeans IDE (using its built-in SASS pre-processing). This prompted a big discussion around the PHPStorm IDE.
Steven Watts then took us through his infographic on setting up a WordPress site and some of the key plugins he uses.