Výsledky hledání (Hledáno: Nastavení SEO)
03. srp 2016 16:39
Odpověď od Jarda
Teď jsem ještě zjistil, že pokud zvolím jako úvodní stránku jinou stránku z horního menu, tak se zobrazí správně - ale pouze jako úvodní a všechny odkazy v horním menu ale pak nefungují, ostatní odkazy fungují.
Ještě píší v nápovědě, ale nevím co to znamená: anglicky umím hovorově, ale ne nijak programátorsky abych to přelouskal v další nápovědě
Aktualizace robots.txt
Od verze 3.3.0
V Joomla! 3.3 byla provedena změna souboru robots.txt, jejímž účelem je pro vylepšení SEO, ve výchozím nastavení, povolení přístupu Google botům k souborům šablon a médiím. Tato změna není při aktualizaci automaticky aplikována, uživatelům je doporučeno zkontrolovat změny v souboru robots.txt.dist a tyto změny použít v jejich vlastním souboru robots.txt.
Skrýt informaci
Aktualizace .htaccess & web.config
Od verze 3.4.0
V Joomla 3.4 byla provedena změna výchozích souborů .htaccess a web.config, jejímž účelem je zakázat ve výchozím nastavení výpis složek. Uživatelů, je doporučeno tuto změnu na jejich soubory použít. Více informací najdete na této stránce.
Ještě píší v nápovědě, ale nevím co to znamená: anglicky umím hovorově, ale ne nijak programátorsky abych to přelouskal v další nápovědě
Aktualizace robots.txt
Od verze 3.3.0
V Joomla! 3.3 byla provedena změna souboru robots.txt, jejímž účelem je pro vylepšení SEO, ve výchozím nastavení, povolení přístupu Google botům k souborům šablon a médiím. Tato změna není při aktualizaci automaticky aplikována, uživatelům je doporučeno zkontrolovat změny v souboru robots.txt.dist a tyto změny použít v jejich vlastním souboru robots.txt.
Skrýt informaci
Aktualizace .htaccess & web.config
Od verze 3.4.0
V Joomla 3.4 byla provedena změna výchozích souborů .htaccess a web.config, jejímž účelem je zakázat ve výchozím nastavení výpis složek. Uživatelů, je doporučeno tuto změnu na jejich soubory použít. Více informací najdete na této stránce.
17. kvě 2016 21:09
Asi hodinku jsem pátral, jak v J!3.5 deaktivovat zobrazení titulku kategorie u zobrazení článku. I když jsem měl všude v Globálním nastavení článků i v nastavení položky nabídky vše označené jako "hide", stejně se mi titulek kategorie nad titulkem článku stále zobrazoval.
To by mi ani tak nevadilo, ale titulek kategorie měl stejný tag H1 jako titulek článku, a to už není SEO friendly.
Na webu jsem nacházel mnoho trápících se Joomlistů a jejich řešení úpravou kódu.
Jak titulek kategorie u výpisu článků skrýt jednoduše?
1) Jděte do administrace položky nabídky, která například Blog kategorie zobrazuje.
2) Dále na "Zobrazení stránky".
3) Nastavte "Zobrazit titulek stránky" na "Ne"
Hotovo.
Náhled: prntscr.com/b58ccm
Vypadá to třeba jako banalita, ale někomu to může ušetřit hodiny času
MaK.
To by mi ani tak nevadilo, ale titulek kategorie měl stejný tag H1 jako titulek článku, a to už není SEO friendly.
Na webu jsem nacházel mnoho trápících se Joomlistů a jejich řešení úpravou kódu.
Jak titulek kategorie u výpisu článků skrýt jednoduše?
1) Jděte do administrace položky nabídky, která například Blog kategorie zobrazuje.
2) Dále na "Zobrazení stránky".
3) Nastavte "Zobrazit titulek stránky" na "Ne"
Hotovo.
Náhled: prntscr.com/b58ccm
Vypadá to třeba jako banalita, ale někomu to může ušetřit hodiny času
MaK.
16. kvě 2016 12:09
Pluginy jsou dobrý, pokud jde např. o zobrazení něčeho (nebo změnu zobrazení něčeho - jako se tomu děje při zobrazování článků - např. pomocí pluginu se dodá fotka, mapa, ...)
Tady jsou dvě strany - výstupní a vstupní - může se zdát, že udělat plugin pro výstup (změna textového pole na select box) je jednoduchá, jenže jsou tam pak vlastnosti, jako přepočítávání cen za pomocí javascriptu, kdy vlastně celej systém reaguje na změnu pole počtu kusů, a to už je složitější, aby systém reagoval na něco, co neexistuje a může existovat jen za pomocí pluginu.
Na straně vstupní je to ještě horší - nechat plugin, aby kontroloval počet kusů, to už taky může být otevřená bezpečnostní díra do komponenty - navíc by ten plugin musel být aktivní na více místech (kusy pro jeden výrobek, kusy pro celou objednávku, atd.)
Takže by to taky mohlo dopadnout tak, že by pro každou takovouto vlastnost byl plugin (když to přeženu, např. proto, aby se cena obarvila do červena) a pak zase postupně ztrácíme kontrolu nad kódem
Já o tom přemýšlím, dát to jako všeobecný pravidlo, pokud zatím uvažuju jen o výstupu, např. select box místo textového pole pro počty kusů, může být jednoduchý, jenže pak bude v eshopu produkt, kde tohle pravidlo nebudeme chtít použít, takže stejně nezbývá nic jinýho než to pravidlo přesunout na produkty a tam je zase problém, že by to člověk musel nastavovat pro každou položku zvlášť. No a pokud by se to udělalo kombinovaně, tedy všeobecné nastavení a případně v produktu lze změnit, a pak bychom přidali víc podobných pravidel, dostáváme se do podoby VM, kde prostě mnoho uživatelů už vůbec netuší, kde se co nastavuje a kde nastavení nefunguje, protože např. bylo přepsáno jiným pravidlem úplně na jiném místě
Odpověď od H13
A co takovéhle "speciality" netahat do obecných pravidel, ale jen umožnit podobné věci řešit pluginům?
Pluginy jsou dobrý, pokud jde např. o zobrazení něčeho (nebo změnu zobrazení něčeho - jako se tomu děje při zobrazování článků - např. pomocí pluginu se dodá fotka, mapa, ...)
Tady jsou dvě strany - výstupní a vstupní - může se zdát, že udělat plugin pro výstup (změna textového pole na select box) je jednoduchá, jenže jsou tam pak vlastnosti, jako přepočítávání cen za pomocí javascriptu, kdy vlastně celej systém reaguje na změnu pole počtu kusů, a to už je složitější, aby systém reagoval na něco, co neexistuje a může existovat jen za pomocí pluginu.
Na straně vstupní je to ještě horší - nechat plugin, aby kontroloval počet kusů, to už taky může být otevřená bezpečnostní díra do komponenty - navíc by ten plugin musel být aktivní na více místech (kusy pro jeden výrobek, kusy pro celou objednávku, atd.)
Takže by to taky mohlo dopadnout tak, že by pro každou takovouto vlastnost byl plugin (když to přeženu, např. proto, aby se cena obarvila do červena) a pak zase postupně ztrácíme kontrolu nad kódem
Já o tom přemýšlím, dát to jako všeobecný pravidlo, pokud zatím uvažuju jen o výstupu, např. select box místo textového pole pro počty kusů, může být jednoduchý, jenže pak bude v eshopu produkt, kde tohle pravidlo nebudeme chtít použít, takže stejně nezbývá nic jinýho než to pravidlo přesunout na produkty a tam je zase problém, že by to člověk musel nastavovat pro každou položku zvlášť. No a pokud by se to udělalo kombinovaně, tedy všeobecné nastavení a případně v produktu lze změnit, a pak bychom přidali víc podobných pravidel, dostáváme se do podoby VM, kde prostě mnoho uživatelů už vůbec netuší, kde se co nastavuje a kde nastavení nefunguje, protože např. bylo přepsáno jiným pravidlem úplně na jiném místě
16. kvě 2016 11:03
Odpověď od Teofil
Jo to je pravda. Pokud člověk nedělá často ve VM, tak jeho nastavení nějakou chvíli trvá.Cony napsal:
A co takovéhle "speciality" netahat do obecných pravidel, ale jen umožnit podobné věci řešit pluginům? Přišlo by mi super mít co nejjednoduší shop s co nejjednoduší administrací, a kdybych potřeboval něco podobného, doinstaloval bych plugin, což by mi zaplo např. v tomto případě editační políčko v produktu na počty ks, změnilo ve FE input na select a třeba kontrolovalo počty v košíku... Druhý plugin by zas mohl být na kontroly počtu všech položek v košíku atd atd...H13 napsal: ...pořád nevím, jak tohle dát do všeobecných pravidel, to bude opravdu muset být nějaká modifikace přímo pro konkrétní e-shop
Při snaze o zabudování do jádra bych se obával "překomplikovanosti" typu VM...
Nejnovější příspěvky
