2004-01-27 20:52:58 -05:00
|
|
|
<?php
|
2018-10-01 17:00:26 -04:00
|
|
|
/**
|
|
|
|
|
* WordPress Version
|
|
|
|
|
*
|
|
|
|
|
* Contains version information for the current WordPress release.
|
|
|
|
|
*
|
|
|
|
|
* @package WordPress
|
2021-06-21 00:29:56 -04:00
|
|
|
* @since 1.2.0
|
2018-10-01 17:00:26 -04:00
|
|
|
*/
|
|
|
|
|
|
2008-01-04 15:05:07 -05:00
|
|
|
/**
|
2020-02-09 22:30:06 -05:00
|
|
|
* The WordPress version string.
|
2008-01-04 15:05:07 -05:00
|
|
|
*
|
2021-09-14 13:31:59 -04:00
|
|
|
* Holds the current version number for WordPress core. Used to bust caches
|
|
|
|
|
* and to enable development mode for scripts when running from the /src directory.
|
|
|
|
|
*
|
2008-01-04 15:05:07 -05:00
|
|
|
* @global string $wp_version
|
|
|
|
|
*/
|
Editor: Allow registering PHP manifest file for block metadata collections for enhanced performance.
Typically, when registering a new block type, its metadata is read from the provided `block.json` file. The more block types are registered on a site, the more costly becomes this process, as it involves filesystem reads and parsing JSON.
WordPress Core's built-in blocks have in the past worked around that by having a auto-generated PHP manifest file that includes the already parsed JSON data for all blocks. This changeset effectively allows plugins to do the same, by introducing a new API function `wp_register_block_metadata_collection()`. The WordPress Core block manifest is now handled using this API as well, rather than custom logic baked into `register_block_type_from_metadata()`.
The `wp_register_block_metadata_collection()` function requires two parameters:
* `$path`: The base path in which block files for the collection reside.
* `$manifest`: The path to the manifest file for the collection.
Every `block.json` file that is supposed to be part of the collection must reside within the provided `$path`, within its own block-specific directory matching the block name (without the block namespace). For example, for a collection `$path` of `/wp-content/plugins/test-plugin` and a block `test-plugin/testimonial`, the block file could be `/wp-content/plugins/test-plugins/blocks/testimonial/block.json`.
It is recommended that plugins use the new API function for enhanced performance, especially if they register several block types. However, the use of the function is entirely optional. Not using it will not result in any difference in user-facing behavior.
Props mreishus, flixos90, gziolo, spacedmonkey, azaozz, mukesh27.
Fixes #62002.
Built from https://develop.svn.wordpress.org/trunk@59132
git-svn-id: http://core.svn.wordpress.org/trunk@58528 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2024-09-30 13:08:26 -04:00
|
|
|
$wp_version = '6.7-alpha-59132';
|
2008-01-04 15:05:07 -05:00
|
|
|
|
|
|
|
|
/**
|
2008-06-24 13:45:33 -04:00
|
|
|
* Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.
|
2008-01-04 15:05:07 -05:00
|
|
|
*
|
|
|
|
|
* @global int $wp_db_version
|
|
|
|
|
*/
|
Options, Meta APIs: Explicitly pass `$autoload` parameter to when potentially adding new options.
It is recommended that for every option it is explicitly set whether to autoload it or not. This changeset updates relevant `update_option()` and `add_option()` calls.
Note that the `$autoload` parameter is only needed for `update_option()` if the option is potentially not present yet, i.e. the call will pass through to `add_option()`. Since WordPress core adds the majority of its options to the database during installation, only `update_option()` calls for dynamically added options need to be modified, which is what this changeset does.
As part of revisiting the autoload values for dynamically added WordPress core options, this changeset modifies some options to no longer be autoloaded, since they are only accessed in a few specific places that are not relevant for a regular request. These options are:
* `recently_activated`
* `_wp_suggested_policy_text_has_changed`
* `{upgradeLock}.lock`
* `dashboard_widget_options`
* `ftp_credentials`
* `adminhash`
* `nav_menu_options`
* `wp_force_deactivated_plugins`
* `delete_blog_hash`
* `allowedthemes`
* `{sessionId}_paused_extensions`
* `recovery_keys`
* `https_detection_errors`
* `fresh_site`
An upgrade routine is present as well that sets those options to no longer autoload for existing sites.
Props pbearne, flixos90, mukesh27, swissspidy, SergeyBiryukov, joemcgill, adamsilverstein.
Fixes #61103.
Built from https://develop.svn.wordpress.org/trunk@58975
git-svn-id: http://core.svn.wordpress.org/trunk@58371 1a063a9b-81f0-0310-95a4-ce76da25c4cd
2024-09-03 14:19:14 -04:00
|
|
|
$wp_db_version = 58975;
|
2004-01-27 20:52:58 -05:00
|
|
|
|
2009-05-18 16:29:26 -04:00
|
|
|
/**
|
2020-02-09 22:30:06 -05:00
|
|
|
* Holds the TinyMCE version.
|
2009-05-18 16:29:26 -04:00
|
|
|
*
|
|
|
|
|
* @global string $tinymce_version
|
|
|
|
|
*/
|
2020-11-10 05:44:08 -05:00
|
|
|
$tinymce_version = '49110-20201110';
|
2009-05-18 16:29:26 -04:00
|
|
|
|
2009-12-17 13:46:19 -05:00
|
|
|
/**
|
2020-02-09 22:30:06 -05:00
|
|
|
* Holds the required PHP version.
|
2009-12-17 13:46:19 -05:00
|
|
|
*
|
|
|
|
|
* @global string $required_php_version
|
|
|
|
|
*/
|
2024-04-11 17:11:16 -04:00
|
|
|
$required_php_version = '7.2.24';
|
2009-12-17 13:46:19 -05:00
|
|
|
|
|
|
|
|
/**
|
2020-02-09 22:30:06 -05:00
|
|
|
* Holds the required MySQL version.
|
2009-12-17 13:46:19 -05:00
|
|
|
*
|
|
|
|
|
* @global string $required_mysql_version
|
|
|
|
|
*/
|
2023-12-08 09:13:27 -05:00
|
|
|
$required_mysql_version = '5.5.5';
|
