M 404 Handler

Diegimas ir aktyvavimas

M 404 Handler diegiamas kaip bet kuris kitas WordPress įskiepis. Reikia WordPress 6.0 ir PHP 7.4 arba naujesnės versijos. Jokios paskyros, jokio licencijos rakto, jokios išorinės paslaugos. Aktyvavus sukuriamos duomenų bazės lentelės ir įrašomi numatytieji nustatymai, bet lankytojams matomo elgesio tai nekeičia.

1. Įkelkite įskiepio aplanką į /wp-content/plugins/ arba įdiekite ZIP failą per Įskiepiai > Pridėti naują > Įkelti įskiepį.
2. Aktyvuokite jį Įskiepių ekrane. Multisite tinkle aktyvavus visam tinklui lentelės sukuriamos visose esamose svetainėse, o vėliau sukurtos svetainės jas gauna automatiškai. Tas ciklas vyksta vienoje aktyvavimo užklausoje ir svetainių skaičiaus neriboja, tad dideliame tinkle jis gali nutrūkti pusiaukelėje; nepasiektos svetainės lenteles susikuria pačios per artimiausią puslapio įkėlimą, o iki tol jų taisyklės neveikia.
3. Atidarykite naują 404 Handler meniu administravimo šoninėje juostoje. Įskiepių ekrane prie įskiepio eilutės taip pat atsiranda dvi nuorodos: Redirects ir Settings.

• Sukuriamos dvi lentelės: wp_m404_redirects ir wp_m404_404_log, vietoj wp_ naudojant jūsų lentelių priešdėlį.
• Sukuriama automatiškai įkeliama parinktis m404_settings su numatytosiomis reikšmėmis, šalia jos m404_rule_counts su trimis nuliais ir m404_db_version.
• Suplanuojamas kasdienis cron įvykis m404_cleanup, pirmą kartą įvykdomas praėjus valandai po aktyvavimo. Jis po 1000 eilučių ištrina tuos žurnalo įrašus, kurie per saugojimo laikotarpį nė karto nebuvo paliesti. Jei įvykis kada nors dingtų, įskiepis jį suplanuoja iš naujo per artimiausią puslapio įkėlimą.
• 404 žurnalas įjungtas, saugojimo laikotarpis 30 dienų, IP anonimizavimas įjungtas.
• Automatinis 404 apdorojimas išjungtas. Numatytasis režimas yra įprastas temos 404 puslapis, tad įskiepis su 404 klaida nieko nedaro, tik ją užrašo.
• Peradresavimo taisyklių dar nėra, tad lankytojo pusėje į duomenų bazę visai nesikreipiama.

Kur rasti įskiepio ekranus

Įskiepis prideda vieną pagrindinio lygio meniu punktą 404 Handler, esantį 80-oje pozicijoje administravimo šoninėje juostoje. Visiems jo ekranams reikia manage_options teisės, tad juos gali atidaryti tik administratoriai. Redaktoriai, autoriai ir parduotuvės valdytojai meniu apskritai nematys. Sąsaja pateikiama anglų kalba, tad jei vertimas neįdiegtas, lietuviškoje svetainėje ekrane matysite būtent šiuos pavadinimus.

• 404 Handler, tada Redirects: taisyklių sąrašas su mygtuku Add New. Adresas: admin.php?page=m404-redirects
• 404 Handler, tada 404 Log: sugrupuotas neveikiančių nuorodų sąrašas. Adresas: admin.php?page=m404-logs
• 404 Handler, tada Settings: visos nustatymų grupės po antrašte 404 Handler Settings. Adresas: admin.php?page=m404-settings
• Abiejuose sąrašo ekranuose Screen Options siūlo Redirects per page ir Log entries per page. Numatyta 20, leidžiama nuo 1 iki 500, reikšmė saugoma kiekvienam naudotojui atskirai.

Redirects ekranas ir peradresavimo forma

Redirects yra pagrindinis įskiepio ekranas. Mygtukas Add New atveria penkių laukų formą, o šeštoji eilutė atsiranda tada, kai į formą ateinate iš 404 Log per Create redirect. Kiekviena sukurta taisyklė patenka į įprastą WordPress lentelę su paieška, filtrais, rikiuojamais stulpeliais ir masiniais veiksmais. Tikslas gali būti svetainės vidinis kelias, prasidedantis pasviruoju brūkšniu, arba pilnas http ar https adresas. //host formos tikslai, kuriuose nėra protokolo, išsaugant atmetami, kaip ir bet kokia kita schema, pavyzdžiui javascript. Exact tipo taisyklė, kurios tikslas sutampa su jos pačios šaltiniu, apskritai neįrašoma. Šis patikrinimas apima tik Exact taisykles, ir tai svarbiau, nei atrodo: žiūrėkite skyrių apie pavojingus veiksmus.

• Source, privalomas. Exact ir Prefix atveju tai svetainės vidinis kelias, pavyzdžiui /senas-puslapis/. Reguliariajai išraiškai tai šablonas be skirtukų, pavyzdžiui ^/old-blog/([0-9]+)/(.+)$
• Match type: Exact match (numatytasis), Prefix match arba Regular expression.
• Target, privalomas. Kelias, pavyzdžiui /naujas-puslapis/, arba pilnas adresas, pavyzdžiui https://example.com/naujas-puslapis/.
• Redirect type: 301, 302, 303, 307 arba 308. Forma atsidaro su 301, ir prie 301 įskiepis grįžta ir tada, kai atsiųstas kodas nėra vienas iš šių penkių.
• Status: žymimasis langelis Enabled, naujoje taisyklėje pažymėtas iš karto. Peradresavimas pradeda veikti tą pačią akimirką, kai išsaugote.
• Šeštoji eilutė, tik atėjus iš žurnalo: žymimasis langelis, siūlantis sukūrus peradresavimą pašalinti tą adresą iš 404 žurnalo. Jis pažymėtas iš karto.
• Lentelės stulpeliai: Source, Target, Match, Code, Hits, Last hit, Status, Created. Rikiuoti galima pagal Source, Code, Hits, Last hit ir Created.
• Filtrai virš lentelės: būsena, peradresavimo kodas ir atitikties tipas, o šalia paieškos laukas, aprėpiantis ir šaltinį, ir tikslą.
• Masiniai veiksmai: Enable, Disable, Reset hit counters, Delete. Eilutės veiksmai: Edit, Enable arba Disable, Reset hits, Delete.

Kaip veikia atitiktis ir ką ji iš tikrųjų apima

Atitikties tikrinimas vyksta per parse_request su 1 prioritetu, dar prieš WordPress pagrindinę užklausą. Jis praleidžiamas administravimo ekranuose, admin-ajax.php užklausose, WP-Cron metu ir dirbant su WP-CLI. REST API užklausų jis nepraleidžia. Įskiepis tikrina REST_REQUEST konstantą, bet ją apibrėžia paties WordPress parse_request funkcija, veikianti 10 prioritetu, tad ties 1 prioritetu tos konstantos dar nėra. Todėl pro atitikties tikrinimą praeina viskas, ką WordPress pateikia per savo bendrą įėjimo tašką: /wp-json/ keliai, /?rest_route= užklausos, /robots.txt, /wp-sitemap.xml, RSS srautai ir paieškos adresai. Jei tam tikro tipo įjungtų taisyklių nėra, visas tas tipas apskritai praleidžiamas ir nieko nekainuoja.

• Pirmiausia tikrinamos Exact taisyklės, jos randamos per maišos indeksą viena užklausa. Paskui šaltinis dar kartą palyginamas PHP kode, tad dėl maišos sutapimo negali suveikti ne ta taisyklė.
• Toliau Prefix taisyklės, pradedant ilgiausiu šaltiniu. Tai paprastas teksto sutapimo tikrinimas nuo kelio pradžios. Kelio segmentai nevertinami.
• Jei prefikso tikslas baigiasi pasviruoju brūkšniu, likusi adreso dalis prikabinama: šaltinis /old-blog/ su tikslu /blog/ paverčia /old-blog/hello į /blog/hello.
• Galiausiai reguliariosios išraiškos, pradedant seniausia taisykle. Šablonas saugomas be skirtukų ir lyginamas su keliu, o tiksle esantys $1, $2 ir taip toliau pakeičiami sugautomis grupėmis. Ilgiausias leidžiamas šablonas yra 500 simbolių.
• Laimi pirmoji taisyklė, davusi tinkamą tikslą, ir užklausa ties ja sustoja.
• Atitiktis visada tikrinama tik pagal kelią. Užklausos eilutę tvarko atskiras Query strings nustatymas.
• Šablonas, kuris veikimo metu nesuveikia, tyliai praleidžiamas. Sugadinta reguliarioji išraiška svetainės nesugriaus, ji tiesiog niekada neatitiks.
• Tik Exact atitiktis yra viena indeksuota užklausa. Prefix ir reguliariųjų išraiškų taisyklės per kiekvieną lankytojo užklausą ištraukiamos iš duomenų bazės visos ir lyginamos PHP kode, tad didelis reguliariųjų išraiškų rinkinys kainuoja.

Nustatymai: Redirect matching

Pirmasis 404 Handler Settings skyrius nurodo, kaip ateinantys adresai lyginami su jūsų taisyklėmis. Visi trys nustatymai yra bendri: jie iškart galioja visoms taisyklėms. Du paskutiniai dar lemia, kaip apskaičiuojamas kiekvienos Exact taisyklės paieškos raktas, ir kaip tik dėl to jų šiame ekrane pakeisti apskritai neįmanoma. Prieš liesdami bet kurį iš jų perskaitykite kitą skyrių.

• Query strings, žymimas kaip "Pass the original query string on to the redirect target". Numatyta įjungta. /senas-puslapis?utm_source=x nukeliauja į /naujas-puslapis?utm_source=x. Jei tikslas jau turi tą patį parametrą, laimi paties tikslo reikšmė.
• Case sensitivity, žymimas kaip "Match URLs case-insensitively". Numatyta išjungta. Kai įjungta, keliai prieš lyginimą paverčiami mažosiomis raidėmis, o kiekviena reguliarioji išraiška papildomai gauna i vėliavėlę.
• Trailing slashes, žymimas kaip "Ignore trailing slashes when matching". Numatyta įjungta, tad /kontaktai ir /kontaktai/ laikomi tuo pačiu adresu. Kartu nuo įrašytų prefikso šaltinių nuimamas galinis pasvirasis brūkšnys, o kuo tai baigiasi, aprašyta skyriuje apie pavojingus veiksmus.

Du nustatymai, kurių per Settings ekraną išsaugoti negalima

Case sensitivity ir Trailing slashes yra vieninteliai nustatymai, kurių pakeitimas išsaugant paleidžia papildomą veiksmą: įskiepis perskaičiuoja kiekvienos Exact taisyklės paieškos raktą. Šis kelias niekada nebaigiamas. Tvarkymo funkcija pati iškviečia update_option(), o update_option() per sanitize_option_m404_settings filtrą, kurį prie jos prikabino register_setting(), iš naujo paleidžia tą pačią tvarkymo funkciją. Įskiepio nustatymų talpykloje tebeguli senoji reikšmė, tad sąlyga suveikia vėl ir vėl be pabaigos. Užklausa nutrūksta su kritine PHP klaida options.php puslapyje.

• Požymis yra baltas ekranas arba HTTP 500 klaida paspaudus Save Changes 404 Handler Settings ekrane, ir tik tada, kai iš tikrųjų pakeitėte vieną iš tų dviejų žymimųjų langelių.
• Niekas nesugadinama. Įrašymas duomenų bazės nepasiekia, tad nustatymas lieka su ankstesne reikšme, kiti to puslapio nustatymai nepaliesti, o lankytojo pusė veikia lygiai kaip veikusi. Rekursija telpa vienoje options.php užklausoje.
• Visi kiti šio ekrano nustatymai išsaugomi įprastai, jei tik tų dviejų žymimųjų langelių nejudinate.
• Komandinės eilutės kelias veikia todėl, kad register_setting() paleidžiama tik per admin_init. Dirbant su WP-CLI rekursyvusis filtras net neprikabinamas, tad įrašymas įvyksta.
• Pakeitę bet kurią iš šių reikšmių, Exact maišos reikšmes turite perskaičiuoti patys. Daugiau to nedaro niekas: įskiepis taisyklės raktą perskaičiuoja tik tada, kai ta taisyklė išsaugoma per administravimo sritį.
• Prefix ir reguliariųjų išraiškų taisyklėms tai neturi įtakos. Jos kelią normalizuoja atitikties metu ir jokios maišos reikšmės nesaugo.

# Change either setting from the shell, never from the Settings screen.
wp option patch update m404_settings case_insensitive 1
wp option patch update m404_settings ignore_trailing_slash 0

# Mandatory second step: recompute the lookup key of every Exact rule.
# Requires the plugin to be active, so the class is loaded.
wp eval '(new M404_Redirect_Repository())->rehash_all();'

# No WP-CLI? Open and re-save every Exact rule under
# 404 Handler > Redirects. Saving a rule recomputes its own key.

Nustatymai: 404 handling

Šis skyrius sprendžia, kas nutinka lankytojui, patekusiam į neegzistuojantį adresą, kuris neatitinka nė vienos taisyklės. Jis veikia per template_redirect su 20 prioritetu, kai WordPress branduolio kanoninis ir seno slug peradresavimai jau turėjo progą adresą išgelbėti, tad čia atkeliauja tik tikros 404 klaidos.

• "When a 404 happens" siūlo tris variantus. Numatytasis yra "Show the theme's normal 404 page (do nothing)", tai yra įskiepis nedaro nieko. Antrasis yra "Automatically redirect to a page or URL of your choice". Trečiasis yra tas, kurio pavadinimas prasideda "Show a custom 404 page": jis pateikia tikrą puslapį ir išlaiko 404 statusą, o ekrane prie to pavadinimo dar prirašyta pastaba apie SEO.
• "Redirect target" sujungia puslapių sąrašą ir laisvo teksto lauką. Numatyta: puslapis nepasirinktas, adresas tuščias. Pasirinktas puslapis nusveria adresą, ir tas puslapis turi būti publikuotas, kitaip naudojamas adresas. Jei tušti abu, lankytojai keliauja į pradžios puslapį. Adresas turi būti vidinis, prasidedantis pasviruoju brūkšniu, arba pilnas http ar https adresas; visa kita išsaugant atmetama.
• "Redirect status code" numatytoji reikšmė yra 302, ir automatiniam 404 peradresavimui tai teisingas atsakymas.
• "Custom 404 page" numatytai nepasirinktas. Tai turi būti publikuotas puslapis, ne įrašas. Puslapis pateikiamas su tikra 404 antrašte ir nekešavimo antraštėmis, tad paieškos sistemos jo neindeksuos. Jei pasirinktas puslapis pašalintas, išmestas į šiukšlinę arba tebėra juodraštis, tyliai perima temos 404 šablonas.
• "Did you mean" pasiūlymai, numatytai įjungti. Iki penkių publikuotų įrašų ar puslapių, kurių slug panašus į trūkstamą. Įskiepis lygina pagal pirmus tris slug simbolius, peržiūri ne daugiau kaip 50 kandidatų ir palieka tik bent 40 procentų panašius. Trumpesnis nei trijų simbolių slug nieko neduoda.
• Pasiūlymai rodomi tik „Show a custom 404 page“ režimu ir visada prikabinami puslapio turinio gale. Trumpasis kodas [m404_suggestions] jų neperkelia: jis prideda antrą sąrašo kopiją ten, kur jį įdėjote. Įskiepis filtruoja the_content 20 prioritetu, o WordPress trumpuosius kodus išskleidžia jau 11 prioritetu, todėl įskiepio patikra trumpojo kodo nebesuranda. Trumpąjį kodą naudokite tik tada, jei sąrašo norite du kartus.
• Nekešavimo antraštės siunčiamos tik "Show a custom 404 page" režimu. Numatytuoju režimu ir automatinio peradresavimo režimu įskiepis jokių savo kešavimo antraščių neprideda, kad ir ką sakytų readme failas.

[m404_suggestions]

Nustatymai: 404 logging

Žurnale saugoma po vieną eilutę kiekvienam unikaliam adresui, tai yra keliui su užklausos eilute, kartu su suveikimų skaitikliu, tad tą patį trūkstamą failą daužantis botas lentelės neišpūs. Įsidėmėkite: ignoravimo šablonai slopina tik įrašymą į žurnalą. Ignoruojamas adresas vis tiek bus peradresuotas automatinio režimo ir vis tiek gaus savo 404 puslapį. Įsidėmėkite ir tai, kad šablonai lyginami tik su keliu, o į žurnalą patenka kelias kartu su užklausos eilute.

• Logging, žymimas kaip "Log 404 errors". Numatyta įjungta.
• Retention. Numatyta 30 dienų, leidžiama nuo 0 iki 3650. Per tą laiką nė karto nepaliestos eilutės kartą per parą po 1000 ištrinamos cron įvykio m404_cleanup. Įrašius 0 žurnalas saugomas amžinai.
• Privacy, žymimas kaip "Anonymize visitor IP addresses before storing them". Numatyta įjungta. Skaitomas tik REMOTE_ADDR; persiuntimo antraštės sąmoningai ignoruojamos, nes jas galima suklastoti.
• Ignore patterns, teksto laukas po vieną šabloną eilutėje. Žvaigždutė atitinka bet kokią simbolių seką, o didžiosios ir mažosios raidės nesvarbios. Šablonas, prasidedantis pasviruoju brūkšniu ar žvaigždute, lyginamas su visu keliu; šablonas, prasidedantis nė vienu iš jų, atitinka kelio pabaigą.
• Numatytajame sąraše yra dvidešimt šablonų: *.php, *.asp, *.aspx, *.env*, *.git*, *.map, *.axd, /wp-content/*, /wp-includes/*, *.jpg, *.jpeg, *.png, *.gif, *.webp, *.svg, *.ico, *.css, *.js, *.woff*, *.ttf
• Kiekvienoje žurnalo eilutėje saugoma: adresas, suveikimų skaičius, paskutinis referrer, paskutinis user agent, paskutinis IP adresas ir pirmojo bei paskutinio karto laikai. Adresas ir referrer trumpinami iki 2000 simbolių, user agent iki 255, IP iki 45.

Pirmasis paleidimas: ką nustatyti ir kokia tvarka

Numatytieji nustatymai jau yra tinkamas atspirties taškas, tad nesiimkite konfigūruoti visko pirmą dieną. Pirmiausia apsispręskite dėl dviejų normalizavimo nustatymų, nes tik juos vėliau keisti skaudu. Tada sukelkite žinomus peradresavimus, leiskite žurnalui parodyti, kas iš tikrųjų neveikia, ir tik tada spręskite, ką daryti su likusiomis 404 klaidomis.

1. Iškart apsispręskite, ar norite nejautrios raidžių dydžiui atitikties ir ar galiniai pasvirieji brūkšniai turi būti ignoruojami. Numatyta atitinkamai išjungta ir įjungta. Jei norite kitaip, nustatykite tai per komandinę eilutę, kaip aprašyta anksčiau, dar neturėdami nė vienos taisyklės.
2. Likusių Settings nelieskite. Žurnalas įjungtas, saugojimo laikotarpis 30 dienų, IP anonimizavimas įjungtas, automatiškai niekas neperadresuojama. Pirmą dieną kaip tik to ir reikia.
3. Suveskite žinomus peradresavimus per Redirects, Add New. Pavieniams adresams naudokite Exact match. Kiekvieną taisyklę pirma sukurkite su 302, patikrinkite inkognito lange ir tik tada pataisykite į 301, jei perkėlimas yra visam laikui.
4. Ištisiems perkeltiems skyriams naudokite Prefix match. Jei norite, kad likusi adreso dalis būtų perkelta, pasvirąjį brūkšnį rašykite ir šaltinio, ir tikslo gale, o pats šaltinis neturi būti ir kito veikiančio adreso pradžia.
5. Reguliariąsias išraiškas palikite pabaigai ir imkitės jų tik ten, kur prefikso taisyklė iš tikrųjų nepadeda.
6. Po kiekvienos prefikso ar reguliariosios išraiškos taisyklės atlikite tris patikras: atidarykite bet kurį įrašą blokų redaktoriuje ir išsaugokite, atsiverskite /robots.txt, atsiverskite /wp-sitemap.xml. Visi trys turi elgtis įprastai.
7. Leiskite žurnalui prisipildyti savaitę ar dvi. Tada 404 Log surikiuokite pagal Hits ir sutvarkykite viršutinius įrašus eilutės veiksmu Create redirect, kuris formą užpildo trūkstamu keliu.
8. Pridėkite ignoravimo šablonų tam triukšmui, kuris išgyveno numatytąjį sąrašą, kad žurnalas liktų skaitomas.
9. Ir tik dabar rinkitės 404 režimą. Saugus variantas yra "Show a custom 404 page", nes jis išlaiko 404 statusą. Automatinį peradresavimą rinkitės tik tada, jei sutinkate, kad jis paslėps visas neveikiančias nuorodas ir nuo paieškos robotų, ir nuo jūsų pačių ataskaitų.

Pavojingi veiksmai: kas gali paguldyti svetainę

Šis įskiepis stovi priešais kiekvieną lankytojo užklausą. Būtent dėl to jis naudingas ir būtent dėl to neapgalvota taisyklė brangiai kainuoja. Perskaitykite šį sąrašą prieš kurdami pirmąją prefikso ar reguliariosios išraiškos taisyklę ir prieš perjungdami 404 režimą į automatinį peradresavimą.

• Prefikso taisyklė, kurios šaltinis yra vienas pasvirasis brūkšnys, atitiks kiekvieną svetainės adresą ir išsiųs visą lankytojo pusę kitur. Įrašymo metu veikiantis savęs peradresavimo patikrinimas apima tik Exact taisykles, tad niekas jūsų nesustabdys.
• Reguliarioji išraiška, tokia kaip ^/(.*)$, padaro tą patį. Šablonai tikrinami tik dėl to, ar susikompiliuoja, o niekada dėl to, kokią svetainės dalį apima.
• Bet kuri taisyklė, kurios šaltinis yra egzistuojantis adresas, tą adresą paslepia, nes taisyklės tikrinamos anksčiau, nei WordPress nusprendžia, kas egzistuoja.
• Plati taisyklė pagauna ir /wp-json/ kelius. O taisyklė, kurios šaltinis yra vienas pasvirasis brūkšnys, pagauna ir /?rest_route= užklausas, nes jų kelias po normalizavimo ir yra vien tas brūkšnys. Pats wp-admin atrodo visiškai tvarkingai, bet blokų redaktorius nebeįkelia ir neišsaugo įrašo, o Site Health nebeveikia. Klaidų pranešimuose apie peradresavimus nėra nė žodžio.
• Plati taisyklė pagauna ir /robots.txt, ir /wp-sitemap.xml, ir jūsų RSS srautus. Peradresavus juos svetainė tyliai iškrenta iš indekso, ir, skirtingai nei sugedusio puslapio, to niekas nepastebi savaitėmis.
• Prefikso atitiktis yra paprastas simbolių palyginimas, o kai "Ignore trailing slashes" įjungtas, įrašytas šaltinis /old-blog/ normalizuojamas į /old-blog. Todėl ta pati taisyklė pagauna ir /old-blogger, ir /old-blog-archive, o su pasviruoju brūkšniu pasibaigiančiu tikslu /old-blogging virsta į /blog/ging. Veikiantys puslapiai dingsta, o tikslas išeina beprasmis.
• Peradresavimo kilpos. Veikimo metu esantis saugiklis atmeta tik tokį tikslą, kurio normalizuotas kelias sutampa su esamu keliu, tad grandinės jis nepagauna. Prefikso taisyklė su šaltiniu /shop ir tikslu /shop/new/ vėl atitinka savo pačios rezultatą ir be pabaigos gamina /shop/new/new/new/. Tą patį padaro ir prie kelio pradžios nepririšta reguliarioji išraiška: šablonas blog su tikslu blog-new iš /blog padaro /blog-new, o tas pats šablonas jį vis dar atitinka. Dvi viena į kitą rodančios taisyklės lankytojui duoda ERR_TOO_MANY_REDIRECTS.
• Bet kurio 301 nebeatšauksite, kai jis jau įsimintas. Tai vienodai galioja ir su 301 išsaugotai peradresavimo taisyklei, ir 301 kodu nustatytam automatiniam 404 režimui. Naršyklės, tarpiniai serveriai ir CDN jo laikosi dar ilgai po to, kai taisyklę sutvarkote. Taisyklės forma atsidaro būtent su 301, tad šią klaidą padaryti lengviausia.
• Pats automatinio peradresavimo pasirinkimas padaro visas neveikiančias nuorodas nematomas paieškos robotams, nes jie vietoj 404 mato veikiantį puslapį. Žurnalas jas vis tiek įrašo, o jūsų SEO įrankiai – ne.
• Įjungus prefikso ar reguliariosios išraiškos taisyklę, kurios tikslas rodo į išorinį serverį, tas serveris pridedamas prie WordPress leidžiamų peradresavimo serverių visoje svetainėje tol, kol taisyklė lieka įjungta. Nuo tada kiekvienas wp_safe_redirect kvietimas bet kurioje svetainės vietoje tą serverį priims. Exact taisyklės to nedaro.

Skubus atstatymas: viskas peradresuojama arba redaktorius nustojo išsaugoti

Sąžinesnis pažado variantas yra siauresnis, nei "prieigos prie wp-admin neprarasite". Nei wp-admin, nei wp-login.php puslapių įkėlimas atitikties tikrinimo nepaleidžia, nes nė vienas iš jų neiškviečia wp(), tad prisijungti, atidaryti įskiepio ekranus ir atšaukti tai, ką daro taisyklė, galėsite visada. Plati taisyklė pasiekia kitką: viską, ką wp-admin daro per REST API, tai yra blokų redaktorių, Site Health, mobiliąją programėlę. Todėl šis skyrius aprašo du skirtingus požymius, ir vienas iš jų į peradresavimo bėdą visai nepanašus.

1. Prisijunkite adresu /wp-login.php ir atidarykite 404 Handler, tada Redirects. Tam jokia taisyklė įtakos neturi.
2. Filtruokite sąrašą pagal atitikties tipą Prefix match, paskui Regular expression. Visą svetainę apimantis peradresavimas beveik visada bus vienas iš šių dviejų, kaip ir sugedęs redaktorius.
3. Įtartinai taisyklei naudokite eilutės veiksmą Disable, o ne Delete, kad paskui dar galėtumėte ją apžiūrėti. Išjungimas įsigalioja iškart.
4. Atidarykite bet kurį įrašą blokų redaktoriuje ir jį išsaugokite. Jei redaktorius skundėsi netinkamu JSON atsaku arba nepavykusiu publikavimu, o dabar išsaugo, ta taisyklė gaudė /wp-json/.
5. Atsiverskite /robots.txt ir /wp-sitemap.xml ir įsitikinkite, kad jie grąžina savo turinį, o ne peradresavimą.
6. Jei lankytojo pusėje vis tiek negerai, atidarykite Settings ir grąžinkite "When a 404 happens" į "Show the theme's normal 404 page (do nothing)".
7. Jei dėl kokios nors kitos priežasties nepasiekiamas ir pats wp-admin, per SSH paleiskite vieną iš žemiau esančių komandų arba per SFTP pervadinkite įskiepio aplanką, kuriame yra m-404-handler.php. Pervadinus aplanką įskiepis deaktyvuojamas, o visos taisyklės, visas žurnalas ir visi nustatymai lieka nepaliesti.

# Deactivate the plugin completely; all rules and logs are kept.
wp plugin deactivate m-404-handler
# On a multisite network, add --network.

# Or keep it active and make every rule stop matching. Temporary only.
wp option update m404_rule_counts '{"exact":0,"prefix":0,"regex":0}' --format=json

# Or turn off only the automatic 404 redirect.
wp option patch update m404_settings fallback_mode none

# Or disable one rule directly in SQL (use your own table prefix).
# Disabling in SQL takes effect at once.
wp db query "UPDATE wp_m404_redirects SET enabled = 0 WHERE id = 12;"

# But RE-ENABLING in SQL does nothing while the cached counts say the
# type has no rules. Refresh them, or the rule stays dead:
wp eval '(new M404_Redirect_Repository())->refresh_counts();'

Negrįžtamas duomenų trynimas

Šiame įskiepyje nėra nei šiukšlinės, nei atšaukimo, nei eksporto. Viskas, kas išvardyta žemiau, pašalina duomenis iškart ir visam laikui, o kai kurie veiksmai pašalina gerokai daugiau, nei atrodo iš mygtuko pavadinimo.

• "Delete all log entries" 404 Log ekrane viena komanda ištuština visą žurnalo lentelę. Vienintelė apsauga yra naršyklės patvirtinimo langas.
• Ta komanda yra TRUNCATE TABLE, o jai reikia DROP teisės. Nemažai valdomos prieglobos tiekėjų svetainės duomenų bazės naudotojui jos neduoda. Įskiepis rezultato netikrina ir bet kuriuo atveju parodo "The 404 log has been emptied.", tad prieš tuo pasikliaudami perkraukite 404 Log ekraną ir įsitikinkite, kad jis tikrai tuščias.
• Delete atskirose žurnalo eilutėse ir masinis Delete tame pačiame ekrane. Nė vienas patvirtinimo neprašo.
• Delete Redirects ekrane. Eilutės veiksmas patvirtinimo prašo, o masinis – ne, tad netyčia pažymėtas langelis dviem paspaudimais gali sunaikinti visą taisyklių puslapį.
• Abu sąrašo ekranai pateikiami GET formoje, tad masiniai veiksmai keliauja užklausos eilutėje. Masinis taisyklių puslapio Delete kartu su savo vienkartiniu raktu atsiduria jūsų naršyklės istorijoje, serverio prieigos žurnale ir bet kurio tarpinio serverio žurnale, ir tol, kol tas raktas galioja, jį galima pakartoti.
• "Reset hit counters" pasirinktoms taisyklėms nuliuoja suveikimų skaičių ir išvalo paskutinio suveikimo datą. Būtent taip prarandami įrodymai, kurie peradresavimai dar reikalingi. Tai vienintelis masinis veiksmas, kuris neatnaujina įsimintų taisyklių skaičių, nes jam to ir nereikia.
• Retention reikšmės sumažinimas. Kitą kartą per parą suveikus m404_cleanup, ištrinama kiekviena žurnalo eilutė, nepaliesta per naują laikotarpį. Pakeitus 365 dienas į 7, metų duomenys dingsta per parą, ir išsaugant apie tai neįspėjama.
• Žymimasis langelis "Remove this URL from the 404 log after creating the redirect" peradresavimo formoje, kuris būna pažymėtas iš karto, kai į formą ateinate iš žurnalo.

Kai kas nors neveikia

Trumpas sąrašas to, kas praktikoje iš tikrųjų sugenda, ir ką kiekvienu atveju tikrinti pirmiausia.

• Peradresavimas nieko nedaro. Patikrinkite, ar taisyklė yra Enabled, tada ar kuri nors ankstesnė taisyklė jau neatitiko: pirma tikrinamos Exact taisyklės, tada ilgiausias prefiksas, tada reguliariosios išraiškos sukūrimo tvarka.
• Blokų redaktorius neišsaugo arba Site Health nebeveikia, ir tai prasidėjo iškart pridėjus taisyklę. Prefikso ar reguliariosios išraiškos taisyklė gaudo /wp-json/. Išjunkite ją ir patikrinkite iš naujo.
• Iškart nustojo veikti visos Exact taisyklės, o ekrane niekas to nepaaiškina. Kažkas pakeitė Case sensitivity arba Trailing slashes neperskaičiavęs maišos reikšmių. Paleiskite perskaičiavimo komandą arba iš naujo išsaugokite kiekvieną Exact taisyklę.
• Viena taisyklė veikia, kita tyliai ne, o iš naujo išsaugojus bet kurią taisyklę viskas susitvarko. Įskiepis parinktyje m404_rule_counts laiko įjungtų taisyklių skaičių pagal tipą, ir jei tas skaičius nulis, praleidžiamas visas tipas. Atidarykite bet kurią taisyklę ir ją išsaugokite, kad skaičius būtų perskaičiuotas.
• Įjungėte taisyklę tiesiai SQL komanda ir nieko neįvyko. Įsiminti skaičiai nebuvo atnaujinti. Išsaugokite bet kurią taisyklę per administravimo sritį arba perskaičiuokite juos per komandinę eilutę.
• 404 žurnalas lieka tuščias. Arba žurnalas išjungtas, arba adresus pagauna ignoravimo šablonai (numatytasis sąrašas jau atmeta .php, paveikslėlius, CSS, JS, šriftus ir viską, kas yra po /wp-content/ ir /wp-includes/), arba viso puslapio kešas ar CDN pateikia 404 taip, kad WordPress apskritai nepasileidžia. Jei jūsų CDN kešuoja viską, 404 atsakus iš kešavimo išimkite.
• Seni žurnalo įrašai niekada nedingsta. Saugojimo laikotarpis veikia tik per kasdienį cron įvykį m404_cleanup. Jei WP-Cron išjungtas ir jo nepakeičia sisteminis cron, niekas nevalo. Įvykio buvimą patikrinkite komanda wp cron event list.
• Vietoj savo 404 puslapio rodomas temos 404. Pasirinktas puslapis turi egzistuoti, būti page tipo ir publikuotas. Juodraštis ar į šiukšlinę išmestas puslapis tyliai atkrenta.
• Pasiūlymai niekada nepasirodo. Jie rodomi tik "Show a custom 404 page" režimu, jiems reikia bent trijų simbolių trūkstamo slug ir bent 40 procentų panašaus publikuoto įrašo ar puslapio.
• Reguliarioji išraiška išsaugoma, bet niekada nesuveikia. Šablonas saugomas be skirtukų ir lyginamas tik su keliu, tad jame reikia pradinio pasvirojo brūkšnio, pavyzdžiui ^/old-blog/.
• Kolega meniu nemato. Visiems trims ekranams reikia manage_options teisės, tad juos mato tik administratoriai.
• 404 Handler klaidos pranešimas iššoka wp-admin puslapyje, kuriame jo nesitikėjote. Įskiepis bet kuriame administravimo ekrane parodo tokį tekstą, koks yra m404_error užklausos parametre, be vienkartinio rakto ir be nukreipiančiojo adreso patikros. Tekstas ekranuojamas, tad kodo jis nepaleis, bet kiekvienas, priviliojęs jus paspausti specialiai parengtą nuorodą, gali įdėti savo žodžius į tikrai atrodantį WordPress pranešimą. Iš nuorodos atėjusiu pranešimu nepasitikėkite ir niekada nesinaudokite jame nurodytu telefono numeriu ar adresu.

Privatumas ir duomenys

Įskiepis nesijungia į išorę jokiu būdu. Nėra jokio duomenų siuntimo kūrėjui, jokio pašalinio atnaujinimų tikrinimo, jokios analitikos ir jokio licencijos tikrinimo. Jame taip pat nėra kodo, kuris siųstų el. laiškus, tad svetainės pašto siuntimui jis niekaip negali pakenkti. Visa, ką jis žino, lieka jūsų pačių duomenų bazėje.

• wp_m404_redirects lentelėje saugoma: šaltinis, atitikties tipas, tikslas, statuso kodas, įjungimo žymė, suveikimų skaičius, paskutinio suveikimo laikas, sukūrimo ir atnaujinimo laikai. Jokių lankytojų duomenų.
• wp_m404_404_log lentelėje saugoma: trūkstamas adresas su užklausos eilute, suveikimų skaitiklis, paskutinis referrer, paskutinis user agent, paskutinis IP adresas ir pirmojo bei paskutinio karto laikai.
• Kai "Anonymize visitor IP addresses" įjungtas (o taip yra numatytai), IP adresai praleidžiami per paties WordPress anonimizavimo funkciją. Skaitomas tik REMOTE_ADDR, niekada persiuntimo antraštė.
• Vėliau įjungtas anonimizavimas jau įrašytų duomenų nesutvarko. Funkcija taikoma tik įrašymo metu, tad esamose eilutėse lieka pilni IP adresai tol, kol tas pats adresas bus paliestas dar kartą arba eilutę ištrins saugojimo laikotarpis. Išvalykite žurnalą arba palaukite, kol praeis saugojimo laikotarpis, o iki tol senas eilutes laikykite asmens duomenimis.
• Jei apie lankytojus nenorite saugoti nieko, išjunkite Logging. Peradresavimai veiks lygiai taip pat kaip anksčiau.
• Į žurnalą patenka tik tie adresai, kurie sukėlė tikrą 404 ir neatitinka nė vieno jūsų ignoravimo šablono.
• Išjungus anonimizavimą, žurnale lieka pilnas IP adresas ir user agent, o tai yra asmens duomenys. Parašykite apie tai savo privatumo pranešime ir laikykite saugojimo laikotarpį trumpą.
• Masiškai trinamos žurnalo eilutės keliauja GET užklausa, tad pasirinktų eilučių adresai atsiduria jūsų naršyklės istorijoje ir serverio prieigos žurnale. Tai verta žinoti, jei patys užrašyti adresai yra jautrūs.

Šalinimas: kas dingsta, kas lieka

Deaktyvavimas ir šalinimas čia daro visiškai skirtingus dalykus, o skirtumas yra visa jūsų peradresavimų istorija. Deaktyvuokite, kai norite, kad įskiepis nustotų veikti. Šalinkite tik tada, kai esate tikri, kad taisyklių nebeprireiks.

• Deaktyvavus sustabdomas visas atitikties tikrinimas ir esamoje svetainėje atšaukiamas kasdienis m404_cleanup įvykis. Abi lentelės, visos taisyklės, visas žurnalas ir visi nustatymai lieka tokie patys, o vėl aktyvavus viskas tęsiasi nuo tos pačios vietos.
• Multisite tinkle deaktyvavimo kabliukas cron įvykį pašalina tik toje vienoje svetainėje, kurioje jis suveikė. Visos kitos tinklo svetainės savo suplanuotą m404_cleanup pasilieka, ir jis toliau kasdien suveikia, nors jokios funkcijos prie jo nebėra. Žalos tai nedaro, bet ir tvarkos neprideda, tad, jei rūpi, kiekvienoje svetainėje jį pašalinkite komanda wp cron event delete m404_cleanup.
• Ištrynus įskiepį Įskiepių ekrane paleidžiama šalinimo procedūra: ji pašalina lenteles wp_m404_redirects ir wp_m404_404_log, ištrina parinktis m404_settings, m404_rule_counts ir m404_db_version bei išvalo cron įvykį. Multisite tinkle visa tai padaroma kiekvienoje tinklo svetainėje.
• Tas multisite ciklas vyksta vienoje užklausoje ir svetainių skaičiaus neriboja. Dideliame tinkle užklausa gali nutrūkti pusiaukelėje: jau apdorotose svetainėse lentelės pašalintos, likusiose nepaliestos, o tęsti nėra kaip, nebent įdiegtumėte ir ištrintumėte iš naujo. Po to patikrinkite, ar niekur nebeliko m404_ lentelių.
• Kas išlieka po ištrynimo: naudotojo lygio ekrano parinktys m404_redirects_per_page ir m404_logs_per_page lieka naudotojų meta lentelėje.
• Už duomenų bazės ribų neįrašoma nieko. Jokie failai wp-content aplanke nekuriami. Bet trumpasis kodas [m404_suggestions] nustoja būti registruotas, o nebeatpažįstamo trumpojo kodo WordPress iš turinio neišima: puslapyje lankytojams tuomet matomas pats tekstas [m404_suggestions]. Prieš deaktyvuodami ar šalindami įskiepį jį iš puslapio pašalinkite.

Automatiniai atnaujinimai

Įskiepis tikrina majevski.com dėl naujų versijų ir siūlo jas per įprastą WordPress atnaujinimų langą — tas pats pranešimas, keitimų sąrašas ir diegimas vienu paspaudimu kaip ir bet kurio kito įskiepio. Tikrinimai talpinami podėlyje, niekada nelėtina puslapių ir veikia saugiai: jei majevski.com nepasiekiamas, svetainė tiesiog dirba toliau ir pabando vėliau. Atnaujinimo paketas priimamas tik iš majevski.com per HTTPS, o senesnė versija niekada nesiūloma. Versijos iki 1.1.0 atnaujinimų kanalo dar nepažįsta, todėl naujų leidimų nemato — vieną kartą rankiniu būdu įdiekite 1.1.0 ar naujesnę, ir visi vėlesni leidimai atkeliaus savaime.