Stopp utilsiktede URL-endringer før de ødelegger lenker.
Lås slug- og permalinkendringer bak en eksplisitt arbeidsflyt slik at utilsiktede URL-endringer ikke ødelegger eksisterende lenker.
Bruk det når redaktører skal oppdatere titler og innhold uten at etablerte URL-er endres i stillhet.
Beskytt URL-er som standard.
Gode URL-er blir infrastruktur. Dette innstikket gjør utilsiktede endringer vanskeligere, men tillater planlagte navneendringer.
Lås eksisterende post- og taksonomi-slugs med mindre du uttrykkelig låser dem opp. Dette innstikket holder etablerte URL-er stabile under importer, synkroniseringer, MCP-kjøringer og andre skriptede oppdateringer.
Last ned siste utgivelse | Se kildekoden på GitHub
Nåværende scope er bare slug-beskyttelse. Det låser ikke lenker inne i innhold og låser ikke postmeta.
Hvilket problem det løser
Mye WordPress-trøbbel starter med en stille slug-endring. Et skript, en import, en migrering eller en KI-flyt oppdaterer en post-slug eller taksonomiterm, og plutselig matcher ikke gamle URL-er det søkemotorer, bokmerker eller interne systemer forventer.
Ødelagte URL-er
Gamle lenker i søkeresultater, e-poster og dokumentasjon slutter å løse rent.
Uventet taksonomi-støy
Kategorier og termer glir når synkjobber eller bulkverktøy skriver dem om.
Kollisjoner i automatisering
Skript og MCP-verktøy kan redigere trygt, men slug-endringer bør kreve en eksplisitt beslutning.
Hva det faktisk låser
Post-slugs
Existing post_name verdiene forblir låst ved oppdatering med mindre du tillater endringen.
Slugs for taksonomitermer
Eksisterende term-slugs fryses også med mindre du tillater endringen.
Ingenting annet
Det låser ikke innholdslenker, postmeta eller urelaterte redigeringsendringer.
Når det hjelper
- Bulkimport som skal oppdatere innhold, men ikke gi etablerte URL-er nye navn.
- Staging-til-produksjon-flyter der slug-avvik kan skape unngåelig SEO-skade.
- MCP- og automatiseringsflyter der assistenter skal kunne redigere trygt uten stille permalink-støy.
- Nettsteder der flere innstikk eller egne jobber endrer poster og termer programmatisk.
Slik tillater du en bevisst navneendring
If you really do want to change slugs, add a temporary allow constant in wp-config.php, gjør endringen, og fjern konstanten etterpå.
define('URL_LOCKDOWN_ALLOW', true);
// Or, for WP-CLI only:
define('URL_LOCKDOWN_ALLOW_CLI', true);Dette holder standardatferden streng, men lar deg fortsatt utføre planlagte navneendringer med vilje.
Gjeldende utgivelsesstatus
- Latest release: 1.4.2
- Krever WordPress: 5.9+
- Krever PHP: 7.4+
- License: GPL v2 or later
Ofte stilte spørsmål
Tillater det fortsatt manuelle slug-endringer i wp-admin?
Nei. Eksisterende post- og taksonomi-slugs forblir fryst med mindre en allow-konstant er satt. Det er gjeldende dokumenterte atferd.
Låser det også lenker i innholdet?
Nei. Innstikket er bare slug-basert nå. Det kontrollerer ikke lenker inne i innholdet.
Låser det postmeta eller egendefinerte felt?
Nei. Postmeta ligger utenfor scopet.
Hva om jeg må gi noe nytt navn med vilje?
Bruk URL_LOCKDOWN_ALLOW eller URL_LOCKDOWN_ALLOW_CLI, utfør endringen, og fjern konstanten igjen.
Hvorfor holde scopet så smalt?
Fordi det nyttige hardening-målet er slug-stabilitet. Å låse urelaterte innholdsfelt skaper støy og kommer i veien for normal redigering.
Trenger du å hindre utilsiktede URL-endringer?
Fortell oss hvordan redaktører endrer innhold i dag og hvor URL-feil skaper risiko. Vi foreslår kontroller.