Die gevreesde ‘interne bedienerfout’ in WordPress op te los (stap vir stap)

WordPress aanbiedings


Ons was almal daar – ‘n webwerf wat net ‘n paar sekondes uitstekend gevaar het, het skielik besluit om ‘n pas te gooi en ‘n interne bedienerfout uit te spoeg. As u gelukkig is, werk die WordPress-bestuurder steeds, maar selfs in sommige gevalle kan dit weier om saam te werk. In hierdie artikel sal ons verduidelik wat ‘n interne bedienerfout is, en, nog belangriker, hoe om dit op te los.

Belangrik: Maak altyd ‘n volledige rugsteun van u webwerf (selfs al werk dit nie soos dit hoort nie) voordat u veranderings aanbring – beter veilig as jammer!

Laat ons kraak.

Wat is ‘n interne bedienerfout

Interne bedienerfoute is irriterend vir gebruikers en ontwikkelaars, omdat hulle geen inligting oor die wortel van die probleem verskaf nie – hulle sê net dat daar een is. Stel jou voor dat jy na die dokter gaan en sê dat jy pyn voel, maar weier om te onthul waar die pyn was – dit sal die dokter baie moeilik maak om dit te behandel! Dit is die probleem met ‘n interne bedienerfout – daar is geen aanduiding van waar die probleem vandaan kom nie.

Interne bedienerfout

Boonop kan die naam ‘interne bedienerfout’ misleidend wees, omdat u gasheer (en / of bediener) in byna alle gevalle nie die skuld het nie. As u na die HTTP-spesifikasies kyk, kan u sien dat die 500-bedienerfout die volgende beteken:

Die bediener het ‘n onverwagte toestand ondervind wat verhoed het dat hy aan die versoek voldoen.

Daar is niks verkeerd met die bediener self nie – dit het bloot iets teëgekom wat dit nie kan uitvind nie. Kom ons kyk wat dit kan wees – en hoe u daarvan ontslae kan raak.

Stap nul: Aktiveer ontfouting

Die eerste stap moet wees om ten minste te probeer om sin te maak van die fout – jy kan gelukkig wees! Afhangend van die manier waarop u bediener foute hanteer, kan dit wat u sien, glad nie ‘n bedienerfout wees nie. Om te sien of dit die geval is, moet u die wp-config.php-lêer in die stamgids van u webwerf wysig. Laai die lêer af (via FTP, maak dit oop (gebruik ‘n teksredakteur en soek ‘WP_DEBUG’.) As u die reël vind, verander eenvoudig vals na waar en laai die lêer weer op die bediener op.

As hierdie reël nog nie in u konfigurasielêer is nie, skep dit dan met behulp van die volgende reël kode:

definieer ( "WP_DEBUG", waar);

Herlaai u webwerf en kyk of die fout verander. As dit so is, en u sien nou ‘n ‘noodlottige fout’-boodskap wat na ‘n spesifieke reël kode in ‘n spesifieke lêer wys, dan kyk u na ‘n relatiewe eenvoudige kodefout. As ons aanvaar dat die fout van ‘n inprop of ‘n tema afkomstig is, moet u die aanstootlike produk deaktiveer en / of self die probleem oplos (of iemand anders daarna kyk as u nie kan uitwerk wat aangaan nie) jou eie).

Opmerking: onthou dat u die bogenoemde ‘ware’ waarde verander nadat u die probleem gevind het terug na ‘onwaar’ binne die voormelde wp-config-lêer.

Stap een: Kyk of u bestuurder werk

Besoek u webwerfadministrateur op http://yoursite.com/wp-admin/. As hierdie bladsy behoorlik laai en u kan aanmeld, kan u redelik seker wees dat die probleem met ‘n inprop of met u tema is. As u bestuurder laai, gaan dan verder na stap twee. As dit nie so is nie, gaan dan na stap vier.

Stap Twee: skakel alle inproppe uit

Daar is bykans geen manier waarop ‘n inprop probleme kan veroorsaak as dit gedeaktiveer is nie. Dus, as u vermoed dat een van u inproppe die probleem veroorsaak, gaan na die inprop-afdeling en skakel hulle almal uit. Dit sal hulle nie uitvee nie, en hulle sal hul gestoorde data bewaar, maar hul kode sal nie uitgevoer word nie. As u al u inproppe gedeaktiveer het en u werf steeds nie laai nie, gaan na stap drie.

As u werf aan die gang is, kan u die inproppe een vir een inskakel. Hou aan om te kyk of die 500 interne bedienerfout na elke inprop is. As u die skuldige gevind het, kan u besluit wat u daarmee moet doen. Die beste manier om te werk is om die inprop uit te skakel en die outeur onmiddellik in kennis te stel. As dit ‘n missie-kritieke inprop is, moet u waarskynlik ‘n beter, stabieler alternatief soek.

In sommige baie seldsame gevalle kan die bestuur van ou sagteware soos PHP 5.3 probleme veroorsaak. Kyk eers na stap sewe voordat u ‘n inprop vervang wat tot dusver betroubaar is.

Stap Drie: Skakel oor na ‘n standaardtema

As die deaktivering van u inprop die probleem nie opgelos het nie, is dit waarskynlik die tema waar u die tema gaan doen. U kan dit maklik verifieer deur oor te skakel na ‘n standaard WordPress-tema. Ek beveel aan dat u Twenty Sixteen gebruik, wat die nuutste standaardtema is. As die oorskakeling na Twintig Sestien die probleem oplos, kan u alle inproppe weer aanskakel en aan die gang kom om die probleem in die kode van u tema te vind..

As u tema van die amptelike temagang of van ‘n onafhanklike temawinkel afkomstig is, moet u die skrywer so gou as moontlik daarvan laat weet. As dit aan die ander kant jou eie tema is, moet jy ‘n ontwikkelaar kry om jou te help, want hierdie foute kan baie moeilik wees om te vind – selfs vir gesoute koders..

In sommige baie seldsame gevalle kan die bestuur van ou sagteware soos PHP 5.3 probleme veroorsaak. Kyk eers na stap sewe voordat u ure spandeer om ‘n fout te vind of honderde dollars aan ‘n ontwikkelaar te betaal.

Stap vier: Verhoog u geheue limiet

As u webwerf te veel geheue gebruik, sal dit beslis ‘n pas kry – dit kan moontlik lei tot ‘n 500-bedienerfout. in baie gevalle, is dit ‘n teken van ‘n sleg gekodeerde tema of inprop. Dit kan vinnig reggestel word deur die geheuegrens te verhoog, maar dit is nie ‘n onfeilbare manier om die probleem op te los nie, en sal nie aan die wortel kom nie.

Hoe dan ook, WooThemes het ‘n kort handleiding oor die verhoging van die WordPress geheue limiet. Hou in gedagte dat daar wel ‘n vasgestelde hoeveelheid geheue aan u bediener of u rekening toegewys kan wees, en dat u nie u geheime limiet verder kan verhoog nie.

Alternatiewelik kan u met u gasheer praat vir meer spesifieke instruksies – sommige sal u graag u geheue beperk sonder om byna geen ophef van u kant te maak nie..

Stap vyf: Ontfout .htaccess-probleme

Die .htaccess-lêer is ‘n konfigurasielêer vir u Apache-bediener wat relatief gevorderde funksies moontlik maak. Deur dit te gebruik, kan u gzip-kompressie inskakel, die maksimum oplaaigrootte verander en allerlei ander handige dinge doen.

Ons het alreeds ‘n handleiding geskryf oor die wysiging van die .htaccess-lêer, maar dit is die moeite werd om te herhaal dat dit ‘n sensitiewe gebied is waar versigtigheid vereis word. ‘N Tikfout, ‘n vergete spasie of ‘n ongeslote aanhaling, byvoorbeeld, kan maklik 500 interne bedienerfoute veroorsaak en u webwerf – insluitend u admin – tot stilstand kom..

Die oplossing is om u .htaccess-lêer oop te maak – dit moet in die root WordPress-lêergids lê – en kyk of daar foute is (veral as u dit onlangs verander het). Ek beveel aan om ‘n rugsteun met die naam backup.htaccess te skep en dan die oorspronklike .htaccess-lêer heeltemal uit te vee om te sien of die webwerf weer aanlyn kom.

As dit so is, is die probleem by u .htaccess-lêer. U kan dit reël vir lyn deurkyk om te sien wanneer u werf afneem; sodra u die beledigende reël gevind het, maak seker dat dit nie onnodige teks bevat nie (miskien ‘n onopgesmukte aanhaling of iets dergeliks). As u die probleem nie kan opspoor nie, stel ek voor dat u die reël verwyder. U webwerf is heeltemal erger as ‘n .htaccess-lyn wat ontbreek. Vra gerus op forums as u meer hulp nodig het.

Stap ses: Installeer WordPress weer

Dit is buitengewoon skaars, maar u het miskien beskadigde lêers in die WordPress-kern. Dit is niks om oor te bekommer nie; iets het moontlik verkeerd gegaan toe u bediener byvoorbeeld die vereiste lêers kopieer. Die herlaai van WordPress Core-lêers kan u probleem oplos.

Laai ‘n nuwe weergawe van WordPress af en gebruik ‘n FTP-toepassing om alles op te laai, behalwe die wp-inhoudmap. As u meer gedetailleerde instruksies benodig, kyk gerus na die Codex-artikel oor die opgradering van WordPress.

Stap sewe: PHP-weergawe uitgawes

Alhoewel ou PHP-weergawes gewoonlik nie 500 interne bedienerfoute veroorsaak nie, kan dit die moeite werd wees om met u gasheer te praat en hulle te vra om ‘n nuwer weergawe te gee voordat u waardevolle tyd en geld spandeer. PHP 7 het sommige vorige funksies afgeskryf – byvoorbeeld, ‘n inprop kan ‘n funksie gebruik wat nie in ‘n ouer weergawe van PHP beskikbaar is nie, ensovoorts.

Vra jou gasheer watter weergawe van PHP jy het. PHP 5.2 is nou tien jaar oud en 5.3 is sewe jaar oud – aanvaar dit nie as u gasheer u webwerf op sulke ou weergawes bestuur nie. U moet ten minste ‘n variant van 5.4 hê, of, nog beter, die splinternuwe PHP 7 (vir optimale prestasie).

Saamgestelde probleme

Alhoewel dit onwaarskynlik is dat u twee probleme gelyktydig sal hê, kan dit wel gebeur. Miskien het u ‘n inprop wat ‘n probleem veroorsaak, sowel as ‘n .htaccess-probleem. In hierdie geval sal die probleem nie opgelos word as u alle inproppe deaktiveer nie, en dit sal nie opgelos word as u u .htaccess-lêer verwyder nie – slegs as u albei doen.

As u hierdie stappe gevolg het en u steeds ‘n 500-bedienerfout ervaar, moet u weer begin en seker maak dat nie ongedaan maak van enige veranderinge. Hou u plugins gedeaktiveer, hou u tema oorgeskakel na Twenty Sixteen, ensovoorts.

Finale gedagtes

As gevolg van die vaagheid van die 500-bedienerfoutboodskap, kan dit moeilik wees, maar deur die bogenoemde stappe te volg, moet u in staat wees om uit te vind wat aangaan.

As u die probleem steeds nie kan oplos nie, kontak u gasheer. Skakel na hierdie artikel en laat weet hulle dat u hierdie stappe probeer het, omdat hulle die moeite waardeer en die probleem baie vinniger kan opspoor!

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me