Tag Archives: roadmap

Felix Arntz 4:44 pm on February 27, 2023
Tags: , , roadmap,   

Core Performance Team Roadmap Published

Over the past few weeks, the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Performance Team has been working on a roadmap for 2023, gathering different priorities of the different contributors and bringing them together in a cohesive roadmap. The team is excited to share this roadmap, which is now available on the Make Performance site.

The roadmap summarizes the team’s big picture focus areas and more specific efforts planned for the year. This is intended to be a living document that may see updates from time to time. It is difficult to plan and scope work for an entire year, so certain priorities may shift or new ones may be raised. Even so, this roadmap is meant to communicate the current intentions for what is on the near horizon for the Core Performance Team.

While most priorities on the roadmap are focused on direct WordPress core enhancements and performance support of the key 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/ phases 2 and 3, other priorities are focused on external tooling, such as to measure performance reliably, or to provide assistance to 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 or theme developers.

Please refer to the 2023 roadmap page for a comprehensive overview. It contains the full list of priorities for the year, and furthermore provides additional context for the big picture focus areas.

#core-performance, #performance, #roadmap, #roadmaps

Andrew Ozz 2:57 pm on March 28, 2018
Tags: , roadmap   

Roadmap: tools for GDPR compliance

This roadmap is for adding privacy tools to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. These tools will help site owners comply with the GDPR and other privacy laws and requirements.

Main tasks

I. Add tools for creating a privacy policy

The idea is to have a “special” page for the privacy policy, #43435 (initial version of this is already committed), and #43491. The site owners are able to select an existing page or create a new one. There will be wp_get_privacy_policy_page() helper functions for use in themes, etc.

Another idea is to have a “postbox” shown when editing the policy page. All plugins that collect personal data or set cookies can output some concise information about what they collect and store and why. This information should be phrased for inclusion in the site’s privacy policy.

Core will also contain text that the site owners can use to create their policies. The text will be used as the default privacy policy and will be inserted in the privacy policy page when a new one is created. See #43473.

II. Create guidelines for plugins on how to get GDPR compliant

This should be a chapter on privacy in the plugins handbook. Needs text.

III. Add tools to core to facilitate compliance, and privacy in general

There are several plugins that are implementing similar tools. It would be great if 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 authors participate/contribute to core to include the base tools, so we don’t double the efforts.

These tools will require a confirmation of the email of the person that requests an action, see #43443 (first version is already committed). When a confirmed request is received, the site owner will perform the action.

This could be done automatically. However deleting and anonymizing will be non-reversible. In this case it’s better if the site owners perform the actions themselves, after additional confirmation if required.

There will be two main tools:

  • To export all personal data stored on the site (by email address or user login), see #43438, #43440, #43547, #43547.
  • To delete all personal data and anonymize published/public content (like posts, comments, etc.), see #43637.

Note that registered users (“author” and above) have access to almost all of their personal data on the User Profile screen. They also have access to all posts and comments they have made on the site, and can edit or delete them. Site owners should deal mostly with requests from “contributor” level users and people that have commented on the site.

Couple of tasks can be performed in core without additional tools. For example a registered user’s account can be deleted and all of their posts can either be deleted or reassigned to another (already created) user account. This is sufficient for anonymizing a user account if there are no plugins that store private user data outside user_meta. Also, admins can search for and delete a specific user’s comments.

However having a specialized tools will enable plugins to hook into the performed actions and do their share. This is critical as many of the top 100 plugins seem to store at least some private user data.

IV. Add documentation/help for site owners on how to use these tools

The documentation should be on the new Tools => Privacy screen. Alternatively we can add only a very brief explanation and link(s) to 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 more extended help. Needs text.

All GDPR related tickets can be accessed here: https://core.trac.wordpress.org/query?status=!closed&keywords=~gdpr

#gdpr-compliance, #roadmap

Alain Schlesser 3:09 pm on January 9, 2018
Tags: , , roadmap,   

Servehappy Roadmap

The group of people in the #core-php channel has been discussing and planning a project codenamed “servehappy” for some time now. We are at the point where we think that our plan has matured enough to present it to a bigger WordPress audience, in the hopes that we can get buy-in from more people to support or join our cause.

Goals

Primary Goal (long-term, indirect):

  • Reduce the number of WordPress installations running on an unsupported PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher version

Secondary Goals (short-term, direct):

  • Make WordPress site owners aware that they are running an unsupported version of PHP
  • Educate WordPress site owners about PHP and its versions
  • Provide WordPress site owners with tools and resources that enable them to update their site’s PHP version

The primary goal is what we’re aiming at. However, this is not something we can directly act upon. The secondary goals are the actionable elements that are in line with the primary goal.

We are confident that we can produce a definite positive impact on the primary goal through a concerted effort on these secondary goals.

Current State

A good overview of the current state can be found in the project repository’s README.md file.

 

Mockup of the ServeHappy page, showing collapsible sections of content.

ServeHappy page mockup
Click to enlarge

 

Through our regular weekly meetings we’ve made good progress on putting together the content for an informational page called “servehappy“ (in reference to the “browsehappy” page that helped get rid of legacy web browsers). The page should ideally be hosted on the wordpress.org infrastructure, similar to how the browsehappy page is stored.

 

Mockup of the WordPress admin dashboard, showing an admin notice warning about the PHP version.

Adminadmin (and super admin) notice mockup
Click to enlarge

 

This page is meant to be linked to by admin notice(s) in the WordPress admin dashboard that will appear for people with unsupported PHP versions. Work on implementing these can start as soon as we have confirmation that the servehappy project should be further pursued.

 

Mockup of a plugin detail screen in the admin dashboard, showing a red "Cannot install" button and a link to the ServeHappy page.

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 requirements mockup
Click to enlarge

 

Finally, we want to work on enforcing plugin/theme PHP requirements as they can already be stated in the plugin/theme 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. information. With time, this will provide developers with better control over their code base and incentivize site owners to keep up with the WordPress ecosystem’s evolution.

We’ve prepared a short overview document that details the core integrations and how they tie into the servehappy page.

As a side note, while working on the servehappy page content, we started collecting links to various resources that can be of use to people wanting to update their PHP version. These can be found in a separate servehappy-resources repository.

Project Progression

We intend to target only PHP 5.2.x initially, to not put too much pressure on the support channels of hosting providers. When a reasonable amount of time has passed and most of the initial updating effort has been completed, we can consider moving the needle up to PHP 5.3.x.

Provided that we have a clear roadmap, transparent communication and the patience to let site owners and hosters handle the updates in manageable intervals, this provides us with a tool to slowly catch up to PHP releases and reduce the currently growing gap between WordPress requirements and PHP versions.

Timeline

Here’s our current preliminary timeline:

Information Page on WP.org – Current Draft
– Trac ticket		 1st Quarter 2018
Admin Notice in Dashboard – Trac ticket 2nd Quarter 2018
Minimum PHP Requirements – Trac ticket 3rd Quarter 2018

Of course, these are only guesstimates. The actual development work involved makes this timeline easily possible, but what is time-consuming (and hard to predict) is the amount of discussions that are needed to find a concensus on all critical decisions.

Our Request

Before we invest more time into this project, we want to get a basic decision (in principle) about whether we should pursue or not.

  1. Is the servehappy project worthwhile and do we have a general buy-in from CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. leadership?
  2. Can we make the servehappy project an official feature project?
  3. Information Page – Can this page be hosted on the wordpress.org infrastructure?
  4. Information Page – Who is responsible for the final editorial check?

To this end, we had the servehappy project added to the agenda of the upcoming devchat meeting on 10th Jan, 2018. This post was prepared to allow attendees of this meeting to get a quick overview of the project in preparation for the meeting.

#php, #roadmap, #servehappy

Ryan McCue 3:15 am on August 23, 2017
Tags: , roadmap   

REST API Roadmap

If you’ve been following WordPress development this year, you may be wondering “what’s been happening with 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/. focus?” We’ve been a little under-the-radar for most of the year so far, so we thought publishing an update and roadmap might be a good idea.

For new contributors looking to get involved with the REST API focus or WordPress generally, there’s never been a better time, and we’d love to have your help on our projects. Read on to see what we’ve been doing, where we’re going, and how you can get involved.

Since 4.7

Since the REST API was merged into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. in WordPress 4.7, development activity has unfortunately been light. The merge into core was a huge effort, and after shipping in 4.7 we saw a drop-off in contribution and overall momentum as many 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. contributors took a break to recover from the stress of the merge. These contributions have not returned to previous levels, and there’s a few factors behind this: the move to TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., lack of a forward roadmap, and overall fatigue have hampered our ability to move forward quickly.

The core REST API focus goal is to utilise the REST API within the WordPress adminadmin (and super admin). Defining the scope of this project has involved auditing all admin-ajax calls, as well as the filters used inside these calls, and where they are used. In addition, we’ve been working on the low-level 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/. utilities we need to offer conceptual compatibility: while we can deprecate and remove old PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher filters, we need to offer new JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.-based filters to replace them.

The admin-ajax audit revealed that the majority of ajax requests can be grouped into four categories: Media, Themes, the Editor, and List Tables. The code for both Media and the Editor will gradually switch to the REST API moving forward with development around 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/, and likewise endpoints for better managing Themes are expected to be incorporated into 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. work.

Rather than simply refactor the existing code for the other actions in a piecemeal fashion, we’ve been working on prototyping bigger groups of related changes and features, starting with the New List Tables and Live Settings.

A significant portion of existing admin-ajax code is for handling list table actions. The existing JS code for these actions is particularly difficult to work with, and the existing list table actions user experience is frustratingly inconsistent (for example, deleting a comment happens inline, whereas deleting a post causes a page refresh). A reworking of the code has the potential to improve UXUX User experience significantly. New List Tables allows us to explore ideas around how we can improve the content organisation and management experience in the admin. This is a prototyping 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 where we’ve been exploring backwards compatibility techniques, and thinking about how a theoretical new management interface would look.

The Live Settings prototype uses the REST API settings endpoints to add live saving to the Settings screens. This dovetails with the work underway by the Accessibility team to switch to the Settings API, and the two projects will be able to work together in the future.

In addition to these API team projects, work has continued on REST API-related pieces on other teams, notably the Customizer 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 teams, who are working on API endpoints in their respective components.

Renewing our focus

Moving forward with the REST API, there’s a few key items we’re going to be focussing on. These items will have their own dedicated subteams and development cycles, and will work in parallel. The two broad goals are to use the API in the admin, and to solve authentication for external applications.

API in the Admin

Getting the API used in the WordPress admin is our primary focus. While it is technically possible to directly switch from admin-ajax calls to REST API calls, this is essentially refactoring with no real user benefit. Instead, we want to focus on changes that can improve the user experience.

For the feature prototypes (New List Tables, and Live Settings), we’re engaging members of the Design team to lead these features from a UX perspective. So far, these prototypes have been primarily about proving out the features and ensuring it’s actually technically possible to migrate these features to use the REST API; with the initial success on the technical side, we need to switch focus to delivering compelling user experiences.

New List Tables will be working with the goal of prototyping improved content management, using the REST API. This includes unifying and standardising existing interactions, and improving the perceived performance. This is a ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/.-based prototype, and uses the existing REST API endpoints.

Live Settings will be working with the goal of making settings changes seamless. We’ve seen huge strides forward with the Customizer for updating your site, and the backend settings deserve a better experience to match. Live Settings touches on similar areas as the Settings API Enhanced project spearheaded by the 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) team; we plan to continue working independently to avoid blocking each other, while keeping in touch about the respective projects.

Work on converting existing admin-ajax code to use the REST API will continue, however this won’t be a priority, as it generally doesn’t provide a strong benefit to end users. Most admin-ajax actions will naturally be deprecated as part of progress by other focuses, including Gutenberg and plans around the Media Library. We’ll continue working with other teams and focuses on their efforts here.

Authentication

External authentication is an unsolved problem, and one that’s crucial to API use outside of WordPress core itself, including the official WordPress apps.

There are two key problems to solve here: how do apps act on behalf of a user (authentication), and how do sites recognise valid apps (initial connection). We have existing solutions to both these problems (OAuth 1.0a and the Broker system respectively), however these are not the easiest solutions, and aren’t adequate for all use cases.

To date the most complete authentication solution maintained by the REST API team has been a plugin providing OAuth 1.0a authentication. Moving forward, we are switching authentication focus to OAuth 2. As Matt announced last year, we are going to begin shipping HTTPSHTTPS HTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information.-only features in WordPress: this allows us to switch to OAuth 2. Work started during the WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe 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/. on a new official OAuth 2 provider plugin which is now under ongoing development.

Simplifying the initial connection is a much harder piece, and this is a long-term project. Eventually, this should be as simple as a “Connect to WordPress” button, requiring minimal effort for app developers and no effort for users. This is a complex problem to solve, and no similar software has to work on the same scale we have. In the meantime however, we’re going to investigate pre-configuring Core to recognize and permit authentication from certain default apps, including the official WordPress mobile applications. Whitelisting applications in core is a practical expedient but this solution is not sustainable in the long-term, and should be replaced with a better system as soon as feasible. Work on solving this issue will be in the mid-term, however, as we need to ensure we have solid basics first.

Help Us!

The toughest challenge facing the REST API team right now is resourcing. There are only a few people working on the API regularly, and we need help to build out our projects—which is hopefully where you come in. We need people of all skillsets to help on New List Tables, Live Settings, and OAuth 2. This includes regular contributors, JS developers, and designers. And all of this will need documentation, too: following a productive contributor day at WordCamp Europe we are making progress expanding and reorganizing the REST API developer handbook, and would gladly welcome any interested docs contributors.

Our plan is to release the first public 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. of each of these projects within the next month, with regular releases from each project following that. New List Tables and Live Settings could be part of either a 4.9 or 5.0 release, while OAuth 2 will remain as a plugin until fully proven out, and would likely target a core release next year. This also requires coordination with the Mobile team, and finalising the approach to usage inside the apps.

If you’re interested in getting involved, we’d love to get your help. The API holds weekly meetings every Wednesday at 13:00 UTC (next meeting at Wednesday at 13:00 UTC), and we’re always happy to spend time helping people get started contributing.

#rest-api, #roadmap

Weston Ruter 2:00 pm on September 23, 2015
Tags: , roadmap,   

Outlining a possible roadmap for the Customizer

Planning for the future is a necessary and important part of the WordPress development process. As we consider the future of WordPress – both as a whole and individual features – we publish proposed roadmaps to encourage greater discussion and give insight into the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team’s thought process.

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

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

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

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

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

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

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

  • Transactions. This re-architecture of some of the Customizer internals improves compatibility with themes by loading the preview using a natural URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, and allows Ajax requests or even 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/. requests to be previewed. It also allows the preview to be viewed independently of the Customizer, so changes can be shared for others to review. See #30937.
  • Selective refresh. Only a piece of the page will need to be refreshed when this backend feature is implemented. (Formerly known as “Partial Refresh”.) Currently, this is available for menus in the Customizer. This eliminates duplication of display between PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors., keeping it DRY. See #27355.
  • Concurrency. Allows for “locking” settings using the Heartbeat 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., improving the overall user experience by preventing users from overwriting each other’s changes. See #31436.
  • 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.. Enables 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 developers to add features like draft, roll back, and scheduled changes (e.g. “change my background on January 1”). This builds upon transactions, as the setting changes are staged in a transaction, and this facilitates settings to be revisioned and for settings to be scheduled. See #28721, #31089.
  • Theme installation. Iterates on and completes the theme browsing experience.
  • Responsive preview. Iterates on the concept of live preview by giving users a better idea of what their site will look like on other devices. See #31195.
  • Bootstrapped Customizer. Lazy-load the Customizer into the current frontend view without having to leave the page. With selective refresh implemented, inline controls and frontend bootstrapping would be possible since full-page refreshes would no longer be required.
  • Improvements for both touch and small devices.

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

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

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

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

Taking these features together, below is a sequence outlining a possible roadmap for live preview and the Customize component in general, along with estimated targets. Please note that this is a proposed roadmap and is entirely dependent on contributor involvement. Additionally, many of these things will take place in a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. prior to core inclusion.

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

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

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

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

#customize, #roadmap, #roadmaps

John Blackbourn 10:35 pm on November 25, 2014
Tags: , , roadmap,   

An update on shared term splitting

Background reading: #30335 and the notes on shared term splitting in https://make.wordpress.org/core/2014/11/20/dev-chat-summary-november-19th/.

As part of the work on the taxonomy roadmap in 4.1, shared terms (terms which are shared across more than one 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. due to a slug collision) now get split when the term gets updated. The end result being that editing a term in one taxonomy will no longer affect the term in another taxonomy.

Many plugins store term IDs in post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., options, terms (!), etc, and the side effect of shared term splitting is that these caches can break when the ID of a term they reference changes. Not only that, but the breakage (and the cause) can be invisible to the user and hard to track down if they do notice it.

Following a discussion in #core Slack I’m proposing that shared term splitting is removed from 4.1 and we’ll add it back in for 4.2 and allow a full release cycle to get the word out to developers about the change. I’ll make the final decision during tomorrow’s dev chat.

Thanks in particular to @mboynes for his time spent on this.

(Note that this only affects existing terms; new terms do not get shared since r30240.)

#4-1, #dev-notes, #roadmap, #taxonomy

Ryan Boren 9:17 pm on February 11, 2008
Tags: , , roadmap   

Announced the feature freeze and first b …

Announced the feature freeze and first 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. hunt.

#25, #bug-hunt, #roadmap

Ryan Boren 6:08 am on February 11, 2008
Tags: , roadmap   

2.5 is now in feature freeze. Bug fixes …

2.5 is now in feature freeze. Bug fixes and polish from now to release.

#25, #roadmap

Ryan Boren 8:45 am on February 9, 2008
Tags: , roadmap   

Considering March 10th as the release da …

Considering March 10th as the release day for 2.5. That allows one month of 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..

#25, #roadmap