Wordpress - Nem tudok hozzáférni a központ
WordPress - Nem tudok hozzáférni a központ
Hello, kedves olvasók és a látogatók 4remind.ru blog. Ebben a cikkben fogunk összpontosítani a kérdésben a bejáratnál a központ (admin) WordPress blogok, amelyek szembe, vagy szembe néhány újonnan.
Ennek oka az írás ezt a cikket volt megkapta a leveleket kaptam a barátaimtól, akik szembesülnek nehézségek át a helyszínek egy másik hosting. Ők maguk megoldhatja a problémákat nem tudott, mert a nagyon kezdők felügyelhető és konfigurálható oldalakon. A probléma az, hogy az áthelyezés után oldalak létre a motor WordPress 3.3.1. a helyi szerverről a valós tárhely, ha megpróbál belépni az admin panel helyett az admin felületen az oldal jelenik meg teljesen üres, fehér oldalon. Nos, ha ez lehetséges volt, hogy megy az admin felületen, módosítása és mentése, amit néhány beállításokat ismét megjelenik egy üres oldal.
Az én segít megoldani a problémát, ezek valahogy sikerült, és mindent meg kell dolgozni, de sokan mások is volt világos, hogyan kell kezelni ezt a helyzetet, menjünk elemezze részletesebben.
A kevésbé tapasztalt vagy nagyon türelmetlen azt fogja mondani egyszer, hogy a fő oka abban rejlik, hogy az állam a PHP output_buffering zászló beállításokat. Tedd PHP output_buffering lobogó szerinti állam «on», a probléma valószínűleg azonnal oldódik.
De a többiek, akik nem nagyon erős a kiszolgáló beállításait, íme néhány példa, hogy mikor és milyen tűnhet a probléma a bejáratnál, hogy az adminisztrátor területet a motor WordPress, és hogyan lehet megoldani ezt a problémát.
Talán kezdjük azzal, hogy az ok megállapításához, akkor tudni kell, hogy a hibák fordulnak elő, amikor dolgozik site scripting.
És hibákat meg kell mutatnunk a böngésző, mert nem mindenki hozzáfér a szerver hosting a naplókat. De a legtöbb szerver alapértelmezett kimenetet a PHP hibákat böngésző van tiltva. Ezért, annak érdekében, hogy a hibákat a helyszínen teljesítése során PHP scriptek, telepíteni kell a PHP display_errors a zászló az állam «on»
Először is, ez lehet tenni a php.ini fájlban. Természetesen, ha tudja, hol van, férhetnek hozzá, és ha tárhely változtathatja PHP beállításokat.
Másodszor, a PHP display_errors zászló lehet kapcsolni a .htaccess fájlt. amelynek székhelye a gyökérkönyvtárban a webhelyen. Ez kell hozzá egy sort az alábbi paranccsal:
Ha nincs .htaccess fájlt a gyökérkönyvtárban a helyén, ott kell lennie, hogy hozzon létre. Elvileg akkor létrehozhat egy .htaccess fájlt vagy a gyökérkönyvtárban, és hol script hívások generáló futásidejű hibák.
És harmadszor, display_errors flag lehet meghatározni a PHP script hívja ini_set () függvény
A bekapcsolás után a kijelző PHP hibák az én teszt idekerültem az ilyen hiba belép a WordPress admin panel:
Nem megy mélyen az elmélet, és azt fogja mondani röviden, hogy az információk egy része a hiba
«Nem lehet módosítani header információk - headers already sent»
Majdnem azonnal kéri az ötlet hogy a szkriptek használata esetén a helyszínen eltérés van. Más szóval, a szerver kiadta a böngésző az információ még mindig szükség van egy szkript, amely működését, vagyis az egyik script vagy funkciók Már elküldött böngésző a csomagok, várakozás nélkül, és anélkül, hogy figyelembe véve azt a tényt, hogy még egy másik forgatókönyvet vagy funkciót adtak a részét kell szállítani.
Az egyik megoldás az lesz kapcsoló kimenet pufferelés PHP és csak akkor kell, hogy a PHP output_buffering zászló vagy a php.ini-ben (ha persze van, hogy a php.ini fájl)
vagy úgy, hogy a következő sort a .htaccess fájlt
Van azonban egy megjegyzést output_buffering zászló. Az értéket a bekapcsolt állapotot figyelembe kell venni azt a tényt, hogy a kimeneti pufferelés PHP szkript fog felhalmozódni a kimeneti memóriát a szerver hosting, ami ahhoz vezethet, hogy a helyzet, amikor a kiválasztás a tárolóhely nem lehet elég, és ennek következtében bizonyos kéréseket a helyszínen nem kerül feldolgozásra, amíg a memória nem szabadul. Általában gyorsan jelennek meg, amikor a helyszínen nagy és intenzív forgalom. Ahhoz, hogy ilyen helyzet elkerülése PHP output_buffering zászló biztosított helyett «a» állítsa be a puffer méretét byte, mint például a
Az értéket a puffer mérete meg kell kísérletezni Természetesen, mivel különböző helyeken különböző szervereken optimális érték lehet egészen más.
Általában tárhely, ahol már előre telepített WordPress, különösen a legújabb verzió, PHP output_buffering zászló van kapcsolva és a fenti hiba általában nem merül fel. De én biztosan meglepte, hogy a motor WordPress 3.3.1 az első start-up, a konfiguráció és a későbbi műveletek nem ellenőrizte a lehetőségét, hogy egy hasonló helyzetben. Reméljük, hogy a jövőben változatban ez a probléma kiküszöbölhető.
Ennél talán amíg a célba.
Sikeres telepítés és megkezdhető a blogolás a motor WordPress!
További cikkek hasonló témákban:
Share anyag másokkal a gombokkal: