WPPoland er Mariusz Szatkowski, seniorutvikler i WordPress siden 2006. Jeg tar saken en vanlig utvikler ikke får lukket: siden er nede etter en oppdatering, den er hacket, den er treg, eller WooCommerce-kassen feiler når trafikken øker. Nye nettsider står på utviklersiden. Her handler det om å finne årsaken og rette den.
Jeg jobber alene fra Gdynia i Polen, uten team og uten underleverandører. Koden du får, har jeg skrevet selv, og tilgangene dine deler jeg ikke med noen. Trenger du heller en frilanser til løpende utvikling, se WordPress freelancer.
Når trenger du en WordPress-spesialist?
- Siden gir kritisk feil etter en oppdatering av tema, utvidelse eller PHP.
- Siden er hacket, sender spam eller videresender besøkende til fremmede domener.
- LCP og INP er røde i Search Console, og ingen vet hvorfor.
- WooCommerce-kassen henger eller mister ordre når trafikken går opp.
- Du har arvet en installasjon ingen dokumenterte, og hver endring føles risikabel.
Forskjellen på spesialist og generalist
Forskjellen vises i feil som ikke har et ferdig svar på Stack Overflow. Tre typer jeg ofte finner i gjennomganger:
- Åpne REST-endepunkter. Et headless-oppsett med egne endepunkter for kladder bruker
permission_callback => '__return_true'fordi noen mente at nginx tok seg av tilgangen. Da kan hvem som helst hente upubliserte kladder. Riktig løsning erpermission_callbackbundet tilcurrent_user_can('edit_post', $request['id']), etargs-skjema medvalidate_callbackogsanitize_callbackper parameter, og rate limiting når endepunktet er åpent for anonym trafikk. - Callback fra betalingsleverandøren uten signaturkontroll. En utvidelse sjekker bare at forespørselen kommer fra en kjent IP-blokk. Signaturen må beregnes på nytt fra rå body i
php://input, ikke fra$_POST, og alt som ikke stemmer, avvises. - Feil valuta i kassen. En butikk som selger i NOK, EUR og SEK viser kassen i feil valuta fordi handlekurven er lagret i sesjonen før valutafilteret kjører. Løsningen er å regne prisen på nytt i
woocommerce_get_cart_item_from_sessionfør totalen bygges.
Hva jeg gjør som WordPress-spesialist
Retting etter utfall
Jeg leser feilloggen, finner endringen som utløste feilen, ruller den tilbake på en kontrollert måte og retter årsaken. Hver retting testes på staging før den går til produksjon.
Egne REST-endepunkter og integrasjoner
Endepunkter med ekte tilgangskontroll, validering per parameter og versjonert namespace fra første dag (merke/v1), slik at neste endring i API-et ikke krever en koordinert mobilrelease. Integrasjoner mot regnskap, lager og CRM bygges med logging, slik at du ser hvor en ordre stoppet.
Egne Gutenberg-blokker
Blokker med InnerBlocks, allowedBlocks og templateLock, registrert i block.json, slik at redaksjonen får faste maler og en forhåndsvisning i editoren som stemmer med forsiden. Layout og grafisk design leverer du; jeg gjør dem om til blokker og tema.
WooCommerce under last
Kassen, katalogen og filtrene er stedene der en butikk stopper opp. Jeg ser på hvilke kall som må skje synkront i kassen og hvilke som kan legges i kø, og rydder i spørringene bak filtrene. Mer om butikker på siden for WooCommerce-utvikler.
Hvordan rydde opp i et hacket WordPress-nettsted
Gjenoppretting starter som etterforskning. Først leser jeg tilgangsloggen for å finne inngangen, så sammenligner jeg filene mot rene versjoner av kjernen, det aktive temaet og de installerte versjonene av utvidelsene. Reinfeksjon skjer som regel fordi noen gjenoppretter fra en sikkerhetskopi som allerede var infisert, eller fordi bakdøren ligger i wp_options som base64 med autoload og ikke i en fil. Derfor skanner jeg options-tabellen med wp-cli i hvert oppdrag. Hele forløpet står på siden om fjerning av skadevare i WordPress.
Etterpå kommer herdingen: filredigering i admin skrus av, xmlrpc.php begrenses på webservernivå, oppslag av brukere via REST blokkeres, og alle API-nøkler og databasepassord byttes. Ingen kan love at en side aldri blir hacket igjen. Det jeg kan gjøre, er å fjerne de kjente inngangene og sette opp overvåking som varsler tidlig.
Hvor WordPress faktisk blir treg
Generelle råd som lazy loading, HTTP/2 og CDN gjelder alle nettsider. Det WordPress-spesifikke ligger andre steder:
- Autoload i
wp_options. Rester etter deaktiverte utvidelser og serialiserte cron-lister lastes ved hver forespørsel. Jeg måler størrelsen og fjerner det som ikke hører hjemme der. get_post_meta($post_id)uten nøkkel i temaets løkker, som henter alle metafelt for hvert innlegg.meta_querymed tekstsammenligning der en taksonomi medtax_querypasser bedre.posts_per_page => -1i sidekolonner, som tømmer PHP-minnet når innholdet vokser.
Object cache med Redis hører hjemme etter at datalaget er ryddet. Jeg måler Core Web Vitals på ekte besøkende via CrUX, ikke på én enkelt Lighthouse-kjøring.
Multisite, roller og tilganger
Multisite deler wp_users og wp_usermeta mellom alle nettstedene, lagrer roller per nettsted i wp_X_capabilities og skiller mellom superadministrator og vanlig administrator. Hvordan current_user_can svarer, avhenger av hvilket nettsted som er aktivt. En overgang til multisite trenger derfor en skriftlig plan: hvem eier hva, hvordan nye nettsteder opprettes, og hvilke utvidelser som aktiveres for hele nettverket.
Har du arvet en installasjon ingen skrev ned, starter jeg med et skriftlig kart over roller, nettsteder og avhengigheter, slik at neste beslutning tas på kjent grunn.
Slik jobber jeg
- Skriftlig. Kommunikasjon går på e-post, i dokumenter og i repositoriet. Trenger du en samtale, sier du fra.
- Staging først. Endringer testes på staging, og du godkjenner dem der før de går til produksjon.
- Personvern. Før jeg får tilgang til en side med personopplysninger, signerer vi en databehandleravtale etter GDPR artikkel 28. Jeg bruker ingen underdatabehandlere.
- Vedlikehold. Vedlikeholdet omfatter oppetidsovervåking hvert 1. til 5. minutt, sikkerhetskopier i minst 30 dager i EU-land og oppdateringer testet på staging. Døgnvakt, garantert responstid og SLA tilbyr jeg ikke.
- Avtale og faktura. B2B-avtale etter polsk rett og faktura med EU-mva-nummer PL7393037445.
Neste steg
Er butikken nede eller kassen feiler, start med WooCommerce rescue sprint. Etter innbrudd eller skadevare: sikkerhetsrevisjon for WordPress. For løpende drift etter stabilisering: Store Reliability Plan. Du kan også sende en kort skriftlig beskrivelse av problemet.
