Descrición
Copia de seguridade, restauración, staging, clonación & migración de WordPress: todo en un
WP STAGING é o plugin todo en un de copias de seguridade, restauración, staging, clonación e migración de WordPress, creado para fluxos de traballo profesionais con código 100 por cento probado con probas unitarias, miles de probas automatizadas e probas extremo a extremo exhaustivas en todas as versións de PHP compatibles.
Crea unha copia de seguridade completa ou un clon exacto da túa web en minutos. Úsao para duplicar o teu sitio, probar con seguranza actualizacións de plugins e temas, restaurar o sitio cando o necesites, mover ou migrar WordPress a outro servidor, transferir o teu sitio a un novo aloxamento ou crear unha copia de staging antes de facer cambios. WP STAGING tamén funciona como duplicador de WordPress, así que non precisas un plugin duplicador aparte para copiar a túa web.
WP STAGING tamén fai copias de seguridade, clona e migra con fiabilidade tendas WooCommerce, incluídos pedidos, produtos e datos de clientes.
WP STAGING desenvólvese en Alemaña e está deseñado para axencias, desenvolvedores e empresas que precisan fluxos fiables de copia de seguridade, recuperación, staging, restauración e migración de WordPress.
WP STAGING | PRO tamén inclúe fluxos avanzados como Remote Sync, que che permite traer un sitio WordPress dun servidor a outro de forma segura mediante unha clave de API, e WP STAGING CLI, que pode converter unha copia de seguridade de WP STAGING nun sitio de desenvolvemento local baseado en Docker.
Todos os datos permanecen no teu servidor a non ser que elixas un fluxo de transferencia ou de almacenamento remoto. WP STAGING está deseñado para a velocidade, a fiabilidade e os contornos de poucos recursos, incluído o aloxamento compartido.
WP STAGING fai automaticamente a busca e substitución de ligazóns e rutas durante os fluxos de clonación, copia de seguridade, restauración e migración.
Este plugin de staging e copias de seguridade pode clonar a túa web de forma rápida e eficiente, incluso se funciona nun servidor de aloxamento compartido débil.
WP STAGING FREE – CARACTERÍSTICAS DE COPIA DE SEGURIDADE & STAGING
- Clona todo o sitio de produción nun subdirectorio como example.com/staging-site.
- Copia de seguridade e clonación de alto rendemento, incluso para webs con bases de datos moi grandes.
- Crea copias de seguridade completas ou parciais: copia completa do sitio, só da base de datos ou só dos arquivos.
- Copias de seguridade programadas con copias diarias automáticas.
- Fácil de usar: crea un clon ou unha copia de seguridade cun clic.
- Procesamento eficiente en segundo plano sen ralentizar a túa web.
- Sen Software como servizo e sen necesidade de conta externa.
- Todos os teus datos permanecen no teu servidor. Os teus datos son só teus.
- Sen tempos de espera do servidor en webs enormes ou servidores débiles.
- Fluxos rápidos de copia de seguridade, clonación e restauración segundo o tamaño do sitio e os recursos do servidor.
- Usa o clon como parte da túa estratexia de copias de seguridade e actualizacións.
- Só os administradores poden acceder á web clonada ou de copia de seguridade.
- Sitios de staging optimizados para SEO con protección de acceso e xestión de no-index.
- A barra de administración da web de staging / copia de seguridade é de cor laranxa e móstrase cando traballas no sitio de staging.
- Amplas características de rexistro.
- É compatible con Apache, Nginx, Microsoft IIS e LiteSpeed Server.
- Cada versión supera extensas probas automatizadas para manter o plugin robusto, fiable e rápido.
- Equipo de soporte rápido e profesional.
WP STAGING | PRO – CARACTERÍSTICAS DE COPIA DE SEGURIDADE & STAGING
As características de abaixo están dispoñibles en WP STAGING | PRO.
- Remote Sync – Trae un sitio WordPress dun servidor a outro de forma segura.
- WP STAGING CLI – Converte unha copia de seguridade nun sitio de desenvolvemento local baseado en Docker.
- Migra e transfire WordPress a outro aloxamento ou dominio.
- Envía os cambios de staging a produción (de staging a vivo), incluídos plugins, temas e arquivos multimedia, cun clic.
- Clona unha copia de seguridade ou un sitio de staging nunha base de datos separada.
- Elixe un directorio personalizado para unha copia de seguridade ou un sitio clonado.
- Selecciona un destino de subdominio personalizado como dev.example.com.
- Define perfís de usuario para acceder ao sitio clonado ou de copia de seguridade. Poden ser clientes ou desenvolvedores externos.
- Compatibilidade con multisitio para migración, copia de seguridade e clonación.
- Programa copias de seguridade recorrentes por hora e intervalo.
- Descarga e sube copias de seguridade a outro servidor para migración e transferencia.
- Axustes de retención das copias de seguridade.
- Nomes personalizados para as copias de seguridade.
- Avisos por correo electrónico se non se pode crear unha copia de seguridade.
- Copia de seguridade e restauración de WordPress multisitio.
- Copia de seguridade na nube, copia externa e copias remotas en provedores de almacenamento externos.
- Copia de seguridade en Google Drive.
- Copia de seguridade en Amazon S3.
- Copia de seguridade en (S)FTP.
- Copia de seguridade en Dropbox.
- Destinos de cartafol de copia de seguridade personalizados para provedores de almacenamento na nube.
- Soporte prioritario.
DOCUMENTACIÓN
Como facer copias de seguridade e restaurar WordPress
Copia de seguridade e restauración de WordPress
Copia de seguridade & transferencia dun sitio WordPress a outro aloxamento
Como migrar o teu sitio WordPress a un novo aloxamento
Remote Sync
Trae un sitio WordPress dun servidor a outro
Desenvolvemento local con Docker usando WP STAGING CLI
WP STAGING CLI – Actualiza agora
Todas as guías de copias de seguridade
Todas as guías de copias de seguridade
Traballar con sitios de staging
Traballar con sitios de staging
FAQ de Backup & Cloning
FAQ de Backup & Cloning
Resolución de problemas de Backup & Cloning
Resolución de problemas de Backup & Cloning
REQUISITOS TÉCNICOS & INFORMACIÓN DE WP STAGING BACKUP & CLONING
- Funciona coa última versión de WordPress
- Versión mínima compatible de WordPress: 3.8
- A clonación e a copia de seguridade funcionan en todos os aloxamentos
- Non se precisan bibliotecas adicionais
- A copia de seguridade & a clonación admiten webs enormes
- O formato de copia de seguridade personalizado é moito máis rápido e pequeno que calquera compresión tar ou zip
- A copia de seguridade & a clonación funcionan en contornos de pouca memoria & aloxamento compartido
SOPORTE
Capturas
Instalación
Instalación mediante a busca de plugins do administrador
- Vai a Plugins > Engadir novo. Selecciona «Autor» no menú despregable xunto ao campo de busca.
- Busca «WP STAGING». Tamén funciona buscar «WPStaging» nunha soa palabra.
- Atopa «WP STAGING – WordPress Backup, Restore & Migration» e fai clic no botón «Instalar agora».
- Activa o plugin.
- O plugin debería amosarse debaixo do menú de axustes.
Instalación como administrador mediante zip
- Visita a pantalla de engadir novo plugin e fai clic no botón «Subir plugin».
- Fai clic no botón «Examinar…» e selecciona o arquivo zip do noso plugin.
- Fai clic no botón «Instalar agora».
- Cando remate a subida, activa WP STAGING – WordPress Backup, Restore & Migration.
- O plugin debería amosarse debaixo do menú Axustes.
Preguntas frecuentes
-
Por que debería usar un sitio de staging e un fluxo de copias de seguridade?
-
As actualizacións de plugins, os cambios de tema e o código personalizado deberían probarse antes de chegar ao teu sitio en produción. Un fluxo de staging permite clonar a túa web de produción, probar cambios con seguranza e ter unha copia de seguridade lista por se algo sae mal. Actualizar con seguranza e probar as actualizacións nunha copia de staging protexe o teu sitio en produción de versións defectuosas.
Normalmente é mellor executar o sitio de staging nun contorno o máis parecido posible ao servidor de produción. Esa é a mellor forma de detectar problemas de compatibilidade antes de que afecten ao teu sitio en produción.
WP STAGING combina copia de seguridade, restauración, staging e migración nun só fluxo, así que podes protexer a túa web en produción, reducir o risco de inactividade e publicar cambios con máis confianza.
-
É WP STAGING un plugin de copias de seguridade?
-
Si. WP STAGING naceu como plugin de staging e converteuse nun plugin completo de copias de seguridade de WordPress, con restauración, staging, clonación e migración nunha soa ferramenta.
Incluso a versión gratuíta permite crear copias de seguridade e restauralas cando o necesites. WP STAGING | PRO engade fluxos de copia máis avanzados, destinos de almacenamento na nube, ferramentas de migración e características orientadas a desenvolvedores.
-
En que se diferencia WP STAGING doutros plugins de copias de seguridade?
-
WP STAGING combina copia de seguridade, restauración, staging, clonación e migración nun só fluxo. Mentres que moitos plugins de copias de seguridade se centran sobre todo en copias baseadas en arquivos ou en migracións sinxelas, WP STAGING tamén che axuda a crear unha copia de staging funcional, probar actualizacións con seguranza e restaurar o teu sitio cando o necesites.
Algúns plugins de copias de seguridade céntranse sobre todo en crear arquivos de copia, mentres que WP STAGING tamén crea copias de staging funcionais para probas máis seguras e fluxos de reversión. Isto é especialmente útil cando queres unha validación similar á de produción antes de publicar os cambios.
Algúns plugins de copias de seguridade poden non ser totalmente compatibles con táboas personalizadas en todos os escenarios. WP STAGING está deseñado para funcionar con fiabilidade cos fluxos de staging e cos prefixos de táboa personalizados que usan os seus propios contornos clonados.
WP STAGING | PRO tamén inclúe fluxos avanzados como Remote Sync e WP STAGING CLI, que pode converter unha copia de seguridade nun sitio de desenvolvemento local baseado en Docker. Iso fai que WP STAGING sexa especialmente atractivo para desenvolvedores, axencias e propietarios de sitios que queren algo máis que un plugin básico de copias de seguridade.
-
Como fago unha copia de seguridade e restauro un sitio WordPress?
-
Despois de instalar WP STAGING, vai á sección de copias de seguridade do plugin e crea unha copia completa do sitio. Despois poderás restaurar esa copia se unha actualización de plugin, un cambio de tema, unha implantación ou un problema inesperado rompe o teu sitio.
WP STAGING está deseñado para facer sinxelas a copia de seguridade e a restauración, incluso en aloxamento compartido e en instalacións grandes de WordPress.
-
Que é Remote Sync en WP STAGING Pro?
-
Remote Sync é unha característica Pro que che permite traer un sitio WordPress dun servidor a outro de forma segura mediante unha clave de API. En vez de exportar bases de datos e copiar arquivos manualmente, conectas os dous sitios e inicias a sincronización desde WP STAGING.
Isto é especialmente útil para axencias, desenvolvedores e propietarios de sitios que queren un fluxo máis rápido e fiable para mover contido entre instalacións de WordPress.
Máis información:
Remote Sync: trae un sitio WordPress dun servidor a outro -
Como podo converter unha copia de seguridade nun sitio de desenvolvemento local con Docker?
-
WP STAGING | PRO inclúe acceso a WP STAGING CLI, que pode converter unha copia de seguridade de WP STAGING nun sitio WordPress local baseado en Docker cun só comando.
Isto é ideal para depurar, facer control de calidade, desenvolver e reproducir problemas de clientes en local. Axúdache a crear contornos locais repetibles sen montar configuracións Docker personalizadas para cada proxecto.
Máis información:
WP STAGING CLI – Actualiza agora -
Como movo, migro ou transfiro un sitio WordPress a un novo aloxamento?
-
WP STAGING | PRO inclúe fluxos de migración e transferencia que che axudan a mover unha web WordPress a outro aloxamento, transferir o teu sitio WordPress a un novo aloxamento, cambiar o dominio ou mudar a outro servidor. Podes mover a túa web entre aloxamentos sen exportacións manuais da base de datos.
Se queres unha guía paso a paso, consulta:
Como migrar o teu sitio WordPress a un novo aloxamento -
Como duplico ou clono un sitio WordPress?
-
WP STAGING funciona como duplicador de WordPress: pode duplicar ou clonar un sitio WordPress en poucos clics e crear unha copia exacta do teu sitio para probas, desenvolvemento ou como rede de seguridade. A duplicación execútase en segundo plano, así que podes duplicar incluso sitios WordPress grandes en aloxamento compartido. Se xa usaches un plugin como Duplicator, WP STAGING cobre os mesmos fluxos de clonación e copia e engade copia de seguridade, restauración e staging.
-
É WP STAGING unha boa alternativa a Duplicator?
-
Si. Se buscas unha alternativa a Duplicator, WP STAGING cobre os mesmos casos de uso: duplicar un sitio WordPress, crear unha copia completa do sitio e movelo ou transferilo a outro aloxamento. Ademais do fluxo de duplicación, no mesmo plugin tes sitios de staging cun clic, copias de seguridade programadas e restauración.
-
Por que necesito un plugin de copias de seguridade?
-
As copias de seguridade constantes da web son a base dunha estratexia sólida de recuperación ante desastres. Protexen a túa web fronte a actualizacións fallidas, erros de usuarios, limpeza de malware, problemas de aloxamento, fallos de hardware, avarías de software e perda de datos.
As copias de seguridade deben incluír os arquivos da web, as bases de datos, os datos dos usuarios e os datos de configuración. Combinar copias completas e incrementais pode mellorar a eficiencia do almacenamento e manter actualizados os puntos de restauración.
Se a túa web xera clientes potenciais, vendas, tráfico ou confianza dos clientes, as copias de seguridade periódicas non son opcionais. Un fluxo fiable de copia, restauración e recuperación permite volver atrás no teu sitio WordPress e pode aforrar horas de inactividade e un custoso traballo de recuperación.
-
Podo activar as ligazóns permanentes no sitio de staging?
-
As ligazóns permanentes están desactivadas no sitio de staging despois do primeiro proceso de clonación.
Le esta guía para activar as ligazóns permanentes no teu sitio de staging:
Activar as ligazóns permanentes no sitio de staging -
Non podo iniciar sesión no sitio de staging ou de copia de seguridade
-
Se usas un plugin de seguridade como Wordfence, iThemes Security, All In One WP Security & Firewall, ou un plugin que oculta a URL de acceso por defecto de WordPress, asegúrate de ter a última versión de WP STAGING.
Se aínda non podes iniciar sesión, vai a WP STAGING > Axustes e desactiva a identificación adicional de WP STAGING. O teu escritorio de administración seguirá protexido.
-
Podo usar só o meu sistema local de desenvolvemento de WordPress para probas e copias de seguridade?
-
Sempre podes probar a túa web en local, pero se o teu contorno local de hardware e software non é un clon exacto do teu servidor de produción, non hai garantía de que todos os aspectos da túa copia local se comporten do mesmo modo.
As diferenzas na versión de PHP, na pila do servidor, na memoria, no rendemento da CPU e no comportamento do sistema de arquivos poden provocar resultados inesperados en produción. Por iso o staging nunha infraestrutura próxima á de produción segue sendo valioso.
WP STAGING | PRO tamén che ofrece un fluxo local máis avanzado mediante WP STAGING CLI, que pode converter unha copia de seguridade nun sitio de desenvolvemento local baseado en Docker.
-
Está WP STAGING dispoñible en varios idiomas?
-
Si. WP STAGING está dispoñible en varios idiomas e algunhas traducións xa están completas ou case completas.
Podes ver aquí as páxinas traducidas do plugin:
Inglés
Francés
Alemán
Español
Croata
Neerlandés
Finlandés
Grego
Húngaro
Indonesio
Italiano
Persa
Polaco
Portugués (Brasil)
Ruso
Turco
VietnamitaSe queres axudar a mellorar as traducións, ponte en contacto connosco a través do foro de soporte.
-
Podo dar a miña opinión sobre WP STAGING?
-
Si. Se algo non funciona como esperabas, abre unha solicitude de soporte e describe o problema con tanto detalle como poidas.
Melloramos WP STAGING continuamente a partir das respostas dos usuarios, dos contornos de aloxamento reais e dos casos de uso de desenvolvedores.
Soporte aberto:
WP STAGING Support Forum
Comentarios
Colaboradores e desenvolvedores
“WP STAGING – Copias de seguridade & restauración, migración & plugin de clonación – Copias na nube, copias de seguridade programadas” é un software de código aberto. As seguintes persoas colaboraron con este plugin.
Colaboradores
“WP STAGING – Copias de seguridade & restauración, migración & plugin de clonación – Copias na nube, copias de seguridade programadas” foi traducido a 11 idiomas. Grazas aos desenvolvedores polas súas contribucións.
Interesado no desenvolvemento?
Revisa o código, bota unha ollada aorepositorio SVN, ou subscríbete ao log de desenvolvemento por RSS.
Rexistro de cambios
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 | Rexistro de cambios completo:
https://wp-staging.com/wp-staging-changelog