WordPress updates
WordPress 7.0 has been the current major release since 20 May 2026. The 7.0 line stands at 7.0.4 of 12 August 2026 today, and that is already the third security release since mid-July. WordPress 7.1 is released on 19 August 2026, on the last day of WordCamp US in Phoenix. This page covers a single case: bringing core, plugins, theme and PHP of an existing installation up to a current state, without the editor coming up empty afterwards or the contact form no longer sending mail. A project with a beginning and an end, not a maintenance contract. Sharpness Solutions GmbH has been developing in Oldenburg since 1999 and works remotely throughout Germany, including on installations that someone else built. This page is current as of 17 August 2026.
Enquiries about WordPress updates rarely come from an interest in new features. They come because the hosting provider has announced a PHP change, because the dashboard shows a two-digit number of pending updates, because a security notice has arrived, or because an update once broke something and nobody has touched the site since. Four starting points cover most of what operators arrive with here. None of them is unusual, and none of them improves on its own.
A plugin update in the dashboard, then a white page or a shifted layout, and someone restored the site from a backup. Since then nothing is touched any more. The effect adds up: the longer the standstill lasts, the more version steps become due at the same time, and the harder it is to assign a fault to a single cause afterwards.
WordPress has updated minor releases itself since version 3.7. In the 7.0 line alone there were three security releases: 7.0.2 of 17 July 2026, for which WordPress.org activated forced auto-updates because of the severity of the vulnerabilities, 7.0.3 of 6 August 2026 with twelve reported vulnerabilities, and 7.0.4 of 12 August 2026. On many installations something has therefore changed several times during the night that nobody tested. On other installations the mechanism is switched off — and there the vulnerabilities are still open today.
The hosting provider announces the change to a newer PHP version, and suddenly the WordPress update depends on a date that someone else has set. It works the other way round as well: current plugin versions require a PHP version that does not run on the server. Whoever chooses the wrong order gets either fatal errors or no way forward at all.
Several dozen plugins are active, grown over years and across several service providers. Some of them have not received an update for years, some are commercial and licensed in the name of the previous agency, and for a few of them nobody remembers which function depends on them. That is not negligence, it is the normal case — but without this knowledge no order of work can be defined.
WordPress 7.0 was released on 20 May 2026. The 7.0 line stands at 7.0.4 of 12 August 2026 today, and the path to that version belongs in the assessment of the situation. 7.0.1 of 9 July 2026 was a pure maintenance release with 31 bug fixes in core and the block editor. 7.0.2 of 17 July 2026 was a security release with two vulnerabilities — an SQL injection and a mix-up of routes in the batch processing of the REST API — which, chained together, led to remote code execution; because of the severity, WordPress.org activated forced auto-updates for affected installations. 7.0.3 of 6 August 2026 was also a security release, with twelve reported vulnerabilities, among them several stored XSS cases, an SSRF in URL validation and a pre-auth XSS on the login page. 7.0.4 of 12 August 2026 closes an authenticated remote code execution from the author role upwards through a file upload, which only affects installations with Imagick and Ghostscript. WordPress 7.1 is released on 19 August 2026, in parallel with WordCamp US in Phoenix, which runs from 16 to 19 August. That is the frame within which every update plan of this summer has to work: a 7.0 line with three security releases in four weeks, and a major release that is available in two days and whose breaking points are known.
A forced update means the following in concrete terms: the version was distributed through the same mechanism that WordPress has used since version 3.7 to install minor releases automatically — not only offered in the dashboard for someone to click. Two things follow from that. First, the vulnerability is already closed on most installations, without anyone having done anything. Second, something has changed on these installations that nobody had seen on a test system beforehand. Both facts are notable, and the second point is the reason why we never work with the assumed version level during an assessment, but with the measured one. You can check this under Dashboard → Updates, or on the command line with wp core version and wp core check-update. The reverse case is important: where AUTOMATIC_UPDATER_DISABLED is set, where a filter switches the mechanism off, or where the file system is not writable for the web server, even a forced update does not arrive. Such installations may still be on 7.0.0 or 7.0.1 today — exactly the versions of the 7.0 line that were affected by the 7.0.2 vulnerabilities — and they have missed two further security releases since then. The faults are publicly described, the patches are ready.
One point belongs at the beginning, because it prevents expensive planning errors: React 19 is not coming with WordPress 7.1. This assumption is widespread, it stood in roadmaps and talks for a long time, and it is wrong. The upgrade was reverted after incompatibilities appeared between the old and the new React version, together with problems in the way plugins include React. WordPress 7.1 stays on React 18.3. Gutenberg offers an experimental flag that allows React 19 to be tested — as a test option, not as the shipped state. Anyone who converted a plugin or an editor interface to React 19 on the basis of the announcement has spent effort on a state that will not occur. The lesson from this is more general: a roadmap is an intention. Budgets are set against release notes and against a test run, not against a plan.
The first and most far-reaching breaking point in WordPress 7.1 is the post editor: it is now always iframed — independent of the theme type, of the block API versions of the registered blocks and of those of the blocks in the content. Until now this was a decision per post: in 7.0 the editor was iframed if every inserted block had block API version 3 or higher, and it fell back to the earlier presentation as soon as one single older block was present. That condition has been removed, and with it the assumption that a classic theme or an old block keeps the editor out of the iframe. Code that accesses the global document or window breaks as a result — it searches in a document that no longer holds the editor content. The way forward is through ownerDocument and defaultView on an element in the canvas: you take an element inside the editor, ask for its ownerDocument and work with that document, or with its defaultView, instead of with the global objects. For event listeners on the canvas the core team recommends useRefEffect, so that registration and clean-up stay together. In practice this affects scripts on meta boxes, custom editor extensions, custom field solutions, TinyMCE adjustments and everything that reaches into the editor with document.querySelector — even where it has worked reliably for five years.
The second breaking point sits in the list tables of the backend. The leading th with scope="row" moved from the checkbox column to the title column. That is the first change at this place since 2010, and it is correct in substance, because the row is identified by its title and not by a selection box. For extensions it is a break all the same: everything that selects on the CSS class check-column now finds nothing. This concerns custom columns in post, page, media or user lists, bulk actions, sorting logic and backend CSS that corrects the column widths. The third change is smaller and is noticed immediately in return: the property __next40pxDefaultSize has become ineffective, form elements render at 40 px unconditionally. Even __next40pxDefaultSize={false} no longer leads back to the earlier 36 px — the property should be removed from the code without replacement. Anyone who used it to build a compact layout in sidebar panels, block settings or custom meta boxes will see a different layout afterwards — not broken, but shifted, and in narrow panels that is enough to cause overlaps.
These three points have one thing in common, and it is decisive for acceptance testing: they are in the backend, not in the frontend. Loading the home page after the update shows none of them. They appear when an editor opens a post and saves it, when someone drags an image into the media library, when a custom column is needed in a list table. That is why our acceptance list does not say “page loads”, but sets out a series of backend paths with real content. And that is why 7.1 is not a mandatory date on 19 August: we install security releases within the 7.0 line promptly, and the step to 7.1 follows after a test run. Part of this is the limitation that WordPress itself writes into every security release: only the most recent version is actively supported, and the project supplies fixes for older lines expressly as a courtesy. Staying on 7.0 is therefore a deadline, not a permanent state. Treating both the same means confusing urgency with being up to date.
In a good number of cases the reason why an update is not possible is not WordPress, but PHP. The relationship is a clamp: current plugin and theme versions require a PHP version that does not run on the server, and a PHP step in turn makes old plugin code crash. Whoever raises PHP first gets fatal errors from extensions that are not ready yet. Whoever raises the plugins first gets requirement errors or a Composer setup that does not resolve. The figures on this are hard and public: PHP 7.4 has received no security updates since 28 November 2022, PHP 8.1 none since 31 December 2025. PHP 8.2 is supplied with security fixes until 31 December 2026, PHP 8.3 until 31 December 2027, PHP 8.4 until 31 December 2028. Anyone who plans 8.2 as the target version in the summer of 2026 is planning the next migration for the same year. Our target version is therefore 8.3 or 8.4, not the smallest step that happens to work.
This is checked by measurement, not by reading. The “Requires PHP” entry in the plugin or theme header is an indication, not a commitment — it is not maintained everywhere, and it says nothing about whether the code produces warnings on the target version. What is reliable is a run on a staging copy with the target version and a log that records deprecations: once through the backend, once through the relevant frontend paths, once through the cron jobs. What typically shows up there is not exotic. Dynamic properties have been deprecated since PHP 8.2, which reliably affects older plugin classes as long as they do not carry #[\AllowDynamicProperties]. Wrong argument types that PHP 7 let through as a warning throw a TypeError in PHP 8 and end the request. And libraries that a plugin brings with it, instead of obtaining them through Composer, age unnoticed — they appear in no update list. The 7.0.4 example shows why the runtime environment belongs on the list as well: the vulnerability closed there only affects installations on which Imagick works together with Ghostscript. Whether that is the case for you is not stated in the WordPress dashboard, but in the PHP configuration.
When the date comes from the hosting provider, the order is set by someone else, and then a different priority applies: first raise the staging copy to the target version, bring the plugin and theme side up to date there, then switch live — not the other way round. An announced PHP change at the hosting provider is the most frequent reason why an update that was left undone suddenly becomes a fixed date. We also run WordPress installations on our own servers in Germany, on Proxmox PVE clusters; there the PHP change is an agreed date and not a notification. A move is not a condition, however: if SSH access, a clean deployment path and a selectable PHP version are available, we work on your hosting.
WordPress has updated minor releases automatically since version 3.7, and plugins and themes on request since version 5.5. That is not a stopgap, but the right default setting for one specific case: core minor releases within a line. The scope of change is small, no API breaks inside the line, and after a security fix is published the pressure from attacks is measurably higher than the risk of an untested small step. Whoever switches this mechanism off takes on the duty of noticing security releases such as 7.0.2, 7.0.3 and 7.0.4 themselves and promptly — three of them between mid-July and mid-August. That is a legitimate decision if there is a process behind it. Without a process it is simply an open vulnerability on purpose.
For plugins the answer is not a blanket one, but a list. Automatic updates make sense for extensions without frontend output and without any intervention in templates: backend helpers, administration tools, small additions without their own data structures. Automation does not make sense wherever an update is a deployment in substance — in forms that send mail, in payment and checkout processes with WooCommerce, in everything that overwrites templates, and in everything attached to the editor. The reason is simple: an automatic update checks whether it completes. It does not check whether the page still looks right afterwards and whether the form still sends a mail. The difference between “runs without errors” and “does the right thing” is exactly the part that a machine does not take over.
What is still left undone when automation is enabled is the more expensive part: the step to a new major release such as 7.1, themes with custom code, the PHP version, orphaned plugins without a successor. There is also a conflict that is regularly overlooked in projects that have grown over time: updates from the dashboard and a Git-based deployment exclude each other. What is updated in the dashboard does not end up in the repository and is overwritten by the next deployment — in the best case that is noticed straight away, in the worse case a patched version quietly returns to the old state. That is exactly how an installation loses a forced security update again. We therefore define beforehand which path applies: core minor releases automatically, plugin automation according to a reasoned list, everything with custom code through Git and staging. And we do not set up automation without a working backup chain. That would be a risk that runs on a timer.
At the beginning there is a plugin and theme inventory, and it is more than a list of names. It contains, per extension: installed version, source (wordpress.org, commercial, in-house development, unknown), who the licence is issued to, when it was last updated, whether it is visible in the frontend and whether it is attached to a business process. Four classes follow from this: current, outdated but maintained, orphaned, and replaceable by a few lines in the theme. The hardest question here is not whether an update exists, but whether the extension is still needed. Experience shows that a noticeable part of the list falls away at this step — not because we want to tidy up, but because nobody can name a function that depends on it any more. Every plugin that does not come along is a plugin that will never break again. One tool for this is wp plugin list --update=available; it does not do the assessment.
Then the order of work, and that is not negotiable. First: backup of database and files, with a way back that someone has already taken once. Second: a staging copy that really is a copy — URLs replaced, mail sending disconnected, indexing blocked, payment integrations on sandbox, cron jobs under control. A staging environment that sends real order confirmations to real customers is a second production system. Third: PHP to the target version, with a deprecation log. Fourth: plugins individually or in small groups, with a check in between. Fifth: the core. Sixth: theme and custom code, and this is where the 7.1 points land — iframed editor, check-column, 40 px. Seventh: acceptance testing. Eighth: the live window. The reason for the small steps in step four is diagnosis, not caution: whoever updates two dozen plugins in one go and then has a fault has two dozen suspects and no lead.
A way back means the following for us: a database dump and a file state taken immediately before the window, and a rehearsed path back. An uncomfortable limitation belongs openly to this. Database migrations of individual plugins are not always reversible. The way back is then a restore to the state before the window, not a downgrade — and everything that happened between dump and restore, in orders, comments, form submissions or editorial changes, is gone with it. That is exactly why the window lies outside business hours and is short, and exactly why an acceptance list is drawn up beforehand: create and save a post, media upload, form submission with a real mail, search, feeds, object cache, backend lists with custom columns, permissions of the editorial roles. And if the inventory shows that a central extension has no successor, we say so before the quotation: the update is then no longer an update, but a small development project. That makes the figure larger, and it is still the more honest figure. If you do not want to take over the maintenance yourself afterwards, you will find the ongoing support including the service level tiers on the page about WordPress maintenance; this page ends with the go-live.
Process
The output of wp core version and wp plugin list is enough, and if necessary the URL alone will do. You receive a written assessment: measured version level, target version for PHP, the plugins that will not come along, and the range of effort — even if you place the order elsewhere afterwards. Sharpness Solutions GmbH, Edewechter Landstraße 161, 26131 Oldenburg. Telephone 0441 21 21 63 0, Mon–Fri 9:00–16:00, info@sharpness.de. We work remotely throughout Germany, meetings in the north-west by arrangement.
We check what is actually running: core version down to the patch level — there are three security releases between 7.0.1 and 7.0.4 —, PHP and database version, origin of the theme, whether and how automatic updates are active, and whether a Git repository and a deployment path exist. With forced security updates the measured level often differs from the expected one, in both directions. You receive the result in writing.
Every extension individually: version, source, licence holder, last update, visible function, role in the business process. From this comes the classification into current, maintained but outdated, orphaned and unnecessary. As a rule part of the list falls away here, and here it becomes clear whether the step to 7.1 is an update or a development step.
We mirror the installation into a test environment: URLs replaced, mail sending disconnected, indexing blocked, payment integrations on sandbox, cron jobs under control. If you do not have a staging environment so far, this is the first lasting gain of the project — every further update becomes cheaper than this one.
On the copy, first the PHP target version with a deprecation log running, then the plugins individually or in small groups with a check in between, then the core. After that the custom code: iframed editor through ownerDocument and defaultView, selectors on check-column, and layouts that relied on __next40pxDefaultSize.
You check on the staging environment against an acceptance list that contains backend paths and not only page views: save a post, media upload, form with a real mail, search, feeds, backend lists, editorial roles. The go-live runs in an agreed window outside business hours, with a dump and a file state taken immediately before it and a documented way back.
After the switch we watch the logs and the mail sending, work through the points from the acceptance test and hand over the state: version list, configuration of the automatic updates, deployment path, and what was deliberately left behind. After that comes the open question of who serves the next release cycles — your team or ours.
Projects on this system
A selection — not the full client list.
The current major release is WordPress 7.0, released on 20 May 2026. Current within this line is 7.0.4 of 12 August 2026, a security release against an authenticated remote code execution from the author role upwards, which affects installations with Imagick and Ghostscript. Before that came 7.0.3 of 6 August 2026 with twelve reported security vulnerabilities, 7.0.2 of 17 July 2026 with forced auto-updates, and 7.0.1 of 9 July 2026 with 31 bug fixes. WordPress 7.1 is released on 19 August 2026, in parallel with WordCamp US in Phoenix. This information is current as of 17 August 2026.
In the backend the version is shown under Dashboard → Updates and at the bottom right of the dashboard start page. It is more precise and faster on the command line: wp core version returns the exact level, wp core check-update says what is pending. Do not rely on the expected value. After a forced security update such as 7.0.2 the installation is often further ahead than assumed — and if the automatic update mechanism is switched off or the file system is not writable, it is clearly behind. The reference value today is 7.0.4. Both cases occur, and both change the plan.
No. This is a widespread misunderstanding, because the upgrade was announced for a long time. It was reverted after incompatibilities appeared between the old and the new React version, together with problems in the way plugins include React. WordPress 7.1 stays on React 18.3. Gutenberg offers an experimental flag that allows React 19 to be tested — as a test option, not as the shipped state. Anyone who converted their plugin to React 19 as a precaution has worked for a state that will not occur. Plan against release notes, not against roadmaps.
Three points, all in the backend. First: the post editor is now always iframed — independent of the theme type and of the block API versions. In 7.0 the content still decided this: the editor was only iframed if every inserted block had API version 3 or higher. Code that accesses the global document or window breaks; the way forward is through ownerDocument and defaultView on an element in the canvas. This affects meta box scripts, custom field solutions, TinyMCE adjustments and custom editor extensions. Second: in the list tables the leading th with scope="row" moved from the checkbox column to the title column — the first change there since 2010. Extensions that select on the CSS class check-column break. Third: the property __next40pxDefaultSize is ineffective, form elements render at 40 px unconditionally; even __next40pxDefaultSize={false} does not bring the earlier 36 px back. This shifts narrow panel layouts.
It means that the version was distributed through the same path that WordPress has used since version 3.7 to install minor releases automatically — not only offered in the dashboard. With 7.0.2 of 17 July 2026 this was the case: two vulnerabilities could be chained into remote code execution, so WordPress.org activated forced auto-updates for affected installations. Two things follow from this for operators: the vulnerability is already closed on most installations without anyone having done anything, and on the same installations something has changed that nobody tested beforehand. Where the mechanism is switched off, or where the file system is not writable for the web server, the update did not arrive. There the vulnerabilities are still open today, although the patches have existed for weeks — by now the patches from three security releases.
For core minor releases, yes. The scope of change within a line is small, no API breaks, and after a security fix is published the pressure from attacks is higher than the test risk. Three security releases between mid-July and mid-August 2026 are the practical argument for it. For plugins and themes — possible automatically since WordPress 5.5 — the answer is: according to a list. It makes sense for extensions without frontend output and without any intervention in templates. It does not make sense for forms that send mail, for WooCommerce in the checkout and payment path, for everything that overwrites templates, and for everything attached to the editor. An automatic update checks whether it completes — not whether the page does the right thing afterwards.
Because both sides depend on each other. Current plugin and theme versions require a newer PHP version, and a PHP step makes old extension code crash. PHP 7.4 has received no security updates since 28 November 2022, PHP 8.1 none since 31 December 2025. PHP 8.2 is supplied until 31 December 2026, 8.3 until 31 December 2027, 8.4 until 31 December 2028. We therefore aim at 8.3 or 8.4, not at the smallest step that happens to run. This is checked on a staging copy with a deprecation log running, not on the basis of the “Requires PHP” entry in the plugin header. And the server configuration belongs on the list as well: the vulnerability closed in 7.0.4 only affects installations on which Imagick works together with Ghostscript.
By effort, and the effort depends on four countable figures: the starting version of core and PHP, the number and state of the plugins, the amount of custom code in theme and extensions, and the number of extensions without a current release. Three of these you can count yourself — the version with wp core version, the plugins with wp plugin list, the custom code with a look into the theme directory. A figure given before the inventory would be a guess. There is no price list, because an average price means that you also pay for the effort of other projects. If the update does not pay off in your case because a rebuild is cheaper, we say so.
During the work, not at all: the work is done on a staging copy, and the production installation keeps running unchanged. The site is only unavailable during the switching window, usually outside business hours. Immediately before it we take a database dump and a file state, so that a way back is documented and rehearsed. Editorial changes that are made in the live system during the rebuild phase are transferred before the switch — which is why it is useful to know the date early.
No. You install security and maintenance releases within the 7.0 line promptly — they close known vulnerabilities and break nothing inside the line. The step to 7.1 is a separate task with a test run, because it brings three known breaking points: the always iframed post editor, the moved scope="row" column in the list tables, and the ineffective property __next40pxDefaultSize. All three are in the backend and are not noticed when the home page is loaded. One point belongs to an honest answer: WordPress actively supports only the most recent version and supplies fixes for older lines expressly as a courtesy. Staying on 7.0 is therefore a deadline, not a permanent state. Whoever treats urgency and being up to date as the same thing either updates too late or too carelessly.
There are three ways forward, and the order is always the same. First: remove it, if nobody can name a function that depends on it any more — in installations that have grown over years this applies to a noticeable part of the list. Second: replace it with a maintained alternative or with a few lines in the theme, if the function is small. Third: take over the code and maintain it yourself, if the function is central and no replacement exists. The third way is a development project with its own effort, and we say that before the quotation. Commercial plugins bring a fourth question with them: who is the licence issued to? If it runs in the name of the previous agency, there is no update, whether or not the vendor has published one.
Mostly yes, but not as one click. The core can be raised in one step; the work lies in plugins, theme and PHP, and that is where several years of version distance add up. In practice this means: inventory, staging, PHP first, then plugins in small groups with checks in between, then the core, then the custom code. Whoever instead updates everything in one go and then has a fault does not have a lead, but a list of suspects. And if the result is that the theme and half the plugin list have to be replaced anyway, we put the figure for a rebuild next to it — even if the update would be the smaller order.
Yes, that is the normal case for update enquiries. What is needed is an administrator account for the backend, SSH or SFTP access to the server, database access and, if available, the Git repository as well as the licences for commercial plugins. Missing documentation is not a reason to decline — undocumented code is the normal case. We document the state we find and have it confirmed, so that it remains possible later to distinguish what we found from what we caused. If we find traces of a compromise, this is no longer an update case, but a clean rebuild with a separate quotation.
Not for this project — it ends with the go-live and the handover. For the time after that the question is justified, because the next cycle is coming: minor releases, plugin updates, the next PHP deadline. Three security releases in four weeks are not an exceptional summer, they are normal operation. If you want to hand this over, a service level agreement sets the response time — BASIC 24 hours, STANDARD 8 hours, ADVANCED 4 hours, PREMIUM 2 hours, as a monthly flat fee, net, per project. Without an agreement we work in order of arrival within 48 hours during our business hours, Mon–Fri 9:00–16:00. What belongs to ongoing maintenance and what does not is set out on the page about WordPress maintenance.
Enquiry
Describe the situation briefly. If you do not know the version level, that is not a problem — that is exactly the first step. You receive a written assessment before we talk about an order.