I am using the npx @wordpress/create-block tool to create my custom block plugin, during the initial installation a number for version that is inserted in package.json, dts-dyslocosaurus.php metadata and block.json is requested.

How can I keep the version the same way in everyone dynamically? Because when I change the version in one of the files does not change in others.

I've used all the options I found, among them all the functions of wp-scripts (start/build).


   "name": "dts-dyslocosaurus",
   "version": "3.1.2"


   "$schema": "https://schemas.wp.org/trunk/block.json",
   "apiVersion": 3,
   "name": "dts-dyslocosaurus/dts-dyslocosaurus",
   "version": "3.1.1"


* Plugin Name:       Dyslocosaurus (Achievements)
* Requires at least: 6.1
* Requires PHP:      7.0
* Version:           3.1.1
* @package           dts-dyslocosaurus

1 Answer 1


WP Scripts provides no such feature for automating this, and if it did automate this it could cause problems.

  • The version in block.json is not the version of your plugin, it's the version of the block, and doesn't have to match. Most people are unaware a version parameter even exists. Likewise if you update your plugins PHP files but make no changes to the block then updating the version field might be misleading!
  • The package.json file is a developer artefact, and not something you should be distributing to customers/clients in final builds. Again though, you might choose to publish this package, share it across plugins, or have internal unreleased versions between plugin releases. This is the version of the package, not the plugin, not the block.
  • The plugin version again is separate, you might only increase your version from 3.1 to 3.2, but that single update may bring with it 2 versions of your blocks that you've developed internally, e.g. you might update the block to v4 but then work on a v5 before releasing the plugin.

TLDR: You don't have to keep those values in sync, and there are lots of reasons you wouldn't want to. Also the version field is not referring to the version of the plugin ( with the exception of the version field in the plugin header ), and in many cases the version field is completely optional.

As for methods to automate this if you want to keep it in sync, there is no canonical official way to do this. Solutions that do exist though are not WordPress specific, e.g. some people set their version to a predefined string such as "VERSION_CONSTANT" or, and replace it using scripts when they do their release process using a build step or github action using some sort of search replace tool.

  • Thanks for the detailed answer, it explains a lot. And if there isn't a native way, it's best not to reinvent the wheel. Commented Sep 27, 2023 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.