Go to file
bernhard-reiter c44432b338 Block Hooks: Store ignored hooked blocks metadata in anchor block.
The biggest tradeoff that was made in the implementation of Block Hooks was that they were limited to layouts (i.e. templates, template parts, and patterns) that ''didn't have any user modifications'' (see #59313 for the reason). This changeset is a preparatory step to remove this limitation, so they’ll eventually also work with user-modified layouts.

The crucial problem to solve is how to acknowledge that a user has opted to remove or persist a hooked block, so that the auto-insertion mechanism won't run again and inject an extraneous hooked block on the frontend when none is solicited.

This is achieved by storing all known blocks hooked to a given anchor block in the `metadata` attribute on that anchor block; specifically in a field called `ignoredHookedBlocks` inside of the `metadata`. Hooked blocks are only rendered on the frontend if they're absent from that field; OTOH, they're injected into that field (via the REST API) when first loaded in the editor.

This simple logic guarantees that once a user modifies a given layout, those changes are respected on the frontend; yet if a plugin that includes a hooked block is activated after those modifications have taken place, the hooked block will be rendered on the frontend. This new technique supplants the one previously used (i.e. rendering hooked blocks on the frontend only if a layout doesn't have any modifications) in a rather direct way.

Note that this changeset only introduces the new metadata field and relevant logic; it does not yet enable hooked block insertion into modified layouts. That will be done in a subsequent step (see #59646).

Props gziolo.
Closes #60008.

git-svn-id: https://develop.svn.wordpress.org/trunk@57157 602fd350-edb4-49c9-b593-d223f7449a82
2023-12-04 20:24:33 +00:00
.cache Build/Test Tools: Cache the results of PHP_CodeSniffer across workflow runs. 2021-11-16 14:17:26 +00:00
.devcontainer Build/Test Tools: Change the version of Node.js in the Codespaces container. 2023-08-24 14:07:53 +00:00
.github Build/Test Tools: Update the MariaDB test strategy matrix. 2023-12-04 18:51:01 +00:00
src Block Hooks: Store ignored hooked blocks metadata in anchor block. 2023-12-04 20:24:33 +00:00
tests Block Hooks: Store ignored hooked blocks metadata in anchor block. 2023-12-04 20:24:33 +00:00
tools Update editor related npm packages 2023-09-26 14:20:18 +00:00
.editorconfig General: Instruct file editors not to trim trailing whitespace in markdown files. 2018-03-20 22:14:53 +00:00
.env Build/Test: Revert unintentional .env change in [56449]. 2023-08-24 17:33:04 +00:00
.eslintignore Build/Test Tools: Enable JSDocs to be linted with ESLint. 2020-07-27 23:33:51 +00:00
.eslintrc-jsdoc.js Build/Test Tools: Enable JSDocs to be linted with ESLint. 2020-07-27 23:33:51 +00:00
.git-blame-ignore-revs Build/Test Tools: First pass at a .git-blame-ignore-revs file. 2022-03-29 03:20:29 +00:00
.gitignore Build/Test Tools: Migrate Puppeteer tests to Playwright. 2023-10-13 08:11:41 +00:00
.jshintrc Emoji: Optimize emoji loader with sessionStorage, willReadFrequently, and OffscreenCanvas. 2023-06-27 17:22:59 +00:00
.npmrc Build/Test Tools: Bump the required versions of Node.js and npm. 2023-08-09 18:52:42 +00:00
.nvmrc Build/Test Tools: Bump the required versions of Node.js and npm. 2023-08-09 18:52:42 +00:00
composer.json Coding Standards: Upgrade WPCS to version 3.0.1. 2023-10-08 13:07:46 +00:00
CONTRIBUTING.md Build/Test Tools: Add a missing word to the CONTRIBUTING.md file. 2021-02-23 19:59:20 +00:00
docker-compose.yml Build/Test Tools: Ensure database containers are prepared for commands. 2023-08-24 21:02:47 +00:00
Gruntfile.js Build/Test Tools: Revert accidental change to Gruntfile.js 2023-10-13 08:13:58 +00:00
jsdoc.conf.json Build Tools: Fix JSDoc configuration include paths. 2018-06-14 12:45:06 +00:00
package-lock.json Editor: update npm packages for 6.4.2. 2023-11-14 00:09:17 +00:00
package.json Editor: update npm packages for 6.4.2. 2023-11-14 00:09:17 +00:00
phpcompat.xml.dist Coding Standards: Remove unnecessary directives in the PHPCompatibility ruleset. 2023-09-23 11:05:18 +00:00
phpcs.xml.dist Coding Standards: Remove a redundant section in the phpcs.xml.dist ruleset. 2023-10-27 08:27:33 +00:00
phpunit.xml.dist Build/Test Tools: Remove random_compat from PHPCS and PHPUnit configuration files. 2023-09-24 07:43:50 +00:00
README.md Build/Test Tools: Add a readme note on passing parameters into the PHPUnit tests. 2023-11-24 14:07:00 +00:00
SECURITY.md Trunk is now 6.5 alpha. 2023-10-17 18:39:45 +00:00
webpack.config.js Build: Enable React Fast Refresh for block development 2022-04-11 16:08:12 +00:00
wp-cli.yml Build/Tests: Default to running unit tests from src. 2019-01-09 10:09:02 +00:00
wp-config-sample.php Text Changes: Update mentions of “web site” to “website” for consistency. 2023-11-22 17:42:11 +00:00
wp-tests-config-sample.php Docs: Use generic references to "Database" in wp-config-sample.php. 2021-12-14 08:42:16 +00:00

WordPress

Welcome to the WordPress development repository! Please check out the contributor handbook for information about how to open bug reports, contribute patches, test changes, write documentation, or get involved in any way you can.

Getting Started

Using GitHub Codespaces

To get started, create a codespace for this repository by clicking this 👇

Open in GitHub Codespaces

A codespace will open in a web-based version of Visual Studio Code. The dev container is fully configured with softwares needed for this project.

Note: Dev containers is an open spec which is supported by GitHub Codespaces and other tools.

In some browsers the keyboard shortcut for opening the command palette (Ctrl/Command + Shift + P) may collide with a browser shortcut. The command palette can be opened via the F1 key or via the cog icon in the bottom left of the editor.

When opening your codespace, be sure to wait for the postCreateCommand to finish running to ensure your WordPress install is successfully set up. This can take a few minutes.

Local development

WordPress is a PHP, MySQL, and JavaScript based project, and uses Node for its JavaScript dependencies. A local development environment is available to quickly get up and running.

You will need a basic understanding of how to use the command line on your computer. This will allow you to set up the local development environment, to start it and stop it when necessary, and to run the tests.

You will need Node and npm installed on your computer. Node is a JavaScript runtime used for developer tooling, and npm is the package manager included with Node. If you have a package manager installed for your operating system, setup can be as straightforward as:

  • macOS: brew install node
  • Windows: choco install nodejs
  • Ubuntu: apt install nodejs npm

If you are not using a package manager, see the Node.js download page for installers and binaries.

Note: WordPress currently only officially supports Node.js 16.x and npm 8.x.

You will also need Docker installed and running on your computer. Docker is the virtualization software that powers the local development environment. Docker can be installed just like any other regular application.

Development Environment Commands

Ensure Docker is running before using these commands.

To start the development environment for the first time

Clone the current repository using git clone https://github.com/WordPress/wordpress-develop.git. Then in your terminal move to the repository folder cd wordpress-develop and run the following commands:

npm install
npm run build:dev
npm run env:start
npm run env:install

Your WordPress site will be accessible at http://localhost:8889. You can see or change configurations in the .env file located at the root of the project directory.

To watch for changes

If you're making changes to WordPress core files, you should start the file watcher in order to build or copy the files as necessary:

npm run dev

To stop the watcher, press ctrl+c.

To run a WP-CLI command

npm run env:cli -- <command>

WP-CLI has many useful commands you can use to work on your WordPress site. Where the documentation mentions running wp, run npm run env:cli -- instead. For example:

npm run env:cli -- help

To run the tests

These commands run the PHP and end-to-end test suites, respectively:

npm run test:php
npm run test:e2e

You can pass extra parameters into the PHP tests by adding -- and then the command-line options:

npm run test:php -- --filter <test name>
npm run test:php -- --group <group name or ticket number>

To restart the development environment

You may want to restart the environment if you've made changes to the configuration in the docker-compose.yml or .env files. Restart the environment with:

npm run env:restart

To stop the development environment

You can stop the environment when you're not using it to preserve your computer's power and resources:

npm run env:stop

To start the development environment again

Starting the environment again is a single command:

npm run env:start

Credentials

These are the default environment credentials:

  • Database Name: wordpress_develop
  • Username: root
  • Password: password

To login to the site, navigate to http://localhost:8889/wp-admin.

  • Username: admin
  • Password: password

Note: With Codespaces, open the portforwarded URL from the ports tab in the terminal, and append /wp-admin to login to the site.

To generate a new password (recommended):

  1. Go to the Dashboard
  2. Click the Users menu on the left
  3. Click the Edit link below the admin user
  4. Scroll down and click 'Generate password'. Either use this password (recommended) or change it, then click 'Update User'. If you use the generated password be sure to save it somewhere (password manager, etc).