Přehled odpovědí
-
Příspěvky
-
Nezmiňujete to, tak se zeptám – zkoušel jste nastavit chování komentářů ve WordPressu? Je tam několik možností, jak se mají chovat a řadit, žádná kombinace vám tedy nevyhovuje?
Může to být třeba mezera přes otevíracím <?php ve functions.php, kam se často bez ladu a skladu doplňují různé snippety. Ale samozřejmě kdekoliv jinde. Pak je dobré vědět, které soubory byly naposledy upraveny – logovat jejich stav.
Na jaké doméně je řídicí web? Měl by být na http://www.triabelo.cz, což tipuju, že není. Pak je problém to dodatečné přidání subdomény – multisite musí být na stejné úrovni. Pokud je řídicí web na subdoméně třetího řádu (trakar), pak jsou jeho weby na subdoméně čtvrtého řádu (neco.trakar.triabelo.cz), nebo v adresáři (trakar.triabelo.cz/novyweb). Jak to máte?
Když pominu jiná rizika, které mohou být ve hře, tak je možné, že máte starší verzi PHP? Máte tam řadu 7?
Asi už to máte vyřešeno, tak já jen pro archiv napíšu, že je to zapomenutý znak, který se dostal na nesprávné místo. Často to bývá mezera na začátku functions.php, ještě před úvodním <?php. A podobně často to bývá napadení webu a poškození systémových souborů WP.
Několikrát jsem se setkal s následující situací:
- znaky na FTP obsahují diakritiku a mezery
- kopie na lokální počítač
- kopie na jiný hosting, znaky v názvech zůstávají stejné, na první pohled nepoškozené
- v databázi i na FTP je vizuálně vše v pořádku, nejsou problémy s právy
- WP sveřepě zobrazuje 404, a to i tehdy, když je soubor řádně vidět v knihovně médií (obvykle všechny náhledy kromě originálu)
V jednom případě to vyřešilo kopírovat data mezi hostingy v Mac OS X. Ačkoliv byly oba hostingy linuxové a já jsem kopíroval data taky v Linuxu, nastala výše uvedená situace. Kolega s Mackem ale zkopíroval data tak, že bylo vše ok.
A závěr? Nevím. Názvy souborů by měly být v Linuxu interpretovány jako UTF-8, chápu, že ve Windows by to bylo jinak (bývá to obvykle 1250, případně 8859-2). Ale stále nevím, proč a kdy se to děje.
