Author Archives: Gary Pendergast

Gary Pendergast 1:52 am on August 30, 2019
Tags: ,   

Gutenberg Local Environment Rewrite

With the introduction of the WordPress Local Environment, the next step was to make this shiny new development environment available for 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/ to use.

tl;dr: If you currently run ./bin/setup-local-env.sh to use the Gutenberg environment, switch to running npm run env install, instead.

Gutenberg’s Local Environment was originally an experiment in making it easy to setup a local development environment. It was a success in some ways, in that it was easier than other methods, but it was by no means easy overall, particularly for non-developer contributors. Over time, it grew into a complex set of shell scripts, with surprising interdependencies and side effects. Being written in Bash made the scripts harder to maintain, and limited the potential audience to those who had a Bash-compatible terminal installed.

Basing Gutenberg’s Local Environment on CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s has several immediate advantages:

  • It’s cross-platform, only requiring Docker to be installed and running. It also works with Docker Toolbox, allowing all Windows users (not just those with Windows 10 Pro) to use it.
  • The WordPress environment uses Docker images that we maintain for the purpose of Core development, which allows us to to customise them as we need.
  • It ensures that tests for Core and Gutenberg run in the same environment.
  • It’s a single environment, which helps avoid the naming clashes we’ve occasionally seen between the Core and Gutenberg environments.

More broadly for WordPress in the long term, tying the development processes of Core and Gutenberg a little closer together helps pave the way for the processes to merge over time.

Architectural Decisions

Removing the Docker config from Gutenberg entirely (barring a minimal template to hook into the Core environment), and requiring wordpress-develop to run on top of gives us significantly more future flexibility with the development environment.

Additionally, this continues to lay the groundwork for an environment that works as easily as possible for non-developer contributors. In particular, this environment is intended to be usable by all feature plugins, allowing them to easily enable new contributions in a familiar environment. (Or, an environment that will become familiar, at least. 😉)

There are several reasons for putting the main Docker config in Core, and extending it in Gutenberg:

  • Having a single docker-compose.yml file in Core, as opposed to having one in Core, one in Gutenberg, and many more in other feature plugins that will be able to use this, means that there’s only set of Docker containers running. Docker has been observed getting a little weird when trying to run containers with the same names, which mount volumes with the same names.
  • Having multiple docker-compose.yml files doesn’t lend itself to testing plugins together: each 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 ends up with its own environment which can’t talk to others.
  • Managing how plugins can mount older versions of WordPress becomes exponentially more difficult if the docker-compose.yml config needs to work for every WordPress 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". (this is a requirement, so that auto updates can be worked on in old branches), rather than being able to tweak the config for each branch.
  • Ideally, feature plugins shouldn’t need to do much customisation of the Docker environment, beyond mounting their particular volumes. Exposing the entire docker-compose.yml file is overkill.

That said, not every Gutenberg contributor will have a WordPress source clone, or want to manage one. So, there’s also a helper which will download and install a copy of the WordPress source repo, when needed.

Much like the WordPress environment, however, the Gutenberg environment doesn’t automate everything. As we found with the original Gutenberg environment, too much automation tended to make it difficult (particularly for more advanced contributors) to customise or debug their environment. For example, the scripts no longer install NVM, switch your Node version, or run npm install.

Using the Gutenberg Local Environment

If you don’t have a WordPress repo to work with, just run npm run env install, that’ll take care of downloading WordPress, building it, and connecting Gutenberg into it.

If you prefer to hook into your own WordPress source checkout (particularly useful for fixing issues that span Core and Gutenberg), set the WP_DEVELOP_DIR environment variable to your WordPress source directory, and run npm run env connect. This will write a docker-compose.override.yml file to the WordPress source directory, and restart the Docker containers. The Docker override file contains the appropriate volume settings for mounting Gutenberg within the WordPress environment.

Running npm run env will give you a complete list of the available commands, and what they’re for.

The WordPress Local Environment configuration options are also available for configuring the Gutenberg environment.

Adding the Local Environment to another feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.

The @wordpress/scripts documentation includes information about including and configuring the local environment.

There currently isn’t a clean method for sharing a managed WordPress checkout (ie, one installed by npm run env install) between plugins. Let’s figure out how that could work!

Also, this process is still mostly untested, so please pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me earlier rather than later if you run into problems. 🙂

Developing Plugins/Themes with the Local Environment

At this stage, the Local Environment is intended for developing Core, and Feature Plugins: it doesn’t have the config options that the wider plugin/theme ecosystem needs, and the base Docker images are built for Core purposes.

Of course, I know y’all will try to use it, anyway. 😉 Testing and feedback is welcome, but please be aware that fixes and features will prioritise Core/Gutenberg requirements for the foreseeable future. Patches and PRs which recognise and allow for this are the best way for additional changes to land. 💖

What’s Next?

Please try out the new Gutenberg Local Environment, and report any issues you run into over on the Gutenberg repository.

If you have thoughts about making this aspect of contributing to Core/Gutenberg easier, I’d love to hear about them!

#block-editor, #gutenberg

Gary Pendergast 2:11 am on August 26, 2019
Tags: , , , , ,   

APAC Triage and Bug Scrub Sessions

Living in APAC timezones can be difficult. From waking up at 3am for meetings, to flying 20+ for WCUS or WCEU (WCAsia is coming to fix that!), to hearing “what’s it like living in the future?” jokes for the millionth time. One thing that shouldn’t be hard is contributing to WordPress, and it’s time to make that even easier, with APAC-friendly triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and 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. scrub sessions.

You may have already seen 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/ meetings happening every second week for the last few months, but starting Thursday at UTC 0600, we’ll alternate each week between working on WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., and Gutenberg! This week, join in the fun in the #core 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 a WordPress Core bug scrub. Next week, the party will be in the #core-editor Slack channel, for a Gutenberg bug scrub. 🎉

The meeting lead will pick a report to work through, but if there are particular issues you’d like to get more eyes on, or you have a 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./PR that you’d like reviewed, this is the place to bring it up!

#apac, #bug-scrub, #core, #core-editor, #gutenberg, #triage

Gary Pendergast 7:10 am on August 5, 2019
Tags:   

WordPress Local Environment

The e2e test infrastructure was recently introduced to WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., using Docker to create a local WordPress environment for running the tests.

Almost immediately, folks started trying to use it as a full local development environment, which is a pretty good indication that we should make that easier. 🙂 #47767 is a complete rebuild of the e2e environment, turning it into a dedicated development environment, that also happens to function as an e2e environment. 🎉

The Goal

As we discovered with 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/ local environment, trying to make a shell script based do-it-all tool results in a sub-par experience for everyone. It’s difficult for such a tool to work well across all use cases: if it tries to handle common problems automatically, it will cause problems for regular contributors. If it does the bare minimum, it will be unusable for infrequent contributors. There doesn’t appear to be a happy middle ground.

As such, the idea with this new tool is to allow setting up a local development environment by running as few commands as possible, providing sensible defaults, but allowing as much customisation as possible. This gives a solid base for regular contributors to work from (particularly when testing against uncommon configurations), but also provides room for an external tool that provides new contributors with a seamless experience.

Infrastructure

In order to make this work as cleanly as possible, there are custom Docker images configured for running WordPress. They work for all versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher from 5.2 to 7.3, allowing easy testing of different PHP versions. The image definitions are generated and committed to the wpdev-docker-images GitHub repository, they’re then built and deployedDeploy Launching code from a local development environment to the production web server, so that it's available to visitors. to Docker Hub by Travis.

These images aren’t intended for folks that wish to host Docker-based WordPress sites. Their primary focus is on creating a WordPress development environment.

Using

This tool currently isn’t optimised for inexperienced contributors. Setting it up and using it requires some familiarity with both Docker and the command line.

First off, you’ll need to install Docker.

You’ll also need a recent version of Node. We rarely bump the minimum version of Node required, so if you don’t have a particular need for switching Node versions, installing the latest LTS version is probably the easiest option.

Following that, you’ll need to run npm install to download some build tools that WordPress needs, then npm run env:start will start the server at http://localhost:8889. npm run env:install will set up a clean installation, with the user adminadmin (and super admin) and the password password.

Congratulations! You can now work on WordPress! Here are some extra commands that will help you along the way:

npm run env:stop

If you prefer to stop your Docker containers when you’re not using them, this command will stop them. You can always restart them by running npm run env:start again.

npm run env:clean / npm run env:reset

These can be used to clean up your development environment if things aren’t working correctly. The former will delete the database and some temporary files, while the latter will remove all images, so the next time you run npm run env:start, they’ll be downloaded fresh.

npm run env:logs

Shows the logs server logs.

npm run env:cli

This will run WP-CLI. Where the WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ documentation mentions running wp, run npm run env:cli instead. For example, npm run env:cli help.

npm run test:php / npm run test:e2e

These commands will run the PHPUnit and E2E test suites, respectively.

Configuring

You can also customise the development environment by setting particular environment variables before starting it. After changing any of these settings, you’ll need to run npm run env:stop then npm run env:start before they take effect.

Each OS has a slightly different way of setting environment variables. In these examples, substitute VARIABLE_NAME for the name of the setting you want to change, and value for the value you want to set it to.

Linux, macOS, and WSL: export VARIABLE_NAME=value
Windows (DOS/CMD.exe): SET VARIABLE_NAME=value
Windows (PowerShell): Set-Item Env:VARIABLE_NAME=value

LOCAL_PORT

Change the port number that the site will be available on. You’ll need to run npm run env:install after changing this.

LOCAL_DIR

Change whether the site runs from the src or build directory.

LOCAL_PHP

The PHP version to use when running the site. Valid options are ‘latest’, and ‘{version}-fpm’, where ‘{version}’ is any x.y PHP version from 5.2 onwards.

LOCAL_PHP_XDEBUG

Set to true or false to enable or disable the XDebug module in PHP.

LOCAL_MYSQL

The MySQL version to use. See https://hub.docker.com/_/mysql/ for valid versions. If you downgrade the MySQL version, you may need to run npm run env:clean to reset the MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. data files.

LOCAL_WP_DEBUG / LOCAL_WP_DEBUG_LOG / LOCAL_WP_DEBUG_DISPLAY / LOCAL_SCRIPT_DEBUG

The debug settings to add to wp-config.php. Set to true or false to change their corresponding debug setting. If you already have a site up and running, it may be easier to just edit these in the wp-config.php file.

What’s Next?

Right now, this has only been committed to trunk. It can soak there for a bit, ensuring it works well for everyone.

Following that, it will be backported to all branches back to WordPress 3.7. Since this is the oldest version we still occasionally make releases for, there’s no value in porting it further back. Importantly, since the Security Team is evaluating ceasing backporting of security fixes to WordPress 3.7, it’s likely that we’ll need to be doing work on that 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". to both inform and help site owners upgrade. Having a working development environment makes this a much less painful task.

I’ve been sporadically working on a tool called TestPress, which is intended to make the experience of contributing to WordPress as seamless as possible, particularly for new and non-developer contributors. It hasn’t been updated to make use of this new local environment yet, but that’s high on my todo list. For folks who aren’t comfortable downloading and installing Docker, managing Node versions, or working on the command line, TestPress manages all of that for you. I’ll have more to write about TestPress when it’s in a more usable state. 🙂

That’s about it! Please test and report bugs as you find them! 🐛

#core

Gary Pendergast 6:03 am on July 12, 2019
Tags: ,   

PHP Coding Standards Changes

This is a follow-up to several changes proposed a few months ago.

While reading these changes, it’s important to keep in mind that they only apply to WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.: you can (and should) choose practices that best suits your development style for your own plugins and themes. The coding standards are intentionally opinionated, and will always lean towards readability and 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) over being able to use every possible language feature.

Closures (Anonymous Functions)

There was quite a lot of discussion around this proposal, particularly with regards to allowing closures as hook callbacks. Thank you everyone for your input, and for keeping disagreements respectful. 🙂

We do need a decision, however, and there were several key points that led to this:

  • It’s currently difficult to remove closures as hook callbacks. #46635 has several interesting proposals to address this in an entirely backward compatible manner.
  • While WordPress Core should strive to allow any callback to be unhooked, plugins have no such restriction.
  • The WordPress 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 Standards allow for closures to be used, we should be aiming to bring the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher standards in line with that.
  • The broader PHP world has embraced closures for many years, and have found ways to use them responsibly. We shouldn’t ignore PHP usage outside of WordPress.

With these points in mind, a conservative, but practical step is to allow closures as function callbacks, but not as hook callbacks in Core. Ultimately, we should be able to allow any sort of complex callback to be attached to 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., but the Core APIs aren’t quite ready for it yet.

Coding Standards Change

Where appropriate, closures may be used as an alternative to creating new functions to pass as callbacks.

Closures must not be passed as filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. or action callbacks, as they cannot be removed by remove_action() / remove_filter() (see #46635 for a proposal to address this).

Short Array Syntax

A little less controversial, but still with varying opinions, was the proposal to require short array syntax ( [ 1, 2, 3 ] ) instead of long array syntax ( array( 1, 2, 3 ) ) for declaring arrays.

While I’m personally partial to short array syntax, there were two particularly convincing arguments for using long array syntax:

  • It’s easier to distinguish from other forms of braces, particularly for those with vision difficulties.
  • It’s much more descriptive for beginners.

So, this change to the coding standards is the opposite of what was originally proposed, but is ultimately the more inclusive option.

Coding Standards Change

Arrays must be declared using long array syntax in WordPress Core.

Short Ternary Operator

The original proposal was to allow the short ternary operator, but this change reverses that. There’s a good argument that it looks too much like the null coalesce operator, especially as they perform different functions.

Take the following example from Core:

$height = isset( $data['height'] ) ? $data['height'] : 0;

It’s not possible to reduce this line with the short ternary operator, but it can be trivially reduced with the null coalesce operator:

$height = $data['height'] ?? 0;

The vast majority of other ternary operators in Core (which don’t have an isset() test) look something like this:

$class = $thumb ? ' class="has-media-icon"' : '';

This also can’t be reduced using the short ternary operator.

As the null coalesce operator is a useful addition (which we’ll be able to use once the minimum PHP version bumps to 7+), whereas the short ternary operator can only be used in a handful of cases in Core, it’s better to avoid the potential confusion, and not use the short ternary operator.

Coding Standards Change

The short ternary operator must not be used.

Assignments Within Conditionals

Particularly when there are multiple conditions, it can be quite difficult to spot assignments occurring in a conditional. This arguably falls under the Clever Code guidelines, but hasn’t been formalised.

I got a little ahead of myself with this one, and have already removed all assignments in conditionals from Core. Adding this change to the standard formalises the practice.

Coding Standards Change

Assignments within conditionals must not be used.

#php, #wpcs

Gary Pendergast 11:17 am on March 27, 2019
Tags: , ,   

Dev Chat Agenda: March 27

Below is the agenda for the weekly devchat meeting on Wednesday March 27 21:00 UTC:

  • Announcements
  • 5.2 updates
    • 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. 1 will be released today
    • Please review the proposed coding standards updates
  • Calls from component maintainers
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

This meeting is held in the #core channel in the Making WordPress Slack.

#5-2, #agenda, #dev-chat

Gary Pendergast 2:14 am on March 26, 2019
Tags: ,   

Coding Standards Updates for PHP 5.6

With the minimum PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher version increasing to 5.6 as of WordPress 5.2, now’s a good time to be reviewing the WordPress Coding StandardsWordPress Coding Standards The Accessibility, PHP, JavaScript, CSS, HTML, etc. coding standards as published in the WordPress Coding Standards Handbook. May also refer to The collection of PHP_CodeSniffer rules (sniffs) used to format and validate PHP code developed for WordPress according to the PHP coding standards..

Here is a set of changes that I’d like to propose.

Anonymous Functions (Closures)

Anonymous functions are a useful way to keep short logic blocks inline with a related function call. For example, this preg_replace_callback() call could be written like so:

$caption = preg_replace_callback(
	'/<[a-zA-Z0-9]+(?: [^<>]+>)*/',
	function ( $matches ) {
		return preg_replace( '/[\r\n\t]+/', ' ', $matches[0] );
	},
	$caption
);

This improves the readability of the codebase, as the developer doesn’t need to jump around the file to see what’s happening.

Coding Standards Proposal

Where the developer feels is appropriate, anonymous functions may be used as an alternative to creating new functions to pass as callbacks.

Anonymous functions must not be passed as filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. or action callbacks in WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., as they cannot be removed by remove_action() / remove_filter() (see #46635 for a proposal to address this). Outside of Core, developers may pass anonymous functions as filter or action callbacks at their own discretion.

Namespaces

Namespaces are a neat way to encapsulate functionality, and are a common feature in modern PHP development practices. As we’ve discovered in the past, however, introducing namespaces to the WordPress codebase is a difficult problem, which will require careful architecture and implementation.

Side note: there’s currently no timeline for introducing namespaces to WordPress Core, expressions of interest are welcome. 🙂

Coding Standards Proposal

At this time, namespaces must not be used in WordPress Core.

Short Array Syntax

Rather than declaring arrays using the array( 1, 2, 3 ) syntax, they can now be shortened to [ 1, 2, 3 ]. This matches how arrays are declared in the WordPress 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 Standards.

To allow for plugins and themes that support older versions of WordPress, I’d like to propose that WordPress Core switches to short array syntax immediately, but plugins and themes may choose which they use. A future iteration would make short array syntax a requirement.

Coding Standards Proposal

Arrays must be declared using short array syntax in WordPress Core. Arrays may be declared using short array syntax outside of Core.

Short Ternary Syntax

A fairly common pattern when setting a variable’s value looks something like this:

$a = $b ? $b : $c;

The short ternary syntax allows this to be shortened, like so:

$a = $b ?: $c;

It’s important to note that this is different to the null coalesce operator, which was added in PHP 7. If $b is undefined, the short ternary syntax will emit a notice.

Coding Standards Proposal

Short ternary syntax may be used where appropriate.

Assignments within conditionals

While this isn’t directly related to the PHP version bump, I’d like to propose disallowing assignments within conditionals. Particularly when there are multiple conditions, it can be quite difficult to spot assignments occurring in a conditional. This arguably falls under the Clever Code guidelines, but hasn’t been formalised.

For example, this if statement would be written like so:

$sticky_posts = get_option( 'sticky_posts' );
if ( 'post' === $post_type && $sticky_posts ) {
	// ...
}

Coding Standards Proposal

Assignments within conditionals are not allowed.

Other New Features

Any other new features available in PHP 5.6 can be used, though we should continue to carefully consider their value and (in the case of newer PHP modules) availability on all hosts.

How do you feel about these changes? Are there other changes related to PHP 5.6 that you’d like to suggest?

#php, #wpcs

Gary Pendergast 4:54 am on March 23, 2019
Tags:   

WordPress 5.2 Beta 1 Status Update (take two)

The remaining feature tickets in the milestone have been successfully committed! Thank you everyone for helping us get there. 🙂

During preliminary testing prior to the release, however, several folks discovered an issue with the new package signing feature, which would cause subsequent WordPress updates to fail (#46615).

Out of an abundance of caution, I’ve cancelled the WordPress 5.2 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. 1 release that was scheduled for today, and tentatively rescheduled it for March 27, 2019, pending investigation of this package signing issue. I haven’t changed any other milestone dates, though they should be reviewed once we’ve released WordPress 5.2 Beta 1, to ensure they’re still realistic.

If you’re running the WordPress 5.2 Alpha nightly builds, you may not be able to update to subsequent nightly builds from the Dashboard due to this issue. Once #46615 is fixed, you can resume updates by manually copying the new files to your test site, or by updating with WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/: wp core update --version=trunk.

#5-2

Gary Pendergast 7:12 am on March 22, 2019
Tags:   

WordPress 5.2 Beta 1 Status Update

WordPress 5.2 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. 1 was scheduled to be released yesterday, March 21, 2019.

At the time of writing, there are two remaining tickets which need to be committed or punted before beta 1 can be released. Both of these tickets have patches that are ready to commit: they implement the functionality that they’re expected to, any remaining issues with these features can be addressed during the beta period.

With that in mind, the WordPress 5.2 Beta 1 release date only needs to be pushed back one day, to March 22, 2019.

Thank you everyone for the work you’ve put in to get us here! If you have some time to review the tickets linked above, all input is greatly appreciated. 💖

#5-2

Gary Pendergast 12:17 pm on February 28, 2019
Tags: , , ,   

Dev Chat Summary: February 27th

This post summarises the weekly dev chat meeting from February 27th (agenda, Slack archive).

WordPress 5.1.1 Updates

To allow a little extra time, WordPress 5.1.1 will now be released on March 12. To make the most of the available time, two 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 have been scheduled. You can read more about them on the WordPress 5.1.1 schedule update post.

The are currently 18 tickets milestoned for 5.1.1.

WordPress 5.2 Updates

There was some discussion last week about the release schedule: @jorbin proposed shifting the release dates by a week. The new release dates for WordPress 5.2 are:

  • 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. 1: 21 March, 2019
  • Release Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).: 17 April, 2019
  • General Release: 30 April, 2019

The WordPress 5.2 scope and schedule proposal included a suggestion for “feature release leads” to help keep the release running on time. If you’re interested in volunteering, please comment on that post, and mention @chanthaboune.

Updates from focus leads and component maintainers

There have been quite a few ongoing discussions around release cadences, @desrosj has kindly summarised the situation into a post. If you have thoughts or feelings on this topic, please comment on this post:

Major and Minor Version Release Cadence

There are several tickets for 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 PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher compatibility with patches that need testing, feedback, and committing. If you’re able to do one or more of these, please lend a hand! 🙂

The work on reverting the recent bulk ticket close will be kicking off soon. If you’re a component maintainer who does not want to have tickets in your component re-opened, please pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” @desrosj know.

General Announcements and Open Floor

@joyously asked about determining if there are test cases for everything, which lead to a discussion about setting up a code coverage tracker. #46373 now exists for researching options, and setting this up.

#5-1-1, #5-2, #core, #dev-chat

Gary Pendergast 1:12 am on February 21, 2019
Tags:   

WordPress 5.1 Release Day

We’re less than 24 hours away from WordPress 5.1! If you’d like to help get this release out the door, here’s how you can join in.

The current plan is to start the release process at February 21th, 2019 at 22:00 UTC, in the #core 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.

The major version release process can take a bit more time than the betas or Release Candidates, particularly if we run into any last minute issues that need to be addressed.

The Release Process

We’ll be working through the Major Version Release process, for anyone who wants to follow along.

I ran through the Dry Run steps earlier, there was one file missing from $_old_files (#46284).

How You Can Help

A key part of the release process is checking that the zip packages work on all the different server configurations available. If you have some of the less commonly used servers available for testing (IIS, in particular), that’d be super helpful. Servers running older versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and MySQLMySQL MySQL is a relational database management system. A database is a structured collection of data where content, configuration and other options are stored. https://www.mysql.com/. will also need testing.

In particular, please test:

  • Does a new WordPress install work correctly? This includes running through the manual install process, as well as WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ or one-click installers.
  • Does it upgrade correctly? Are the files listed in $_old_files removed when you upgrade?
  • Does 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 upgrade properly?
  • Run through some basic usage flows, both on desktop and mobile:
    • Publish a post, including a variety of different blocks.
    • Comment on the post.
    • Install a new 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/theme, or upgrade an existing one.
    • Change the site language.
    • If you’re a plugin developer, or if there are complex plugins you depend upon, test that they’re working correctly.

You can even start this early, by running the WordPress 5.1 RC2 packages, which are built using the same method as the final packages.

#5-1