Tag Archives: proposal

Ari Stathopoulos 6:35 pm on October 12, 2021
Tags: , proposal,   

Proposal for a Performance team

We (the undersigned) believe that WordPress needs an official Performance team responsible for coordinating efforts to increase the performance (speed) of WordPress.

This proposal outlines why we believe that this is necessary, how we envision such a team might function, and some potential initial areas of focus. It is authored by contributors from Yoast and Google.

What problems are we trying to solve?

Users expect and prefer fast experiences (consciously or otherwise). Research shows that fast websites can provide a better user experience, increase engagement, benefit SEO, increase conversion, and be more economically and ecologically friendly.

References:

The benefits of improving performance driving investment across the web [ref]. This further raises users’ expectations, and thus may comparatively ‘harm’ slow(er) things.

Compared to other platforms (e.g., Wix, Shopify, Squarespace), WordPress is falling behind. Other platforms are on average faster – and becoming increasingly faster – than WordPress websites (see The HTTP Archive’s Core Web Vitals report), and are actively investing in (and marketing) coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. performance-as-a-feature [1, 2].

We can see the impact of this investment in the widening gap between the proportion of WordPress sites which achieve ‘good’ Core Web Vitals scores, vs other platforms.

Performance graph for CMSs on desktop clients.
Performance graph for CMSs on mobile clients.

This gap continues to widen, despite the availability of many performance plugins and performance-focused themes. This suggests that there’s a discovery and/or education problem, or an updating/staleness problem – neither of which the 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 ecosystem solves for. 

In order to meet the increasing needs and expectations of site owners and end-users, WordPress needs to be actively investing in performance in WordPress Core and beyond (e.g., core code, themes & plugins requirements, setup and onboarding processes, adminadmin (and super admin)/editing experiences, education for content creators).

We believe that:

  • Performance is a fundamental part of user experience, and WordPress should aim to deliver a good user experience.
  • Achieving reasonable performance levels shouldn’t be plugin territory, but part of core (aka, “performance by default”), because;
    • All WordPress users (of all types) need a well lit path to good performance.
    • Average end-users can’t be expected to be performance experts.
    • Achieving high levels of performance requires technical considerations to be ‘built-in’ across the whole stack; and as this is often not the case with themes/plugins, performance solutions are limited to ‘brute-forcing’ performance solutions over non-performant behaviour (e.g., output buffering).
    • The plugin ecosystem doesn’t help users who don’t know that they need help, or who are poorly served by the plugin ecosystem.
  • Users determining which CMS to choose are / will be increasingly influenced by performance (and the associated UXUX User experience/SEO/conversion factors), and we’ll lose ground to faster platforms.
  • ‘Democratizing publishing’ requires that published content be discoverable; which will be less likely to occur via search engines (which influence or account for the majority of new content discovery) for slow(er) sites.

Web Vitals metrics provide a standardized and accepted mechanism for evaluating performance.

Plugin territory

Whilst we argue that some (perhaps most) performance considerations should be part of core, there are definitely areas that should remain firmly in ‘plugin territory’. For example, the following areas should be handled by plugins:

  • Integrations with specific CDNs
  • Template transformation processes (e.g., AMP)
  • Any non-standardized performance technology
  • Any experimental standards (e.g., browser APIs / capabilities with limited adoption)

These distinctions will need exploring and lines will need drawing (and maintaining) as part of the team’s activity.

Why a team?

Performance is already a focus in Trac and a label in the Gutenberg GitHub repository; but these alone don’t attract enough attention to the issues, nor unify efforts and priorities. Experienced and active contributors are not necessarily performance experts.

A team gives more visibility to the effort: contributors that are not interested in working on Core as a whole can be attracted by working on performance specifically. It also opens up contributing to new types of contributors, like performance or data analysts.

A performance team could also attract contributions from different groups; browsers, hosting, SEO companies, etc.

Resources and efforts

In practical terms, the creation of a performance team requires the following:

  • A performance tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) on Make websites
  • A performance channel in 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/.
  • A meeting every two weeks; time to be determined
  • Two team representatives for administrative purposes: they will be responsible for: 
    • Giving a quarterly report to the project leadership
    • Assigning roles in the website
  • A team lead/product owner. They will be responsible to create a mission statement for the team, highlight the areas to tackle, outline the scope and the roadmap for the improvements that need to be made.
  • Representation in (and influence on) other Make verticals and processes (e.g., themes, plugins, etc)

Next steps

Next steps should be discussed and determined as part of the process of exploring and responding to this proposal.

In the case that there are no objections, the next major steps are likely to be:

  • Set up Slack channel and meeting schedule, and make.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/ infrastructure.
  • Benchmark performance and define ongoing/future measurement & success criteria
  • Identify priority projects for CWV improvements with high-level timelines
  • Assign responsibilities for the projects identified

Props

Thanks to the following for this involvement in outlining this proposal.

@francina, @adamsilverstein, @tweetythierry, @joostdevalk, @jonoaldersonwp, @flixos90, @aristath (in no particular order)

#performance, #proposal, #team

Darren Ethier (nerrad) 2:51 pm on September 21, 2021
Tags: , , , proposal   

WordPress JavaScript Standards Change Proposal

This post was authored by @opr18 (Thomas Roberts).

During a recent WordPress #core-js meeting there was a discussion about updating the JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. coding standard. The specific update that is being proposed is to change the rules relating to comments.

Currently, the standard reads:

Comments come before the code to which they refer, and should always be preceded by a blank line. Capitalize the first letter of the comment, and include a period at the end when writing full sentences. There must be a single space between the comment token (//) and the comment text.

The proposal is that the new wording should be:

Comments come before the code to which they refer, and should always be preceded by a blank line. Unless writing a linter override, or a `@see` type comment, capitalize the first letter of the comment, and include a period at the end. There must be a single space between the comment token (//) and the comment text.

The problem with the current guideline is that it is not enforceable by automated tools. It is hard for linting tools to easily distinguish between what is and isn’t a full sentence in the context of code comments.

Code reviews can quickly fill up with noisy comments and suggestions to capitalise or add periods to code comments. If this were fixable with a linting rule then these comments wouldn’t be necessary.

There are instances where it may not make sense to write in sentence case, for example: adding linter overrides or writing `see` comments where the comment may just be the name of a method or file, etc. so we would not enforce the rule on these types of comments.

If this guideline were to be amended, there would be several instances of code in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ repository alone that do not follow it. It would be necessary to create a PR that fixes all of these issues. Because the change only relates to comments, a single PR can be made addressing all instances of comments that don’t follow the guideline, because the rule relates to comments only, this would have no impact on functionality so minimal testing would be required.

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. currently uses JSHint for linting JavaScript files, and it does not appear that even the existing style guideline is enforced. Even so, if efforts were made to move to ESLint in WordPress core, implementing a fix for any comments that do not follow the standard should be straightforward.

Initially the rule could be enforced as a “warning” while the PR to fix the issues is completed and after it has been merged the rule could graduate to an “error”.

Here is a draft PR demonstrating the punctuation aspect of the proposed change: https://github.com/WordPress/gutenberg/pull/34964

As a part of next steps, this post is looking for feedback on:

  • How do you feel about the proposed changes to the wording of the standard?
  • Are there any concerns about the plan for implementing this change?

This proposal is open for feedback until October 5th, 2021 at which point a final decision will be made during #core-js office hours that day.

#coding-style, #codingstandards, #proposal

Thierry Muller 8:49 pm on September 15, 2020
Tags: , proposal,   

Enhancing image preview: core proposal

For many years search engine results have shown various images size publicly made available by site owners. Last year (September 2019), some extra controls over the content preview was introduced to Google Search followed by Bing who announced similar capabilities for their Search Engine earlier this year (April 2020).

In practice, this means that many sites do not get the benefit of large image previews, and may be losing out on traffic. Today, WordPress sites do not opt-in to large image previews by default even when “Search Engine Visibility” setting is turned on.

Below is an example comparison of Discover content for small image preview vs large image preview:

Proposed Solution 

This proposal is to opt-in to large image previews by default when “Search Engine Visibility” setting is turned on allowing search engines to display large images resulting in an enhanced user experience and CTR (click-through rate).

Theoretically, this is as simple as conditionally injecting <meta name="robots" content="max-image-preview:large"> in the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. head of all pages.

WordPress may already inject a “robots” 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. tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) into a page, for example when a site is set to disallow search engines from indexing it. To facilitate large image previews as well as exposing a central management layer for the “robots” meta tag, a new function wp_robots() should be introduced. The function would include a filterable list of values to include in the “robots” meta tag and render the meta tag only if necessary. Having this centralized layer will streamline robots management and interoperability between plugins.

By default, the list would cover the following values:

  • noindex, to be included when search engines are disallowed from indexing the page or due to certain other circumstances
  • nofollow, to be included when noindex is provided when search engines are disallowed from indexing the page
  • follow, to be included when noindex is provided due to certain other circumstances
  • max-image-preview: large, to be included when search engines are allowed to index the page, and when large preview images may be used for the page

This would only be the default behavior and could be expanded or modified by plugins, for example to add additional robots tag directives.

The function would be hooked into wp_head and other relevant actions, and it would essentially supersede the existing noindex() and wp_no_robots() functions.

What’s next?

Your thoughts on this proposal would be greatly valued. Please share your feedback, questions or interest in collaboration by commenting on this post. After that we can create a tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. and kick start development.

#images, #proposal, #seo

Justin Ahinon 2:03 pm on June 15, 2020
Tags: , , , meeting calendar, proposal   

Setting the structure and an agenda for APAC-friendly devchat

@francina‘s proposal for APAC-friendly devchats attracted interest from commenters on every continent. I approached them recently to get their thoughts on moving forward.

Based on that advice, I propose a first meeting to set up these devchats and schedule them on the #core channel on Make WordPress 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/..

A look at all the team meetings in the Meeting Calendar shows an opening on Thursdays at 15:00 AEST – this replaces the APAC Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Session which will be rescheduled.

So let’s meet this week: Thursday, June 18th, at 15:00 AEST.

Please comment below with your thoughts on discussion topics, ongoing structure and agenda or anything else that seems relevant.

See you on Thursday!

Edit: This post has been edited to bring forward the start date by a week — @peterwilsoncc.

#apac, #dev-chat, #meeting-calendar, #proposal

Jeffrey Paul 1:45 am on April 17, 2020
Tags: proposal,   

Proposal: Core Team Rep Elections

It’s been an eternity since team reps were updated for the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Team.  @helen and I (@jeffpaul) have been serving since before GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ development began, way longer than team reps usually would… so it’s time to talk about how we update Core team reps.

The Role

In the WordPress open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project, each team has on average one or two representatives, abbreviated as reps.  Some teams have more than two, but for the sake of sanity sticking with two for now keeps things simpler.  And for the historians out there, the role goes way back to 2012.

Historically with the Core team, the team repTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. duration was around a year, though some reps stuck around longer if there was a particularly good fit.

Anyone who serves as a “team rep” is responsible for communicating on behalf of the Core team to the other contributor groups via weekly updates, as well as occasional cross-team chats.  Reps are also consulted on Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/., helping find someone within the Core team attending an event who can help lead a Core table.  Full details on the Team Rep role is on the Team Update site.

It is not called “team lead” for a reason.  While people elected as team reps will generally come from the pool of folks that people think of as experienced leaders, remember that the team rep role is designed to change hands regularly.

This role has a time commitment attached to it.  Not a huge amount, but in my experience, it’s at least one hour a week.

Here are the main tasks:

  • Writing regular Core team recaps and posting it in Updates
  • Keeping an eye on the moving parts of the team to be able to report for quarterly updates (example)
  • Occasionally helping release leads with devchat agenda posts, chats, and summaries

More details on coordinating devchat are available in the Core handbook.

The Community Team has been running the following process which makes for a tried and tested model for the Core Team to similarly try out.  Hat tip to @francina for sharing these details!

Nominating

Nominations happen in the comments of a Core Team Reps Election post (here’s a sample Community Team nominating post).  Self-nominations are welcome.  The deadline for nominations should be around two weeks.  

If you want to nominate someone in private, please reach out to @current-team-rep-1 and @current-team-rep-2 on 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/..

Disclaimer: if you get nominated, please don’t feel like you have to say yes.  The polls will only include the names of the people that are responding positively to a nomination.  So feel free to reply with a “Thank you, but no thank you”.

Once the deadline has passed for nominating, a comment will be added and pinned to the top:

Nominations are now closed and voting is open until <voting deadline>. Voting details and link here: https://make.wordpress.org/core/<voting-link>/

Voting

After nominations have ended, a poll for voting will be opened and linked from a voting announcement post (here’s a sample Community Team voting post).  It will stay open for around two weeks.

Once the deadline has passed for voting, a comment will be added and pinned to the top:

Voting has concluded and the new team reps will be announced on <date> during the Core devchat.

Once the results have been finalized and announced, a comment will be added and pinned to the top:

Selected Core Team reps are announced here: https://make.wordpress.org/core/<results-link>/

Results

After voting has ended, results should be shared in an announcement post (here’s a sample Community Team results post).  Similarly, the new team rep(s) should be updated on the Team Reps page.

The outgoing team rep(s) should plan to be available for questions and consultation from the incoming team rep(s) as there will undoubtedly be a learning curve as new rep(s) get into the role.

Next steps

I will bring this proposal up in the next devchat on <date> and lacking any major concerns, will work to publish a nominating post after that devchat.

If you have any questions, please feel free to ask in the comments.  I will be happy to reply (or look to past team reps for input)… thanks!

#proposal, #team-reps

Thierry Muller 11:50 am on June 12, 2019
Tags: , , proposal, , ,   

XML Sitemaps Feature Project Proposal

Note: a follow post was published with more recent information about this project.

While web crawlers usually discover pages from links within the site and from other sites, sitemaps supplement this approach by allowing crawlers to pick up all URLs included in the sitemap and learn about those URLs using the associated metadata.

Today, WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. does not generate XML Sitemaps by default, affecting a high number of WordPress websites search engine discoverability. 4 out of the top 15 plugins on WordPress 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 repository currently ship with their own implementation of XML sitemaps, pointing to a universal need for this feature and a great potential to join forces.

This post proposes integration of XML Sitemaps to WordPress Core as a feature project. The proposal was created as a collaboration between Yoast*, Google** and various contributors.

Proposed Solution

In a nutshell, the goal of the proposal is to integrate basic XML Sitemaps in WordPress Core and introduce an XML Sitemaps 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. to make it fully extendable. Below is a diagram of the proposed XML Sitemaps structure:

XML Sitemaps will be enabled by default making the following content types indexable

  • Homepage
  • Posts page
  • Core Post Types (Pages and Posts)
  • Custom Post Types
  • Core Taxonomies (Tags and Categories)
  • Custom Taxonomies
  • Users (Authors)

Additionally, the robots.txt file exposed by WordPress will reference the sitemap index.

Developers

An XML Sitemaps API will be introduced as part of the integration allowing extensibility. At a high level, below is a list of the ways the XML Sitemaps may be manipulated via the API:

  • Add extra sitemaps and sitemap entries
  • Add extra attributes to sitemap entries
  • Provide a custom XML Stylesheet
  • Exclude a specific post type from the sitemap
  • Exclude a specific post from the sitemap
  • Exclude a specific 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. from the sitemap
  • Exclude a specific term from the sitemap
  • Exclude a specific author from the sitemap
  • Exclude a specific authors with a specific role from the sitemap

Non Goals

While the initial XML Sitemaps integration will fulfill search engines minimum requirements and cover most WordPress content types, below is a list of features which will not be included in the initial integration:

  • Image sitemaps
  • Video sitemaps
  • News sitemaps
  • User-facing changes like UIUI User interface controls to exclude individual posts or pages from the sitemap
  • XML Sitemaps caching mechanisms

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.

The XML Sitemaps will leverage standard internationalization functionality provided by WordPress core.

Since there are plans by WordPress leadership to officially support multilingual websites in WordPress, the XML Sitemaps will be flexible enough to list localized content in the future as per web development best practices.

What’s next?

Your thoughts on this proposal would be greatly valued. Please share your feedback, questions or interest in collaboration by commenting on this post. After that we can decide on how to best proceed with this proposed project and set up a meeting on 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/. to kick things off.

* @joostdevalk, @omarreiss, @jonoalderson, @herregroen

** @swissspidy @albertomedina @westonruter @flixos90 @tweetythierry

#feature-plugins, #feature-projects, #proposal, #seo, #sitemaps, #xml-sitemaps

Weston Ruter 5:29 am on October 12, 2016
Tags: , , , proposal   

Customize Changesets (formerly Transactions) Merge Proposal

This is a merge proposal and overview of Customize Changesets (#30937), a project formerly known and proposed as 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. Transactions back in January 2015. The customizer is WordPress’s framework for doing live previews of any change on your site. One of the biggest problems the customizer faces right now is that changes are ephemeral. If you navigate away, you lose what you are working on. Additionally, you can not share proposed changes with others, nor can you take the changes you are working on and save to continue working later.

Imagine a WordPress user named Tina. Tina is building a website for her daughter’s band. The band has been getting more and more popular, and Tina wants to experiment with some new widgets in 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. but also wants to be able to share the proposed solutions with her husband Matthew. Right now, Tina and Matthew would need to be in the same room to collaborate. Or Tina would need to take screenshots, but that kind of defeats the purpose of live preview. If only there was a way to make customizer changes persistent without publishing them.

Introducing Customize Changesets

Customize changesets make changes in the customizer persistent, like autosave drafts. Users can make changes to one theme and switch to another in the customizer without losing the changes upon switching. A customizer session can be bookmarked to come back to later or this URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org can be shared with someone else to review and make additional changes (the URLs expire after a week without changes). The new APIs make possible many new user-facing features in future releases and feature plugins, including saving long-lived drafts, submitting changesets as pending for review, scheduling changes, seeing the previewed state on the frontend without being in an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., sharing preview URLs with others who do not have customizer access, and others.

Customize changesets allow each change you make in the customizer for a given live preview session to be persistent in the database. A unique identifier (a UUID like f67efbbf-c663-4271-ab1c-95ce1d447979) for each live preview session is generated and as soon as a change is made, the change setting value is sent in an Ajax request to be written into a custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. whose post_name is the UUID for the customizer session. Once the changes have been written into the changeset post, then any request to WordPress (including to the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.) can be made with a customize_changeset_uuid query param with the desired UUID and this will result in the customizer being bootstrapped and the changes from that changeset being applied for preview in the response. The unique UUID means that customizer sessions can be sent to other users and also that they can be used as query parameters on the front end.

Design and Technical Decisions

For the initial coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. merge, no UIUI User interface changes are being proposed. The feature will only be exposed as the new query parameter on the URL. Adding a UI to this feature will happen in a future release. As such, the proposal for customize changesets is similar to the proposal for including the REST API infrastructure: it provides a foundation for new core features in future releases and a platform for plugins to add new features. Nevertheless, while the customize changesets 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. doesn’t introduce any new features it does fix several long-standing issues related to incompatibilities between JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. running on the site’s frontend when previewed in the customizer. Under the hood, the customize changesets patch touches on many of the lowest level pieces of the customizer. Please check out the Customize Changesets Technical Design Decisions to see what is happening under the hood.

Testing

Please test! If you use any plugins that extend the customizer, please ensure that there aren’t any regressions. The patch is intended to be fully backwards compatible and users shouldn’t notice any difference in normal use. Two things to look for when testing is as soon as you make a change, you should see a customize_uuid query param added to the URL. You should be able to reload and find your changes persist (note the AYS dialog is retained because there is no UI yet for listing changesets). Also, when you navigate around the preview it should feel much more natural like normal browsing as opposed to having a fade effect. Otherwise, previewing settings that require refresh should still work as normal, as will settings that preview with JavaScript and selective refresh.

The patch is in a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ pull request and you can apply the patch via:

grunt patch:https://github.com/xwp/wordpress-develop/pull/161

If you’re using the GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. repo from develop.git.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/ then you can check out the 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". directly via:

git remote add -f xwp https://github.com/xwp/wordpress-develop.git && git checkout xwp/trac-30937

I’d appreciate code review feedback directly on the pull request. For any 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. to the patch, please open a pull request to that trac-30937 branch if possible.

The Future

In future releases we can explore new UIs to take advantage of the new capabilities that changesets provide. New UIs can provide a way to schedule changes, the ability to undo the last change, show an audit log (revision history) for changes, collaborative editing of a customizer changeset, and so on. Future feature projects will explore many of these and feature plugins will start to prototype them.

Thanks to @jorbin who contributed to this proposal post.

#4-7, #customize, #feature-projects, #proposal

Helen Hou-Sandi 5:58 pm on October 11, 2016
Tags: , proposal   

The Road to 4.7 Beta 1

For the last 55 days, trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. has been in an alpha state and open for all commits. In 15 days this will change and the first betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. for 4.7 will be released. During beta, no new enhancements or feature requests should be committed to WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. While some may desire to wait for just one more thing, that is a rabbit hole which is inconsistent with the WordPress philosophies. Here is a list of things that need to happen during the next 15 days in order to get ready for Beta 1 on October 26th.

The deadline for merging feature projects into WordPress core is in 8 days. There are currently three proposals for projects to merge published with several additional proposals actively being worked on. All committers and active contributors should review these proposals (I’ll add links to additional proposals when they are made):

There are 60 enhancements and feature requests milestoned for 4.7.  Of these, 21 have no owner.  At the end of this week, all enhancements and feature requests without an owner will be punted.  Tickets will also be regularly evaluated this week.  Over the next two weeks, tickets will be evaluated during both scheduled and unscheduled 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. scrubs, and tickets not moving forward will be removed from the milestone. The next scheduled bug scrub will be at Wednesday, October 12, 2016 17:00 UTC.

During this week’s dev chat, we will discuss all the proposals that have been made thus far. If additional meetings for considering any of the proposals before the merge deadline are needed, this will be decided then.

#4-7, #proposal

Nick Halsey 5:36 pm on October 11, 2016
Tags: , , , proposal,   

Feature Proposal: Better theme customizations via custom CSS with live previews

When people ask “why WordPress?”, some of the most common answers center around flexibility for users of all kinds, whether they’re building their sites primarily through code or UIUI User interface. Let’s take the story of a user who does a little of both – we’ll call her Becky.

Becky is a pretty savvy user. She knows that you’re supposed to make child themes instead of hacking on a theme directly, because updates can wipe out your changes. She found that out the hard way when she first started using WordPress – she hardly knew what CSSCSS Cascading Style Sheets. or PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher were, but she knew there was a theme editor in the adminadmin (and super admin) and that she could make tweaks to colors or remove the author byline pretty easily without having to figure out this FTPFTP FTP is an acronym for File Transfer Protocol which is a way of moving computer files from one computer to another via the Internet. You can use software, known as a FTP client, to upload files to a server for a WordPress website. https://codex.wordpress.org/FTP_Clients. stuff. Later on, most colors could be changed with the 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. so having a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. just to remove an author byline seemed like overkill, but it was certainly better than having it reappear every time her site updated, especially with auto updates turned on.

After a couple years with the same theme on her personal site, Becky felt it was time to change things up. She was pleasantly surprised to find some new features that made getting a theme set up a lot easier, especially when live previewing them. Still, though, that pesky author byline remained, and since her last child theme copied a template to get rid of the byline, she would have to set up a whole new one to do it again. Then Becky found an “Edit CSS” option and realized she could hide things using CSS without having to go through the entire child theme process. Now, it turns out that those CSS tweaks didn’t come with live previewing, and that functionality was provided by a certain 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, but Becky got what she needed to get done a lot faster than she would have otherwise, and ended up with the site she wanted.

This isn’t one specific story, but it is a combination of user stories many have heard, witnessed, or even personally experienced. You could replace Becky with @helen and it would be 100% accurate. The theme editor is a dangerous but useful entry point to more deeply customizing your site – rather than outright removing it and cutting off that introduction not just to WordPress code but to the concept of web development at large, why not provide a far safer and more user-friendly alternative? This post will explain why custom CSS with live previewing is valuable for WordPress and propose an implementation for inclusion in 4.7.

Proposed solution: Custom CSS with live preview

When bridging the gap between advanced user and beginning developer, desired changes are typically visual tweaks, such as changing a font size or hiding something, that are theme-specific. These sorts of changes should not require that users take risks editing live files that might white screen their sites or jump immediately into developer-facing tasks such as using FTP. Therefore, the scope of this feature has been defined as a custom CSS editor that leverages the customizer for a user-friendly live preview experience. This live preview allows for users to try various tweaks to a theme before saving and setting their changes live.

There are hundreds of thousands (if not millions) of users making use of custom CSS plugins or other themes/plugins that have custom CSS capabilities, and the frequent suggestion of CSS fixes in support forums justify a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. need for this functionality. When plugins and themes interact in unexpected ways, CSS snippets are often an efficient solution to fixing the particular problem on particular sites.

The CSS editor takes inspiration from the many plugins offering similar solutions, but with an updated approach that offers instant live previewing in the customizer. The proposal for 4.7 looks like this:

custom-css-proposal-demo

Notably, previewing CSS in the customizer allows the site to be navigated and previewed on different sized devices by leveraging existing core features, allowing users to visualize the impact of their changes across their site. Error messages are shown for common syntax mistakes to help users ensure that their CSS is formatted properly before saving.

In future releases, the interface can be iterated on to further improve usability. The long-term design vision provides functionality such as 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., syntax highlighting, and in-preview selector helpers, and can be implemented iteratively over time (click through for the full version):

customizer-css-i2

CSS would be stored in a custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. (without admin UI), with a post stored for each theme. The editor would be used to supplement and override theme styles rather than editing them directly, as users have long been advised that directly editing files may lead to lost changes during updates. Instead, custom CSS safely stays available through updating and switching themes, starting fresh for each new theme. Projects such as customize changesets (#30937) and revisions for customizer settings (#31089) would bring future enhancements to this feature and further leverage the opportunities that come with storing the data in post objects.

This is proposed as core functionality rather than remaining as plugin territory because it is designed as the first step toward a next generation of the existing theme editor in core, with a more refined feature set and safer, more user-oriented focus. The theme editor is not proposed to be removed at this time, though with the introduction of this feature it likely makes sense to introduce more friction before accessing the editor (#31779).

Documentation

To improve the user experience further, it is critical that a link to documentation and resources for learning CSS be included with useful help text. This could initially be the “CSS” codex page but would ideally live on a user or developer handbook of some sort eventually (perhaps the theme developer handbook?). This help text must be much more succinct than the help tab on the existing theme editor, conveying what CSS is, where to learn about specific rules, and explaining that it’s specific to each theme in only a few lines.

Help is needed to create a resource for using custom CSS in WordPress, and locate it on 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/. There are some related resources on make/training and WordPress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/ has a good introductory page that they may be willing to contribute. Translated versions will eventually be needed as well. If anyone is interested in improving this aspect of the feature, which will presumably live on WordPress.org, please comment on this post.

Security, Capabilities, and 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

While the proposal includes basic validation, it is not possible to fully sanitize CSS. For this reason, a new 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. capability will be introduced for managing css, unfiltered_css. By default, this is mapped to the unfiltered_html capability.

Site administrators on multisite networks do not have the unfiltered_html capability by default. A plugin that remaps unfiltered_css to a different capability can be created to provide this access on multisite, where custom CSS is especially useful given the need to restrict the number of themes and child themes in the networknetwork (versus site, blog). This is an area of potential evolution over time.

Related Customize 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. Improvements

There are a couple of customizer API improvements introduced as part of the implementation of custom CSS in the customizer. A new “Code Editor” customizer control (WP_Customize_Code_Editor_Control) is used for the CSS editor and can also be utilized in plugins and elsewhere in the future. It currently handles line numbers and basic code styling, and will eventually add enhancements such as syntax highlighting.

Additionally, the WP_Customize_Section class has a new “description_hidden” parameter, which locates the section description in the section headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. behind the help icon toggle (“?”), functioning in the same manner as the customizer panel descriptions.

Contributors

@johnregan3 is leading development of this project, based on initial work by myself (@celloexpressions). @folletto is leading design efforts, with a focus on the long-term growth of the feature for maximum usability.

The implementation takes inspiration from many of the numerous plugins and services that implement custom CSS, specifically including:

  • Simple Custom CSS (@johnregan3)
  • Modular Custom CSS (@celloexpressions)
  • WordPress.com Custom CSS in the design upgrade (Automattic)
  • Jetpack (Automattic)

Testing, Feedback, and Next Steps

Your help is needed in giving feedback on this proposal and testing the feature! To test, please apply 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. either via TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. or the PR (helpful reminder: grunt patch handles both) and try some custom CSS in the customizer using various themes.

Pending approval of this proposal, the next steps will be to finalize and commit the patch on #35395. Code review is ongoing in the GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ PR linked on the ticketticket Created for both bug reports and feature development on the bug tracker.. Feedback on the feature in general and the specific implementation is encouraged via the comments on this post, with any more technical implementation discussion happening on the Trac ticket or GitHub PR.

#4-7, #css, #customize, #proposal, #themes

Nick Halsey 7:00 pm on October 3, 2016
Tags: , , , proposal, , ,   

Feature Proposal: A New Experience for Discovering, Installing, and Previewing Themes in the Customizer

This is the feature merge proposal for the new themes experience in the 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. introduced with #37661. Here’s an overview of the current proposed UIUI User interface:

Customizer themes design and user flow mockup

Customizer themes design and user flow mockup by @folletto.

A theme is the most fundamental aspect of customizing a site. This project seeks to unify the theme-browsing and theme-customization experiences by introducing a comprehensive theme browser and installer directly in the customizer.

Walkthrough of the latest patch on #37661.

Walkthrough of the latest 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. on #37661.

Background & History

The customizer originated as a tool for previewing and customizing themes and as such, was closely integrated into the theme browsing experience in wp-adminadmin (and super admin) when it was introduced in WordPress 3.4. The theme browser and installer were rewritten in WordPress 3.8 and 3.9, respectively, offering a fast JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.-based way to explore, install, and switch themes.

Eventually, as the customizer’s role grew to that of a framework for live-previewing any change to a site, it became apparent that it would benefit from a more direct way to switch themes, without entering the wp-admin context. The Customizer Theme Switcher 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 was created, and after some refinement, merged into WordPress 4.2. However, while it initially included external links to install themes in the admin, these were eventually removed due to the jarring experience of unexpectedly leaving the customizer.

Currently, there is no indication that additional themes can be installed when viewing available themes in the customizer. For new users, it may take quite a bit of time to discover the ability to install themes, via wp-admin, or they may give up on WordPress before making this discovery. This is a usability dead-end where a user’s flow is disrupted in the process of discovering, installing, previewing, and activating themes, both on initial site setup and when considering a redesign.

When the theme switcher plugin was developed, the team made preliminary plans for a theme installation interface as a second phase of the project. Specifically, it would leave the “preview” context of the customizer but retain the same identity in the user experience. @folletto helped develop this initial concept in early 2015.

Technical Constraints & Requirements

There have been several technical limitations preventing theme installation in the customizer from being addressed previously. Most notably, such an interface requires “shiny” ajax-based theme installation, updates, and deletion, so that the user flow can persistently stay in the customizer themes interface rather than jumping to separate “installing” views. This is now possible with phase 2 of “Shiny Updates” in WordPress 4.6. Additionally, expansions of the customizer JavaScript and JS-templated controls APIs to better support dynamically-registered controls were needed to support theme installation within the customizer framework, and these were fully fleshed out for the customizer menus interface introduced in WordPress 4.3. With these technical constraints eliminated, theme installation in the customizer is now possible without additional significant improvements to the underlying themes or customizer APIs.

The customizer must currently be completely reloaded from PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher to preview a different theme. To perform a theme switch without a reload, theme-defined settings, sections, and controls would need to be updated dynamically with JavaScript. While the customizer internals have been working toward making this possible for some time, significant work remains to make inline theme switches possible. Therefore, changes to this part of the theme-switching workflow are out of scope for the current project, which focuses on the user-facing flow.

The biggest usability blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. that this limitation causes is that unsaved changes are lost when the theme is switched. Unsaved changes are currently handled by prompting users with an are-you-sure notice in the browser before making the switch. Unfortunately, limitations in JavaScript require the loading indicator to be hidden after the user decides to stay on the page or to continue to the new theme, causing confusion. In the new interface, this is further mitigated by displaying a warning that there are unsaved changes, with an inline button to save and publish them, at the top of the interface. With customize changesets (transactions) (#)30937, a “save draft” option could also become possible in the future, allowing changes to be saved (potentially automatically) without being published between theme previews.

Previewing Themes

One of the biggest challenges with theme installation in wp-admin, and opportunities in the customizer, is previewing themes. Currently, a customizer-like frame displays a preview hosted on 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/, with limited content. Rather than opening this potentially-disorienting similar but different interface, the proposed flow de-emphasizes the distinction between installed and available themes. The primary action for available themes is now “Install & Preview”, which installs the theme and live previews it in one step.

Users can now see any theme on their site with their content and play with its options in the customizer in one click. If they decide it’s the wrong theme for their site, the themes panel can be quickly reopened and another theme selected and previewed with no harm done. A secondary action allows themes to be installed without instantly previewing, so that the installed themes tab can become a personal theme library of sorts, where users can save themes that they might want to try on their site. Installed themes being a 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. along with the available theme headings unifies the previously-disorienting separation of themes and add-new themes on separate screens, with confusingly-separate search and headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. (add new/upload theme) functionality.

Proposed Themes Interface

Due to the tight integration with the existing system, with the existing theme control and section as well as internal elements in the customizer manager and theme details template requiring moderate modifications, this project was implemented as a patch and cannot be reasonably converted into a plugin and back. The patch has been available on trac for six+ weeks, with iterations continuing to improve and polish the new experience.

The technical implementation continues adapting the concepts present in the backbone.js-based themes experience in wp-admin to leverage the customizer 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.. With the themes experience natively built on the customizer framework, it should be much easier for developers to improve and maintain the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. experience in the future as well as extending the core experience in a structured way.

A few highlights of the proposed details:

  • Installed themes are no longer loaded every time the customizer is opened, resulting in potentially significant performance improvements by only calling wp_prepare_themes_for_js() when needed. This also allows themes in the customizer to be fully disabled with remove_panel( 'themes' ).
  • The themes experience is unchanged on the top level of the customizer, but selecting the change theme button now opens a panel that fills the entire screen, as the preview is not relevant when considering a theme change.
  • The UI diverges somewhat from what is found in the theme installer in wp-admin (which will remain), particularly around the filters.
  • The theme details view is unified between installed and available themes; clicking on a screenshot opens the details view to match the admin UI.
  • Primary buttons are used where clicking them takes you away from the current page (ie, for previews); secondary buttons are used elsewhere.
  • The loading strategy attempts to balance performance with wait time by loading theme data from Ajax in large batches (100 themes) and following up by rendering screenshots as they become visible (as the existing interface does).

Usability Testing

Four usability tests have been conducted so far. The full test screencasts are available on Make/Design, alongside key takeaways. These tests expose a lot of largely-known issues with themes and the customizer in general, but did not reveal any significant issues with the proposed new theme browser. Because the tests were conducted in-person with a limited set of volunteers, additional testing with a broader user base would be ideal.

There has been design feedback since the user testing was conducted, resulting in some significant changes. @karmatosed has volunteered to coordinate additional testing in the next week to verify that the changes haven’t introduced usability regressions, and to test with a broader audience. Check out the call for user testing on make/design to help out here.

A visual record on a phone of the revised design has been posted on make/flow.

Extensibility

Because the new interface is built entirely on the customizer API, third-party plugins should now be able to integrate much more easily. This means that other theme marketplaces (including commercial themes) could realistically be browsed (and maybe even installed) from within WordPress, while leveraging the core UI exactly.

The presentational flexibility is available via the customizer API (with custom theme sections for other theme sources, and theme controls for individual themes), but there are likely some gaps in the ability to do this seamlessly in the internals. If anyone is interested in building this sort of functionality, please evaluate whether any additional hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. are needed so that they can launch alongside the new feature.

Review and Approval

In addition to a general core approval of this proposal, the following sign-offs are required before the feature could be approved for merge, based on the applicable elements of this list:

  • Flow (and mobile) review (see also an initial post)
  • Docs review
  • Security audit
  • Polyglots/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. review
  • Design/UXUX User experience review – tentative approval has been provided from @karmatosed and @folletto (with additional input from others in last week’s design meeting) with an expectation that minor adjustments will continue to be required. General design feedback is still welcome, but major changes are unlikely to be feasible at this point.
  • 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) review – @afercia completed an initial review, with the issues fixed in a subsequent patch. A comprehensive final review would be a good idea as well, since there have been significant design changes.
  • Code review – to be handled by @westonruter once the patch is otherwise deemed “ready” based on review from other teams.

To test, update to latest trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. and apply the latest patch on #37661. On your test site, open the customizer and “change” the theme. Try out the various filters, browse themes, and install and preview them. Also test the inline update and deletion functionality.

To meet the feature merge deadline for 4.7 (10/19), reviews from various teams and any corresponding iterations need to be completed by October 12th, leaving a week for final code review and commit. General feedback and specific reviews and action items should be provided as comments on this post.

Update: this feature was merged in 4.9.

#4-7, #4-9, #customize, #proposal, #shiny-updates, #theme-switcher, #themes