At the beginning of the past few releases or so, we’ve put a call out for community priority tickets. There are over 3000 tickets in Trac. If there’s a ticket you feel is neglected or should have light shined upon it: leave a comment here with a link so we can triage it. Help us help you.
Updates from January, 2015 Toggle Comment Threads | Keyboard Shortcuts
It’s this time of the week again: WordPress Core Weekly is here. This updates covers all commits since last week up to to today, October 29th.
But there are many more things going on behind the scenes and Core has even passed revision [30,000]! Let’s have a look at this week:
- Add labels to the Personal Options input fields on the user profile editing screen.  #30101
- Editor: Use
<a>for the Visual/Text buttons, make them focusable.  #27553
- Twenty Fifteen: If the sidebar is taller than the viewport scroll it with the content, if it’s shorter keep it fixed.  #29979
- Introduce a new means of outputting a
<title>tag in the theme head. Requires a theme to add support by calling
add_theme_support( 'title-tag' ).  #18548
- Introduce some new template functions for navigation  #29808
the_post_navigation()for navigation to the next and previous post.
the_posts_navigation()for navigation to the next and previous page of posts.
the_pagination()for paginated navigation between pages of posts.
paginate_links(). This reduces the need for themes to define their own sets of navigation functions.
- Introduce an
edit_form_before_permalinkaction which gets fired after the title field but before the permalink fields.  #29691
wp_link_pages(), only output link separators between actual pagination links.  #24940
_wp_get_password_hint()to bring it inline with core terminology.  #21243
- Don’t add
ignore_sticky_postsquery var is set.  #18035
- Don’t display Standard post format twice in the meta box if the theme unnecessarily mentions it in the
add_theme_support()call.  #16555
get_comment_reply_link()arguments.  #10569
get_terms()to accept an array.  #23636
get_terms().  #23261
slugcolumn of terms table.  #22023
wp_json_encode(), a wrapper for
json_encode()that ensures everything is converted to UTF-8. Change all core calls from
wp_json_encode().  #28786
wp_is_trusted_network(). A first step to establish concepts around trusted and untrusted networks.  #30145
- Don’t hardcode
heightfor videos – this was a workaround for MediaElement internals causing problems. Responsive videos now work properly and don’t cause extra whitespace.  #30078
- Introduce some actions and filters which aid plugins in revisioning post meta.  #20564
WP_Comment_Query::query()to be disabled.  #29902 Disable
ORDER BYby passing boolean
false, an empty array, or the string
orderbyparameter. This mirrors the behavior of
WP_User_Query.  #30064 This lets the results of a user query be sorted manually by the value of the
meta_query.  #23369
- Optimize site query when performing network database upgrades  #30097
WP_Tax_Queryparam sanitization for empty strings.  #30117
- Support multiple
WP_Comment_Query.  #29612
Thanks to @peterwilsoncc, @iamtakashi, @nacin, @mnelson4, @afercia, @psycleuk, @rianrietveld, @davidakennedy, @celloexpressions, @DrewAPicture, @jipmoors, @ipm-frommen, @mattwiebe, @avryl, @heshiming, @desaiuditd, @ankit-k-gupta, @captaintheme, @marcosf, @obenland, @tmtrademark, @briandichiara, @tareq1988, @jakub.tyrcha, @johneckman, @kosvrouvas, @ptahdunbar, @nacin, @pushplaybang, @joedolson, @aaroncampbell, @jfarthing84, @dlh, @danielbachhuber, @wpsmith, @hotchkissconsulting, @JustinSainton, @jwenerd, @wonderboymusic, @tollmanz, @chrisbliss18, @joostdevalk, @TobiasBg, @nofearinc, @karpstrucking, @ebinnion, @boonebgorges, @mattheu, @adamsilverstein, @momo360modena, @tareq1988 for their core contributions!
Interested in joining in? Write or test a patch for 4.1.
Hi Everyone! It’s time for another update. This edition covers through Sunday, June 15th, and has taken a while due to travel, but @swissspidy & @designsimply have joined the team, helping to gather the information to bring us up to date. Hopefully this will help these updates be a bit more sustainable over time. If you’re interested in pitching in with these updates as well, please let me know in the comments below!
Especially of note are the first pass of the grid view for the media library, several SSL and oEmbed updates, and a new ‘Beta Testing’ tab on the Plugins screen.
- Plugins Screen: Add a new ‘Beta Testing’ tab on the plugin installation screen, for features as plugins such as Press This.  #28513
- Media Library: Grid view for the media library, first pass. This is alpha; expect imperfection to start.  #24716
- Forcing SSL logins now forces SSL for the entire admin.  #10267
- Force SSL on the frontend when the home URL uses HTTPS.  #27954
- Force SSL admin when
siteurlis explicitly configured with HTTPS.  #27954
- Use a secure
logged_in_cookiewhen the home URL is forced HTTPS.  #15330
url_is_accessable_via_ssl().  #19555
srcattribute for the
[embed]shortcode if the shortcode body is empty.  #24456
- Add “edit” mode for
[embed]and URL media previews.  #28532
wp_embed_register_handlerto catch bad YouTube URLs and try correct them.  #24660
- Add oEmbed support for:
- Update SlideShare oEmbed regex.  #28380
- Remove Viddler oEmbed support.  #28379
- Make it simpler for plugins to register MCE views.  #28458
shortcodeequal to the passed
typefrom default args when calling
wp.mce.views.register().  #28458
- Improve handling of embed errors/error messages.  #28195
Themes and Templates
- Add a filter to
human_time_diff()to allow more detailed depictions of time differences.  #27271
- Allow simple modification of sections of the title by adding a
wp_title().  #17877
- Add CSS rules to ensure that videos will be responsive, regardless of theme.  #28414
get_stylesheet_directory(). These constants are now deprecated  #18298
- Update Twenty Thirteen and Twenty Fourteen to Genericons 3.0.3.  
- Improve keyboard accessibility for the media modal.  #23560
- Add screen reader labels to the date inputs on the post editing screen.  #25461
- When parsing the main query, if
sis set to empty:
$this->is_main_query() && array_key_exists( 's', $this->query )– kill the query instead of loading the homepage. This will load the search page with no results.  #11330
- Kill queries that explicitly pass empty arrays to
WP_Query.  #28099
- Fix SQL generation when
'relation' => 'OR'for its queries and wants to
'orderby' => 'meta_value'.  #25538
- Allow users to sort posts by type in
WP_Query.  #28214
- Add access modifiers to
WP_User_QueryAdd magic methods for BC:
call().  #27881, #22234
- Wide-reaching changes to do away with many instances of variable-variables. See #27881 for full list of changes.
- Eliminate use of
extract()within WordPress. #22400
- Fix curly quotes around numbers when applicable.  #8775
- Only include relevant post authors in WXR exports.  #20206
- Append the date to
$wp_versionin the build output, for nightly packages.  #26751.
wp_new_comment()with a check for successful database insert.  #28254
get_pages()instead of a raw SQL query in
get_body_class().  #28159
- Pre-populate the selected URL or
mailto:<email-address>when “Insert/edit link” is clicked.  #19992
- Live update the menu item title when the user is editing the “Navigation Label” field.  #23076
get_terms()as a replacement.  #21200
like_escape()and replace with
$wpdb->esc_like().  #10041
upload.phpto avoid an empty list table.  #27951
- Add new function
wp_spaces_regexp()to filter for common whitespace characters.  #27588
like whitespace by using
wp_spaces_regexp()instead of raw regex.  #27588,  #27587,  #23185
wptexturize(), ensure that texturization does not corrupt contents of HTML elements, HTML comments, and smartcode attributes. Adds a variety of unit tests/assertions.  #27602, #12690, #8912
- Various updates to
wptexturize()in  #19308,  #22823,  #20342
- Allow user to disable texturization.  #19550
- Update TinyMCE to 4.0.28.  #28391, #27941
- In iOS, fix placing the caret at the bottom of longer posts when the keyboard is open and disable resizing on switching editors and on show/hide of the kitchen sink row.  #28242
- Fix problems with undo/redo after resizing an image several times.  #28389
- Fix saving the editor content on switching from Visual to Text.  #28353
Thanks to @aaroncampbell, @adamsilverstein, @alexander.rohmann, @aliso, @atimmer, @avryl, @azaozz, @boonebgorges, @bramd, @celloexpressions, @clifgriffin, @coffee2code, @danielhuesken, @DavidTheMachine, @DeBAAT, @donncha, @DrewAPicture, @eddiemoya, @edwin-at-studiojoyo.com, @ericlewis, @filosofo, @frank-klein, @Funkatronic, @garhdez, @gauravmittal1995, @gcorne, @georgestephanis, @ghost1227, @grahamarmfield, @harrym, @helen, @iamtakashi, @iljoja, @issuu, @ixkaito, @jackreichert, @JanHenkG, @Jayjdk, @jdgrimes, @jeffstieler, @jeremyfelt, @jesin, @jgadbois, @jjeaton, @jkudish, @joedolson, @johnbillion, @johnjamesjacoby, @johnzanussi, @jtsternberg, @kitchin, @knutsp, @kovshenin, @kpdesign, @kraftbj, @kurtpayne, @kwight, @lancewillett, @lessbloat, @markoheijnen, @mdbitz, @MikeHansenMe, @mikemanger, @miqrogroove, @mrmist, @MuViMoTV, @nabil_kadimi, @nacin, @nd987, @Nessworthy, @netweb, @niallkennedy, @ocean90, @obenland, @pdclark, @pento, @purzlbaum, @rclations, @redsweater, @ruudjoyo, @schoenwaldnils, @scribu, @senlin, @SergeyBiryukov, @sharonaustin, @shaunandrews, @simonwheatley, @sixhours, @slimndap, @solarissmoke, @tar.gz, @tillkruess, @topher1kenobe, @torresga, @UmeshSingla, @winterDev, @wonderboymusic, @wpsmith, @zamfeer, and @duck_ for their core contributions!
Interested in joining in? Write or test a patch for 4.0.
Summary of 5/7 dev chat (IRC log):
Proposed 4.0 ideas
- Multisite enhancements: SSL, get site creation/editing UIs in line with the arbitrary domain/path support. Planning on weekly office hours.
- Mobile experience: media modal and upload flow, Press This feature plugin.
- oEmbed discoverability, usability, and caching improvements.
- Widgets: JS API (#28093)
- Taxonomy roadmap, part one.
- Background images in the customizer.
- Plugin installer improvements: better search and more information (needs .org API support), upgrading a plugin or theme via zip upload (#19641)
- Export API improvements/overhaul (#22435)
- Post meta: support for revisions (#20564)
- APIs for posts/comment types/statuses. Ping @nacin if interested in collaborating (#12706).
- Continuous a11y enhancements, particularly in the media modal.
- Texturize patches, continuing on performance enhancements and bugfixes in 3.9.
If you are interested in any of the above, sound off in the comments below.
Potential themes for the release:
- More visual cues in the admin for user tasks, as has been done for themes.
- Continuing to improve the editing and media experiences.
- Lots of under the hood things and API attention to make devs happy.
- Front-end Editor looks like it’ll continue past 4.0, as enabled by being a feature as a plugin, but we should continuously keep an eye on it and see what improvements can be brought into core sooner.
- Media Grid View and Press This are under way.
- WP API continues to move forward.
Patches needing early dev attention
- #17689: Terms should not be sanitized inside term_exists(). This is the first step in moving along with the taxonomy roadmap, so please look here if this has been of interest to you. Potentially needs more unit tests. Thanks to @aaroncampbell for the latest patch.
- #14759: Improve the way oEmbed deals with caching (patch from @markjaquith).
And finally, 3.9.1 is out now, if you haven’t already updated or been updated.
Lots of news to share! First: Helen Hou-Sandí has had guest commit for the past three release cycles. She’s been spending the last year reviewing contributions, mentoring contributors, and working on some of our larger UI projects. I’m proud to announce @helen is now a permanent committer to WordPress!
We’ve invited John Blackbourn (@johnbillion) to be a committer for the 3.9 cycle. His strong, consistent contributions have been backed by excellent judgment and temperament.
Matt Thomas, who led the dashboard redesign in 3.8 (and 3.2, and 2.7, etc.), will keep his commit to continue to maintain and improve WordPress UI. He’s been a great mentor to many contributing designers and his long-term impact is indelible.
For the last few years, we’ve been granting commit access on per-cycle basis, sometimes for a particular component, feature, etc. Generally, after about a year, a guest committer can be considered for permanent commit access. Dominik Schilling, Sergey Biryukov, Drew Jaynes, and Scott Taylor have all had their commit extended for 3.9.
Drew (@DrewAPicture) was given temporary commit for inline documentation starting with 3.7. He’s been heading up the long-running initiative to document every hook in WordPress. Scott (@wonderboymusic) also started committing during 3.7, and has a particular penchant for digging deep into the query and taxonomy APIs. And Sergey (@SergeyBiryukov) and Dominik (@ocean90), well, they are forces of nature.
(@aaroncampbell was also given guest commit in 3.7, but he ended up not having much time to use it.)
Here’s a full list of those with permanent commit: @markjaquith, @ryan, @westi, @matt, @azaozz, @dd32, @koopersmith, @duck_, @helen, and me (@nacin); @lancewillett for bundled themes; @iammattthomas for UI. You might have also seen commits before from @josephscott (XML-RPC), @nbachiyski (internationalization), and @mdawaffe (secret weapon for really tricky problems).
Next weekly meeting is January 8. Happy new year, everyone. Here’s to a great 2014.
Kicking off the WordPress 3.9 development cycle | 10up, BenRacicot, Nashwan Doaqan, and 3 others are discussing. Toggle Comments
Version 0.7 is tagged and I am planning to submit it to the WordPress.org plugin directory later today or tomorrow.
Viewing code revisions now feels much more native: By default WordPress makes use of normalize_whitespace() before comparing two posts to one another. This results in loss of blank lines and missing multi-space indention as often seen in css files. I fixed this by plugging into the wp_text_diff() function (#302). Further more you now get the correct menu item expanded when viewing code revisions (#316).
Besides those I am still struggeling with syntax checking (#335). Looks like I will be settling for just using ‘php -l’ if available. Problem there is I am still not able to get a reliable path to the php binary. Since PHP 5.4 there is the PHP_BINARY constant, so I need a way to get it manually in PHP versions lower than 5.4..
In the days before the WordPress Community Summit in October, a number of contributing developers huddled together to discuss a number of long-term architecture ideas. Among them were taxonomy meta and post relationships. (Ah, I see I now have your attention!) This post is more or less a proposed roadmap. It’s an ambitious plan that is designed to take place over perhaps five or more releases.
(During WordCamp San Francisco’s keynote, @matt talked a little about a new aim to build teams of contributors and reviewers around individual core components. There will be a lot more on that in the coming days and weeks. For now, here’s a post that covers two components, post types and taxonomy.)
The discussion included all core committers at the time — @ryan, @markjaquith, @westi, @azaozz, @nacin, @dd32, @koopersmith, and @duck_ — and a number of contributing developers, including @aaroncampbell, @dh-shredder, @helen, and @scribu.
At the moment, terms are represented in WordPress using two different IDs: a term ID, and a term taxonomy ID. A term ID (and name and slug) can actually appear in multiple taxonomies, so to identify a particular term, you must have either the term ID and the corresponding taxonomy, or just the term taxonomy ID. This dates back to the original taxonomy schema in WordPress 2.3. At the time, the concept of “shared terms” seemed like it could be an important abstraction. Hindsight is 20/20, and shared terms are the bane of taxonomies in WordPress.
So when we talk about term meta, we’re actually talking about term taxonomy meta — meta associated with a term taxonomy ID, not a term ID. The problem is, the public ID used in the API and elsewhere is the term ID (and, by necessity, a taxonomy is also passed). This confusion — and the need for there to be only one object identifier in our metadata API (term taxonomy ID, not two, as in term ID and taxonomy) — has long forced us to table the discussion of term metadata.
(There are separate conceptual issues here — at what point does a term with metadata simply become a post-like object that can relate to other posts? And given post relationships, could terms and posts actually converge in their underlying schema? I’m not actually going to answer those questions in this post. Purely talking schema and architecture at this point.)
At WordCamp San Francisco last year, four of us — me, Gary Pendergast (@pento), @scribu, and @koopersmith — came up with a rather crazy way to make major changes to our table schema while still being backwards compatible. In fact, we came up with two ways to do it. This was the plan everyone heard and discussed at the summit.
It was clear that shared terms had to go. The first step is removing a UNIQUE index on the slug field in the
wp_terms table. (This is dependent on #17689.) Then, we stop creating new shared terms. Step three, on an upgrade routine, we actively look for any existing shared terms and split them.
These three initial steps must happen over two to three major releases, as we’re talking about a bug fix, a schema change, an API change, and an upgrade routine — in that order.
Then comes the fun part, in yet another major release. With shared terms split, term ID and term taxonomy ID will be identical on every install. If we moved the slug and name fields from
wp_term_taxonomy, we could actually drop
How can we remove an entire table but still be backwards compatible? We came up with two solutions:
- Because all fields in
wp_termswill exist in
wp_termscan be recreated as a MySQL view to be a read-only mirror of term data, thus being compatible with all existing queries.
- Because all fields in
wp_termswill exist in
wp_term_taxonomy, and because table aliases like `t`and `tt` are always used when joining these two tables,
$wpdb->termscan simply be set to
$wpdb->term_taxonomy. A query that previously joined
wp_term_taxonomywould just join itself.
In all: Using the second approach (yes, it works), it took about 20 lines of code to make WordPress run without a
wp_terms table. Wow, right?
So by this point, we would finally have a sane taxonomy schema. Less joins, a cleaner API (probably helped by a new
WP_Term object to model
WP_User), no more shared terms headaches, and a single, sane ID for a single taxonomy’s term.
Once that is all finished, we can finally have term meta. Maybe. (Kidding. (Kind of.))
Where do post relationships come in? The existing Posts 2 Posts plugin by @scribu is fantastic and serves the niche well. But we’re not really comfortable making any architecture or API changes along these lines while our taxonomy schema is still in a far from ideal state.
The post relationships plugin supports posts to posts, and posts to users. Core taxonomy relationships supports posts to terms, but it can also be rigged to relate users to terms. (It also supported links to terms, yet another object type.) We didn’t fully iron out this idea yet, but one idea is to convert the current
wp_term_relationships table to a more generic object relationships table, which can support posts to posts, posts to users, terms to users, and of course posts to terms (and, really, any arbitrary relationship).
A disclaimer: This post doesn’t promise anything. Do not rely on the contents of this post for future projects. It will take us some time to lay out the proper groundwork and make sure we get this right. Do not expect this to happen in WordPress 3.7, or even 3.8. (Actually, do not expect this to happen at all.)
That said, I’m really glad to get this information out there and I’m excited to hear any feedback you may have. We are always thinking toward the future, and a lot of contributing developers have mile-long roadmaps in their heads — it’s long past time to get those on paper.
I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.
Things this will likely involve:
- Local storage of post data while editing, in-between autosaves and manual saves.
- More frequent “heartbeat” pings to the server (allowing data to hitch a ride at certain intervals, and also allowing us to quickly deliver messages back from the server about events).
- Real and more granular post locking. Right now we just have a wimpy notice that isn’t a good deterrent against people simultaneously editing a post and overwriting each other’s changes.
- Probably some interaction with the team working on improving Post Revisions.
- UX work for making recovery from failure scenarios smooth, clear, and worry-free.
Post formats is going to be a major win for 3.6. It’s one of those features that has so much potential, but it really falls short in usability and honestly we haven’t really taken the time to truly show what it can do. We’re going to re-think the admin UI for post formats, similar to what Alex King did with his WordPress Post Formats Admin UI plugin. The goal is to make post formats much more user friendly and then show them off with the 2013 theme.
We’ve chosen @helen as lead for this project. Helen has done some amazing stuff customizing the post screen for various projects, and we’re glad to be able to leverage that for core.
Anyone interested in helping with this feature, please comment to let us know. The 3.6 schedule is considerably shorter than the 3.5 schedule was, so we really need to get moving on things as quickly as possible.