Beschreibung
WordPress Backup, Restore, Staging, Cloning & Migration — All in One
WP STAGING is the all-in-one WordPress backup, restore, staging, cloning, and migration plugin, built for professional workflows with 100% unit-tested code, thousands of automated tests, and extensive end-to-end testing across supported PHP versions.
Create a full backup or an exact clone or copy of your website in minutes. Use it to duplicate your site, test plugin and theme updates safely, restore your site when needed, move or migrate WordPress to another server, transfer your site to a new host, or build a staging copy before making changes. WP STAGING also works as a WordPress duplicator, so you do not need a separate duplicator plugin to copy your website.
WP STAGING reliably backs up, clones, and migrates WooCommerce stores too, including orders, products, and customer data.
WP STAGING is developed in Germany and designed for agencies, developers, and businesses that need reliable WordPress backup, recovery, staging, restore, and migration workflows.
WP STAGING | PRO enthält auch fortgeschrittene Workflows wie Remote Sync, mit dem Sie eine WordPress-Website sicher von einem Server auf einen anderen übertragen können, indem Sie einen API-Schlüssel verwenden, und WP STAGING CLI, mit dem Sie ein WP STAGING-Backup in eine lokale Docker-basierte Entwicklungswebsite umwandeln können.
Alle Daten bleiben auf Ihrem Server, es sei denn, Sie wählen einen Übertragungs- oder Remote-Speicher-Workflow. WP STAGING ist für Geschwindigkeit, Zuverlässigkeit und Umgebungen mit geringen Ressourcen konzipiert, einschließlich Shared Hosting.
WP STAGING führt automatisch Suchen und Ersetzen für Links und Pfade während des Klonens, Backups, Wiederherstellens und Migrationsvorgangs durch.
Dieses Staging- und Backup-Plugin kann Ihre Website schnell und effizient klonen, selbst wenn sie auf einem schwachen Shared-Hosting-Server läuft.
WP STAGING FREE – BACKUP & STAGING FUNKTIONEN
- Klont die gesamte Produktions-Site in ein Unterverzeichnis wie example.com/staging-site.
- Hochleistungs-Backup und Klonen, auch für Websites mit sehr großen Datenbanken.
- Create full or partial backups — full-site backup, database-only, or files-only backups.
- Scheduled backups with automatic daily backups.
- Einfach zu bedienen: Erstellen Sie mit einem Klick einen Klon oder ein Backup.
- Effiziente Hintergrundverarbeitung, ohne die Geschwindigkeit Ihrer Website zu verlangsamen.
- Keine Software als Dienstleistung und kein externes Konto erforderlich.
- Ihre Daten bleiben auf Ihrem Server. Ihre Daten gehören nur Ihnen.
- Keine Server-Timeouts auf riesigen Websites oder kleinen und schwachen Servern
- Schnelle Backup-, Klon- und Wiederherstellungs-Workflows je nach Website-Größe und Server-Ressourcen.
- Verwenden Sie den Klon als Teil Ihrer Backup- und Update-Strategie.
- Nur Administratoren können auf die Klon-/Backup-Website zugreifen.
- SEO-freundliche Staging-Websites mit Anmeldungsschutz und No-Index-Verarbeitung.
- Die Adminleiste auf der Staging-/Backup-Website ist orangefarben und zeigt an, wenn Sie auf der Staging-Website arbeiten.
- Umfangreiche Protokollierungsfunktionen
- Unterstützt Apache, Nginx, Microsoft IIS und LiteSpeed Server.
- Jedes Release durchläuft umfangreiche automatisierte Tests, um das Plugin robust, zuverlässig und schnell zu halten.
- Schnelles und professionelles Support-Team
WP STAGING | PRO – BACKUP & STAGING FUNKTIONEN
Die Funktionen unten sind in WP STAGING | PRO verfügbar.
- Remote Sync – Sicheres Übertragen einer WordPress-Website von einem Server auf einen anderen.
- WP STAGING CLI – Verwandeln Sie ein Backup in eine lokale Docker-basierte Entwicklungswebsite.
- Migriere und übertrage WordPress auf einen anderen Host oder eine andere Domain.
- Push staging changes to production (staging to live), including plugins, themes, and media files, with one click.
- Erstellen Sie eine Kopie einer Backup- oder Staging-Website in einer separaten Datenbank.
- Wählen Sie ein benutzerdefiniertes Verzeichnis für das Backup oder der geklonten Website.
- Wählen Sie ein individuelles Subdomain-Ziel wie dev.example.com aus.
- Definieren Sie Benutzerrollen für den Zugriff auf die Klon- oder Backup-Website. Dies können Kunden oder externe Entwickler sein.
- Unterstützung für Multisite bei Migration, Backup und Klonen.
- Planen Sie regelmäßige Backups nach Zeit und Intervall.
- Herunterladen und hochladen von Backups auf einen anderen Server für Migration und Transfer.
- Sicherungsspeicherungseinstellungen.
- Individuelle Sicherungsnamen.
- E-Mail-Benachrichtigungen, wenn ein Backup nicht erstellt werden kann.
- WordPress multisite backup and restore.
- Cloud backup, offsite backup, and remote backups to external storage providers.
- Backup auf Google Drive
- Backup auf Amazon S3
- Backup auf (s)FTP
- Backup nach Dropbox
- Individuelle Backup-Ordnerziele für Cloud-Speicheranbieter.
- Bevorzugter Support.
DOKUMENTATION
Wie man WordPress sichert und wiederherstellt
WordPress sichern und wiederherstellen
Backup & Transfer WordPress Website zu einem anderen Host
Wie man Ihre WordPress-Website zu einem neuen Host migriert
Remote Sync
Eine WordPress-Website von einem Server auf einen anderen übertragen
Lokale Docker-Entwicklung mit WP STAGING CLI
WP STAGING CLI – Jetzt upgraden
Alle Backup-Anleitungen
Alle Backup-Anleitungen
Arbeiten mit Staging-Websites
Arbeiten mit Staging-Websites
FAQ für Backup & Cloning
FAQ für Backup & Cloning
Fehlerbehebung bei Backup & Klonen
https://wp-staging.com/docs/category/troubleshooting/
WP-STAGING-BACKUP & TECHNISCHE ANFORDERUNGEN FÜR DAS KLONEN & INFORMATION
- Funktioniert auf der neuesten Version von WordPress
- Mindestens unterstützte WordPress-Version 3.8
- Klonen und Backup funktioniert auf allen Webhosts
- Keine zusätzlichen Bibliotheken erforderlich
- Backup / Datensicherung & Das Klonen unterstützt riesige Websites
- Das benutzerdefinierte Backup format ist viel schneller und kleiner als jede Tar- oder Zip-Komprimierung
- Datensicherung / Backup & Klonen funktioniert bei wenig Arbeitsspeicher & gemeinsam genutzte Hosting-Umgebungen
SUPPORT
Screenshots









Installation
Installation über Admin-Plugin-Suche
- Gehe zu Plugins > Neu hinzufügen. Wähle „Autor” aus dem Dropdown neben der Sucheingabe.
- Search for „WP STAGING“. Searching for „WPStaging“ in one word works as well.
- Finde das „WP STAGING WordPress Backup Plugin” und klicke auf den Button „Jetzt installieren”.
- Aktiviere das Plugin.
- Das Plugin sollte unterhalb des Menüs „Einstellungen“ angezeigt werden.
Admin-Installer über zip
- Rufe den Bildschirm „Neues Plugin hinzufügen” auf und klicke auf den Button „Plugin hochladen”.
- Klicke auf den Button „Durchsuchen…” und wähle die Zip-Datei unseres Plugins aus.
- Klicke auf den Button „Jetzt installieren”.
- Sobald der Upload abgeschlossen ist, aktiviere WP STAGING – WordPress Backup, Restore & Migration.
- Das Plugin sollte unterhalb des Menüs „Einstellungen“ angezeigt werden.
FAQ
-
Warum sollte ich einen Staging-Website und Backup-Workflow verwenden?
-
Plugin updates, theme changes, and custom code should be tested before they reach your live site. A staging workflow lets you clone your production website, test changes safely, and keep a working backup ready in case something goes wrong. Safe updates and update testing on a staging copy protect your live site from broken releases.
In der Regel ist es am besten, die Testumgebung auf einer Umgebung laufen zu lassen, die so nah wie möglich am Produktivserver ist. Das ist der beste Weg, um Kompatibilitätsprobleme zu erkennen, bevor sie sich auf Ihre Live-Website auswirken.
WP STAGING kombiniert Backup, Wiederherstellung, Staging und Migration in einem Workflow, damit du deine Live-Website schützen, das Risiko von Ausfallzeiten reduzieren und Änderungen mit mehr Vertrauen übertragen kannst.
-
Ist WP STAGING ein Backup-Plugin?
-
Yes. WP STAGING started as a staging plugin and grew into a complete WordPress backup plugin, with restore, staging, cloning, and migration in one tool.
Sogar die kostenlose Version ermöglicht es Ihnen, Backups zu erstellen und sie bei Bedarf wiederherzustellen. WP STAGING | PRO bietet zusätzliche erweiterte Backup-Workflows, Cloud-Speicherziele, Migrationswerkzeuge und Entwickler-Funktionen.
-
Was unterscheidet WP STAGING von anderen Backup-Plugins?
-
WP STAGING kombiniert Backup, Wiederherstellung, Staging, Klonen und Migration in einem Workflow. Während sich viele Backup-Plugins hauptsächlich auf archivbasierte Backups oder einfache Migration konzentrieren, hilft WP STAGING Ihnen auch dabei, eine funktionierende Staging-Kopie zu erstellen, Updates sicher zu testen und Ihre Website bei Bedarf wiederherzustellen.
Einige Backup-Plugins konzentrieren sich hauptsächlich darauf, Sicherungsarchive zu erstellen, während WP STAGING auch funktionierende Staging-Kopien für sicherere Test- und Rollback-Workflows erstellt. Dies ist besonders nützlich, wenn Sie eine produktionsähnliche Validierung wünschen, bevor Sie Änderungen live übernehmen.
Einige Backup-Plugins unterstützen möglicherweise individuelle Tabellen in allen Szenarien nicht vollständig. WP STAGING ist darauf ausgelegt, zuverlässig mit Staging-Workflows und individuellen Tabellenpräfixen zu arbeiten, die in den eigenen geklonten Umgebungen verwendet werden.
WP STAGING | PRO enthält auch fortgeschrittene Workflows wie Remote Sync und WP STAGING CLI, die ein Backup in eine lokale Docker-basierte Entwicklungsumgebung umwandeln können. Das macht WP STAGING besonders attraktiv für Entwickler, Agenturen und Website-Besitzer, die mehr als nur ein grundlegendes Backup-Plugin möchten.
-
Wie sichere ich eine WordPress-Website und stelle sie wieder her?
-
Nach der Installation von WP STAGING gehen Sie zum Backup-Abschnitt im Plugin und erstellen Sie ein vollständiges Website-Backup. Sie können dann dieses Backup wiederherstellen, wenn ein Plugin-Update, eine Theme-Änderung, ein Deployment oder ein unerwartetes Problem Ihre Website beschädigt.
WP STAGING ist darauf ausgelegt, Backups und Wiederherstellungen auch auf Shared Hosting und großen WordPress-Installationen einfach zu machen.
-
Was ist Remote Sync in WP STAGING Pro?
-
Remote Sync ist eine Pro-Funktion, die es Ihnen ermöglicht, eine WordPress-Website sicher von einem Server auf einen anderen zu übertragen, indem Sie einen API-Schlüssel verwenden. Anstatt Datenbanken manuell zu exportieren und Dateien zu kopieren, verbinden Sie die beiden Websites und starten die Synchronisierung von innerhalb von WP STAGING.
Dies ist besonders nützlich für Agenturen, Entwickler und Website-Besitzer, die einen schnelleren und zuverlässigeren Workflow für den Austausch von Inhalten zwischen WordPress-Installationen wünschen.
Erfahren Sie mehr:
Remote Sync: WordPress-Site von einem Server auf einen anderen übertragen -
Wie kann ich ein Backup in eine lokale Docker-Entwicklungswebsite umwandeln?
-
WP STAGING | PRO beinhaltet Zugriff auf WP STAGING CLI, mit dem ein WP STAGING-Backup mit einem Befehl in eine lokale Docker-basierte WordPress-Website umgewandelt werden kann.
Dies ist ideal zum Debuggen, für Qualitätssicherung, Entwicklung und zur Reproduktion von Client-Problemen lokal. Es hilft Ihnen, wiederholbare lokale Umgebungen zu erstellen, ohne individuelle Docker-Setups für jedes Projekt erstellen zu müssen.
Erfahren Sie mehr:
WP STAGING CLI – Upgrade installieren -
How do I move, migrate, or transfer a WordPress site to a new host?
-
WP STAGING | PRO includes migration and transfer workflows that help you move a WordPress website to another host, transfer your WordPress site to a new host, change the domain, or move to another server. You can move your website between hosts without manual database exports.
Wenn Sie eine geführte Schritt-für-Schritt-Anleitung wünschen, sehen Sie sich an:
Wie man Ihre WordPress-Website zu einem neuen Host migriert -
How do I duplicate or clone a WordPress site?
-
WP STAGING works as a WordPress duplicator: it can duplicate or clone a WordPress site in a few clicks and create an exact copy of your site for testing, development, or as a safety net. Duplication runs in the background, so you can duplicate even large WordPress sites on shared hosting. If you have used a plugin like Duplicator before, WP STAGING covers the same clone and copy workflows and adds backup, restore, and staging.
-
Is WP STAGING a good Duplicator alternative?
-
Yes. If you are looking for a Duplicator alternative, WP STAGING covers the same use cases: duplicate a WordPress site, create a full-site copy, and move or transfer it to another host. In addition to the duplicator workflow, you get one-click staging sites, scheduled backups, and restore in the same plugin.
-
Warum brauche ich überhaupt ein Backup-Plugin?
-
Konsistente Website-Backups sind die Grundlage einer robusten Notfallwiederherstellungsstrategie. Sie schützen Ihre Website vor fehlgeschlagenen Updates, Benutzerfehlern, Malware-Bereinigung, Hosting-Problemen, Hardware-Ausfällen, Softwarefehlern und Datenverlust.
Sicherungskopien sollten Website-Dateien, Datenbanken, Benutzerdaten und Konfigurationsdaten enthalten. Eine Kombination aus Voll- und inkrementellen Sicherungskopien kann die Speichereffizienz verbessern und gleichzeitig die Wiederherstellungspunkte aktuell halten.
If your website generates leads, sales, traffic, or customer trust, regular backups are not optional. A reliable backup, restore, and recovery workflow lets you roll back your WordPress site and can save hours of downtime and expensive recovery work.
-
Kann ich Permalinks auf der Staging-/Backup-Site aktivieren?
-
Permalinks sind auf der Staging-Website nach dem ersten Klonvorgang deaktiviert.
Lies diese Anleitung, um Permalinks auf deiner Staging-Website zu aktivieren:
Permalinks auf der Staging-Website aktivieren -
Ich kann mich nicht bei der Staging-/ Backup-Seite anmelden
-
Wenn Sie ein Sicherheits-Plugin wie Wordfence, iThemes Security, All In One WP Security & Firewall oder ein Plugin verwenden, das die Standard-WordPress-Anmelde-URL verbirgt, stellen Sie sicher, dass Sie die neueste Version von WP STAGING verwenden.
Wenn Sie sich immer noch nicht anmelden können, gehen Sie zu WP STAGING > Einstellungen und deaktivieren Sie die zusätzliche Authentifizierung von WP STAGING. Ihr Admin-Dashboard bleibt weiterhin geschützt.
-
Kann ich mein lokales WordPress-Entwicklungssystem einfach für Tests und Backups verwenden?
-
Sie können Ihre Website immer lokal testen, aber wenn Ihre lokale Hardware- und Softwareumgebung kein 100%iger Klon Ihres Produktionsservers ist, gibt es KEINE Garantie, dass jeder Aspekt Ihrer lokalen Kopie auf Ihrer Produktionswebsite genau so funktioniert, wie Sie es erwarten.
Unterschiede in der PHP-Version, im Server-Stack, im Speicher, in der CPU-Leistung und im Dateisystemverhalten können alle zu unerwarteten Ergebnissen in der Produktion führen. Deshalb bleibt das Staging auf einer Infrastruktur, die der Produktion nahe ist, wertvoll.
WP STAGING | PRO bietet Ihnen auch einen fortgeschritteneren lokalen Workflow durch WP STAGING CLI, der ein Backup in eine lokale Docker-basierte Entwicklungsumgebung umwandeln kann.
-
Ist WP STAGING in mehreren Sprachen verfügbar?
-
Ja. WP STAGING ist in mehreren Sprachen verfügbar, und mehrere Übersetzungen sind bereits abgeschlossen oder fast abgeschlossen.
Sie können übersetzte Plugin-Seiten hier anzeigen:
English
French
German
Spanish
Croatian
Dutch
Finnish
Greek
Hungarian
Indonesian
Italian
Persian
Polish
Portuguese (Brazil)
Russian
Turkish
VietnameseWenn Sie bei der Verbesserung von Übersetzungen helfen möchten, kontaktieren Sie uns bitte über das Support-Forum.
-
Kann ich Feedback für WP STAGING geben?
-
Ja. Wenn etwas nicht wie erwartet funktioniert, öffnen Sie bitte eine Support-Anfrage und beschreiben Sie das Problem so detailliert wie möglich.
Wir verbessern WP STAGING kontinuierlich basierend auf Benutzerfeedback, realen Hosting-Umgebungen und Entwickler-Anwendungsfällen.
Offener Support:
WP STAGING Support Forum
Rezensionen
Mitwirkende und Entwickler
„WP STAGING – Backups & Restore, Migration & Clone Plugin – Cloud Backups, Scheduled Backups“ ist Open-Source-Software. Folgende Menschen haben an diesem Plugin mitgewirkt:
Mitwirkende„WP STAGING – Backups & Restore, Migration & Clone Plugin – Cloud Backups, Scheduled Backups“ wurde in 11 Sprachen übersetzt. Danke an die Übersetzer für ihre Mitwirkung.
Interessiert an der Entwicklung?
Durchstöbere den Code, sieh dir das SVN-Repository an oder abonniere das Entwicklungsprotokoll per RSS.
Änderungsprotokoll
4.16.0
- New: Add „Create Blank WP Site“ option that installs a fresh WordPress instead of cloning the live site. (Pro) #2959
- New: Add opt-in low disk space mode for Remote Sync pull that creates and transfers the backup in capped parts, so the source site no longer needs free disk space for the whole backup. #5317
- New: Preview and map subsite URLs when cloning and pushing. (Pro) #5898
- Enh: Duplicate an FTP / SFTP storage profile, so a second destination on the same server needs no retyped connection details. (Pro) #6506
- Enh: FTP / SFTP settings move to a new place on update, so going back to an older version needs them entered again. #5946
- Enh: Keep FTP / SFTP destinations out of staging sites, so production credentials are not copied to a clone. #5946
- Enh: Load remote storage code only for WP STAGING requests. (Pro) #3879
- Enh: Refuse to save an FTP / SFTP profile into a folder another profile already uses on the same server. (Pro) #6506
- Enh: Support multiple independent FTP / SFTP storage profiles per site. #5946
- Fix: Backups no longer fail their own integrity check when their size lands just below a power of ten. #6480
- Fix: Cancelling a backup started from the first-run screen now closes the progress window and offers the choice again, instead of leaving the window open and failing on a second attempt. #6406
- Fix: Delete every wpstg_staging_sites_backup_ option when the plugin is uninstalled. #6185
- Fix: Delete the backups a plan no longer keeps once the new one exists, so a plan that keeps a single backup is never left without one. #6359
- Fix: Delete the temporary copy of the staging site’s storage credentials when an update cannot restore it, and on uninstall. #6263
- Fix: Exclude the background-processing queue table from staging site clones. #6362
- Fix: Expect the storage profile AJAX callbacks in the storage service provider test, so master’s unit tests pass again. #6550
- Fix: Give the backup a plan makes with Create backup now the plan’s schedule id, so the plan counts that backup toward the number of backups it keeps, rotates it away in its turn, and reports it as its last run. #6462
- Fix: Honour WP-CLI options written with a leading double dash and report unknown ones. #6413
- Fix: Keep rebuilding the backup cron events when one backup plan’s schedule id is not a string. #6370
- Fix: Keep the „Cancelling & Cleaning up“ modal after cancelling a backup restore instead of reporting the job as cancelled from another page. #6620
- Fix: Keep the Next-Gen transfer method selected after a push. (Pro) #6527
- Fix: Make WP-CLI staging-site-create honour its database and other advanced options. (Pro) #6257
- Fix: Name the missing automatic login endpoint instead of blaming a firewall when the staging site runs WP STAGING Free. #6222
- Fix: Prevent duplicated domain suffixes and preserve escaped page-builder URLs when restoring backups. (Pro) #3439
- Fix: Protect updates clicked before the page finishes loading. #6337
- Fix: Record the actual reason a Remote Sync authentication failed instead of one generic message. #5505
- Fix: Reduce temporary files created during backups. #2037
- Fix: Refuse cloning to a target directory PHP cannot read instead of failing with a fatal error. #6494
- Fix: Refuse creating a staging site when its destination table prefix is already in use. #6220
- Fix: Refuse to back up a subsite in the WP-CLI backup-create command when it is archived, suspended or deleted, or belongs to another network. #6384
- Fix: Regenerate Elementor CSS after restoring a backup or syncing a database with Remote Sync. #6251
- Fix: Report a cancellation that cannot finish instead of asking the server about it for ever. #6422
- Fix: Say which task could not be built instead of blaming disk space, and keep the object that came back out of the error report. #6277
- Fix: Select custom folders under wp-content by default when pushing, so a push no longer leaves them behind without saying so. #6157
- Fix: Show actionable guidance for Error 429 during backup uploads. #1162
- Fix: Show only one label at a time on the backup „Contains“ icons, instead of leaving several overlapping. #5381
- Fix: Stop a cancelled backup, staging site or push from logging the request the cancel aborted to the browser console, and report an error a finished job runs into while it closes down instead of swallowing it. #6007
- Fix: Stop an interrupted clone from leaving a live WordPress in the staging folder wired to the production database. #6145
- Fix: Stop an unchanged save of a backup plan from restarting the point its runs are counted from, so a missed backup stays reported. (Pro) #6409
- Fix: Stop counting failed Remote Sync authentications as sync attempts in usage analytics. #5505
- Fix: Stop reporting a backup restore as failed when its status check fails right after pressing Cancel. #6620
- Fix: Stop the WP-CLI backup-create command from backing up a different subsite than the one subsite_blog_id names. #6384
- Fix: The Create Backup modal no longer opens by itself on the backup page of a site that stopped running WP Staging Pro. #6613
- Fix: The Upload Backup to Cloud and Create Backup modals no longer reopen by themselves after saving cloud storage settings that did not leave the page. (Pro) #6613
- UX: Show „Always on“ in the staging summary for isolation controls that only Pro can turn off. #5987
- Tweak: Create a full-site backup before pushing to production. (Pro) #5240
- Tweak: Explain why uninstall keeps staging sites and backups. #6155
- Dev: Align AGENTS.md with the house rules in CLAUDE.md, so Copilot and Codex follow the same changelog, test, comment and code style rules. #6510
- Dev: Align the code-style guide and the test docs with CLAUDE.md. #6515
- Dev: Apply the blocked label from the lifecycle controller in place of fast-tests-failed and fast-tests-cancelled. #6592
- Dev: Apply the review-role labels from the lifecycle controller and take an unsupported ready-to-merge off. #6601
- Dev: Ask Copilot for its review from the lifecycle controller when nobody did. #6644
- Dev: Ask for the kind and the reproduction in the pull request template, so a pull request filled in by hand can satisfy the merge-readiness status. #6560
- Dev: Ask the author for the missing Follow-up owed line, not another fix, when every open review finding is already reported fixed and waits on the reviewer. #6591
- Dev: Ask the reviewer a second approval waits for to review the head, and name them in the merge-readiness status. #6614
- Dev: Bring the process docs and diagrams in line with the lifecycle controller. #6678
- Dev: Build WP Staging Free during make reset when dist/wp-staging holds no complete build, so WP Staging Pro can activate it on the dev sites. #6103
- Dev: Build the JavaScript the fast-test browser fixture serves, so a Playwright run cannot silently test a stale bundle. #6457
- Dev: Cap a review at 25 lines and name the defect in each finding title. #6594
- Dev: Check each open pull request’s labels against its reviews, checks and holds, and report where they disagree, without writing any. #6525
- Dev: Check every SCSS file with Prettier, not only those one folder deep. #6509
- Dev: Check the translation template on every push to master, so a stale template is reported against the merge that introduced it instead of being discovered in an unrelated pull request. #6312
- Dev: Claim a GitHub issue before starting on it, and take several off the backlog with one command. #6394
- Dev: Continue HIGH PRIORITY reviews into fixing verified blockers. #6448
- Dev: Correct fast-test label and WordPress 7.0 RC documentation. #6537
- Dev: Count the project owner’s skip-tests in the lifecycle controller, so merge-readiness can pass on a pull request merged without a test run. #6576
- Dev: Credit a fast-tests status only when GitHub Actions posted it. #6606
- Dev: Delete CI artifacts that a newer run or a closed pull request made obsolete, and keep the E2E packages for three days instead of fourteen. #6634
- Dev: Describe the pull request workflow in plain words with its diagrams, count the E2E rounds the controller dispatches, and let the author verify every review fix and feature. #6622
- Dev: Fail loudly when the Free fixture switch cannot read a version or a worktree E2E run skips every test, and restore the edition when a run is interrupted. #6392
- Dev: Generate the translation template without committing it in PRs. #6481
- Dev: Keep AGENTS.md and CLAUDE.md from contradicting each other. #6562
- Dev: Keep Playwright traces only for failed tests, which shrinks the report a failed E2E suite uploads. #6638
- Dev: Keep a review finding open when the author asks the wrong reviewer back for it. #6589
- Dev: Keep a review round whose holders already read the head, and read re-review signatures and bare approvals as follow-ups. #6646
- Dev: Keep a role review counting when the round moves to a new commit before the other review is in. #6669
- Dev: Label unit-test results as unit-baseline-passed and unit-full-matrix-passed, the names the lifecycle controller reads, instead of the fast-tests-passed family. #6574
- Dev: Let a reviewer hold a review role on request without joining the assignment rotation. #6615
- Dev: Let the author close a role-review finding that carries no Verify line, as review-procedure § 10 says, instead of holding it for a reviewer follow-up. #6587
- Dev: Let the author close every finding the hand-back reports fixed or dismisses, and never wait on a follow-up the PR asked for. #6653
- Dev: Let the author verify most review fixes and owe a follow-up only to the reviewer who raised the finding. #6533
- Dev: Let the project owner’s skip-reviews label lift the review roles, and have the lifecycle controller apply ready-to-merge to routine work once every gate passes. #6568
- Dev: Limit review findings to blockers and performance or UX gains. #6536
- Dev: List Pro-only changes in their own section of the wordpress.org release notes instead of dropping them. #6510
- Dev: Merge the labels that meant the same thing and name each one once in the skills, the controller and its policy. #6572
- Dev: Move the release procedure from the project slash command into .agents/skills, so every agent working in this repository can read and follow it. #6464
- Dev: Publish the lifecycle controller’s merge-readiness verdict as an advisory commit status on each open pull request’s head. #6548
- Dev: Queue the lifecycle controller’s runs instead of cancelling them, and keep merge-readiness from waiting on GitHub’s own blocked or unknown merge state. #6554
- Dev: Rebuild the stale Pro build before make tests_e2e serves it after a PHP edit. #6490
- Dev: Record a human verification of a feature on its head, and report the merge-eligibility and merge-readiness results it gates, without writing any. #6534
- Dev: Remove dead Selenium leftovers from the test tooling and repair make targets that cannot run. #6521
- Dev: Remove the inactive Kanban workflow and retire the unused in-progress label. #6604
- Dev: Remove the staging site the missing login endpoint E2E test left in the site root, which grew the full-site backup before push past the backup explorer’s memory limit. #6659
- Dev: Require every fix pull request to record whether it is a regression, what introduced it and which release shipped it. #6451
- Dev: Require the human verification of a feature to cover its whole workflow, and keep agents from recording it. #6610
- Dev: Rewrite the Copilot instructions as review rules, with path-specific rules and a code-review skill. #6502
- Dev: Rewrite the developer docs that still described the removed Selenium browser suite. #6516
- Dev: Run Fast tests on pull requests again by keeping the job results out of the size-limited verdict script expression. #6585
- Dev: Run the Flywheel and WordPress.com E2E suites nightly instead of on every Pro round. #6458
- Dev: Run the full PHP matrix once per pull request head: every push tests PHP 7.4 and 8.3, and the fast-tests label adds only the versions that head has not passed yet. #6520
- Dev: Run the lifecycle controller on runners of its own, so it never queues behind the tests. #6668
- Dev: Run the lifecycle controller’s job on the self-hosted xsimulator fleet instead of a paid Blacksmith runner. #6563
- Dev: Say in the review procedure that make tests_web and make tests_e2e rebuild a stale Pro build by themselves. #6485
- Dev: Set GitHub’s review state when a signed role review is posted. #6674
- Dev: Skip TickLockTest’s exclusivity checks where flock is not exclusive, such as the macOS Docker bind mount. #6523
- Dev: Spend the full fast-tests matrix only after a pull request has been reviewed. #6485
- Dev: Split pull request reviews into a correctness role and a workflow role, each held by its own assigned developer. #6485
- Dev: Start the owed E2E round from the lifecycle controller instead of waiting for a trigger label. #6596
- Dev: Stop a second WordPress version from cancelling an E2E workflow run dispatched on the same branch and PHP version. #6511
- Dev: Stop counting a review, hand-back or decision somebody other than its author edited. #6609
- Dev: Stop guardrail checks failing at random when grep -q closes the pipe early. #6651
- Dev: Stop reviews from reporting agent credits in commits and PR descriptions as blocking findings. #6647
- Dev: Stop running CI jobs a documentation-only pull request cannot affect. #6566
- Dev: Stop the skills from prescribing git commands the permission rules deny. #6546
- Dev: Stop the staging delete test from racing the modal backdrop. #6097
- Dev: Switch off the lifecycle controller’s Copilot request, which the workflow token cannot make. #6670
- Dev: Take changes-required off from the lifecycle controller once every blocking finding is settled. #6645
- Dev: Tell the release skill to reproduce a failed test locally before dispatching a CI shard. #6121
WP STAGING Backup & Cloning | Vollständiges Änderungsprotokoll:
https://wp-staging.com/wp-staging-changelog
