Joomla 5.2.2 Security & Bugfix Release
Joomla 5.2.2 je nyní k dispozici. Jedná se o bezpečnostní vydání pro Joomla 5.x.
Jak poznat, co vic zatezuje Joomlu?
09. bře 2015 12:00 #120755
Odpověď od radek
Zkušený uživatel
Aha, takze to nema smysl se v tom babrat, protoze to stejne nezjistim. Debug jsem zkousel, ale nic z toho nepoznam. Jediny me prave prekvapilo, ze pocitove je ten flash na webu rychlejsi, nez ten graf od Joomlartu. Ten modul od JA umoznuje tahat data z Googlu, ale ja mu je dal primo, takze se nikde na nic nepta.
Joomlu mam na Nginxu, jestli to ma vliv i na tohle netusim.
Zatim jsem to vyresil tak, ze jsem si na zkusebni instalaci udelal graf ve flashi, udelal z toho fotku a na web dal screen. Pritom mne stacil jen obycejnej progres bar nebo jak se tomu v tom bootstrapu rika, ale Rockettheme to nema nikde popsany pro blbecky.
Joomlu mam na Nginxu, jestli to ma vliv i na tohle netusim.
Zatim jsem to vyresil tak, ze jsem si na zkusebni instalaci udelal graf ve flashi, udelal z toho fotku a na web dal screen. Pritom mne stacil jen obycejnej progres bar nebo jak se tomu v tom bootstrapu rika, ale Rockettheme to nema nikde popsany pro blbecky.
09. bře 2015 12:32 #120757
Phoca Cart - www.phoca.cz/phocacart - e-shop, e-commerce
Phoca Gallery - www.phoca.cz/phocagallery - obrázková galerie
Phoca Download - www.phoca.cz/phocadownload - stahování souborů
Phoca Guestbook - www.phoca.cz/phocaguestbook - guestbook
Odpověď od H13
Admin
Ahoj, no právě, pocitově - záleží na tom, jak rychle se např. zpracuje javascript a flash v uživatelově prohlížeči, to v podstatě nemá s tvým serverem co společnýho.
Jde o to jakej je cíl:
a) snížit zátěž serveru - pak přes debug mode - jednou nahrát ten script v pluginu - zjistit údaje o MB a čase a pak ho nahrát z modulu a porovnat to (vícektrát) - to se bavíme jen o zátěži serveru - vlastně jen o tom, kolik toho musí poslat. Např. když se pár věcí tahá z externího sereru, někdo to může být rychlejší, někdy pomalejší ale pro server je to úleva. Příklad s fonty: tahat fonty z google font directory může významně šetřit server - otázka je, jestli to je rychlejší nebo ne - záleží, kterej server v daný chvíli bude rychlejší
b) co nejrychleji uživatelovi nahrát kompletní script - pak opravdu záleží na testech v prohlížeči, ale to už je v podstatě hodně těžko měřitelný (připojení k internetu, server, externí server, nějaká chyba na cestě, prohlížeč, výkon PC (např. pro běh javascriptu nebo flashe), program pro běh flashe, atd. atd.)
Pokud a) pak debug mode prostě řekne: v tomhle případě jsem musel poslat tolik a tolik MB a stálo mě to tolik a tolik času a v druhým případě to bylo o nějakej ten KB míň a časově o pár setin míň. Atd.
Jde o to jakej je cíl:
a) snížit zátěž serveru - pak přes debug mode - jednou nahrát ten script v pluginu - zjistit údaje o MB a čase a pak ho nahrát z modulu a porovnat to (vícektrát) - to se bavíme jen o zátěži serveru - vlastně jen o tom, kolik toho musí poslat. Např. když se pár věcí tahá z externího sereru, někdo to může být rychlejší, někdy pomalejší ale pro server je to úleva. Příklad s fonty: tahat fonty z google font directory může významně šetřit server - otázka je, jestli to je rychlejší nebo ne - záleží, kterej server v daný chvíli bude rychlejší
b) co nejrychleji uživatelovi nahrát kompletní script - pak opravdu záleží na testech v prohlížeči, ale to už je v podstatě hodně těžko měřitelný (připojení k internetu, server, externí server, nějaká chyba na cestě, prohlížeč, výkon PC (např. pro běh javascriptu nebo flashe), program pro běh flashe, atd. atd.)
Pokud a) pak debug mode prostě řekne: v tomhle případě jsem musel poslat tolik a tolik MB a stálo mě to tolik a tolik času a v druhým případě to bylo o nějakej ten KB míň a časově o pár setin míň. Atd.
Phoca Cart - www.phoca.cz/phocacart - e-shop, e-commerce
Phoca Gallery - www.phoca.cz/phocagallery - obrázková galerie
Phoca Download - www.phoca.cz/phocadownload - stahování souborů
Phoca Guestbook - www.phoca.cz/phocaguestbook - guestbook
09. bře 2015 12:37 #120758
Odpověď od Cony
Moderátor
Nemyslím že si odporujeme
Modul se vykresluje pouze tehdy, je-li aktivní pro právě zobrazenou položku menu. Druhá věc je, jestli se pak vykreslí nebo ne. Může mít v sobě nějakou další zabudovanou logiku, která jeho obsah vykreslí v závislosti na právě zobrazeném obsahu (typicky např. související články, články z kategorie v dynamickém módu, nebo vlastně i modul nabídky).
Oproti tomu Content plugin dostane vždy a pro každý článek jeho obsah, a má možnost tento obsah upravit. Pokud jej upraví a jak, je už v jeho pravomoci.
Myslím že tedy hlavně záleží na tom, kde chcete příslušný obsah zobrazit.
Já bych se spíše ale klonil k modulu, protože Content plugin vždy bude muset dělat navíc nějakou kontrolu, zda obsah upravit nebo ne. Navíc pro stránky typu blog se Content plugin spustí tolikrát, kolik je na stránce článků, popř. i modulů se zapnutou možností Připravit obsah. Ano v něm být nějaká triviální kontrola, zda obsah upravovat nebo ne (podle kontextu nebo rychlým hledáním tagu v obsahu), ale vždy je to o trochu "zátěžovější" než modul (i když minimální).
Vyjímkou by pak mohl být např. plugin čerpající informace z právě zobrazeného článku - tam by modul musel provádět další akce a dotazy do databáze aby měl stejné informace jako plugin - v takovém případě by plugin byl asi vhodnější.
Modul se vykresluje pouze tehdy, je-li aktivní pro právě zobrazenou položku menu. Druhá věc je, jestli se pak vykreslí nebo ne. Může mít v sobě nějakou další zabudovanou logiku, která jeho obsah vykreslí v závislosti na právě zobrazeném obsahu (typicky např. související články, články z kategorie v dynamickém módu, nebo vlastně i modul nabídky).
Oproti tomu Content plugin dostane vždy a pro každý článek jeho obsah, a má možnost tento obsah upravit. Pokud jej upraví a jak, je už v jeho pravomoci.
Myslím že tedy hlavně záleží na tom, kde chcete příslušný obsah zobrazit.
Já bych se spíše ale klonil k modulu, protože Content plugin vždy bude muset dělat navíc nějakou kontrolu, zda obsah upravit nebo ne. Navíc pro stránky typu blog se Content plugin spustí tolikrát, kolik je na stránce článků, popř. i modulů se zapnutou možností Připravit obsah. Ano v něm být nějaká triviální kontrola, zda obsah upravovat nebo ne (podle kontextu nebo rychlým hledáním tagu v obsahu), ale vždy je to o trochu "zátěžovější" než modul (i když minimální).
Vyjímkou by pak mohl být např. plugin čerpající informace z právě zobrazeného článku - tam by modul musel provádět další akce a dotazy do databáze aby měl stejné informace jako plugin - v takovém případě by plugin byl asi vhodnější.
09. bře 2015 12:47 #120759
Odpověď od radek
Zkušený uživatel
No ja myslim, ze staci:), uz v tom mam hokej a to jsem to radsi nezkousel. Uz toho na me zacinate poustet moc:)
H13
Jaky je cil? Oba. Snizit zatez serveru a rychle to zobrazit uzivatelovi. Vypada to, ze se to asi vylucuje. Nicmene, toto uz je fakt mimo me. Uz ted se v Joomle motam jak mantak a delat jeste tohle, tak si muzu vzit rovnou i dovolenou. Takze diky za vysvetleni, ale k akci asi nedojde.
Cony
Mne prave prislo, ze jste si odporovali, protoze H13 napsal, ze zalezi, jak je to napsany a ja si vydedukoval, ze to muze byt napsany tak, ze se sice modul ma zobrazit pouze na dane strane, ale ze pokud je nejakym zpusobem napsany, tak se klidne muzou napriklad jeho CSS nebo JS nacitat i tam, kde neni zobrazenej. Proste globalne, ale to je jedno. Na to uz kaslu, protoze to uz neni v mych silach.
Ptal ses, kde chci obsah zobrazot. Netusim, cos tim myslel. Myslis tim stranku? Protoze ja to chci zobrazit jen na strance, do ktere se vlozi kod ke spusteni.
Znamena to teda, ze content plugin funguje takto? Zkusim to polopate.
Na web mne prijde najednou 10 lidi. Z toho 2 se dostanou na stranku, kde se ma spustit ten plugin. On bude ale spustenej i na tech zbyvajicich 8 strankach, ale jen nezobrazi obsah, protoze v clanku nenajde kod ke spusteni?
H13
Jaky je cil? Oba. Snizit zatez serveru a rychle to zobrazit uzivatelovi. Vypada to, ze se to asi vylucuje. Nicmene, toto uz je fakt mimo me. Uz ted se v Joomle motam jak mantak a delat jeste tohle, tak si muzu vzit rovnou i dovolenou. Takze diky za vysvetleni, ale k akci asi nedojde.
Cony
Mne prave prislo, ze jste si odporovali, protoze H13 napsal, ze zalezi, jak je to napsany a ja si vydedukoval, ze to muze byt napsany tak, ze se sice modul ma zobrazit pouze na dane strane, ale ze pokud je nejakym zpusobem napsany, tak se klidne muzou napriklad jeho CSS nebo JS nacitat i tam, kde neni zobrazenej. Proste globalne, ale to je jedno. Na to uz kaslu, protoze to uz neni v mych silach.
Ptal ses, kde chci obsah zobrazot. Netusim, cos tim myslel. Myslis tim stranku? Protoze ja to chci zobrazit jen na strance, do ktere se vlozi kod ke spusteni.
Znamena to teda, ze content plugin funguje takto? Zkusim to polopate.
Na web mne prijde najednou 10 lidi. Z toho 2 se dostanou na stranku, kde se ma spustit ten plugin. On bude ale spustenej i na tech zbyvajicich 8 strankach, ale jen nezobrazi obsah, protoze v clanku nenajde kod ke spusteni?
09. bře 2015 13:41 #120763
Odpověď od Cony
Moderátor
No tak nějak, modul spouští šablona (ve vzácných případech, jako je např. loadmodule plugin se spustí i jinak, ale to bych do toho nemotal). Šablona se mrkne na konkrétní pozici a vybere si moduly, podle jejich nastavení, které by se měly zobrazit. Pak je jeden po druhém zavolá.
Modul se pak sám rozhodne, jestli něco vykreslí, přidá nějaké CSS nebo JavaScript a apod. Zde už záleží na tom jak je modul napsán, ale první omezení lze zaručit již v Joomle, tím že se nastaví pro vykreslení jen někde.
Content plugin oproti tomu spouští komponenty (tedy většinou ). Např. komponenta pro články, při zobrazení jednoho článku si načte údaje pro článek nějak si je předzpracuje a pak je pošle všem Content pluginům, které jsou aktivní.
Content plugin dostane informaci o článku, o tom že se jedná o zobrazení jednoho článku (tzv kontext) a pak si může zase dělat co chce. Měl by správně obsahovat kontrolu na kontext (tj. aby se opravdu spouštěl jen tam kde má a nezatěžoval systém) a obvykle (pokud se jedná o plugin typu nahraď {graph} za můj graf) rychlou kontrolu na výskyt hledaného tagu (např. {graph}). Aź pak by měl provádět složitější záměny, přidávání JS a CSS apod. Zde už opět záleží na tom jak je napsaný.
Oproti modulu, který se na jedné stránce spustí jen jednou (resp. tolikrát, kolikrát tam je zveřejněn) se Content plugin spustí pro každý obsah na stránce, tj. pro zobrazení typu Blog se spustí např. 10 krát - nemusí to být však na škodu, tady by už se to muselo asi opravdu zkoumat detailně přes debug.
S tím dotazem "Kde zobrazovat" jsem myslel spíš umístění na stránkách (v pozici pro modul, v hlavním obsahu apod.) i když, když o tom přemýšlím je to v podstatě jedno, modul v obsahu lze zobrazit pomocí loadmodule, plugin v modulu zas pomocí "Připravit obsah".
Modul se pak sám rozhodne, jestli něco vykreslí, přidá nějaké CSS nebo JavaScript a apod. Zde už záleží na tom jak je modul napsán, ale první omezení lze zaručit již v Joomle, tím že se nastaví pro vykreslení jen někde.
Content plugin oproti tomu spouští komponenty (tedy většinou ). Např. komponenta pro články, při zobrazení jednoho článku si načte údaje pro článek nějak si je předzpracuje a pak je pošle všem Content pluginům, které jsou aktivní.
Content plugin dostane informaci o článku, o tom že se jedná o zobrazení jednoho článku (tzv kontext) a pak si může zase dělat co chce. Měl by správně obsahovat kontrolu na kontext (tj. aby se opravdu spouštěl jen tam kde má a nezatěžoval systém) a obvykle (pokud se jedná o plugin typu nahraď {graph} za můj graf) rychlou kontrolu na výskyt hledaného tagu (např. {graph}). Aź pak by měl provádět složitější záměny, přidávání JS a CSS apod. Zde už opět záleží na tom jak je napsaný.
Oproti modulu, který se na jedné stránce spustí jen jednou (resp. tolikrát, kolikrát tam je zveřejněn) se Content plugin spustí pro každý obsah na stránce, tj. pro zobrazení typu Blog se spustí např. 10 krát - nemusí to být však na škodu, tady by už se to muselo asi opravdu zkoumat detailně přes debug.
S tím dotazem "Kde zobrazovat" jsem myslel spíš umístění na stránkách (v pozici pro modul, v hlavním obsahu apod.) i když, když o tom přemýšlím je to v podstatě jedno, modul v obsahu lze zobrazit pomocí loadmodule, plugin v modulu zas pomocí "Připravit obsah".
09. bře 2015 13:47 #120767
Odpověď od radek
Zkušený uživatel
Aha.
No tak modul jsem chtel zobrazit v clanku. Je to lepsi. Na druhou stranu je docela dost blby, ze pokud budu mit na webu rekneme 30 grafu, tak budu muset mit 30 modulu. Kdezto s tim pluginem mam porad 1 plugin.
Ono by asi bylo fakt nejlepsi pouzit nejakej kod z Bootstrapu a nemusim mit ani plugin, ani modul. Jenze s tim moc neumim a hlavne cisty kody primo z Bootsrap vetsinou nefunguji v RT sablonach. Zase by se asi muselo neco upravovat. Uz me u RT stvou, nemaji zadny shortcodes apod, jaok ostatni.
No tak modul jsem chtel zobrazit v clanku. Je to lepsi. Na druhou stranu je docela dost blby, ze pokud budu mit na webu rekneme 30 grafu, tak budu muset mit 30 modulu. Kdezto s tim pluginem mam porad 1 plugin.
Ono by asi bylo fakt nejlepsi pouzit nejakej kod z Bootstrapu a nemusim mit ani plugin, ani modul. Jenze s tim moc neumim a hlavne cisty kody primo z Bootsrap vetsinou nefunguji v RT sablonach. Zase by se asi muselo neco upravovat. Uz me u RT stvou, nemaji zadny shortcodes apod, jaok ostatni.