
🔒 4 Måter å programmatisk avpublisere et innlegg i WordPress
Nettstedet gikk ned etter en plugin-oppdatering, du må raskt skjule det problematiske innlegget før det er for sent. Og en uke senere hente det tilbake når feilen er rettet. Eller en kunde ber deg fjerne en utdatert artikkel fra søkeresultatene, men ikke slette den permanent.
Å manuelt endre status via administrasjonspanelet fungerer for ett eller to innlegg. Men når det er dusinvis av dem eller logikken må utløses automatisk, trenger du en programmatisk tilnærming. WordPress gir deg fire måter å avpublisere et innlegg på via PHP: fra et trygt utkast til full sletting.
Nedenfor finner du hver metode med klar-til-bruk-kode, en forklaring og et hint om når du bør bruke hvilken.
💡 Rask oversikt:
- Gjorde et innlegg om til et utkast via
wp_update_postmed statusendraft, den tryggeste og mest reversible måten - Gjorde et innlegg privat (
private), kun synlig for administratorer og redaktører - Sendte et innlegg inn i fremtiden via
post_date, innlegget forsvinner fra søkeresultatene til den angitte datoen kommer - Slettet et innlegg permanent via
wp_delete_post, en siste utvei med advarsler og en sikkerhetskopi
Trinn 1. Utkast: avpubliser et innlegg uten å miste data
Det vanligste scenarioet: du må midlertidig skjule et innlegg, men beholde alt innhold, URL-en og muligheten til å hente det tilbake med ett klikk. Å bytte til utkast er det ideelle alternativet.
Kun feltet post_status i wp_posts-tabellen endres. Selve innlegget, dets metafelter, vedlegg og URL forblir urørt. Når du bestemmer deg for å hente det tilbake, endrer du statusen tilbake til publish.
Kode for å endre statusen til draft. Legg den til i barnetemaets functions.php eller via Code Snippets-pluginen:
1 /** 2 * Converts a post to draft by ID. 3 * 4 * @param int $post_id ID of the post to unpublish. 5 */ 6 function sd_unpublish_to_draft( $post_id ) { 7 wp_update_post( array( 8 'ID' => $post_id, 9 'post_status' => 'draft', 10 ) ); 11 } 12 13 // Example call: unpublish post with ID = 42 14 sd_unpublish_to_draft( 42 );
wp_update_post() oppdaterer en post i databasen. Vi sender bare ID-en og den nye post_status-verdien, WordPress håndterer alt annet selv. Ingen andre felt endres.
Når du bør bruke dette: midlertidig skjuling av et innlegg for revisjon, automatisk deaktivering av innlegg med utløpt relevans (f.eks. kampanjer), programmatisk moderering av brukergenerert innhold.
Trinn 2. Privat innlegg: skjul for besøkende, behold for redaktører
Statusen privat er en mellomting mellom offentlig og skjult. Innlegget er ikke synlig for vanlige besøkende, men er tilgjengelig for administratorer og redaktører i administrasjonspanelet. Praktisk for internt materiale: teaminstruksjoner, klientinnholdsutkast, private sider.
Forskjell fra et utkast: et privat innlegg er teknisk sett «publisert» og kan ha sin egen URL, men WordPress sjekker brukertillatelser før det vises. En besøkende uten read_private_posts-egenskapen vil se en 404.
Koden er lik den forrige, bare statusen endres:
1 /** 2 * Makes a post private — visible only to admins and editors. 3 * 4 * @param int $post_id Post ID. 5 */ 6 function sd_unpublish_to_private( $post_id ) { 7 wp_update_post( array( 8 'ID' => $post_id, 9 'post_status' => 'private', 10 ) ); 11 } 12 13 // Example call 14 sd_unpublish_to_private( 42 );
Merk: hvis nettstedet har tilpassede brukerroller med tilpassede egenskaper, sjekk dem før massebruk. Som standard er private innlegg synlige for rollene editor og administrator.
Når du bør bruke dette: premium abonnementsinnhold (sammen med medlemskapspluginer), intern teamdokumentasjon, skjuling av innlegg for ny godkjenning hos en klient før republisering.
Trinn 3. Fremtidig dato: utsatt avpublisering
Et interessant triks: i stedet for å endre statusen, kan du «sende et innlegg inn i fremtiden», sette publiseringsdatoen til år 2050. Innlegget forsvinner umiddelbart fra søkeresultatene fordi WordPress kun viser innlegg med en dato ≤ nåværende tidspunkt.
Denne metoden endrer ikke post_status: innlegget forblir publish. Det har bare «ikke skjedd ennå» fra WordPress sitt perspektiv. Et pluss: om nødvendig kan du gjenopprette den virkelige datoen, og innlegget vil dukke opp igjen.
Koden bruker feltene post_date og post_date_gmt:
1 /** 2 * Hides a post by setting its publication date far into the future. 3 * 4 * @param int $post_id Post ID. 5 */ 6 function sd_unpublish_to_future( $post_id ) { 7 $future_date = '2050-12-31 23:59:59'; 8 9 wp_update_post( array( 10 'ID' => $post_id, 11 'post_date' => $future_date, 12 'post_date_gmt' => get_gmt_from_date( $future_date ), 13 ) ); 14 } 15 16 // Example call 17 sd_unpublish_to_future( 42 );
get_gmt_from_date() konverterer lokal tid til GMT, WordPress lagrer begge versjonene av datoen. Ikke forsøm GMT-feltet: uten det blir oppførselen uforutsigbar når nettstedets tidssone endres.
Når du bør bruke dette: «planlagt» innholdspublisering, midlertidig skjuling av nyheter uten å endre status, scenarioer der post_status må forbli publish for bakoverkompatibilitet med andre pluginer.
Trinn 4. Sletting: når innlegget ikke trengs i det hele tatt
wp_delete_post() er en irreversibel operasjon. Innlegget slettes fra databasen, sammen med alle dets metafelter, taksonomirelasjoner og (valgfritt) vedlegg.
Dette er ikke «avpublisering» i streng forstand. Men i kontekst av programmatisk innholdsadministrasjon er sletting det fjerde, mest drastiske verktøyet. Og det krever sikkerhetstiltak.
Før du kjører, ta en fullstendig databasesikkerhetskopi. Skriptet nedenfor gir først ut en liste over hva som vil bli slettet, og først deretter produksjonsversjonen.
1 /** 2 * Deletes a post. First — dry-run with info output, then — actual deletion. 3 * 4 * WARNING: irreversible operation. Backup before running. 5 * 6 * @param int $post_id Post ID. 7 * @param bool $force_delete true — delete permanently (skip trash), false — move to trash. 8 */ 9 function sd_delete_post_safe( $post_id, $force_delete = false ) { 10 $post = get_post( $post_id ); 11 12 if ( ! $post ) { 13 error_log( "Post with ID {$post_id} not found." ); 14 return; 15 } 16 17 // Dry-run: output info without deleting 18 error_log( sprintf( 19 'READY TO DELETE: ID=%d, title="%s", status=%s, attachments=%d', 20 $post->ID, 21 $post->post_title, 22 $post->post_status, 23 count( get_attached_media( '', $post_id ) ) 24 ) ); 25 26 // Uncomment the following line for actual deletion: 27 // wp_delete_post( $post_id, $force_delete ); 28 } 29 30 // Dry-run: only outputs info 31 sd_delete_post_safe( 12341, false );
Flagget $force_delete:
false, innlegget går til Papirkurven, det kan gjenopprettes innen 30 dager.true, permanent sletting, kan ikke gjenopprettes selv via databasen (uten en sikkerhetskopi).
Funksjonen logger via error_log(), meldinger vil vises i wp-content/debug.log når WP_DEBUG er aktivert. I produksjon, erstatt den med din egen varslingsmekanisme.
Når du bør bruke dette: automatisk opprydding av spam-innlegg, sletting av utløpt innhold (stillingsannonser, arrangementer), programmatisk innholdsrotasjon med full fjerning av gamle oppføringer.
Sammenligning av de fire metodene
Metode | Innleggsstatus | Reversibilitet | Synlighet for lesere | Synlighet i admin | Når du bør bruke |
|---|---|---|---|---|---|
Utkast |
| Full | Skjult | Alle roller med innleggstilgang | Midlertidig skjuling, revisjon |
Privat |
| Full | Skjult | Admin og redaktører | Internt innhold, premium |
Fremtidig dato |
| Full | Skjult til datoen | Alle | Planlagt publisering, tidsplan |
Sletting | - | Kun fra papirkurven (30 dager) | - | Kun admin | Full sletting, opprydding |
⁉️🤔 Ofte stilte spørsmål
Hva er forskjellen mellom avpublisering og sletting?
Avpublisering (utkast/privat/fremtidig) beholder innlegget i databasen: innhold, URL, vedlegg og SEO-historikk forblir. Sletting (
wp_delete_post) sletter posten fullstendig. For midlertidig skjuling, bruk alltid et utkast, det er trygt og reversibelt på et sekund.
Hvilken metode krever ikke endring av post_status?
Å sende inn i fremtiden via
post_date. Innlegget forblirpublish, men WordPress anser det som «ikke skjedd ennå» og viser det ikke til besøkende. Dette kan være viktig hvis andre pluginer eller kodebiter avhenger avpublish-statusen.
Kan jeg avpublisere flere innlegg samtidig?
Ja, pakk funksjonskallet inn i en løkke over en rekke med ID-er. Legg til
wp_die()eller en grense for antall innlegg per kjøring for å unngå å krasje nettstedet under en masseoperasjon:array_slice($post_ids, 0, 50)for en batch på 50.
Må jeg tømme hurtigbufferen etter en programmatisk statusendring?
Absolutt. WordPress tømmer den interne innleggsbufferen når
wp_update_post()kalles, men ekstern buffer (pluginer som WP Rocket, serverbuffer, CDN) må tømmes separat. Legg til etwp_cache_flush()-kall ellerclean_post_cache-hooken etter statusendringen.
Er det trygt å kjøre wp_delete_post i produksjon?
Kun med sikkerhetstiltak. Før du kaller: (1) sjekk
current_user_can('delete_posts'), (2) be om bekreftelse via et separat nonce-token, (3) logg ID-en og tittelen på innlegget som slettes. Og viktigst av alt, en sikkerhetskopi. Selv i papirkurven lever et innlegg i 30 dager, hvoretter WordPress sletter det automatisk.
Hva du bør bruke i ditt tilfelle: konklusjonen
De fire metodene dekker nesten ethvert scenario for programmatisk publiseringsadministrasjon. Valget koker ned til ett spørsmål: trenger du å beholde innlegget?
- Hvis du trenger å midlertidig skjule et innlegg for revisjon, gå for et utkast (
draft). Et par linjer, null risiko. - Hvis innholdet er for en begrenset krets av personer, privat status (
private). Redaktører ser det, besøkende ikke. - Hvis du trenger å skjule et innlegg uten å endre statusen, en fremtidig dato (
post_datesatt til 2050). Et smart, men fungerende triks. - Hvis innlegget definitivt ikke trengs, sletting (
wp_delete_post). Men først, en tørrkjøring og en full sikkerhetskopi.
Start med en innpakning i functions.php for én metode, for eksempel et utkast. Når du forstår logikken til wp_update_post(), vil de tre andre metodene falle på plass på fem minutter.
Og hvilken metode bruker du for programmatisk innleggsadministrasjon? Skriv i kommentarene, det er interessant å sammenligne tilnærminger.



