Přehled odpovědí
-
Příspěvky
-
Jen pro úplnost – autor pluginu nakonec objevil místo, které způsobovalo zde popisovanou chybu a udělal fix. Sláva! :)
Pročetl jsem tu diskusi s popup_maker a je to mazec :) Řekl bych, že problém s pluginem meta-box jde stejným směrem, možná jim pošlu tu diskusi jako inspiraci, kde mají kluci hledat zádrhel :))
Autor naštěstí komunikuje, i když odezva je dost fádní.. O tom, že je se chyba projevuje na čisté instalaci (mimochodem to nemusí být nutně 5.0, pozoruju to i na 4.9.8 a dost možná je to i na starších verzích) jsem podal snad dostačující důkazy.
Využil jsem nějaký online tool, který na nějaké veřejné adrese vytvoří čistou instalaci WP a chyba je samozřejmě i tam. Aktuálně čekám na reakci.
Musím se zeptat. Jak je možné (pokud vůbec), že nějaký plugin poruší toto pravidlo výpisu uvozovek tím, že ho aktivuji. Jsem v kontaktu s autorem onoho pluginu a reakce ja taková, že v žádném případě plugin nezasahuje do jazykového nastavení WordPressu, toto chování si tedy nedokáže vysvětlit. A já nevím, jak mu argumentovat, kde může být zádrhel..
Možná více vysvětlit, jak toto pravidlo českých uvozovek vůbec pracuje. Vím, že zde exituje někde článek, kde se popisuje, že je to otázka překladového souboru, že existuje filtr wptexturize, znaky se převadí do entit, jsou gettextované..
Zde byl a zatím stále je problém v konfliktu pluginu. Pokud někdo používáte plugin “meta-box”, tak jeho aktivování z nějakého důvodu udělá to, že jsou uvozovky i na české verzi WP “anglické”.
Zde zmiňovaný plugin problém vyřešil, díky.
Ahoj,
převádí vám WordPress automaticky uvozovky na české (tedy 99 vlevo dole, 66 vpravo nahoře) i nyní?
Osobně s tím mám problém. Uvozovky se mi převedou na 66 (vlevo nahoře) a 99 (vpravo nahoře).
Kde je obecně problém a dá se to řešit?
Pravděpodobně došlo k nějaké změně na straně WP, jelikož jak jsem psal, WordPress na čisté instalaci udělá dvě podtržítka za převedeným znakem, v případě mé fce pouze jedno. Samotná fce testovací řetězec převede správně, ale pokud ji zahookuju, tak je výsledek špatně (jiný).
Osobně také nahrávám, nebo pojmenovávám názvy souborů bez diakritiky. V tomto případě jde o klienta, který nahrává soubory s českým pojmenováním..
Díky za tip na plugin, vyzkouším.
Řešíte názvy souboru po uploadu? Všem se vám diakritika automaticky převede na “bez” a nijak extra to nenastavujete?
Plánoval jsem nějaké vlastní defaultní automatické přiřazení v případě, že příspěvěk spadá do více rubrik, ale tento plugin asi také poslouží..
Díky za tip.
Autor dodělal nějakou novou funkcionalitu na toto – takže se to vyřešilo jinak. Ale zde jsem jistě postupoval správně.
Nejednalo se o veřejný plugin a tento problém vyřešil nakonec autor pomocí opravného “patche”. Ale i tak díky za podporu zde v diskusi.
Zkusil jsem více variant i tyto zde popisované (codex k remove_action() v podstatě toto i demonstruje) .. krásně je to popsané i tady – bohužel u mě zatím bez výsledku.
Pokud uvážíme, že plugin spouští kód později, jsou pak nějaké možnosti řešení?
Díky za super vyčerpávající odpověď. Ano, potřeboval jsem to promíchat – využil jsem nakonec bodu 4 – i když některé věci tam použité jsou pro mě záhadou (hlavně to pole
$defaults, bez toho to nešlo). Ještě jednou díky!U CPT nepoužívám žádné rubriky (ani taxonomie). Výše uvedený příklad vrátí posty pouze z rubriky a CPT ignoruje.
Jak jsem psal, na webu není žádný plugin.. E-mail a tvar odkazů je stejný, jako je výše uvedeno, ale ten odkaz se přesměruje na přihlášení, nikoli na zadání hesla..
Obsah .htaccess je stejný, jako jinde (tzv. default nastavení z WP), tady také nebude problém..
Bohužel odkaz na preview verzi nemohu poslat..
Proces vygenerování hesla funguje všude jinde v pořádku, pouze na tomto webu se to takto chová .. a naštěstí zde nejde o možnost registrace pro uživatele, takže to na tom nestojí, spíše mě zajímalo, co se mohlo “pokazit” a jak to spravit.
Mohu potvrdit, že to funguje v mé popisované konfiguraci – tedy WP nainstalovaný v podadresáři (s indexem v rootu).
ABSPATHvrací cestu k adresáři, kde je WP nainstalovaný – tzn. pro načtení vlastního adresáře např. “themes” uvnitř WP použijiregister_theme_directory( ABSPATH . 'themes/' );Abych docílil možnosti instalovat šablony mimo WP, nejprve mě napadlo použít výše popisovaný
$_SERVER['DOCUMENT_ROOT']– tím dostanu cestu k rootu – ovšem tímto se dostanu do stejného stavu s chybovou hláškou při aktivaci jako dříve. Ani jiné pomocné fce na zjištění absolutní cesty k rootu mi uvnitř “register_theme_directory” nefungují – nakonec jsem to udělal taktoregister_theme_directory( ABSPATH . '../themes/' );a funguje to i mimo WP.Já jsem sice měl tu fci v obou šablonách, tedy teoreticky, pokud se načítala jiná aktivní šablona/functions.php, o kód bych neměl přijít, ale stejně to nechodilo..
Pomohlo to dát do toho MU pluginu – na to jsem nikde nenarazil – nyní to funguje přesně tak, jak jsem potřeboval.. :)
Díky moc za pomoc! Palec nahoru – dobrá práce..
Kód s funkcí vkládám do aktuální šablony – do functions.php
Měl jsem tam toto:
register_theme_directory( $_SERVER['DOCUMENT_ROOT'] . '/themes' );v případě, že mám adresář “themes” v rootu, ale i tento kód
register_theme_directory( ABSPATH. 'themes/' );se chová bohužel stejně – vidím šablony, ale pokud se pokusím o aktivaci, napíše to, že je šablona asi poškozená (vyzkoušeno i s defaultními šablonami twenty*).
Ještě jsem si všiml, že pokud kliknu na “aktuální náhled” šablony místo aktivace, mám hlášku “Nezkoušíte podvádět?” nebo “Cheatin’ uh?”.
Vyřešil jsem to přepsáním ve 2 souborech:
plugins/bbpress/includes/topics/template.php
plugins/bbpress/includes/replies/template.phpPočítám s tím, že při aktualizaci BBPressu se to přepíše, ale nerozumím tomu, proč se to netahá s .po souboru, když tam tento řetězec je :/
