5 Entry points and configuration

5.1 Entry points overview

Updates reach the same upgrader stack through the admin interface, AJAX (admin-ajax.php), cron (WP_Automatic_Updater), and WP-CLI. Core does not expose XML-RPC methods that run the plugin, theme, or core upgrade stack; treat XML-RPC as legacy for other workflows, not as a first-class update entry point (§5.7). Your choice of entry point determines the credentials, output channel, and capability context.

How it works

The Updates screen posts forms to upgrade actions. List tables use row and bulk actions with the updates script. AJAX actions call upgraders with WP_Ajax_Upgrader_Skin. Cron invokes WP_Automatic_Updater. WP-CLI loads admin includes and calls primitives directly. The bundled REST API does not offer a generic “upgrade an installed package to a new version” operation (§5.8).

Process flow

1. A user or process initiates an action.
2. Capabilities and nonces verify the request.
3. The appropriate skin attaches.
4. The upgrader runs.
5. The outcome returns through the skin, JSON, terminal, or email depending on the entry path.

Reference

Entry	Output
wp-admin screens	HTML skin
AJAX	JSON
Cron	Background skin and email
WP-CLI	Terminal

Developer resources

• Managing plugins in the admin — plugin management context.

---

5.2 Dashboard Updates screen

wp-admin/update-core.php lists core, plugin, theme, and translation updates and submits bulk operations.

How it works

The screen loads through admin.php, enqueues the updates script, and checks capabilities (update_core, update_plugins, update_themes, and update_languages as appropriate). Forms POST to actions such as core upgrade and bulk plugin or theme updates. On multisite, non-network administrators may redirect to the network Updates screen per update-core.php logic.

Process flow

1. A user opens the Updates screen.
2. Core refreshes or displays cached offers.
3. The user submits a form.
4. The server runs the upgrader.
5. A redirect or message shows the outcome.

Reference

Screen	Capability mix
Updates	Varies by action: update_core, update_plugins, update_themes, update_languages

Developer resources

• Dashboard Updates screen — end-user documentation for the screen.

---

5.3 AJAX update flow

AJAX updates plugins and themes without a full page reload using admin-ajax.php and JSON responses.

How it works

Core registers actions such as update-plugin and update-theme in wp-admin/admin-ajax.php. Handlers verify the updates nonce, require capabilities, call wp_update_plugins() or wp_update_themes() to refresh transients, construct Plugin_Upgrader or Theme_Upgrader with WP_Ajax_Upgrader_Skin, and run bulk_upgrade() even for a single item. JSON returns success or error for the async interface. The toggle-auto-updates action persists auto_update_plugins and auto_update_themes without invoking the upgrader.

Process flow

1. The browser posts to the AJAX handler.
2. WordPress verifies the nonce and capability.
3. The upgrader runs with the AJAX skin.
4. The skin collects errors and messages.
5. JSON returns to the browser.
6. The list interface updates the row state.

Reference

Action	Effect
update-plugin	Plugin upgrade through AJAX
update-theme	Theme upgrade through AJAX
toggle-auto-updates	Toggle opt-in arrays only; no upgrader call

Developer resources

• AJAX in plugins — how admin AJAX handlers work with WordPress.

---

5.4 Per-plugin and per-theme auto-update interface (WordPress 5.5+)

List tables and theme details expose auto-update toggles stored in site options.

How it works

WordPress 5.5 added an Automatic Updates column and bulk actions on Installed Plugins; preferences persist in auto_update_plugins. Themes use auto_update_themes and controls in the theme details modal under Appearance, Themes.

plugin_auto_update_setting_html filters the markup in the plugins list table (class-wp-plugins-list-table.php). For single-site theme screens, theme_auto_update_setting_template filters the theme-details modal template (wp-admin/themes.php). The network themes list uses theme_auto_update_setting_html (class-wp-ms-themes-list-table.php).

Who may change toggles depends on capabilities and multisite role (network versus site administrator). Do not assume only super administrators in every setup.

Process flow

1. A user toggles the control.
2. AJAX or a form saves the options.
3. The next should_update() call reads the opt-in arrays together with offer flags.

Reference

Hook	Type	Parameters	Notes
plugin_auto_update_setting_html	filter	string	Installed Plugins list: column and control HTML
theme_auto_update_setting_template	filter	string	Single-site theme modal: template fragment
theme_auto_update_setting_html	filter	string	Network themes list table: control HTML

Developer resources

• Plugins and themes auto-updates — user-facing article with multisite rules.

---

5.5 Core major auto-update interface (WordPress 5.6+)

The Updates screen includes controls for major core automatic updates, stored separately from minor branch options.

How it works

WordPress 5.6 added interface controls on update-core.php to opt in or out of major core automatic updates. The preference is stored in the auto_update_core_major site option (enabled, disabled, or default unset semantics) — not a separate wp_auto_update_core option. See §1.3 and update-core.php together with Core_Upgrader::should_update_to_version().

Filters core_auto_updates_settings_fields and after_core_auto_updates_settings_fields extend that section. When WP_AUTO_UPDATE_CORE is defined in wp-config.php, the constant overrides branch policy and the auto_update_core_* site options are bypassed for that policy path.

Process flow

1. A user sets a preference on the Updates screen.
2. WordPress saves the option unless the constant overrides it.
3. Core_Upgrader::should_update_to_version() and should_update() apply the effective policy together with branch filters.

Reference

Name	Type	Default	Effect
auto_update_core_major	site option	unset	Major core auto-update interface control (enabled, disabled, or unset); see §1.3

Developer resources

• Core major versions auto-updates UI changes in WordPress 5.6 (correction) — interface correction note.

---

5.6 WP-CLI

WP-CLI bootstraps WordPress and calls the same upgrade primitives as the admin after loading required files.

How it works

Typical commands include wp core update, wp core update-db, wp plugin update, wp theme update, and wp language update subcommands. WP-CLI is not bundled in core but is the supported CLI surface for scripted maintenance. Forced installation of an older core release than the current files (--version with --force) and schema implications are covered in §5.13.

Process flow

1. An operator runs a command.
2. WP-CLI loads WordPress.
3. The upgrader or upgrade routine executes.
4. Output prints to the terminal.
5. No core email sends unless hooks add that behavior.

Reference

Command area	Examples
Core	wp core update, wp core update-db, wp core verify-checksums
Packages	wp plugin update, wp theme update
Languages	wp language core update, wp language plugin update, wp language theme update

Developer resources

• WP-CLI command index — handbook index.

---

5.7 XML-RPC and Application Passwords

Legacy remote clients may trigger workflows that load admin code and require capabilities. XML-RPC is not the primary automation path for new projects.

How it works

XML-RPC and Application Password–authenticated requests can invoke supported remote procedures where enabled. Updates still require filesystem access and high-privilege checks. Prefer WP-CLI or controlled custom endpoints for new automation.

Process flow

1. A client authenticates.
2. WordPress routes the request.
3. If the procedure performs updates, the same capability and filesystem constraints apply as in the admin interface.

Reference

Mechanism	Notes
XML-RPC	Legacy breadth; capability-gated
Application Passwords	Modern REST authentication companion

Developer resources

• Application Passwords API — authentication API.

---

5.8 REST API: no native update trigger

Core does not expose a REST endpoint that runs plugin, theme, or core upgrades as a generic operation.

How it works

The bundled /wp/v2/plugins and /wp/v2/themes routes expose metadata and support activation and deactivation (and directory installs by slug for plugins). The update_item handlers (PATCH or PUT on a plugin or theme) adjust status and fields — they do not download and install a newer version of an already-installed package.

Programmatic updates outside the browser typically use WP-CLI, custom admin code that loads upgrader classes with proper authentication, or patterns mirroring admin-ajax.php handlers.

Process flow

1. A REST client requests metadata or status changes allowed by the API.
2. The upgrade itself requires a different orchestration layer.

Reference

Route	Upgrades installed package to newer release
/wp/v2/plugins	Not supported
/wp/v2/themes	Not supported

Developer resources

• Plugins REST API reference — supported operations.
• Themes REST API reference — supported operations.

---

5.9 Filesystem methods

WP_Filesystem abstracts direct, FTP, FTPS, and SSH access. Background updates fail closed without non-interactive credentials.

How it works

Core uses WP_Filesystem and request_filesystem_credentials(). The FS_METHOD constant in wp-config.php can force direct, ftpext, ftpsockets, or ssh2. When the web server cannot write files, interactive flows show the credentials form. Background updates cannot prompt — they fail if credentials are not available non-interactively. wp_is_file_mod_allowed( $context ) centralizes whether modifications are allowed, defaulting to ! DISALLOW_FILE_MODS with the file_mod_allowed filter.

Process flow

1. The upgrader requests filesystem access.
2. A direct or credential-based method connects.
3. Writes proceed or return WP_Error.
4. The automatic updater aborts when file modifications are disallowed.

Reference

Name	Type	Default	Effect
FS_METHOD	constant	auto	Forces a specific filesystem backend
DISALLOW_FILE_MODS	constant	false if unset	Blocks file modifications unless filtered

Developer resources

• Filesystem API overview — accessing the filesystem.

---

5.10 Configuration constants (wp-config.php)

Constants in wp-config.php override defaults for cron, HTTP, automatic updates, and filesystem behavior.

How it works

AUTOMATIC_UPDATER_DISABLED disables the background automatic updater pipeline including its notification emails when true. WP_AUTO_UPDATE_CORE as a boolean or string scopes core automatic updates (true, false, minor, or prerelease channel strings per version behavior). Before WordPress 5.6, true often implied minor-only; new installs since 5.6 default to major core auto-updates unless the user changes the setting.

When WP_AUTO_UPDATE_CORE is undefined, branch policy falls through to the auto_update_core_* options (§1.3). DISALLOW_FILE_MODS blocks file changes unless the file_mod_allowed filter overrides. DISABLE_WP_CRON stops cron spawning on page loads; scheduled checks need external wp-cron.php triggers (§1.5).

WP_HTTP_BLOCK_EXTERNAL and WP_ACCESSIBLE_HOSTS gate outbound HTTP. Blocking api.wordpress.org or downloads.wordpress.org breaks discovery unless you allowlist them. Outbound-only egress through a corporate HTTP proxy requires WP_PROXY_* constants (§5.12).

Process flow

1. PHP reads constants from wp-config.php before runtime.
2. Updaters consult them during is_disabled(), should_update_to_version(), and HTTP client calls.
3. Misconfiguration surfaces as missing updates or failed background runs.

Reference

Name	Type	Default	Effect
AUTOMATIC_UPDATER_DISABLED	bool	false if unset	Disables the automatic updater and its notification emails
WP_AUTO_UPDATE_CORE	bool or string	See handbook	Overrides branch options when defined
DISALLOW_FILE_MODS	bool	false if unset	Disallows file modifications unless filtered
FS_METHOD	string	auto	Forces a specific filesystem backend
DISABLE_WP_CRON	bool	false if unset	Stops cron spawning on page loads
WP_HTTP_BLOCK_EXTERNAL	bool	false	Blocks outbound HTTP unless allowlisted
WP_ACCESSIBLE_HOSTS	string	empty	Hostnames allowed when blocking external requests

Developer resources

• wp-config.php configuration reference — full constant reference.

---

5.11 Multisite: update scope and database upgrade propagation

Multisite shares one codebase and site transients at the network level while database upgrades apply per site. After core updates, operators must run network upgrade flows.

How it works

Many update interface actions are network-admin only or redirect from site admin per update-core.php. Capabilities depend on user and site context; super administrator rules apply for network operations. Update transients are site transients, so the network shares one update cache.

Replacing core files is network-wide. wp_upgrade() runs upgrade_all() for the current site’s tables, then upgrade_network() on the main site when is_multisite() && is_main_site(). Sub-sites do not all upgrade in one call.

wp-admin/admin.php may detect a db_version mismatch and trigger do_mu_upgrade (filter default true) with upgrade.php?step=1 on large networks, using sampling when the blog count exceeds 50. Each site’s db_version updates when that site’s wp-admin/upgrade.php runs.

Network Admin, Upgrade Network (wp-admin/network/upgrade.php) walks sites in batches of five, switches blogs, and sends HTTP GET requests to each site’s admin_url( 'upgrade.php?step=upgrade_db' ). WP-CLI wp core update-db --network runs the database upgrade across sites non-interactively.

After a network-wide core file update, each subsite may still show a pending database upgrade until the Upgrade Network screen, per-site upgrade, or network CLI completes.

Process flow

1. Core files update once (network-wide).
2. The main site may run partial upgrade routines.
3. Subsites upgrade lazily through the Network Upgrade screen or CLI.
4. Until each site’s db_version matches, schema may lag on that site.

Reference

Mechanism	Scope
Codebase	Network-wide single tree
wp_upgrade() per request	Current site tables plus network routines on main
Network Upgrade screen	Batched per-site HTTP upgrade
wp core update-db --network	CLI upgrade for all sites

Developer resources

• wp core update-db CLI command — --network flag.
• upgrade_network() reference — network upgrade routines.

---

5.12 Enterprise HTTP proxy configuration

Hosts that egress only through an HTTP or HTTPS proxy must define proxy credentials and endpoints in wp-config.php. Without them, discovery requests to api.wordpress.org and package downloads fail, so no update offers appear and packages cannot download.

How it works

WordPress reads WP_PROXY_HOST and WP_PROXY_PORT to route outgoing HTTP requests through the corporate proxy. Optional WP_PROXY_USERNAME and WP_PROXY_PASSWORD supply authenticated proxy access. WP_PROXY_BYPASS_HOSTS lists hosts that should not use the proxy (comma-separated; wildcards such as *.wordpress.org are supported per class-wp-http-proxy.php).

These constants are consumed by the HTTP API when building requests (see wp-includes/class-wp-http-proxy.php). TLS interception, custom CA bundles, or server-level allowlists may still be required beyond WordPress constants. Discovery (wp_version_check(), wp_update_plugins(), wp_update_themes()) and package downloads all depend on the same HTTP stack; a misconfigured proxy blocks both.

Process flow

1. PHP loads wp-config.php constants before HTTP calls.
2. WP_HTTP uses proxy settings for each outbound request.
3. If the proxy rejects the connection or returns 407 without valid credentials, transients stay stale or downloads error.
4. After correcting proxy settings, a forced discovery refresh (§1.6) may be required to populate offers.

Reference

Name	Type	Default	Effect
WP_PROXY_HOST	string	—	Proxy hostname or IP
WP_PROXY_PORT	string	—	Proxy port
WP_PROXY_USERNAME	string	—	Optional proxy user
WP_PROXY_PASSWORD	string	—	Optional proxy password
WP_PROXY_BYPASS_HOSTS	string	—	Comma-separated hosts that skip the proxy

Developer resources

• WP_PROXY_HOST and related constants — wp-config.php proxy configuration.

---

5.13 WP-CLI: explicit core downgrades

WP-CLI can install a specific WordPress core version, including an older release than the one currently on disk, when invoked with --version and --force. This bypasses the normal “upgrade only” semantics of the admin interface and carries database and compatibility risks.

How it works

The wp core update command downloads and installs the requested ZIP from WordPress.org (subject to signatures and filesystem checks in the CLI context). The --force flag is required when the target version is lower than the installed version so the operator explicitly accepts a downgrade.

Downgrading files does not automatically roll back the database schema. db_version in the options table may remain higher than the code in wp-includes/version.php expects, or the reverse if the operator runs steps out of order. Operators should run wp core update-db after file changes when appropriate, and understand that downgrading across major versions can leave incompatible schema or data. Automatic backups and staging are strongly advised. Plugin and theme compatibility with the older core is not validated by the command.

Process flow

1. The operator runs wp core update --version=X.Y.Z --force.
2. WP-CLI fetches and extracts core files.
3. File replacement completes.
4. The database version may still reflect the previous upgrade until wp core update-db runs or until wp-admin loads wp_upgrade() for the current code path.
5. A mismatch between files and schema can cause fatal errors or subtle data corruption until reconciled.

Reference

Concern	Downgrade risk
File version versus db_version	Schema newer than code, or code newer than schema
--force flag	Required for version regression; implies explicit acceptance
Rollback	Not a guaranteed atomic undo; restore from backup if needed

Developer resources

• wp core update CLI command — flags including --version and --force.
• wp core update-db CLI command — database schema upgrade after core file changes.