Skeakelje de native sykfunksje yn WordPress folslein út om te foarkommen dat kweade programma's de database scannen en crashje.

Folslein útskeakelje WordPress De frontend hat in native sykfunksje om te foarkommen dat de databank oerlêst wurdt troch it scannen.

De database crasht net om't jo webside tefolle ynhâld hat, mar om't jo noch altyd dy bespotlik ineffisjinte native WordPress-sykfunksje brûke.

In protte webside-eigners sjogge ien feit oer: de front-end ... ?s= Sykparameters binne in favoryt fan hackers en scanners.

As immen oanfragen bliuwt yntsjinjen by de sykinterface, sil jo database twongen wurde om tûzenen betsjuttingsleaze fragen út te fieren.

It resultaat? It CPU-gebrûk naam ta, it ûnthâldgebrûk eksplodearre, en de webside crashte.

Dit is gjin oerdriuwing, mar in echte en pynlike ûnderfining fan ûntelbere siden.

Wêrom útskeakelje native sykfunksje fan WordPress?

De ynboude sykfunksje fan WordPress is yn essinsje in folsleine tekst LIKE-fraach yn 'e database.

Dizze query is ekstreem ineffisjint, foaral as it oantal artikels mear as 1 is; ien sykaksje kin mear as 0.5 sekonden duorje.

As immen in webcrawler of oanfalsskript brûkt om tsientallen sykfragen per sekonde te ferstjoeren, sil jo database direkt oerlêst wurde.

Neffens de offisjele WordPress-dokumintaasje hat native search gjin beskermingsmeganismen en is folslein bleatsteld oan 'e frontend. Dit betsjut dat oanfallers dit yngongspunt kinne eksploitearje sûnder sels yn te loggen.

Alternative oplossing: Ferbine mei in tûkere sykmasine

In protte profesjonele websiden fertrouwe net mear op 'e native sykfunksje fan WordPress.

Bygelyks, tagong Google Programming Search of Algolium Sokke syktsjinsten fan tredden binne net allinich rap, mar leverje ek krektere resultaten.

Wichtiger is dat dizze tsjinsten jo database net sille ferlamje, om't alle fragen ekstern wurde útfierd.

Dus as jo websidePositioningAs it in arkside, in blogside, of sels in side is dy't al fertrout op eksterne sykjen, is d'r gjin reden om de ynboude sykfunksje fan WordPress te behâlden.

Skeakelje de ymplemintaasje fan WordPress front-end sykkoade folslein út

De meast direkte manier is om te fokusjen op it tema. functions.php Foegje de folgjende koade ta oan it bestân:

// 禁用 WordPress 前台搜索功能，防止被扫描拖垮数据库
function disable_wp_search( $query, $error = true ) {
    if ( is_search() && !is_admin() ) {
        $query->is_search = false;
        $query->query_vars['s'] = false;
        $query->query['s'] = false;
        if ( $error == true ) {
            // 直接返回 404 页面，不走任何数据库查询
            $query->set_404();
            status_header( 404 );
            nocache_headers();
        }
    }
}
add_action( 'parse_query', 'disable_wp_search' );
add_filter( 'get_search_form', '__return_empty_string' );

De logika fan dizze koade is hiel ienfâldich:

• Sadree't in sykfraach op 'e foargrûn wurdt ûntdutsen, wurde databasefragen fuortendaliks blokkearre.
• Weromgean nei in 404-pagina blokkearret it yngongspunt folslein.
• Tagelyk is it sykformulier fuorthelle om tafallige brûkersaksjes te foarkommen.

It foardiel fan dizze metoade is dat sels as in oanfaller ferskate oanfragen docht ... ?s=xxxIt sil gjin databasefragen triggerje.

In elegantere ymplemintaasje: it brûken fan Fluent Snippets

As jo ​​de temabestannen net direkt wizigje wolle, kinne jo brûke ... Floeiende fragminten ynstekke.

Dizze plugin lit jo koadesnippets direkt op 'e eftergrûn tafoegje, en de effekten en oanpassingen sjen. functions.php Itselde, mar feiliger.

As it ienris ynskeakele is, kinne jo al jo oanpaste koade maklik beheare sûnder jo soargen te meitsjen dat tema-updates it oerskriuwe.

Werkelike resultaten: De druk op de databank is skerp sakke.

Yn in konfiguraasje fan 2-kearn CPU + 4GB RAM Op 'e VPS, doe't de native sykaksje 50 oanfragen per sekonde die, sprong it CPU-gebrûk fan 'e database omheech nei 95%.

Nei it útskeakeljen fan sykjen joech itselde fersyk direkt in 404-flater werom, en de databankbelesting wie hast nul.

Dêrom advisearje in protte feiligenseksperts sterk om de native sykfunksje fan WordPress fuortendaliks út te skeakeljen as jo it net nedich binne.

Feiligensûndersikers hawwe eksplisyt oanjûn yn 'e offisjele blog fan Sucuri:

"Native sykfunksjes fan WordPress binne ien fan 'e maklikste yngongspunten om te eksploitearjen; oanfallers kinne denial-of-service-oanfallen meitsje troch faak sykfragen te dwaan."

Dizze útspraak is genôch om it probleem te ferklearjen.

Konklúzje: Feiligens is gjin opsje, mar in ferplichte kursus.

Websidefeiligens is net allinich in bonus, it is in kwestje fan libben en dea.

It útskeakeljen fan 'e native sykfunksje fan WordPress liket miskien in lytse aksje, mar it kin jo database foarkomme dat se oerlêst wurdt.

Yn dit tiidrek fan ynformaasje-oerlêst leit wiere wiisheid net yn it tafoegjen fan funksjes, mar yn it beslissend fuortsmiten fan dyjingen dy't ineffisjint of gefaarlik binne.

Tink derom: Feiligens is gjin kostenpost, it is wearde.

As jo ​​noch wifkje, freegje josels dan dit ôf: Soene jo leaver jo database crashje litte te midden fan it laitsjen fan oanfallers, of soene jo leaver de kontrôle oer de situaasje nimme?