Dev Chat Summary: January 18th (4.7.2 week 1)

This post summarizes the dev chat meeting from January 18th (agendaSlack archive).

4.7.x Releases

  • Moving to monthly checkins for 4.7.x releases
  • A few people stepped up to lead a future 4.7.x releases, a great way to get involved in the release process. If you’re interested in leading a future minor release, ping @samuelsidler anytime.
  • For 4.7.2, we haven’t set a schedule yet, but we’ll be checking tickets and commits in early February to decide if we should release. @jnylen0 will be the release lead.
  • Reminder for those who helped get 4.7.1 out, please check the handbook to see if updates are needed to help @jnylen0 on 4.7.2.
  • @jnylen0: some API stuff I want to get into a potential 4.7.2, but let me know about other tickets you’d like to milestone
  • Outside pressure on MIME issues not as horrific as one might have expected (ticket #39550: Some Non-image files fail to upload after 4.7.1)
  • Potential that since people using special MIME types (which are the most likely to get caught by this bug) are already aware of having to add in custom mimes, adding in the “unbreak” plugin to fix the problem right now isn’t seen as insurmountable.

REST API team update

  • kicking off the new year by defining the scope of our activities, and prioritizing what is most critical to do first
  • @kadamwhite, @jnylen0, @tharsheblows, @kenshino, & others working on expanding the documentation
  • As we’ve moved the support for the REST API from the “WP-API” github repo, we’re seeing a few repeat questions that can be clarified with better docs & docs organization
  • Today we finished grouping existing docs from the old wp-api.org site into “Using” and “extending” buckets, which are reflected in the left nav; next up, we’ll be adding more docs for using the basics of what’s there
  • @rmccue leading the technical investigations into what to prioritize from an implementation standpoint (see: January 9th 4.8 kickoff meeting notes)
  • a lot that could be converted to use the API within WP-Admin, but change for the sake of change has never been a core value of this project
  • Whereas for something like list table actions, there’s a lot of inconsistency within the admin and converting some of those areas of functionality to use the REST API endpoints would be a clear win
  • We’re using a Trello board to track the areas of investigation
  • the Multisite and BuddyPress teams are both investigating how best to improve or create API endpoints tailored to those use cases
  • @flixos90 did an excellent writeup of our users endpoint discussion
  • We are sorting out how user and site membership management and display should work for the users endpoint.
  • master ticket #39544: REST API: Improve users endpoint in multisite
  • the REST API team intends to continue using the feature projects model to structure proposed API enhancements (such as menu support), with the added requirements of starting from a design document, and checking in with a core committer for periodic review to avoid the feature project from becoming silo’d
  • Multi-site is the first such feature project that’s officially under way.
  • For 4.7.2 we should be looking for related bugs around the existing functionality
  • @jnylen0: propose that we continually evaluate test and documentation coverage for new additions, as an excellent way to find bugs before they ship and we are stuck with them
  • Regarding bugs, to all: when (not if) you find a documentation issue or omission, or find an area where the API does not behave as expected, you are all welcome in #core-restapi at any time and we welcome the feedback.
  • We’re glad to see that the support questions so far tend to fall in a few specific buckets, but this is a new thing and the more eyes on it, the more likely that we’ll be able to identify the key areas where improvement will really drive admin or customizer improvements.
  • REST API team meeting is weekly at Monday 14:00 UTC in #core-restapi, and we welcome one and all to come chime in about how you’d like to see this used

Customizer team update

  • Please read and contribute to the discussion happening on the “What makes a great customization experience?” post
  • Also recommend reading through the meeting that happened earlier today in #core-editor. There’s going to be a lot of overlap, especially as the editor team starts working on content blocks. Lots of discussions have been happening there and in #core-customize related to what we focus on for customizer in the immediate term.
  • We’re identifying some smaller, quick wins we can do to improve the customization experience while content blocks are being built.
  • Update coming on Make/Core soon for more ways to get involved and a separate post from @karmatosed on Make/Design for some ways to help us test the existing customization flow
  • Customize team meeting is weekly at Monday 17:00 UTC in #core-customize, please do join us for general brainstorming and ticket triage (see also: prior meeting notes)

Editor team update

  • Please read and comment on the “Editor Technical Overview” post
  • Recap of #core-editor meeting on a target of a prototype plugin for exploring these concepts from @matveb: Yes, target could be:
    • Data structure.
    • Parsing mechanism.
    • General UI for block display / controls.

Trac Ticket(s)

  • #39535: Canonical redirects disallow tag named comments
    • @asalce: looking to get owner on the ticket and review of patch
    • will ping @markjaquith or @dd32 as maintainers of Canonical component

#4-7, #4-7-2, #dev-chat, #summary

Dev Chat Summary: January 11th (4.7.1 week 5)

This post summarizes the dev chat meeting from January 11th (agendaSlack archive).

4.7.1 Update

2017 Release Schedule

  • 4.7.1 will NOT be last in the 4.7 branch, so it’s best to start on anything that needs to go in 4.7.2 immediately
  • Proposal from @samuelsidler:
    • Since we don’t have a set release date for WordPress 4.8, I’d like to propose we look at applicable 4.7.x issues about once a month, and decide if we should ship a release.
    • For 4.7.2, I think we should take a look at issues at the beginning of February, during devchat, and decide if the issues warrant a release, then ship about a week later.
    • That would mean we’d be looking at a release around February 14, but we’d update the schedule after looking at the specific issues.
    • We’d want to evaluate issues the week of February 6 and make a call.
    • I think we said regressions and minor bug fixes are okay in 4.7 at the moment, but we can evaluate other fixes on a case-by-case basis.
  • General agreement on approach, though date for 4.7.2 to be confirmed in February
  • Plan to choose someone soon to lead 4.7.2, maybe at or before next week’s devchat, to keep things moving along. @jnylen0 @aaroncampbell @voldemortensen @swissspidy interest in leading that or future releases. If you have interest, ping @samuelsidler as he’s compiling a list of those interested.
  • @davidakennedy: I’d imagine we’ll package up default theme updates more in minor release. Though, we can also release those whenever to .org. I’d like to think through a schedule for that. Maybe looking at things monthly, and making a decision.

Trac Tickets

  • #39309: Secure WordPress Against Infrastructure Attacks
    • @paragoninitiativeenterprises: propose making it a point of focus for 4.8
    • @aaroncampbell: may not fit as a focus for 4.8, since those should be in the editor, customizer, and API areas. But good to talk about and try to figure out steps forward.
    • @paragoninitiativeenterprises: recommend against punting too far into the future
    • @samuelsidler: let’s think through how to implement it and work on patches for that, then decide which release to put it in
    • @westonruter: Security and performance hardening are ongoing and not limited to focuses
    • @paragoninitiativeenterprises: would like to see this land ASAP, will work on a patch with necessary tests and any necessary back-compat and post to the ticket
  • #38418: Add telemetry (aka usage data collection) as opt-in feature in core)
    • @lukecavanagh: thoughts from the group?
    • @brechtryckaert: personally in favor of usage data collection, but we’ll need to be very upfront about it upon release to avoid criticism; also worried what the impact would be on loading times/slowdown due to communication with the servers that store the data, would all depend on the way it’s implemented.
  • #39157: Feed returns 404 when there are no posts
    • @stevenkword: looking for feedback on approach on adding new conditionals and what to do now. Issue was addressed in 4.7 but caused a regression and code was reverted for 4.7.1.  After 4.7.0 landed, before the reversion, an updated patch was committed that resolved the regression, but it introduced new getters to WP_Query.
    • @stevenkword: would like to find a resolution for this for 4.7.2, but need some opinions how to solve it.
    • Will ping @peterwilsoncc and @dd32 to look at it

#4-7, #4-7-1, #dev-chat, #summary

Week in Core, November 30 – December 6, 2016

Welcome back the latest issue of Week in Core, covering changes [39380-39529]. Here are the highlights:

  • 150 commits
  • 63 contributors
  • 140 tickets created
  • 17 tickets reopened
  • 104 tickets closed
  • WordPress 4.7 released 🎉

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes

Administration

  • Accessibility: Remove inappropriate content from the Themes screen heading. [39528] #26601
  • Accessibility: Remove inappropriate content from the Add Themes screen heading. [39527] #26601
  • Accessibility: Remove inappropriate content from the Media Library screens headings. [39526] #26601

Build/Test Tools

  • Correctly set up the current screen during list table tests so that they don’t fail when run individually. [39481] #38761
  • Specify exact node version in package.json. [39480], [39478] #35105, #38657
  • Remove PHP 7.1 from allowed failures [39424-39425] #37625

Bundled Theme

  • Default Themes: Update version numbers and readme files for 4.7 release [39496] #38858
  • Twenty Seventeen: Fix CSS specificity problem with CSS feature query for object-fit [39495] #39073
  • Twenty Seventeen: Improve display of video header and header image in modern browsers [39485], [39483] #39035
  • Twenty Seventeen: Add specific font stack for Thai language [39484], [39482] #38937
  • Twenty Seventeen: Improve ARIA for the nav menu. [39451-39452] #39029, #39026
  • Twenty Seventeen: Ensure header text color updates in Customizer preview when cleared [39447-39448] #38993
  • Twenty Seventeen: Fix broken menu toggle in Customizer after menu items are added [39419], [39423] #38992
  • Twenty Seventeen: Fix style issues with gallery image links [39418], [39422] #38969
  • Twenty Seventeen: Hide front section panels on page load of Customizer. [39417], [39421] #38951
  • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39416] #38995
  • Twenty Seventeen: Better handling of custom headers when no image is set. [39413-39414] #38995
  • Twenty Seventeen: Make spacing on pages without comments consistent [39404-39405] #38972
  • Twenty Seventeen: Make sure header text color is applied when color schemes are active. [39397-39398] #38980
  • Twenty Seventeen: Make fixed navigation apply at correct height on front page, without header video or image [39394], [39392] #38927
  • Twenty Seventeen: Provide a background color fallback for non-webkit browsers on input styles [39388] #38939
  • Twenty Seventeen: Allow child themes to easily extend custom color patterns [39386] #38949
  • Twenty Seventeen: Make screen reader text on scroll arrow more meaningful [39384] #38970
  • Twenty Seventeen: Keep header videos from extending past footer. [39380-39381] #38950

Comments

  • Merge a similar string between comments.php, XML-RPC and the REST API comments controller. [39508] #39013

Customize

  • Prevent infinite full refresh from occurring when selective refresh falls back for a nav menu that has items excluded from rendering via filtering. [39510-39511] #38612
  • Defer populating post_name for auto-draft posts in customized state until posts are published. [39506-39507] #39078
  • Ensure changeset_uuid query param is removed from the customize.php window’s location once a changeset has been published (committed) with starter content. [39504-39505] #39081
  • Prevent posts/pages imported via starter content from being dropped when adding post/page stubs via nav menus and the dropdown-pages control. [39502-39503] #38114, #34923, #39071
  • Ensure textarea for Custom CSS displays as code (in LTR) when an RTL language is active. [39499-39500] #35395, #39085
  • Ensure a custom_css post insertion gets an initial post revision. [39479], [39477] #30854, #38672, #35395, #39032
  • Custom CSS: Change the help link to something better for users. [39467], [39466] #39015
  • Fix posts limit query arg for WP_Query from incorrect number to posts_per_page. [39434-39435] #39022
  • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39411] #38114, #38928
  • Reject a changeset update when a non-future date is provided and also ensure that a published changeset always gets set to the current date/time. [39409-39410] #30937, #38943
  • Fix handling of the nav menu item labels (titles) that match defaults (original titles) and fix the display of item type labels. [39395], [39393] #38015, #38955

Feeds

General

Help/About

Media

  • Accessibility: Improve keyboard accessibility avoiding confusing tab stops in the Media views. [39529] #30599
  • Docs: Add inline documentation for image-edit.js. [39493] #38748
  • Fix regression with display of small images in media library. [39399], [39396] #38965
  • Docs: Document the usage of the global $wpdb in _filter_query_attachment_filenames(). [39390] #38973

Misc

  • Tag 4.7 [39525] #
  • WordPress 4.7 “Vaughan”. [39524] #
  • Post-RC3 bump. [39519] #
  • WordPress 4.7 RC3. [39516] #
  • Post-RC2 bump. [39474] #
  • WordPress 4.7 RC2. [39473] #
  • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39415]

Options, Meta APIs

  • REST API: Register the admin_email setting in single site only. [39470-39472] #38990
  • REST API: Site URL setting should not be present on multisite installations. [39468] #39005
  • REST API: Correct the admin_email setting description for single site installs. [39406] #38990
  • Multisite: Display different descriptions for multisite or single site installations. [39407] #38990
  • Options: Pass the $passed_default parameter to the 'default_option_{$option} filter in add_option(). [39382] #38176, #38930

Plugins

REST API

  • Comments: Merge similar strings between comments.php and the REST API comments controller. [39490-39491] #39014
  • Merge similar date strings in the revisions and comments controllers. [39488-39489] #39016
  • Treat any falsy value as false in ‘rest_allow_anonymous_comments’. [39487] #39010
  • Docs: Add missing REST API-related args to register_post_type() and register_taxonomy(). [39462-39463] #39023
  • Merge similar strings in a comments endpoint parameter description. [39457] #39036
  • Fix bug where comment author and author email could be an empty string when creating a comment. [39446], [39444] #38971
  • Fix handling of some orderby parameters for the Posts controller. [39440-39441] #38971
  • Disable DELETE requests for users in multisite. [39438-39439] #38962
  • Return a WP_Error if meta property is not an array. [39436-39437] #38989
  • Add test for creating a comment with an invalid post ID. [39408] #38991
  • Fix incorrect uses of rest_sanitize_value_from_schema(). [39400-39401] #38984

Role/Capability

  • Don’t assign the delete_site capability to anyone on single site installs. [39494] #38326
  • Multisite: Replace is_super_admin() with manage_network for admin bar permissions. [39492] #39064, #37616

Taxonomy

  • Docs: Update an @since as there will not be a 4.6.2 before 4.7. [39475-39476] #37291
  • REST API: Capability check for editing a single term should use the singular form. [39464] #35614, #39012
  • REST API: Use the correct error message when editing a single term. [39460-39461] #39017
  • REST API: Fix incorrect capability check on term create. [39402-39403] #35614, #38958
  • Performance: Revert [38677] from the 4.7 branch. This avoids fatal errors caused with recursive calling of term functions within the get_terms filter. [39454] #21760

Themes

  • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39412] #38114, #38928

TinyMCE

  • Fix the styling of notices generated by the editor UI. [39501] #38917

Users

  • Clarify the return value of get_current_user_id() for non-logged-in users. [39486] #39051
  • REST API: Require the reassign parameter when deleting users. [39426-39427] #39000

Thanks to @andizer, @mor10, @adamsilverstein, @afercia, @azaozz, @boonebgorges, @celloexpressions, @ChopinBach, @clorith, @coffee2code, @davidakennedy, @dd32, @desrosj, @dlh, @flixos90, @georgestephanis, @helen, @helen, @hnle, @iaaxpage, @imnok, @jbpaul17, @jeremyfelt, @jnylen0, @joedolson, @joehoyle, @joemcgill, @johnbillion, @jorbin, @kadamwhite, @karmatosed, @ketuchetan, @laurelfulford, @littlebigthing, @lucasstark, @melchoyce, @michaelarestad, @mikeschroder, @mt8.biz, @nacin, @netweb, @ocean90, @ovenal, @pento, @peterwilsoncc, @presskopp, @rachelbaker, @rahulsprajapati, @ramiabraham, @ramiy, @rensw90, @rianrietveld, @rmccue, @samuelsidler, @sayedwp, @SergeyBiryukov, @sstoqnov, @The PHP tea, @timmydcrawford, @utkarshpatel, and @westonruter for their contributions!

#4-7, #week-in-core

Comments Bug Scrub Summary, 2016-05-09

The 90-minute bug scrub took place in #core-comments and ended in a 1 – 1 tie between @boonebgorges and @rachelbaker. You can read an archive of the bug scrub and discussion: https://wordpress.slack.com/archives/core-comments/p1462820499000036.

Attendees:
@rachelbaker, @boonebgorges, @aaroncampbell, @ocean90, @samuelsidler, @sidati, @presskopp, and @dshanske

Bug Scrub:
#6342 – moved to “Future Release”
#16365 – moved to “Future Release”
#16576 – moved to “Future Release” and needs testing for backwards compatability
#17913 – needs a refresh and screenshots
#18762 – closed, after testing confirmed this was resolved in 4.4
#26596 – moved to “Future Release” to limit the scope of the JS selector
#20302 – moved to “Future Release”, with suggestion from @boonebgorges
#20977 – moved to “Future Release”, but needs more input to determine how to approach

Open Floor:
#36427 – milestoned for 4.6, needs a refresh for the inline docs
#36564 – needs additional exploration before we can decide how to store the data/time of when a comment was last modified
#36424 – moved to “Future Release”, and requested a patch refresh and screenshots
#36409@sidati is going to attempt writing the unit tests

#4-6, #comments

Release Process Checklists

The release process is complex and beyond one person. Releasing is an intricate dance that we haven’t been sufficiently capturing. Knowledge siloed in heads needs to be committed to public, institutional memory. The upcoming 4.5 release is an opportunity to capture every step of the dance so that we can iterate process, automate away lingering drudgery, and improve our cognitive net for the stressful task of releasing to 25%. I like using checklists in this cognitive net. They relieve anxiety, make process transparent, and help teams flow during stress. We already have a couple release checklists. We can build on those while adopting a little checklist culture in a manner empathetic to developers and flow. Pitch:

Checklist cool tricks

Checklists…

  • distribute power.
  • push power of decision making to the periphery.
  • provide a cognitive net.
  • make the minimum necessary steps explicit.
  • make sure simple steps are not missed.
  • make sure people talk.
  • capture and shape real flow.
  • inspire flow in emergencies and sustain it through the quotidian.
  • capture flow between teams.
  • encourage a shared culture around flow.
  • accessibly capture institutional memory in the context of flow.

Attributes of a good checklist

What makes a good checklist? Checklist shouldn’t be about just checking boxes. Instead of being a chore and an admonishing finger, checklists should fit and assist real flow. The Checklist Manifesto offers these suggestions. Ideally, checklists…

  • are not lengthy.
  • have clear, concise objectives.
  • define a clear pause point at which the checklist is supposed to be used.
  • have fewer than ten items per pause point.
  • fit the flow of the work.
  • continually update as living documents.

See this checklist for checklists and this example checklist for more.

Stuff to checklist

The major release checklist attempts to use pause points and follow the suggestions above. The major and minor release checklists are pretty rough and incomplete and overlap with each other. These and the things to keep in mind list need love and unification with help from developers who are in the release flow and handling controls on the release train.

about.php is…quite the process. It needs the oxygenating powers of a checklist.

Checklist Feature plugin merges.

Checklist bundled theme releases so stuff like this makes it into institutional memory.

Beta and RC releases.

Plenty of other stuff. 🙂

Start by capturing. As we walk 4.5 release flows, capture.

Selected quotes from The Checklist Manifesto

Checklists supply a set of checks to ensure the stupid but critical stuff is not overlooked, and they supply another set of checks to ensure people talk and coordinate and accept responsibility while nonetheless being left the power to manage the nuances and unpredictabilities the best they know how.

Continue reading

#checklists, #pitch, #process, #release-process

4.3 Retrospective Results

I missed posting the 4.3 post mortem recap before I went on vacation, so without further ado:

We discussed the 4.3 release in Slack, where I asked for things that should be improved and things that went well, in order to get some feedback on how I did and helpful tips for future release leads (please find the Slack log here):

Should be improved:

  • Figure out some ways to get more testing and more eyes on betas and RCs.
  • Not having feature plugin complete (with core patch) before the merge window.
  • The menu customizer proposal could have been written differently in anticipation of community perception.
  • The people who are able to test term splitting properly are very limited. Not sure how to wrangle people for this kind of specialized testing.
  • there seemed to be a lack of movement at the end of the cycle.
  • Features like site icon should be done as a feature plugin.
  • The merge proposal could have been proof-read by someone from the core team.
  • Getting dev-notes written up earlier.
  • There were also not a lot of feature plugins ready for core at the start of 4.3.
  • Don’t think it’s really okay to be relaxing standards in the name of forcing something to fit a deadline.
  • We did a freeze/RC maaaaybe 24 hours before release that had significant changes in it, that did not feel good.
  • We completely changed features after beta 1.
  • I think in 4.2 we discovered that have a core mentor involved much earlier also helped get it to that “ready” place. Or closer to ready.
  • Find a way to increase participation for bug scrubs.

Went well:

  • passwords went really well.
  • We had a solid crop of guest committers that really made things go well for there project area.
  • Update to 4.3 went really smoothly over all as well.
  • We had some epic traction on Formatting component patches during this cycle. I’m a bit surprised how many tickets we closed with 4.3 because those are usually very problematic.
  • Touch and small screen usability improved significantly. Two of my top five issues were fixed outright and progress was made on a third.
  • I demoed the keyboard shortcuts in the editor to some people and they were like “DAMN, that’s amazing”.
  • i’m really happy about list table changes!
  • Shared taxonomy terms are dead.
  • WE RELEASED ON TIME!!!!

I’m probably a little biased, but contrary to what the amount of bullet points in each section might suggest, I agree with @samuelsidler who said: “Almost everything went really smooth.” I’m proud of what we accomplished, and the download and update numbers speak for themselves. Thank you again for everyone who helped out during the release, let’s make 4.4 even better!

#4-3, #post-mortem

Outlining a possible roadmap for the Customizer

Planning for the future is a necessary and important part of the WordPress development process. As we consider the future of WordPress – both as a whole and individual features – we publish proposed roadmaps to encourage greater discussion and give insight into the core team’s thought process.

The process of creating a roadmap is just as important as the vision behind it and the final roadmap itself. This process gives the entire community an opportunity to research and document history, define what specific items can be accomplished to bring us closer to the vision, and outlines how those tasks fit together within a possible timeframe.

What follows is a potential roadmap for the Customize component. If you’re interested in the future of live preview in WordPress, now is the perfect time to get involved and leave your feedback.


A couple of months ago, the WordPress lead developers met with the maintainers of the Customize component to discuss the future of live preview in WordPress. The goal of the chat was to come up with a potential roadmap for both the component and for how live preview can improve the user experience of WordPress for all users.

The ultimate goal of live preview in WordPress is to create user trust and remove the “save and surprise” inherent in some of the backend features.

After a lot of discussion, the group decided to target the following goals over the next two years:

  • Considerably improve performance.
  • Continue iterating on current live preview features to ensure they are solid and as easy-to-use as possible, including theme browsing and installation, menus, and widgets.
  • Experiment with new and different user interfaces. If we were creating live preview today, what would it look like? In what ways can we ease the feeling that you’re looking through a “porthole”?
  • Removal of the ambiguous mode. Currently, the Customizer is contained in a sidebar without the admin toolbar, but ideally there is the admin and the theme, and no in-between. One direction this may go is enabling “Customize” on the front end to immediately load the Customizer controls.
  • Experiment with a guided new user experience (NUX). Live preview lends itself to site setup. How can we improve the live preview experience and combine it with the NUX? Consider a “setup wizard” use case and ensure the flow has no dead ends, i.e. users can customize everything in one.

Those overall goals for live preview in WordPress can be rewritten into some specific features that are in development or planned for the future of the Customize component. These include:

  • Transactions. This re-architecture of some of the Customizer internals improves compatibility with themes by loading the preview using a natural URL, and allows Ajax requests or even REST API requests to be previewed. It also allows the preview to be viewed independently of the Customizer, so changes can be shared for others to review. See #30937.
  • Selective refresh. Only a piece of the page will need to be refreshed when this backend feature is implemented. (Formerly known as “Partial Refresh”.) Currently, this is available for menus in the Customizer. This eliminates duplication of display between PHP and JS, keeping it DRY. See #27355.
  • Concurrency. Allows for “locking” settings using the Heartbeat API, improving the overall user experience by preventing users from overwriting each other’s changes. See #31436.
  • Revisions. Enables plugin developers to add features like draft, roll back, and scheduled changes (e.g. “change my background on January 1”). This builds upon transactions, as the setting changes are staged in a transaction, and this facilitates settings to be revisioned and for settings to be scheduled. See #28721, #31089.
  • Theme installation. Iterates on and completes the theme browsing experience.
  • Responsive preview. Iterates on the concept of live preview by giving users a better idea of what their site will look like on other devices. See #31195.
  • Bootstrapped Customizer. Lazy-load the Customizer into the current frontend view without having to leave the page. With selective refresh implemented, inline controls and frontend bootstrapping would be possible since full-page refreshes would no longer be required.
  • Improvements for both touch and small devices.

Beyond those features, the group identified some specific changes that should be prioritized, in conjunction with the features planned:

  • The sliding animation between panels should feel more like “moving panels” (see: iOS).
  • Keyboard navigation should be consistent and clear.
  • Identify “dead ends” in the interface and remove them, when possible. For example, prior to menus in the Customizer, it was not possible to customize that aspect of your site’s design with the Customizer.

The concepts surrounding live preview and the Customizer have been in development for a long time. Many of the concepts from Elastic Theme and the Visual CSS Editor have been incorporated over time. Over the next few years, experimentation with these concepts will likely take place in feature plugins. For example, this team may experiment with inline content editing, where it makes sense in the context of customizing a site. Another path for exploration is simple theme customization – e.g. change the header font, change the sidebar color, or change the width of the sidebar.

As with all components and new features, we shouldn’t be afraid to experiment and fail and should continually push for new experiments and ideas, especially in the context of feature plugins. Further, some of the above experiments may not make it into core, but are meant as a general direction that live preview should take in WordPress.

Taking these features together, below is a sequence outlining a possible roadmap for live preview and the Customize component in general, along with estimated targets. Please note that this is a proposed roadmap and is entirely dependent on contributor involvement. Additionally, many of these things will take place in a feature plugin prior to core inclusion.

  • Partial refresh. Performance Improvements. (Target: 4.4)
  • Responsive Preview. Transactions. (Target: 4.5)
  • Concurrency. Revisions. Theme Install. Beginning of NUX wizard. (Target: 4.6)
  • Focus on touch screen / small device improvements. (Target: 4.7)
  • Developer API improvements based on feedback from plugin developers. (Target: 4.8)
  • Improved UI after experiments in 2016. NUX “wizard mode.” (Target: 4.9)

Live preview is one of the most critical features in WordPress as we continually combat “save and surprise.” The Customizer in its current form provides an improved user experience to WordPress users when customizing their site’s design. Each feature mentioned above is a continuation of the live preview concept, building and improving upon the Customizer.

Everything above is just a proposal and we need your feedback to ensure it is the right direction. If you’re interested in any of the above, comment here with your feedback, or join the team in #core-customize.

This post was a collaboration between @helen, @nacin, @mark, @celloexpressions, @samuelsidler, and yours truly.

#customize, #roadmap, #roadmaps

WordPress and PHP7

For the last few months, WordPress Core has been getting ready for the upcoming release of PHP7. PHP7 is bringing a host of improvements to PHP. One of the most notably is substantial performance improvements.Benchmarks of WordPress using PHP7 are showing a 2-3x speed improvement compared to PHP5.6.

The first step towards support for PHP7 was to add PHP7 nightlies to the automated test matrix. For six months, WordPress has been testing every commit against PHP7. This helped us uncover a couple of now fixed issues.

For example, PHP7 deprecates PHP4 style constructors. Therefore, WordPress Core removed them and also added a deprecation notice to all themes and plugins using them to extend core classes. This is done to help ensure that as many themes and plugins as possible are ready for PHP7.

Next, WordPress Core fixed a small number of issues related to the Uniform Variable Syntax changes in PHP7.  Plugin and Theme authors are strongly encouraged to familiarize themselves with this change and all other backwards incompatible changes.

PHP7 is currently targeted for release on November 12, 2015. Coincidentally, this is also the date that WordPress intends to officially fully support PHP7. 😃 While WordPress doesn’t officially support unreleased versions of PHP, you are encouraged to test and report any issues you find with PHP7 before the its official release.  PHP7 builds are available for Ubuntu 14.04 and CentOS 7 (and compatible distros) from php7.zend.com.

Even as WordPress Core continues to expand its support for new versions of PHP, we have no intention of abandoning support for older versions until usage numbers show that the impact on users will be minimal. WordPress will continue to work with hosting providers to encourage them to upgrade their users to a current version of PHP and, when it’s reasonable, we will consider raising our minimum requirements. Regardless, WordPress continues to encourage all users to run the latest and greatest versions of PHP, including PHP7 upon its release.

#php7

Taxonomy meeting summary – 2015/09/03

Present: @boonebgorges, @swissspidy, @masonjames, @drewapicture, @georgestephanis, @khromov, @srwells, @michaeltieso, @dpegasusm, @kraft, @mrahmadawais, @samuelsidler, @leatherface_416, @jblz, @tyxla, @jeroenvanwissen, @lindsaymac, @eric, @jbrinley, @brashrebel, @pdufour, @joehoyle, @timothybjacobs, @ryanduff, @krogsgard, @aaroncampbell, @rahe

Logs: https://wordpress.slack.com/archives/core/p1441310435002734

  • Had a general discussion about term meta: who’s used plugins for it, who’s used workarounds, various use cases. We talked a bit about some arguments against term meta: that it will not perform well at scale, that it encourages poor data modeling – but decided that they could be set aside for the most part.
  • Outlined the interpretation, including database table name and schema, function names, and other API additions to support term meta. @boonebgorges will work up a RFC for make/core for feedback.
  • Talked about various ways in which existing term meta libraries might conflict with the core implementation: duplicated function names, duplicate table names, incompatible table schemas, etc. @boonebgorges is assembling a list of plugins in the repo that may conflict with the core implementation. Once the outline of the core implementation is pretty much settled, @aaroncampbell, @krogsgard, @masonjames, and @boonebgorges (and anyone else who is interested) are going to collaborate on reviewing these plugins to see which ones will conflict in serious ways (via a Google Doc, which @boone will share once we’re ready to go). This will help us gauge the extent of potential problems, and get a sense of what outreach will look like.
  • We talked a little about combining the wp_terms and wp_term_taxonomy database tables #30262. We outlined some backward compatibility concerns, and strategies for minimizing conflicts. Put out a general call for thoughts and initial patches on the ticket, though we probably won’t move forward with schema changes for at least one more release cycle.
  • Had a very brief discussion about WP_Term #14162. Initial implementation – probably doable for 4.4 – will be simple, and will focus on strict typing for term data as well as cache invalidation. Future releases may see more functionality moved to the class.

#4-4, #chats, #meeting, #summaries, #taxonomy

Introducing Twenty Sixteen

WordPress 4.4 will see a brand new default theme; that’s right, today is time to meet Twenty Sixteen! The process of selecting the Twenty Sixteen theme was a long one, taking several months. Lots of themes were considered, eventually settling on the one you see below. It’s a perfect fit!

00.twentysixteen

Twenty Sixteen features a new, never-released design that has some really unique touches on a traditional blog layout. It adapts well to different devices and is a joy to use.

Twenty Sixteen is a modernised approach of an ever-popular layout — a horizontal masthead and an optional right sidebar that works well with both blogs and websites. It has custom color options that allow you to make your own Twenty Sixteen. The theme was designed on a harmonious fluid grid with a mobile first approach. This means it looks great on any device.
– @iamtakashi

Let’s take a look at more!

We have the pleasure of welcoming back Takashi Irie as the designer of Twenty Sixteen. This year, the core team developing our new default theme will be myself and @iamtakashi — and you! We hope you can join us in getting Twenty Sixteen out to the world. Along with us, @iandstewart and @samuelsidler will be making sure the ship stays on course and giving us their wisdom as we charter the default theme seas.

How can you get involved?

There will be weekly meetings every Monday and Friday 16:00 UTC in #core-themes for half an hour. These weekly meetings will start once the theme has initially landed in core. If you are interested in contributing, subscribe to this blog (if you haven’t already), and leave your name in the comments. Once we’re ready, we will give everyone a ping and we’ll let you know on this blog too.

Want to know more about default themes?

There are some great links where you can find out more about past default themes.

The road to releasing a new default theme is long, but we’re already well on our way! The next step is to commit the initial code to core. From there, we will begin testing and patching. We hope you join in the adventure of releasing Twenty Sixteen.

#4-4, #bundled-theme, #twenty-sixteen