A call for feedback around pending improvements to validation in the Customizer.
In #34893 and the accompanying Customize Setting Validation feature plugin I’ve suggested improvements to the Customizer setting validation model. More can be read about the proposal in that ticket description and plugin readme, but the short of it is that settings in the Customizer generally undergo clean-up sanitization but lack a robust system for pass/fail validation. Here is a video demo depicting what I think validation should look like in the Customizer: Normally the Customizer just sanitizes values by attempting to coerce them and clean them up into something that can be safely used (e.g. stripping tags). As for validation, and while I believe this is relatively unusual to encounter, you can also do strict validation of a setting by blocking it from being saved: this is done by returning null from WP_Customize_Setting::sanitize() (often via WP_Customize_Setting::$sanitize_callback). This is the behavior for setting the background_color: if the value is not a valid hex code, it will not save. The problem here is that there is no feedback to the user that the save was blocked. If user tries to enter “blue” as a color instead of a hex code, they will not get informed that this
A technical write-up with high relevance for anyone working with the Customizer.
As described in the Improving Setting Validation in the Customizer proposal post and detailed in #34893 and #36944, WordPress 4.6 includes new APIs related to validation of Customizer setting values. The Customizer has had sanitization of setting values since it was introduced. Sanitization involves coercing a value into something safe to persist to the database: common examples are converting a value into an integer or stripping tags from some text input. As such, sanitization is a lossy operation. But what happens in sanitization if a provided value is irrecoverable, beyond the ability to sanitize? The Customizer did allow sanitizers to return null in such cases which resulted in the value being skipped entirely from previewing and saving, but there was no feedback to the user that the value was skipped. Additionally, when multiple settings were modified but some were skipped due to returning null, the result was that a save operation would only persist the non-skipped settings to database: a user would unexpectedly find that only some of their settings were applied, resulting in an inconsistent saved state. Save operations were not transactional/atomic.
These are the problems that
Great news! The website and code are all coming in under the WordPress.org umbrella and financial support is also involved.
Fun time to be alive ;) Cool stuff is happening with WPCLI. Look at that badass logo. New workflows, features, commands, and everything!
Happy release day! After 325 merged pull requests, we’re excited to bring you WP-CLI v1.2.0, chock full of enhancements, bug fixes… and a bootstrap refactor.
We have a new logo!
Coming soon to a laptop near you:
Thanks to Chris Wallace and the crew at Lift UX for their work, as well as everyone who responded to my pings about feedback.
Commands abstracted to distinct packages
We’ve split up the project!
The main wp-cli/wp-cli repository now only contains the framework itself. All of the bundled commands can be found in separate repositories. For instance, the wp cache * series of commands are now located at github.com/wp-cli/cache-command.
This abstraction provides a few benefits:
While developing, the tests are only run for the specific component you’re working on, making the feedback loop much shorter.
Individual command packages can be controlled and set up independently, opening up the opportunity for better collaboration.
Hotfixes and intermediary releases can be published for individual commands, that can then be updated through the built-in package manager.
Tests run really fast now.
When you submit a pull request, you don’t have
There you go! Lots of improvements and certain enhancements I was looking forward to.
Happy release day! Today, I’m excited to bring you WP-CLI v1.1.0, chock full of enhancements and bug fixes.
Want to get props in the next release? There are a few projects we’ll be working on:
Creating a new WPorg home for wp-cli.org/commands and wp-cli.org/docs/internal-api [meta#2465]
Splitting internal commands into distinct packages [#3728]
Transforming some ideas into working prototypes.
And, in case you missed it: I’m looking for help maintaining WP-CLI (paid opportunity, commitment of 5-10 hours/week). Know someone who might fit? Email firstname.lastname@example.org or ping ‘danielbachhuber’ on the WordPress Slack.
Everything in 1.1.0
wp cache *:
Explicitly sets default cache group as ‘default’ to replicate WordPress’ behavior [#3714]
wp (comment|post|user) list:
Magically parses CSV values for any argument with double underscore [#3726, #3744]
wp core config:
Introduces --force parameter for overwriting existing wp-config.php file [#3706]
wp core is-installed:
Prevents error notice from wp_guess_url() when core isn’t installed [#3711]
wp core language install:
Passes $wp_version through to translations_api() so
WordPress officially ending support for Internet Explorer versions 8, 9, and 10, starting with WordPress 4.8.
Previously, we discussed the new editor and browser support within WordPress core. Following up on those conversations, we are officially ending support for Internet Explorer versions 8, 9, and 10, starting with WordPress 4.8. Microsoft officially discontinued supporting these browsers in January 2016, and attempting to continue supporting them ourselves has gotten to the point where it’s holding back development. I realize that folks still running these browsers are probably stuck with them because of something out of their control, like being at a library or something. Depending on how you count it, those browsers combined are either around 3% or under 1% of total users, but either way they’ve fallen below the threshold where it’s helpful for WordPress to continue testing and developing against. (The numbers surprised me, as did how low IE market share overall has gone.)
Of course, wp-admin should still work in these older browsers, but with fewer capabilities, and we will no longer be testing new features and enhancements in these browsers. For example, the next versions of TinyMCE – currently targeted at WordPress 4.8 – will not support older IE browsers.
It's that time! Proposal to merge into core. A 2-parter though. Whatcha think?
Hello everyone! This is the post you’ve all been waiting for. We on the REST API team (myself, @rachelbaker, @joehoyle, @danielbachhuber, and newest member and core committer @pento) would like to propose merging the REST API into WordPress core. We’ve been working a while on this, and think it’s now ready to get your feedback.
This is our first iteration of the proposal, and we’re actively looking for feedback. If you have thoughts on the project, or on this proposal, let us know! Only with your feedback can we make progress.
What is the REST API?
The REST API differs from existing WordPress APIs in that it is explicitly designed from the ground up for modern mobile and browser usage, using the lightweight and widely-supported JSON data serialization format with a modern REST interface.
Well, slap me with a feather! I never thought I'd see the day where perhaps the biggest annoyance in all of WPland is now going to be just a distant memory! Happy days, oh happy days! :D
In  and  for #31168, we’ve turned comments off on new pages by default. I know many of you have done the “make a bunch of pages, fill them out, realize comments are turned on, go back into the admin, turn off comments” dance. Now when you make a page, you won’t have to manually turn off comments — it’ll match the expected behavior of being off by default.
In addition to pages, this functionality has been extended to all custom post types. Post registrations that don’t explicitly add support for comments will now default to comments being off on new posts of that type (before, they defaulted to on). Up until now, post type support for comments has only affected admin UI; a developer could omit comment support on registration but still allow comments to be posted. This is a change in behavior, and we will be closely monitoring its effects during beta. Moving to explicit support will allow core behavior to be more predictable and robust in the future, but we will always consider real-world usage.
In trunk, you’ll notice two new things: the get_default_comment_status() function, which accepts the post type and comment type as arguments (both optional), and within it a get_default_comment_status
NICE! WordPress 4.8 includes media widgets for not only images but also video and audio, on top of an extensible base for introducing additional media widgets in the future, such as for galleries and playlists.
As first introduced in the Image Widget Merge Proposal, WordPress 4.8 includes media widgets (#32417) for not only images (#39993) but also video (#39994) and audio (#39995), on top of an extensible base for introducing additional media widgets in the future, such as for galleries and playlists. To quote : The last time a new widget was introduced, Vuvuzelas were a thing, Angry Birds started taking over phones, and WordPress stopped shipping with Kubrick. Seven years and 17 releases without new widgets have been enough, time to spice up your sidebar!
Eric Andrew Lewis asks for feedback regarding pending improvements to the data schema for meta.
register_meta() is a tiny function, which lets you register a sanitization and authorization callback for post meta, term meta, user meta or comment meta. We’re going to expand the utility of this function to describe the data type of the field. This will be useful for the REST API as well as the Fields API.
This discussion has started in #35658, but I’d like to share the latest thoughts for general feedback.
Imagine a “movie” custom post type which has a “star-rating” post meta field, which should accept the value 1, 2, 3, 4 and 5. REST API clients like the iOS app would want to know this information, so they can offer appropriate UI for their users. Ditto for the Fields API.
Here are some loose thoughts on what that API might look like.
Here is a post meta field for “mood” that accepts any string. The value would fit in a single row. There would only be one row per post, as it is not “repeatable.” Repeatable might be a default.
Progress on the Gutenberg Editor continues. Anna Harrison reports on user testing at the Brisbane WordPress Meetup. Overall, feedback was good, though there are some areas that testers found difficult.
Development on the new editor for WordPress is steaming ahead towards a big reveal at WordCamp Europe in June this year. Last week, I tested the Gutenberg prototype using the community-created Gutenberg testing script (a big shout out to @martinlugton, @j-falk, @lucijanblagonic, and @karmatosed for the hard work on this!). Here are the insights from the analysis of the 3.5 hours of user test footage. Being a total UX nerd, I also took the opportunity to test the test.
Summary of findings
As the user test script contained 18 tasks, the detailed observations and video footage make this for a very long post. If you are after a quick summary, the main takeaways are that participants love the overall minimalist and modern direction of Gutenberg (kudos to all the WordPressers!) and they find the general concept of blocks and contextual menus really intuitive to use, confirming earlier user test results.
The main insights from this user test session pertain to perfecting the finer, detailed-level interactions:
Keyboard shortcuts, tooltips and search are a must
Inserting a new block is really, really hard
Inserting a new block is also a little confusing as new blocks lack definition and are
Ryan McCue proposes a new feature project to modernise the rewriting and routing system for WordPress.
Hi everyone! Today I’d like to propose a new feature project for WordPress: Next Generation Rewrites. After proposing this at the last feature projects meeting, it’s time to flesh out the details of what this project would be. The aim of the project is to modernise the rewriting and routing system for the modern CMS and platform era of WordPress.
(This project was previously proposed in a ticket on Trac, however the project is larger than a single Trac ticket and needs a larger discussion.)
If you’ve worked with custom development on WordPress, you’ve probably registered at least one rewrite rule. Rewrites are the key to what WordPress calls “pretty permalinks”, which are URLs designed for humans rather than the server. They look like /2016/04/19/, or /about/requirements/, rather than index.php?p=42.
As a developer, you can register your own rewrite rules as well. For example, bbPress registers URLs like /forums/topic/jjj-is-awesome/ and WooCommerce has URLs like /product/gs3/. WordPress then “re-writes” these to the internal query variables (“query vars”), which are eventually passed into the main WP Query.
The rewrite system was initially designed to implement pretty permalinks,
A collection of useful links to all the things shipping with WordPress 4.7. A must-read for all WordPress developers.
WordPress 4.7 is shaping up to be the best WordPress yet! Users will receive new and refined features that make it easier to “Make your site, YOUR site”, and developers will be able to take advantage of 173 enhancements and feature requests added. Let’s look at the many improvements coming in 4.7… RESTing, RESTing: 1, 2, 3
The foundation for RESTful APIs has been in core since 4.4, and 4.7 sees the addition of Content Endpoints after a healthy discussion. We’ve defined four success metrics as part of the merge discussion and you can help by building themes and plugins on top of the API, using the API in custom development projects, and utilizing the API for a feature project, core features, or patches. So, dive in, start playing around, and let us know what you build!
Hi everyone, it’s your friendly REST API team here with our second merge proposal for WordPress core. (WordPress 4.4 included the REST API Infrastructure, if you’d like to check out our previous merge proposal.) Even if you’re familiar with the REST API right now, we’ve made some changes to how the project is organised, so … Continue reading
It don’t mean
WordPress has supported custom page templates for over 12 years. With WP 4.7 the same functionality is coming to all post types, using "Template Post Type" in the file header.
WordPress has supported custom page templates for over 12 years, allowing developers to create various layouts for specific pages. While this feature is very helpful, it has always been limited to the ‘page’ post type and not was not available to other post types. With WordPress 4.7, it will be. By opening up the page template functionality to all post types, the template hierarchy’s flexibility continues to improve.
In addition to the Template Name file header, the post types supported by a template can be specified using Template Post Type: post, foo, bar. Here’s an example:
<?php/*Template Name: Full-width layoutTemplate Post Type: post, page, product*/// … your code here
That way, you’ll be able to select this full-width template for posts, pages, and products.
When at least one template exists for a post type, the ‘Post Attributes’ meta box will be displayed in the back end, without the need to add post type support for 'page-attributes' or anything else. The ‘Post Attributes’ label can be customized per post type using the 'attributes' label when registering a post type.
Selecting the post template
The proposal for a new feature in WordPress core that will allow non-destructive CSS editing of WordPress content.
When people ask “why WordPress?”, some of the most common answers center around flexibility for users of all kinds, whether they’re building their sites primarily through code or UI. Let’s take the story of a user who does a little of both – we’ll call her Becky. Becky is a pretty savvy user. She knows that you’re supposed to make child themes instead of hacking on a theme directly, because updates can wipe out your changes. She found that out the hard way when she first started using WordPress – she hardly knew what CSS or PHP were, but she knew there was a theme editor in the admin and that she could make tweaks to colors or remove the author byline pretty easily without having to figure out this FTP stuff. Later on, most colors could be changed with the customizer so having a child theme just to remove an author byline seemed like overkill, but it was certainly better than having it reappear every time her site updated, especially with auto updates turned on.
After a couple years with the same theme on her personal site, Becky felt it was time to change things up. She was pleasantly surprised to find some new features that made getting
MIka explains policies regarding forks and copies in the WordPress repo.
This has come up recently. What happens when someone submits a plugin that’s a copy of another? The tl;dr here is this: Please email us at email@example.com if you find someone has slipped an uncredited fork or identical copy of another plugin into the repository.
In general, we spot these before they ever get published. We rejected 10s of plugins a month for being identical copies. That said, we also approve double that for being legitimate forks.
While the GPL and it’s compatible licenses allow for forking, we have an ‘above and beyond’ rule for hosting here, that means your plugin must be a substantial change of the original. We do not allow direct copies of other plugins to be re-listed under somebody else’s name, we allow changed forks.
What does that mean? It’s very simple. You have to add new features, remove features, modernize, fix, clean up, or otherwise make a change to the plugin that differentiates it from the original. In rare cases, a simple clean-up will be accepted, but normally we try to get a hold of the original authors and have the fixes folded in to the original plugin. If you have a fork, we require you to retain all credit and/or copyright information.
It might come down to React vs. Vue.js. Important to monitor this and future discussions, since it impact WordPress core in a major way.
@omarreiss helped lead the discussion and kick-started the conversation by opening a detailed and thoughtful ticket in trac (#40834) which introduces modules, their goals and how we could go about using them in core. The discussion was around considerations specific to WordPress and a need for modularity was mentioned – @westonruter called out this need for the Customizer, see #30277. Ideas for code that could be extracted into modules included quickedit, core date utilities and wp.media.view.FocusManager.
The decision was made to move in the direction of using Webpack (and ES6 imports) as our bundler of choice, and to work first on switching out browserfy in our current build chain.
Discussion started on choosing a new framework for use in core. The main frameworks discussed so far were React and Vue. Attendees shared their hope, goals and criteria for choosing a new framework and mentioned: stability, longevity, mature, well-adopted, proven in a WordPress context, accommodating to accessibility requirements,
The Customizer just keeps getting better and better. An overview of several improvements coming to 4.5
In addition to the ~35 defects that were fixed in this release, there were also ~17 features and enhancements that were made. What follows are some highlights, starting with some smaller enhancements and then listing out full posts that document the larger features. Setting-less Controls (#35926)
Sometimes controls need to be added which don’t directly have associated settings. For example, there can be controls needed which manipulate some aspect of the Customizer interface or manage the behavior of other controls and their settings: consider a control for managing repeating controls, where the button only serves to create other controls and their settings. When nav menus were added in the Customizer in 4.3, the UI for creating a new menu involved two controls which had custom settings associated them (create_new_menu and new_menu_name) which served no purpose other than to make sure the control wouldn’t raise an error. The settings had custom types to prevent them from getting saved to the DB.
In 4.5, controls are no longer required to have associated settings. By default registering a control without an explicit settings argument will result in the control’s own id being supplied
Some great changes are coming to the plugins page within the WordPress admin.
The WordPress Plugins page has barely changed in 5 years or more – compare WP 2.7.1 with 3.9.1. The very first page seen by a new user who clicks on the Plugins tab is a list view showing two installed plugins. The main thing thing that has changed since 2.7 is that the way to find and install new plugins has become less obvious.
Similarly, the plugin-install page has barely changed in that time: WP 2.7.1 and 3.9.1.
The default page is very much geared towards maintenance by established users. The most common interaction is probably deactivating and reactivating plugins for troubleshooting – certainly a necessary task, but I think it misses a good opportunity for helping people to find and use the plugins they need.
There are a number of improvements that could be made with relatively minor changes:
Improve the experience for new and infrequent users.
The obvious fix here would be to make the path for discovering and installing new plugins much more obvious than the “Add New” link. Perhaps even go as far as making plugin-install.php the default page.
The Search Installed Plugins box on plugins.php is easily mistaken for a plugin directory search. Either make it less confusing, or use
Mika Epstein did a tremendous job re-writing, editing and tweaking the plugin guidelines and now she needs our help for one final review!
Thank you everyone for being patient about this. This summer was spent re-writing and editing and tweaking the guidelines. I ripped them down, sat and spelled out what they meant, then I rewrote them to be more clear. Then I got the plugin review team to review the changes. Then I had a group of people at WCNYC Contributor Day review them.
Finally, I moved it all to a GitHub repo and started to ask smaller groups to review it. Then we had a quick rebranding and that all brings us here.
I would like everyone in the community to read these proposed updates to the Plugin Directory Guidelines.
WordPress.org Plugin Guidelines
At the risk of sounding trite, pull requests and issues are welcome.
If you feel a guideline’s explanation is unclear, please create an issue or a pull request with what you feel should be changed and why. All grammar/spelling corrections are greatly welcome. We’re trying to write these for all levels of developers, as well as people who may not speak English proficiently. Using words like ‘obsequious’ should be avoided (nb: That’s mostly to me who uses those words regularly).
All feedback should be opened as issues in the tracker.
If you're a WordPress plugin developer with plugins in the repo, note these changes to two specific guidelines.
With the advent of the new directory being on the horizon, which allows us to easily hard-limit the number of plugin tags displayed, we have taken the time to change the guidelines. While minor updates to the guidelines (with regard to spelling, grammar, etc) are common, major changes are rare and we are striving to be more transparent about them. Hence this post
Guideline 12 (readme links) clarified to cover spam and tags.
The guideline now reads as follows:
12. Public facing pages on WordPress.org (readmes) may not spam.
Public facing pages, including readmes and translation files, may not be used to spam. Spammy behavior includes (but is not limited to) unnecessary affiliate links, tags to competitors plugins, use of over 12 tags total, blackhat SEO, and keyword stuffing.
Links to directly required products, such as themes or other plugins required for the plugin’s use, are permitted within moderation. Similarly, related products may be used in tags but not competitors. If a plugin is a WooCommerce extension, it may use the tag ‘woocommerce.’ However if the plugin is an alternative to Akismet, it may not use that term as a tag. Repetitive use of a tag or specific
It's that time again, when you can make your suggestions count, and dump your wishlist for WP 4.4 :)
Would like to see improvements in these areas: User profile screen.
To be make as post edit screen. Means we could add custom metaboxes, collapse metaboxes, use featured image in profiles (avatar ?), rearange drag and drop sections (metaboxes) in profile screen. Anyway WordPress would benefit tremendously if profiles worked similar way as post/pages.
User/Role dependent TinyMce settings. (as Drupal has long time ago)
Visual Editor in comments, maybe optional as one checkbox in settings.
Post/Page/Settings/etc.. Save and Close button. Saving close edit screen and redirect to the list.
Easy to adapt Dashboard.
Random Math captcha in the core for registration, login, comments. Forms can follow and use core code.
Default featured image fallback.
Put basic robots.txt in root.
Put Interconnect script for converting URLs in core folder, or implemented in settings. Dont know how other people do but I am using it 100%, on all websites. If this doesnt qualify as candidat for core, I dont know what would.
Number of revisions and Autosave interval as settings in backend.
Backend left sidebar auto adapting to longer menu item names, adapting middle area too.
One or two metaboxes of beer and collapsible
Gutenberg continues to improve. Version 1.4 is now out — you can change the HTML of an individual block now.
With this release Gutenberg allows you to make edits and tweaks to the HTML of individual blocks, without having to hunt for the relevant code in the full document view. Redesigned the header area of the editor for clarity—groups content actions in the left, and post action in the right.
Group block settings (delete, inspector, edit HTML) on an ellipsis button.
Added new reusable Dropdown component.
Show frequently used blocks in the inserter shortcuts (at the bottom of the post).
Offer option for the button block to clear content.
Refactor block toolbar component in preparation for some iterations (docked toolbar, for example).
Allow partial URLs in link input.
Avoid using state for tracking arrow key navigation in WritingFlow to prevent re-renders.
Improve mobile header after design cleanup.
Add focusReturn for Dropdown component.
Updated Audio block markup to use figure element.
Removed transition on multi-select affecting the perception of speed of the interaction.
Show Gallery block description even if there are no images.
Persist custom class names.
Merge initialization actions into a single action.
Fix scroll position when reordering blocks.
Fix case where
Look for touch and small-screen features when WP 4.3 hits the net on August 18th (scheduled date).
First I’d like to thank @drewapicture for his outstanding work in 4.2! I was particularly impressed with his ability to keep meetings on track and in time, I’ll work on making sure that won’t change going forward. A lot of the structure and artifacts he put in place have been proven quiet successful and I’d like to continue that, so you shouldn’t see too much change in that regard either. Release Date
We’re aiming to release on Tuesday, August 18th. The 4.3 schedule is live and can be found here: https://make.wordpress.org/core/version-4-3-project-schedule/
Deadlines are not arbitrary, and with your help I fully intend to get this version shipped comfortably on the 18th. Past releases have been quite good about releasing on time, let’s make that a signature trait of the WordPress project!
WordPress 4.3 will be all about enabling users of touch and small-screen devices. @ryan has been testing flows on a myriad of different devices the past few releases and uncovered many things that desperately need attention.
@joedolson has published a post over on make/accessibility about a11y priorities.
If you see anything that sparks your interest feel free to leave a comment here and attend