Welcome to another edition of our monthly WordPress Core updates!
It’s always useful to keep tabs on what’s been going on in the Core development space. A lot has happened since our last update post so I won’t waste any time with chit-chat this month. Let’s get right down to the details, shall we?
Andrew Nacin offered an update on where the Core team currently stands on internalization. There were five goals previously outlined for this and Nacin provided the status of each. The first pass on being able to select a language when installing WordPress is completed. Several aspects of this are still being worked on, like the error handling when the filesystem or API can’t be accessed, adding language suggestions at the top of the browser, and improving the markup.
The second goal was to make it so people can select or switch between different languages in general settings to prompt a language pack download. Third is to allow users to search for plugins and themes from the dashboard that are available in a specific language. This means adding a new argument to the plugins screen server side. This mostly affects WordPress.org, not Core, by the way.
The fourth goal is to automatically generate localized packages when a new version of Core is released. Nacin says there’s a script for this already. The fifth and final goal that the team wanted to address regarding internalization was that only initial downloads from WordPress.org would use localized packages. After that, language packs would be used for all updates. The good news here is this development is complete and only needs to be activated in API.
More work still needs to be done to shore up internalization for 4.0 but it’s well on its way and I’m looking forward to seeing it in action.
Adding Widgets to Customizer
There was another rather lengthy update from Nick Halsey that went into great detail about the various improvements to the Customizer that will be available in WordPress 4.0. With eight enhancements proposed or in the works, the team has their work cut out for them. And all of this was slated to be completed before the beta release!
For starters, the team is thinking about calling it “Customizer” rather than ‘Theme Customizer.” The idea here is to apply the act of customizing a theme to any part of the site.
UI changes are a pretty big deal here as well. The Customizer itself is getting pretty significant changes that will directly affect users. The new Panels API makes it so widget areas are grouped. Widgets were added back in 3.9 but 4.0 sees them getting their own designated place. Panels slide to the side, so no more drop-downs, and include sub-sections that expand vertically. The close button is now just an “X” icon and a warning “Are you sure?” prompt now appears when you try to close the Customizer with unsaved changes.
Some of the phraseology has been modified as well. For instance, when previewing an inactive theme, it will display with the text, “You are previewing ‘Theme Name Here'”, but if it’s an active theme, it’ll read, “You are customizing ‘Site Name Here.'”
The customizer controls now support descriptions, too, and WordPress will return you to the screen from which you opened Customizer upon closing.
The API has been modified as well. As mentioned previously, Customizer now uses Panels to better group options together. And new controls have been built-in to Customizer to offer greater flexibility. This will make it so developers don’t have to create custom controls most of the time.
Controls support descriptions as well, allowing for help text inline as needed. Contextual controls change based on the context in which Customizer is being used. The example Halsey offers is if you’re previewing the front page, then you’d only be shown options that are relevant to the front page. Makes sense to me!
The latest updates will make it so you can also register arbitrary types for Customizer in addition to option and theme_mod types. And Customizer is getting a customize meta capability that makes it so it can be used for more than just customizing themes – like posts, for instance.
Finally, Halsey offered some insights into what the team will be working on next like building out the Customizer JS API, improving user experience on desktop and mobile, increasing its speed, improving custom background images, adding menus, and more.
Nick Halsey hit us with another update about Customizer a few days later. The focus this time? Scalable menus.
Development is happening in a plugin for now, but 4.2 seems to be a likely time for Core rollout for this feature. The plugin makes it so you can now add new menus thanks to a + New Menu section. It still needs some work, but the basics are in place. A menu-deletion mode that can be toggled from add-menu was also implemented , which should reduce the possibility of deleting a menu by accident.
Since menus aren’t very scalable – they require a lot of data for even a single update – but there is effort being made to experiment with different ways to scale menus, specifically for how menu data is saved. It’s a work in progress at this point but it’s a step in the right direction, for sure.
Dev Chat Overview
On July 17, Helen Hou-Sandi gave a brief rundown of the previous three dev chats to get everyone up to speed. And it’s no wonder for the delay – a lot happened! Beta 1 was released on July 10 with Beta 2 following shortly thereafter on July 17. TinyMCE got some updates between releases and everything is looking good so far, according to the dev team.
Testing is underway on several projects and the team requested feedback on plugin modals, accessibility devices, customizer panels, media grid, install language flow, and wpviews. There were several tickets still needing attention but nothing major.
She also noted several of the specific areas that had gone or were currently undergoing updates like the Media Grid, which still needed some help on architectural reviews. The plugins install page was getting some API changes and i18n still needed help to complete. oEmbed got placeholders for those occasions when embeds weren’t available, too.
JSON REST API Version 1.1.1
Lastly, on July 26, Ryan McCue announced the availability of the JSON REST API Version 1.1.1. It’s a security release for a small issue but it was recommended that all users update immediately. It only affects those running WordPress on a domain that has other non-WordPress software running. It’s also available on HackerOne now so developers can really delve into it and figure out if there are any other security vulnerabilities.
July was a productive month for Core development – it saw numerous changes across various aspects of WordPress, just in time for version 4.0.
The updates affected everything from language selection during the installation process to adding the ability to add widgets to Customizer. It also marked the release of two different beta versions. Slight tweaks and modifications are still being made to prep 4.0 for its official release, but everything seems to be coming together pretty well thus far.
What are you most excited about from the latest development updates? What are you looking forward to making it into Core? Please feel free to share your thoughts below!