19 open tickets. Last 7 days: +0 tickets
|19 open tickets||defect (bug)||enhancement||feature request|
Earlier today, we released WordPress 4.2.3, which includes a relatively large security fix that affects the Shortcode API. Due to the nature of the fix – as is often the case with security fixes – we were unable to alert plugin authors ahead of time, however we did make efforts to scan the plugin directory for plugins that may have been affected.
With this change, every effort has been made to preserve all of the core features of the Shortcode API. That said, there are some new limitations that affect some rare uses of shortcodes.
Reminder: Never, under any circumstances, should you hack core files. This includes downgrading specific files. Doing so could have unintended consequences on your WordPress installation, including major security implications.
A brief explanation on the original purpose of shortcodes will help to explain the change. In a basic post, like this example, shortcodes are used to insert dynamic code:
Here are my images. [gallery]
Here you can see that the shortcode stands on its own as a dynamic element within the blog post content. This is the central premise of the Shortcode API: make it easy to insert blocks of dynamic code.
In today’s release of WordPress 4.2.3, however, we’ve added some new limitations that affect some existing plugins. Take, for example, the following shortcode, which is no longer recognized:
<div style="background-image: url('[shortcode]');">
The shortcode in the example above appears in a context that is no longer supported. Further, this use of a shortcode stretches the imagination for how the Shortcode API was intended to be used. Fortunately, there are some workarounds still available, so that site administrators are not overly restricted in their use of HTML.
The following example still functions as expected and is considered more acceptable:
Going forward, plugins implementing shortcodes for inline styles should output the entire
style attribute rather than a bare value. Keep in mind that this workaround – just as the original example above – is only available to administrators and editors (i.e. only roles with unfiltered_html). Less-privileged users are still prevented from using shortcodes to output whole attributes in this manner. If a plugin is intended to work with author and contributor roles, we recommend that the plugin output an entire
The following example is also no longer allowed:
<a href="/[shortcode query="?ref="]">
In the above situation, the shortcode is now properly recognized as HTML and it is rejected by the API. Apart from the example being confusing, WordPress cannot parse that shortcode.
Instead, either of the following examples would be appropriate:
<a href="/[shortcode query='?ref=']">
<a href='/[shortcode query="?ref="]'>
Administrators as well as lesser-privileged authors can continue to use shortcodes in this way, as long is it conforms to the usual HTML filtering rules. However, as explained in the first example, administrators are now somewhat limited in this situation in one case: if the content in this
href attribute is generated by a shortcode that does not conform to the HTML filters, then the shortcode is rejected for all users.
We do not make this change lightly and understand that it may affect some usecases. The above examples and explanations should help plugin authors make the modifications needed to support the Shortcode API.
Development leading up to the first beta brought several visual changes. These are available right now in the nightly build. Switch a site to nightly builds and try them out.
To disambiguate between links to the Customizer and links to the Appearance screens from the front-end, Customize now has a top-level toolbar button rather than having links to it mixed with dashboard links in the site menu. This context mixing leads to disrupted user expectations as they navigate, as well as experiences that feel slower or actually are slower in some cases. See #32924.
This means an additional top-level menu item, but the existing links to Widgets and Themes in the dropdown will now point to the admin, as the Dashboard and Menus links do. The advantage and goal for this change is to make it clear that you are about to enter the customizer. Deep links have not been added back in this go-round; this means that direct links to Header and Background are currently absent (with a very narrow exception related to old browsers). Those two deep links are still available in the admin menu under Appearance, which similarly mixes context but has not yet been addressed.
List tables now scale down to phones. The column truncation strategy they used before didn’t scale down to small screens. A single column layout with disclosures is the new strategy. Some of our most important screens use list tables, notably Media and Posts. Truncated columns was number 5 on our top 5 impediments to flow on touch devices list.
For more screenshots, see these visual surveys of the list table screens.
I’ve been wanting this one for a long time. Toolbar interaction was number 3 on the top 5 impediments to flow on touch devices.
See #29906. That ticket is a good read. It has: Visual feedback and visual surveys. Punting a working fix to the next release so that a new, more future proof approach could be tried. Development of touch capability detection. Working around iOS. Development of testing checklists. Lots of iteration.
The password set/change UI was updated with these improvements.
See #32589 for more screenshots.
Dashicons received a big update.
My Sites now moves to a single column layout on narrow viewports. Here it is on an iPhone 6, an iPad, and a Macbook, as well as at full-width.
Here’s what it looked liked before.
See #31685 – Better responsive styling for my-sites.php
The graf in the Menus panel details about using the Customize Menu widget now links directly to the widgets panel.
You might notice the misaligned question mark icon on that screenshot. #32733 is tracking that.
The beta tester plugin makes it easy to switch a site to nightly builds. Now switching back to the latest stable build is just as easy. It’s not the prettiest, but it is shown only to beta testers and will suffice until we finally refresh the Grand Unified Updater screen. For info on using the beta tester plugin to test with nightly builds, see the Beta Testing page of the core handbook.
One of the most important things in WordPress is users being able to feel confident as they make changes to their content and more generally to their sites. Being able to make non-destructive changes and preview them is an important component of building that trust. This is perhaps most noticeable in the “save and surprise” approach of the widgets admin screen – every time you add a new widget, modify its settings, or move one around, the changes are saved and appear live on your site, even if you’re not ready yet. The customizer is our framework for live previewing changes. We are committed to providing live preview for all aspects of site customization and making it usable on all devices from phones to large screens.
The customizer is the result of a tremendous amount of work over many releases. It was first introduced in 3.4. In 3.9, it received its first big updates in the form of widgets support and improved header upload and cropping. 4.0 brought panels and contextual controls. Development really started to take off in 4.1 when JS-templated customizer controls and a JS api were introduced, making possible an ecosystem of live preview compatible plugins and themes. 4.2 followed that up with two important features, theme switching and mobile support.
That brings us to today and the ongoing 4.3 development effort. Revamped navigation for the customizer is already in trunk and the nighty builds. The menu customizer feature plugin is a merge candidate for 4.3 and could land soon. These marquee features further our commitment to live preview and need all of the attention we can muster.
The customizer has come a long way, but it still lacks some features and needs time to mature. We have many improvements planned and in-progress, including transactions, partial refresh, theme installation, speedier loading, scaling to large screens, and possibly even integration with front end editing. Our live preview framework offers many possibilities.
Meanwhile, the Appearance screens will remain and will be maintained. Appearance > Menus recently received some attention in the form of a few fixes. More attention is needed and will be given. There are still differences in the flows each approach best enables, whether it’s new site/theme setup, small maintenance tasks, or dedicated content managers for heavy usage of widgets, menus, or other pieces of content that benefit from having a preview mechanism. We should gather quantifiable metrics when it comes to performance and time to completion for a given flow, as well as evaluating the less-objectively-quantifiable perceived performance. There may come a time where the worlds converge; however, that time is not now.
The feature plugin merge window is currently scheduled for June 17th. We have 8 days to get the Menu Customizer plugin ready for merge. Feature plugins must meet several criteria to be considered for inclusion in a release. To meet this criteria, the flow team has started testing and documenting flow and visuals for the menu customizer as well as the recently landed navigation changes. Merge criteria include identifying flows through the customizer, creating visual records of those flows, and creating flow comparisons of existing flow through Appearance > Menus versus flow through the customizer. This is a great and necessary way to contribute that requires no coding. All you need to do is take screenshots and publish them as a captioned gallery using the tool we’re making together, WordPress. We endeavor to be an Alan Lomax of flow, capturing and cataloging real user scenarios. Please help us capture the flows through Appearance > Menus used by you and your clients. We need this information to ensure our new interfaces are mindful and aware of how WordPress is actually used. Information on how to test and contribute visual records is available on the 4.3 development tracking page.
If you’d like to get involved, our documentation could really use some editing / additions. Feel free to open a GH issue with suggestions, or stop by
#feature-shortcode in Slack.
Next chat: same time and place
4.3 was kicked off on April 28th by release lead @obenland and is currently scheduled for August 18th. Enabling users of touch and small-screen devices is the focus of 4.3. make/core is the development hub for WordPress. If you want to follow WordPress 4.3 development, that’s the first place to look. Posts relevant to 4.3 are tagged accordingly.
A good way to contribute to 4.3 is to help out a feature team. 4.3 has five feature teams.
Use the beta tester plugin to put a site on the bleeding edge nightly track. This will set you up to receive nightly updates for core WordPress.
That’s a pretty convenient way to follow 4.3 development. With that in place, test the customizer and create a captioned gallery visual record full of your feedback. Like this: https://make.wordpress.org/flow/2015/06/04/menu-customizer-iphone-6/
Here are some example comparison vizrecs. These are very useful and valuable.
Pick a goal, such as adding a menu to the top of the front page containing Home, About, what have you. Start on the front page and show the flow. If you have flows of interest to you or your clients, document those in a vizrec using both Appearance > Menus and the menu customizer. Compare the two flows and show your work in a captioned gallery visual record. Help us curate these flows and increase our awareness of what our users are really doing. And don’t just do this on desktop. Do this on mobile. Do this on every device you have.
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.
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.
If you see anything that sparks your interest feel free to leave a comment here and attend the kickoff meeting tomorrow, when we go through the list of things that were suggested. Specifically, Admin UI can will need a lot of hands. The meeting will also be a good time to suggest additional areas that you want to work on.
We’ll kick 4.3 off with a 2-hour meeting in #core at the usual time, April 29, 20:00 UTC.