Week in Core, Jan. 19-26 2016

Welcome back to the latest issue of Week in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., covering changes from January 19th – January 26th, 2016, changesets [36351-36406]. Here are the highlights:

  • 55 commits
  • 44 contributors with props
  • 99 tickets created
  • 10 tickets reopened
  • 86 tickets closed

Ticketticket Created for both bug reports and feature development on the bug tracker. numbers based on trac timeline for the period above.

Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

Code Updates

AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)

  • Improve the focus style on the Credits screen. Leads and contributing developers will now look nicer when focused. Also, combines adjacent image and text links for the same resource thus simplifying markup and reducing noise for screen reader users. [36406] #34953
  • Accessibility: Improve the color contrast ratio replacing the residual occurrences of the #777 gray. Uses the existing #72777c on white backgrounds and the new #555d66 “dark medium gray” on darker backgrounds. [36396] #35605
  • Fix the color contrast ratio in the login screen. [36395] #31548
  • Remove title attributes from the Menus screen. [36379] #35374

Cache APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.

  • Pass $clean_taxonomy param to ‘clean_term_cache’ action. [36399] #35611

Comments

  • Fire an action after a comment is removed from object cache. When a comment is removed from the object cache, the clean_comment_cache action is now fired. This provides pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme developers a chance to perform secondary cache invalidation as needed. [36405] #35610
  • In comments list table, $post_id should default to false rather than 0. [36387] #35090
  • Allow comment query results to be limited to comments with comment_post_ID = 0. [36381] #35090
  • Ignore hierarchy in pagination calculation when comment threading is disabled. Merges [36275] to the 4.4 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch".. [36362] #8071, #35419
  • Respect all post-related filters in WP_Comment_Query. Merges [36326] to the 4.4 branch. Fixes #35478. [36361] #35478
  • Use the post-filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. WHERE clause when querying for comment descendants. Merges [36277] to the 4.4 branch. Fixes #35192. [36357] #35192
  • Always respect $comments array passed to wp_list_comments(). Merges [36276] to the 4.4 branch. [36356] #35175, #35356
  • In comments_template(), don’t run hierarchical queries if comment threading is disabled. Merges [36226] to the 4.4 branch. [36353] #35378

CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.

  • Use “(Untitled)” as site title if blogname is empty. Fixes #35579. [36388] #35579
  • Add shift-click on nav menu items in preview to focus on corresponding nav menu item controls in pane. [36383] #32681
  • Hide help toggle button in panel when no description is supplied. This aligns with the .customize-panel-description element which is also excluded if there is no description. [36374] #35540
  • Fix click.preview event handler for jump links and shift+clicks in preview. Fixes #26005. [36371] #32681, #26005
  • Prevent erroneously directing user to login screen when closing. Fixes #35355. [36363] #32637, #35355
  • Respect custom pagination params when using wp_list_comments() in a query loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop.. Merges [36324] to the 4.4 branch. [36360] #35402

Documentation

  • Correct return value for is_allowed_http_origin(). [36398] #35607
  • Clarify that mu-plugins can’t be “active” in docs. [36397]
  • Fix parameter documentation ordering in the hook docs for the register_taxonomy_args filter. [36391] #32246

Editor

  • TinyMCE: add inline link dialog. First run. Links the advanced button to the “old” dialog for now. [36384] #33301
  • TinyMCE: remove the srcset and sizes attributes (if any) after replacing or editing an image. [36376] #35434

Emoji

  • Work around a mod_security rule which prevents pages with 4 or more instances of String.fromCharCode( from being served. [36359] #35412

I18ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.

  • Add the text domain to translate_nooped_plural() calls as well. [36390] #34126
  • Add a test for the add-textdomain.php script. [36389]

Media

  • In _wp_handle_upload(), move ending brace to a new line. [36373] #35565
  • When reusing the initial values from the global MediaElement config object, the config object should first be cloned. Objects in JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. are references that will retain any changes. Fixes #34152. [36364] #34152

Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site

Plugins

  • Pass data consistently on plugin, networknetwork (versus site, blog) plugin, and network theme screens. [36394] #35335

Query

  • Respect ‘suppress_filters’ when filtering search-related SQL. [36404] #35594
  • Introduce $comment_status and $ping_status params for WP_Query. [36403] #35601
  • Avoid invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. SQL when building ORDER BY clause using long search strings. Merges [36251] to the 4.4 branch. Fixes #35361. [36354] #35361

Quick/Bulk Edit

  • Remove a no more used jQuery loop for unsupported post formats. See #24096. [36375] #23426, #24096, #35564
  • On the Taxonomies screens, prevent a page reload when pressing Enter on a focused field. Merges [36260 to the 4.4 branch. [36355] #35401

Posts, Post Types

  • Allow is_post_type_viewable() to accept a post type name. Previously, it accepted only a post type object. [36402] #35609
  • Add tests for is_post_type_viewable(). [36401] #35609

TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies.

  • Populate term cache with proper clone of term objects. Merges [36323] to the 4.4 branch. [36358] #35462

Themes

  • Themes: Enhance filtering options for allowed themes on a network. [36366] #28436

TinyMCE

  • Update to 4.3.3. Update the QUnit tests and revert back to testing the non-minified files in /src. [36352] #35539

Upgrade/Install

  • Switch the locking mechanism to using static methods so that it can be accessed from other upgrade-classes. [36370] #34878

Widgets

  • Show the “Clear Inactive Widgets” button only after the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. with inactive widgets. Merges [36326] to the 4.4 branch. [36369] #35447

Props

Thanks to @5um17, @afercia, @azaozz, @berengerzyla, @birgire, @boonebgorges, @chandrapatel, @chriscct7, @danielbachhuber, @dd32, @dmsnell, @dotancohen, @drebbitsweb, @DrewAPicture, @ericlewis, @Fab1en, @firebird75, @Frozzare, @georgestephanis, @iseulde, @ivankristianto, @jeremyfelt, @jmdodd, @johnjamesjacoby, @johnnypea, @kraftbj, @lamosty, @luciole135, @MattGeri, @michalzuber, @mrahmadawais, @obenland, @ocean90, @pauldewouters, @rob, @salvoaranzulla, @scarinessreported, @SergeyBiryukov, @spacedmonkey, @tahteche, @walbo, @westi, @westonruter, and @wonderboymusic for their contributions!

#4-5, #week-in-core

Dev Chat Summary, February 4th

Agenda

https://make.wordpress.org/core/2015/02/04/dev-chat-agenda-february-4-2015/

Chat Archive

https://wordpress.slack.com/archives/core/p1423083640001782

Decisions, Announcements

  • @drew will lead a NUX working group during the 4.2 cycle. The first chat will be held in #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-flow next Tuesday at 19:00UTC / 2:00 pm EST.
  • @ryan (hey, that’s me) will attempt to be UXUX User experience lead for 2015. 🙂

Assignments

Links Mentioned

https://make.wordpress.org/core/2015/02/03/new-lead-developers-helen-and-dion/

Screen Shot

https://github.com/MichaelArestad/Press-This/issues

https://core.trac.wordpress.org/ticket/29820

https://core.trac.wordpress.org/ticket/12696

https://core.trac.wordpress.org/ticket/29820#comment:43

https://make.wordpress.org/core/2015/01/26/customizer-transactions-proposal/

https://github.com/xwp/wordpress-develop/pull/61

https://core.trac.wordpress.org/ticket/30988

https://core.trac.wordpress.org/ticket/30936

https://core.trac.wordpress.org/ticket/30937

https://core.trac.wordpress.org/ticket/28599

https://core.trac.wordpress.org/ticket/26504

https://core.trac.wordpress.org/ticket/29079

https://core.trac.wordpress.org/ticket/30589

https://core.trac.wordpress.org/ticket/21616

https://core.trac.wordpress.org/ticket/18946

https://make.wordpress.org/core/2015/02/04/new-chapters-for-ryan-and-westi/

https://www.openhub.net/p/wordpress/contributors?query=&sort=commits

Continue reading

#meeting

New chapters for Ryan and Westi

WordPress lead developers Ryan Boren (@ryan) and Peter Westwood (@westi) started contributing to WordPress more than a decade ago. Ryan and Peter, along with Mark and Matt, served as the foundation for much of the early years.

For some time now, Ryan and Peter have avoided weighing in on technical matters. Very simply, when you aren’t able to be active in development, you know you’re not up to speed, and you realize your words shouldn’t carry the weight that they do. Being able to make this judgment is one of the things that makes both of them such great leaders.

We’ve all been there, at least for particular features or releases. It’s worth noting, for example, that my own time on coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. has been cyclical for years, as sometimes I end up working full time on the security team, maintenance releases, the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ site, or related projects.

The great thing is, there are a lot of fantastic developers who have stepped up over the last few years to seamlessly fill in the huge holes they’ve left. Some of that culminated in promoting Helen and Dion to lead developer yesterday, and my own promotion three years ago.

When I started contributing, I received a lot of advice and learned a lot from both of them. Peter reviewed a lot of my code and was the guy who would revert my code when I broke something. 🙂 Ryan became my mentor and pushed me to become the engineer I am today.

And so, it is with mixed emotion I share that Ryan and Peter have stepped down as lead developers.

Peter will be moving into a dormant/inactive/emeritus status. We hope to have him back when his life and work allows. In the meantime, you may see him committing a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fix here and there, as he is wont to do.

Ryan has been focusing all of his energy on improving UXUX User experience for more than a year, especially for mobile and touch devices, and especially for workflows like media management. So I’m pleased to say he’ll continue to do that: Ryan will be spearheading UX for WordPress in 2015. It’s been a while since we’ve had someone truly focusing on just UX, so this is really exciting.

Along with yesterday’s announcement, the active lead developers are @markjaquith, me, @azaozz, @helen, and @dd32.

Please join me in congratulating Ryan and Peter on an epic run. 🙂

The email used for notifications on Trac is…

The email used for notifications on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. is currently specified in Trac preferences. I’m changing this to pull automatically from your WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ profile. After this change, there will not be a way to have a separate email address for Trac and any manually specified email address will be overridden.

We need to make this change because, very simply, it’s a better user experience. By killing this extra user preference, it’s one less step users need to set up in order to receive notifications. (And a tighter feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. could possibly boost engagement.)

That will affect about a thousand users we have in the system, probably incidentally for most. But, about 50-100 users might have been deliberately declaring a separate email address; for example 50 users had “trac” appear specifically in their email. Even without a dedicated email, it is trivial to filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. Trac emails; you just might need to make some adjustments.

As you may have noticed, this is part of a series of changes I’ve been making to Trac. I’ll be doing a summary post in a few days outlining everything that has changed.

NOTE: This does not affect wp-trac@lists.automattic.com. If you subscribe to the “firehose” this is not affected.

Edit, 20:23 UTC. This is now enabled. For the moment, the email address will sync when you next visit Trac. Please find me if you have any questions.

#housekeeping, #trac

Commit announcements for 3.9

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 UIUI User interface projects. I’m proud to announce @helen is now a permanent committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. 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 taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. 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.

#3-9, #commit

Potential roadmap for taxonomy meta and post relationships

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 taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. 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 WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. San Francisco’s keynote, @matt talked a little about a new aim to build teams of contributors and reviewers around individual coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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 bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fix, a schema change, an API change, and an upgrade routine — in that order.

Then comes the fun part, in yet another major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.. 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_terms to wp_term_taxonomy, we could actually drop wp_terms.

How can we remove an entire table but still be backwards compatible? We came up with two solutions:

  1. Because all fields in wp_terms will exist in wp_term_taxonomy, wp_terms can be recreated as a MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. view to be a read-only mirror of term data, thus being compatible with all existing queries.
  2. Because all fields in wp_terms will exist in wp_term_taxonomy, and because table aliases like `t`and `tt` are always used when joining these two tables, $wpdb->terms can simply be set to $wpdb->term_taxonomy. A query that previously joined wp_terms with wp_term_taxonomy would just join itself.

In all: Using the second approach (yes, it works), it took about 20 lines of codeLines of Code Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses. 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_Post and 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 pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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.

#post-types, #roadmaps, #taxonomy

Code Revisions: Week 1

My initial post did get quite some feedback – not overall good. I expected the negative feedback. I did not take part in the discussion, but I think others did a nice job there (thanks Jen & Aaron). Also thanks to the developers who offered to give support when I might get stuck.

To make it short:  I already prepared myself for this project before the official coding phase started and could skip the initial “warm up phase”. At the moment I am ahead of the timeline.

This week mostly was on the connection between a file and a post (#284), the initial creation of a post when a file is edited for the first time (#285) and the updating of the corresponding post on every edit (#287). I also chatted with my mentors about the brought up security worries. We will definitely look into those and discuss them (and possible solutions) with lead developers – the code resulting from this project will not make it into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. if it introduces security flaws!

The next week will be about viewing code revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision.. This on the one hand includes a revisions list which needs to be added below the editors (#286) and on the other hand fixing possible problems with the revisions view on revisions.php (e.g. #289). I will take the negative feedback as a challenge and still hope to get code revisions into core. Till next week then.. Comments are open!

#code-revisions, #weekly-update

Revisions Update, 2/11

As has been the case for many sessions now, Monday’s revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. office hours focused on changes to the UIUI User interface. @karmatosed provided new mockups, influenced by a thread on the Accessibility blog. @adamsilverstein also posted a series of patches on #23396 that begin to implement the general direction we’ve chosen for UI updates (aside: we’ll do our best to keep future mockups on this ticketticket Created for both bug reports and feature development on the bug tracker., for easier discovery; until now, most have been posted in the comments on these update threads). We are certainly approaching a consensus on the new design, but have held off on any significant UI-specific coding until we’re confident that our efforts won’t be wasted.

Beyond UI, there are patches on three tickets that could use testing: #16215, #22289, and #19932. @adamsilverstein and @westi are working on unit tests, which should help move the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. review along.

We should have new mockups to review during tomorrow’s office hours at 1500 UTC in #wordpress-dev.

[IRC log]

#3-6, #revisions

Editorial Flow Update, 2/7

Editorial flow is making progress and hitting interesting questions to answer. Our two primary tickets right now are #12706 and #23314.

For the first, we’re waiting on feedback on the approach from @nacin. Once we’ve gotten confirmation it’s the right direction, I’ll continue working to make the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. commit-ready.

For the second, the biggest question was how we should handle revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. for post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. terms. In the interest of getting to a committable patch, we’ll be dropping post meta / custom taxonomy support in favor of just being able to stage edits for the title and body content. Furthermore we’ve decided it would be worthwhile to add a new post type property so this functionality is opt-in. Posts and Pages in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will receive this by default.

Our primary goals are to have commit-ready patches for both tickets by the beginning of next week. Konstantin’s secondary goal is to chat with @westi and @ethitter and see whether revisions for post meta is within scope for 3.6. My secondary goal is to go through other editorial flow tickets and touch base with where each is at.

Next office hours are Tuesday, February 12th at 10 am PT / 1 pm ET / 1800 UTC.

Office hour log

#3-6, #editorial-flow

Revisions Update, 2/7

We started today’s office hours by reviewing @karmatosed’s latest mockups for the revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. screen. We’re in agreement that these reflect the direction we’ll take, so @adamsilverstein will begin coding the changes in preparation for Monday’s meeting. As some concerns have been raised about the use of red and green, @karmatosed will post to the Accessibility group’s P2 asking for feedback on the current mockups. She will also explore the use of patterns to differentiate additions and deletions, as suggested by @helen.

@westi made a few suggestions, based on his recent experiences with Revisions, which we’ve agreed to incorporate. For clarity, the current version will be included in the revisions list to provide a stronger connection with the overall revisions workflow. Second, we decided that when first landing on the revision screen for a given post, we should show the diff of the current version and its immediate predecessor revision; since most users are probably looking for this anyway, why not save them a step?

Lastly, we chatted about the status of code-oriented tickets scoped for 3.6. A few (#16215, #22289, and #19932) have patches, which we’ll be reviewing and providing feedback on before Monday’s meeting. With any luck, we can land at least one in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. before the next dev chat. Beyond that, development on the remaining tickets should progress over the weekend, with the aim of having more patches to review for our next office hours.

For reference, the tickets that are in scope for 3.6 (at least at this point), can be found here.

[IRC Log]

#3-6, #revisions