Přehled odpovědí
-
AutorPříspěvky
-
A pro Custom post type (CPT)
autapoužíváte klasické rubriky (anebcategory), které můžete přiřazovat i u příspěvků (anebpost)? Nepoužíváte tam nějakou vlastní taxonomii?Co se objeví jako výsledek uvedeného dotazu?
Díky :-)
Každopádně je to dost podivné (nevěřím na náhody), možná nějaký problém s cachováním stránky s pokladnou, těžko říci… Zatím to budeme brát za vyřešené :-)
Díky, jen pozor, správně by to mělo být
a:1:{s:13:"administrator";b:1;}(u někoho původní verze způsobovala problémy, viz originální anglický návod). Význam je sice na první pohled stejný, ale v prvním případě je hodnotou jednička jako hodnotastring, zatímco v druhém případě vyjadřujetrue. Možná už to dnes nevadí, ale vzpomínám, že dříve to mohlo způsobovat problémy… Ale pokud to funguje, tak to asi není potřeba řešit…Jinak je AutomateWoo zajímavý plugin s mnoha možnostmi, zatím jsem na něj ale ještě u nikoho nenarazil :-) Pokud jsem to dobře pochopil, tak když jste testoval objednávku, kterou provedl administrátor, tak ho plugin také přehodil do jiné skupiny uživatelů a tím mu odebrat práva, což je docela povedené chyba :-) WordPress se tomu většinou sám snaží zabránit, aby vždy existoval nějaký administrátor a nebylo potřeba si “hrát” v databázi se serializovanými hodnotami, ale v tomto případě to patrně někde proklouzlo. Doporučil bych asi do budoucna testovat mimo administrátorský účet (může se chovat trochu jinak), mělo by stačit si vytvořit nějakého testovacího zákazníka…
@syrda: Na
wordpress.orgnemůžete mít hosting, to je doména pro opensource projekt WordPress. Pokud máte hosting na doméněwordpress.com, tak jste správně našel v manuálu, že přístup na FTP nedostanete. K čemu ho vlastně vůbec potřebujete?V podstatě by mělo stačit v databázi (tabulka
wp_posts) jen změnit hodnotu sloupečkupost_type. Ale doporučil bych asi jednoduchý plugin Post Type Switcher, který to umožní provádět přímo v administraci WordPressu a je velmi povedený. Pokud máte článků mnoho, tak to lze automatizovat, např. pomocí pluginu Convert Post Types (nebo opět ručně přímo v databázi).To by neměl být problém, většinou je to otázka chvilky (i včetně importu demo dat, pokud jde o nový web), horší je pak nastavit vše tak, jak autoři šablony zamýšleli :-) Pokud se nikdo neozve, tak napište, domluvíme se…
Omlouvám se, ale nějak jsem to nepochopil :-) Co vlastně konkrétně potřebujete? Nainstalovat šablonu nebo něco upravit/nastavit?
Teď jsem to zkoušel a místo “Smazat” tam mám všude “Odstranit” a soubor není smazán, ale pouze přesunut do koše (viz screenshot).
Attachments:
Plugin Google Sitemap by BestWebSoft používá mnoho lidí, ale pouze pár jich má podobný problém. Buď to bude souviset s nějakým nastavením serveru nebo tam je konflikt s jiným pluginem (či šablonou), uvidíte, jestli se to dořeší až vyjde nová verze…
Každopádně bych se raději do budoucna zbavil i výše uvedených zastaralých pluginů :-)
21. října 2016 (14:35) odpověď na téma: Woocomerce zobrazení uživatelských vlastností produktu #29483Přílohu se nepodařilo nahrát?
Obecně je název napojen na akci
woocommerce_single_product_summary, konkrétně takto:add_action( 'woocommerce_single_product_summary', 'woocommerce_template_single_title', 5 );A funkce
woocommerce_template_single_title()zobrazuje obsah souborutemplates/single-product/title.php, takže by mělo stačit pokud si vytvoříte nějakou vlastní funkci, které bude zobrazovat uživatelské vlastnosti a napojíte ji na akciwoocommerce_single_product_summarys trochu vyšší prioritou (aby se načítala až po názvu).Perfektní, pokud na něco narazíte, tak dejte prosím vědět, zařadím si to sbírky obskurních chyb :-)
Tak už se tam
navigation.jsnačítá, i když tam ještě nedávno nebyl. Nevím, přijde mi to podivné, ale možná jste to opravil…Každopádně bude patrně problém v úpravách šablony, přijde mi, že tam máte kombinaci staré a nové verze, např. soubor
wp-content/themes/padhang/js/jquery.slicknav.js, který tam na serveru vidím, by neměl být ve verzi 1.0.3 obsažen, ale je až součástí nové verze 1.1.0, takže byste ho tam zatím neměl vůbec mít?Těžko říci co s tím, šablona už se patrně nebude do budoucna aktualizovat (i když kdo ví), takže odvozená šablona nemusí být nutná. Na druhou stranu by se tím hezky oddělily provedené úpravy a věděli bychom, zda je to chyba šablony nebo provedených úprav. Vytvoření odvozené šablony by neměl být problém, musíme pouze porovnat čistou verzi 1.0.3 s upravenou verzí nasazenou na webu a následně provedené úpravy správně oddělit. Pokud budete mít zájem, tak je možné to provést v rámci placené zakázky.
Schválně jsem šablonu Lifestyle (odvozená šablona pro Omega) vyzkoušel a to mobilní menu mi moc nefungovalo (zcela odskočilo někam mimo web)?
Mobilní menu je řešeno JavaScriptovým souborem tinynav.js, který je ale správně načítán prostřednictvím funkce wp_enqueue_script() v rámci
inithooku, takže se ho můžete zase snadno zbavit:function separatista_lifestyle_setup() { remove_action( 'init', 'lifestyle_init', 1 ); } add_action( 'after_setup_theme', 'separatista_lifestyle_setup', 12 );Kam tento kód přesně vložit naleznete v našem návodu.
Původní dotaz je zde.
20. října 2016 (13:21) odpověď na téma: Problém s nastavením popisku tlačítka, a vyhledávání. #29468Ať se daří :-) Jestli budete mít čas, tak by to chtělo ještě upozornit autora, aby opravil
textdomaina mohlo se snadno překládat pomocí pluginu Loco Translate…Použitá šablona Padhang už nebyla více než dva roky aktualizována, takže možná není zcela kompatibilní s nejnovějším WordPressem 4.6.1 (nebo nějakým pluginem) a dochází tam k JavaScriptovému konfliktu.
Po chvíli: Díval jsem se ještě do konzole prohlížeče a nenačítá se tam soubor
/wp-content/themes/padhang/js/navigation.jsa ani ho nelze zobrazit. Můžete zkontrolovat, zda ho máte na FTP a nic mu nebrání v zobrazování (např. CHMOD)? Nepoužíváte nějaký bezpečnostní plugin?A po další chvíli: Ale nakonec ještě koukám, že máte sice verzi šablony 1.0.3, ale dostupná je ještě 1.1.0, která už tento soubor neobsahuje? Vypadá to, že máte nějakou kombinaci verzí 1.0.3 a 1.1.0, což patrně způsobuje popisovaný problém s načítáním menu…
@ota.n: Aha, už asi vidím souvislost :-) Jen pozor, pokud to maže nějaký skript automaticky, tak je možné tento koš obejít (stejně jako u příspěvků). Pokud to ale někdo maže ručně, tak by to mohlo pomoci (pokud koš samozřejmě nevysype)…
Zajímavé, jako prvního podezřelého bych asi viděl právě plugin Post Expirator, i když by podle popisu neměl mazat mediální soubory… Nebo by to mohl dělat nějaký jiný (např. optimalizační) plugin?
Děje se to pouze u příspěvků, které byly pomocí tohoto pluginu přesunuty do archivu? Děje se to u všech příspěvků nebo konkrétního typu souboru (nebo mají něco společného)? Odkazy v příspěvku zůstanou, ale nefungují? Odkazovaný soubor neexistuje ani na FTP ani v databázi?
Pomohl mi hosting.
@ota.n: Do souboru
wp-config.phpse musí přidat následující:define('MEDIA_TRASH', true);Potom jsou i smazané mediální soubory nejdříve odstraněny do dočasného koše (jako u příspěvků) a můžete je snadno obnovit. Dříve to bývala docela oblíbená funkce, ale možná bude do budoucna z WordPressu zcela odstraněna, nevidím ji ani v oficiální dokumentaci (anglicky).
Ano, díky, už jsem na to přišla.
Takže nakonec pomohl hosting nebo máte vlastní zálohy? Každopádně díky za celý dotaz, nikdy jsem si neuvědomil, že se mohou vlastně i smazat obrázky, které uživatel nahrál a jsou použité na stránce, kterou nevytvořil…
Musíte mít nějakou zálohu dostupnou (buď na straně hostingu nebo zálohujete sama pomocí nějakého pluginu/služby). Potom je vhodné web na chvíli “odstavit” a nahrát na FTP soubory ze zálohy + importovat databázi. Ale různých postupů je mnoho, záleží i hodně na tom, jaký používáte případně plugin. Nejjednodušší řešení je asi u některých hostingů, kde mají přímo v administraci možnost obnovit starší zálohu…
-
AutorPříspěvky
