Proposal to Start a News blog on developer.WordPress.org

Staying on top of the new features coming to the WordPress open-source project is one of the main barriers expressed by developers.

The Make CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blogblog (versus network, site) has a heavy emphasis on meeting notes for the various core teams, rather than highlighting new features. This makes it difficult for developers who are not contributors or who just occasionally contribute to find the relevant information among the team-related posts. 

To achieve one of the big-picture goals for 2022 (“Create a developer-focused communications site“), this is a proposal for creating a Developer News blog. The content focuses on updates for developers, extenders creating plugins and themes, and those who work with WordPress at an agency or as freelancers. 

Preliminary Timeline

  • Proposal and request for comment period: February 25 – March 18, 2022
  • Coordinate with Design and 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. Teams for theme (the News theme would be spectacular) 
  • Brainstorm meeting with team representatives: End of March
  • Content creation and first post: early April 2022 
  • Start-up phase: Through mid-July
  • Review and expansion to regular topics for developers: Fall 2022

Problem to be Solved 

The current developer.wordpress.org holds a ton of comprehensive documentation with examples, tutorials, getting started guides, and more. That being said, there are various improvements that could be made to make the site much more impactful. Some of these areas for improvement are outlined below. 

What’s missing: 

  • There is no changelog to signal various changes including when pages are updated or when new APIs appear or existing ones are augmented with new filters, 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., and configuration. 
  • There is no mechanism to subscribe to updates. A blog would provide this feature. 
  • Outside #core-editor meetings and 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/, there is no single place to keep up with  ongoing discussions. For example, to learn about the new styling engine, a developer needs to visit three sites: Discussion, Tracking Issues, and the first PR.

Start-Up Phase

As a first step, the Developer News can tackle the above pain points by:

  • Surfacing updates to documentation, 
  • Highlighting new tutorials, and, 
  • Providing a way for developers to subscribe to stay up to date 

The Developer News blog can also be added to the Planet WordPress feed, so post titles also appear in the WordPress News WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. in the WP Adminadmin (and super admin) Dashboard. 

This initiative requires cross-team collaboration among contributors from the Documentation, Core (core-css, core-js, core-editor etc.), Training, and Support teams. 

These teams could use an existing WP SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel for synchronous meetings, such as #docs or #core. During the meeting, team reps and other contributors can make editorial suggestions for topics and links that could be included in the next edition of an update post.

An editorial calendar can be an early agenda item for the meetings. 

After the initial start-up phase, the blog would be extended to regular topical posts relevant to developers. 

Possible Ideas for Future Expansion

  • Summaries from GitHub Discussions 
  • Excerpts from meeting discussions for distribution to a wider audience of developers
  • A post consisting of a summary of multiple dev updates 
  • Useful questions/solutions found on StackOverflow/StackExchange 
  • Reviews of existing documentation to identify gaps 

A possible future expansion would include a regular revision process to update content with new information and changelog recording. 

I recommend that contributors to this initiative comply with the Make Core Post and Comment Guidelines. Should the editorial group decide to also include highlights of example plugins or themes, all products must adhere to the Community Team’s guidelines regarding GPLGPL GNU General Public License. Also see copyright license. compliance of the products, including premium products. 

As mentioned above, these are just some initial steps to get processes and contributors in place. Reader comments and discussion in the Slack channel will surface opportunities for further enhancements. 

What do you think? How could this proposal be improved?
Please share  your comments, your thoughts, and content ideas. If you’d like to contribute to the Developer News, mention this also in the comments. The comment period on this proposal will end on March 18, 2022. 

Props to Dion Hulse (@dd32), Destiny Fox Kanno (@piyopiyofox), Tara King (@sparklinerobots), Anne McCarthy (@annezazu), Tonya Mork (@hellofromtonya), Daisy Olsen (@daisyo), Dan Soschin (@dansoschin), and Anjana Vasan (@anjanavasan) for fruitful collaborating on this proposal. 
Props to Mary Baum (@marybaum) and Jean-Baptist Audras (@audrasjb) for final review

#developer-news, #proposal

Proposal for a Performance team

Note: a follow up post was published with information about next steps for this proposal.

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

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

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

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

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

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

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

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

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