Tag Archives: proposal

Adam Zieliล„ski 9:40 am on July 4, 2022
Tags: , , proposal   

Proposal: Better REST API handling in JavaScript

This call for feedback will be open for the next two weeks until July 18th.

I propose extending the useEntityRecord hook to support editing and deleting WordPress data. It should make building features and plugins on top of WordPress 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/ easier.

The hook is a part of @wordpress/core-data, a 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 package providing tools for interacting with the WordPress REST API. You may know coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-data from Redux selectors, actions, and ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org 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. likeย  getEntityRecord, saveEntityRecords, useSelect.

Today, useEntityRecord enables easy access to data

The useEntityRecord hook enables fetching data with just a single line of code:

import { useEntityRecord } from '@wordpress/core-data';
 
// Inside of a React Component:
function PageTitle() {
    const { record, hasResolved } = 
        useEntityRecord( 'postType', 'page', 15);
    return hasResolved ? record.title : 'Loading...';
}

It was introduced to 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 in PR #38782 and will land in WordPress core in 6.1, the next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope..

For comparison, achieving the same result without useEntityRecords requires much more knowledge about the Gutenberg internals:

import { useSelect } from '@wordpress/data';
import { store as coreDataStore } from '@wordpress/core-data';

// Inside of a React Component:
function PageTitle() {
	const { page, hasResolved } = useSelect(
		( select ) => {
			const selectorArgs = ['postType', 'page', 15];
			return {
				page: select( coreDataStore )
					.getEntityRecord( ...selectorArgs ),
				hasResolved: select( coreDataStore )
					.hasFinishedResolution(
						'getEntityRecord',
						selectorArgs
					),
			};
		},
		[]
	);
	return hasResolved ? page.title : 'Loading...';
}

Tomorrow, useEntityRecord could ease editing data

In PR #39595, I proposed taking useEntityRecord one step further to make editing WordPress data equally easy:

const { record, edit, editedRecord, hasEdits, save } =
	useEntityRecord( 'postType', 'page', pageId );

// edit({ title: โ€œMy new titleโ€ });
// save();

// After React re-render:
// console.log( record.title );
// "My new title"

In comparison, this is how itโ€™s done today:

const {
	editEntityRecord,
	saveEditedEntityRecord,
} = useDispatch( coreStore );

const { record, editedRecord, hasEdits, isSaving, saveError } =
	useSelect(
		( select ) => {
			const args = [ kind, type, id ];

			return {
				editedRecord: select( coreStore )
					.getEditedEntityRecord( ...args ),
				hasEdits: select( coreStore )
					.hasEditsForEntityRecord( ...args ),
				isSaving: select( coreStore )
					.isSavingEntityRecord( ...args ),
				saveError: select( coreStore )
					.getLastEntitySaveError( ...args ),
			};
		},
		[ kind, type, id ]
	);

// editEntityRecord(kind, type, id, { title: โ€œMy new titleโ€ });
// saveEditedEntityRecord(kind, type, id);

// After React re-render:
// console.log( record.title );
// "My new title"

I combed through the WP Directory and found existing plugins that could already benefit from this pattern.

If this resonates with you, speak out before July 18th!

Introducing new APIs means having to maintain them indefinitely. Therefore, I would like to confirm this proposal offers an attractive solution to a real problem. This post attempts to do just that, and I would love to hear from you! All opinions are welcome, especially if:

  • Your JavaScript code interacts with the WordPress REST API
  • Youโ€™re maintaining code that leans on wordpress/core-data
  • Youโ€™ve struggled to learn how to use it
  • This new 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. would be helpful for you
  • Youโ€™re not convinced thereโ€™s a need to introduce such an API

Iโ€™m also interested in all the code samples related to editing and saving entity records that you are willing to share. It would be a great way to validate and exercise the proposed API.

This call for feedback will be open for the next two weeks until Jul 18, 2022.

Props to Anne McCarthy (@annezazu) and Grzegorz Ziรณล‚kowski (@gziolo) for their help in putting this proposal together.

#editor, #gutenberg, #proposal

Birgit Pauli-Haack 10:22 pm on February 25, 2022
Tags: , , , , , proposal   

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

Update Dec 1, 2022: The Developer Blogblog (versus network, site) went live as 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. on November 18, 2022 and was announced on this blog the following Monday WordPress Developer Blog is in publicย beta

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. blog 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 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 by 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

#core-dev-blog, #developer-news, #proposal

Ari Stathopoulos 6:35 pm on October 12, 2021
Tags: , 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 / capabilitiescapability Aย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โ€œedit_postsโ€ capability), but not permission to edit other usersโ€™ posts (the โ€œedit_others_postsโ€ capability). with limited adoption)

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

Why a team?

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

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

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

Resources and efforts

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

  • A performance tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) on Make websites
  • A performance channel in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/
  • A meeting every two weeks; time to be determined
  • Two team representatives for administrative purposes: they will be responsible for:ย 
    • Giving a quarterly report to the project leadership
    • Assigning roles in the website
  • A team lead/product owner. They will be responsible to create a mission statement for the team, highlight the areas to tackle, outline the scope and the roadmap for the improvements that need to be made.
  • Representation in (and influence on) other Make verticals and processes (e.g., themes, plugins, etc)

Next steps

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

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

  • Set up Slack channel and meeting schedule, and make.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ infrastructure.
  • Benchmark performance and define ongoing/future measurement & success criteria
  • Identify priority projects for CWV improvements with high-level timelines
  • Assign responsibilities for the projects identified

Props

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

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

#performance, #proposal, #team

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

WordPress JavaScript Standards Change Proposal

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

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

Currently, the standard reads:

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

The proposal is that the new wording should be:

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

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

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

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

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

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

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

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

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

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

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

#coding-style, #codingstandards, #proposal

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

Enhancing image preview: core proposal

For many years search engine results have shown various images size publicly made available by site owners. Last year (September 2019), some extra controls over the content preview was introduced to Google Search followed by Bing who announced similar capabilitiescapability Aย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โ€œedit_postsโ€ capability), but not permission to edit other usersโ€™ posts (the โ€œedit_others_postsโ€ capability). for their Search Engine earlier this year (April 2020).

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

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

Proposed Solutionย 

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

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

WordPress may already inject a โ€œrobotsโ€ metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) into a page, for example when a site is set to disallow search engines from indexing it. To facilitate large image previews as well as exposing a central management layer for the โ€œrobotsโ€ meta tag, a new function wp_robots() should be introduced. The function would include a filterable list of values to include in the โ€œrobotsโ€ meta tag and render the meta tag only if necessary. Having this centralized layer will streamline robots management and interoperability between plugins.

By default, the list would cover the following values:

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

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

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

Whatโ€™s next?

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

#images, #proposal, #seo

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

Setting the structure and an agenda for APAC-friendly devchat

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

Based on that advice, I propose a first meeting to set up these devchats and schedule them on the #core channel on Make WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.

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

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

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

See you on Thursday!

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

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

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

Proposal: Core Team Rep Elections

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

The Role

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

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

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

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

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

Here are the main tasks:

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

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

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

Nominating

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

If you want to nominate someone in private, please reach out to @current-team-rep-1 and @current-team-rep-2 on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.

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

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

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

Voting

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

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

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

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

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

Results

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

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

Next steps

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

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

#proposal, #team-reps

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

XML Sitemaps Feature Project Proposal

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

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

Today, WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. does not generate XML Sitemaps by default, affecting a high number of WordPress websites search engine discoverability. 4 out of the top 15 plugins on WordPress pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. repository currently ship with their own implementation of XML sitemaps, pointing to a universal need for this feature and a great potential to join forces.

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

Proposed Solution

In a nutshell, the goal of the proposal is to integrate basic XML Sitemaps in WordPress Core and introduce an XML Sitemaps APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to make it fully extendable. Below is a diagram of the proposed XML Sitemaps structure:

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

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

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

Developers

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

  • Add extra sitemaps and sitemap entries
  • Add extra attributes to sitemap entries
  • Provide a custom XML Stylesheet
  • Exclude a specific post type from the sitemap
  • Exclude a specific post from the sitemap
  • Exclude a specific taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. from the sitemap
  • Exclude a specific term from the sitemap
  • Exclude a specific author from the sitemap
  • Exclude a specific authors with a specific role from the sitemap

Non Goals

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

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

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

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

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

Whatโ€™s next?

Your thoughts on this proposal would be greatly valued. Please share your feedback, questions or interest in collaboration by commenting on this post. After that we can decide on how to best proceed with this proposed project and set up a meeting on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/ to kick things off.

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

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

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

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

Customize Changesets (formerly Transactions) Merge Proposal

This is a merge proposal and overview of Customize Changesets (#30937), a project formerly known and proposed as CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your siteโ€™s appearance settings. Transactions back in January 2015. The customizer is WordPressโ€™s framework for doing live previews of any change on your site. One of the biggest problems the customizer faces right now is that changes are ephemeral. If you navigate away, you lose what you are working on. Additionally, you can not share proposed changes with others, nor can you take the changes you are working on and save to continue working later.

Imagine a WordPress user named Tina. Tina is building a website for her daughterโ€™s band. The band has been getting more and more popular, and Tina wants to experiment with some new widgets in the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. but also wants to be able to share the proposed solutions with her husband Matthew. Right now, Tina and Matthew would need to be in the same room to collaborate. Or Tina would need to take screenshots, but that kind of defeats the purpose of live preview. If only there was a way to make customizer changes persistent without publishing them.

Introducing Customize Changesets

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

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

Design and Technical Decisions

For the initial coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. merge, no UIUI User interface changes are being proposed. The feature will only be exposed as the new query parameter on the URL. Adding a UI to this feature will happen in a future release. As such, the proposal for customize changesets is similar to the proposal for including theย REST API infrastructure: it provides a foundation for new core features in future releases and a platform for plugins to add new features. Nevertheless, while the customize changesets patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. doesnโ€™t introduce any new features it does fixย several long-standing issues related to incompatibilities between JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a userโ€™s browser. https://www.javascript.com running on the siteโ€™s frontend when previewed in the customizer.ย Under the hood, the customize changesets patchย touches on many of the lowest level pieces of the customizer. Please check out the Customize Changesets Technical Design Decisions to see what is happening under the hood.

Testing

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

The patch is in a GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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 by 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 capabilitiescapability Aย capabilityย is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on theirย role. For example, users who have the Author role usually have permission to edit their own posts (the โ€œedit_postsโ€ capability), but not permission to edit other usersโ€™ posts (the โ€œedit_others_postsโ€ capability). that changesets provide. New UIs can provide a wayย to schedule changes, theย ability to undo the last change, show anย audit log (revision history) for changes, collaborative editing of a customizer changeset, and so on. Futureย feature projects will explore many of these and feature plugins will start to prototype them.

Thanks to @jorbin who contributed to this proposal post.

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

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

The Road to 4.7 Beta 1

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

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

There are 60 enhancementsย and feature requests milestoned for 4.7. ย Of these, 21 have no owner. ย At the end of this week, all enhancements and feature requests without an owner will be punted. ย Tickets will also be regularly evaluated this week. ย Over the next two weeks, tickets will be evaluated during both scheduled and unscheduled bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs, and tickets not moving forward will be removed from the milestone. The next scheduled bug scrub will be at Wednesday, October 12, 2016 17:00 UTC.

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

#4-7, #proposal