Pokročilé hledání ve fóru

Ano ty odkazy jsem všechny smazal už před migraci na Joomla 4. A pak si nechal vytvořit nové. Ono já se s tím už natrápil s těmi odkazy, už v předešlých verzích Joomla. Já totiž dávám nějaké odkazy do fóra do TOP menu, ale mám zkušenost, že uživatelé na mobilech často toto menu nevidí. Ptal jsem se jich často v diskuzi a mnozí o tom vůbec nevěděli, že je tam nahoře TOP menu, protože na mobilu to většinou není vidět a musí se to prvně nějak rozkliknout. Proto vytvářím nový modul s nabídkou a dávám jej někam na web do postranního sloupce a ten je pro lidi s mobilem a tam vytvářím nové odkazy na Kunenu. Čili některé odkazy mám dva stejné na webu i když mají jiný název a ono se to asi hádá.
Ale... nyní jsem vypnul, jak jste mi radil, ono SEF URL (to je to přátelské URL že?) a sice indexování to nepomohlo, ale pomohlo to těm odkazům na Kunenu. Mohu mít nyní všechny odkazy i dvojité a i vyhledávání klasické v Kunena funguje (dříve nešlo po zveřejnění odkazů odpovídat ve fóru). Jen nevím jestli to tak nyní mohu nechat? To vypnuté SEF URL? Mohu to tak nechat nebo to něčemu vadí? 

Ano tlačítko s překladem funguje už správně, děkuji.

*doplnění: koukám, že to asi vadí. Modul s komentáři k článkům neodkazuje nyní správně na články. I odkazy mnou vložené v článcích na jiné články na webu také přestaly fungovat. Tak to musím asi vrátit zpět.

No je to zvlastni

Není, zvláštní je jaké nepochopitelné kroky děláte Vy?
Jak můžete přesunout J3 na PHP8 aniž si předem zjistíte jestli všechny aplikace co v ní máte na této verzi PHP poběží?

Přehoďte to na PHP 7.4, aktualizujte všechna rozšíření, protože Vám i na této verzi možná staré verze nepojedou.

Následně můžete teprve pouvažovat o upgradu J4 - ta běží i na PHP7.4
Zkušenosti máte již z minulého upgradu, takže stejný postup.
Až budete mít hotovo, pak můžete přesouvat na PHP8, ale jak psal Cony, budete mít problémy, pochybuji že všechna rozšíření mimo Joomla jsou již odladěny pro PHP8.

pri upgradu na J3 admin joomly hlasil ze chybi user ID XXX

To je chyba která se stala při migraci a podle mne souvisí s tím, že máte někde v administraci něco (článek, kategorii, menu, akci...) co jste vytvořil pod uživatelem ID XXX a následně ho smazal.
Běžnému provozu to nevadí == není kritická chyba, ale opravit by se to mělo.
Pokud například používáte rich snippets (což vám gratuluji, je to nutné pro vyhledávače), autor je jedna z povinných položek.

To by jste ale měl vidět v error logu migrátora a ten jak jste asi správně udělal, po přečtení dokumentace, jste si zapnul a sledoval. Můžete ho taky najít v DB tabulce logů migrátora, pokud jste nestihl.

Bong napsal: Ty uživatelské tabulky jsou:

_usergroups
_users
_user_keys
_user_notes
_user_profiles
_user_usergroup_map

Ještě mi občas na jednom webu zhavaruje

_session

Ale to se projeví nefunkčností stránek. Musí se tabulka úplně smazat a vytvořit znova. Ale tuším, že se to děje na J1.5.

zkusím tedy ze zálohy přetahat tyto tabulky. Pokud to nepomůže a problém bude jinde, tak kapituluji a budu do zálohy přetahovat články a fotky.

OPC od Rupostel tento checkbox má již dva roky pro italské zákony, takže pokud používáte OPC od Rupostelu, jen si to nastavíte v administraci.

Další aplikaci, kterou používáme je
storejextensions.org/extensions/gdpr.html

která obsahuje funkci anonymize a má v sobě tendenci vytvářet checkboxy u každého formuláře co najde na webu pomocí interních JS - osobně jsem tuto funkci raději vypnul (nedá se pak nastylovat a umístit tam kde ji chci mít), využíváme jen cookie modul a doprogramovali jsme funkci GDPR ji do Virtuemartu manuálně, dle přání klientů=>

1. Samostatný souhlas:
Zduplikovali jsme funkci ve VM, která vytváří souhlas s obchodními podmínkami == zásah do core VM a vytvořili duplicitní funkci pro GDPR včetně všech věcí okolo
2. Souhlas v rámci obchodních podmínek (alá bata.cz):
upravili jsme jazykovou konstantu pro odkaz na obchodní podmínky a do ní přidali odkaz na GDPR článek
Tohle asi bude pro Vás nejjednodušší, pro právníky možná neakceptovatelné, bohužel zákazníci na tom trvali

Další co používáme je aplikace od Joomlart:
www.joomlart.com/joomla/extensions/ja-joomla-gdpr-extension

která navíc řeší automatické emaily, dotazy klientů na archivovaná data, automatické žádosti na vymazání dat atd. atd.

Další aplikaci, kterou používáme a která dělá v podstatě to co my manuálně, ale na nových eshopech (myšleno ne na VM1.19, VM2.X) je
aplikace od Virtueplanet:
www.virtueplanet.com/extensions/privacy-policy-for-virtuemart

Když udělám resume:

GDPR a Virtuemart (seřazeno dle náročnosti použití):
1. Jednoduchá úprava obchodních podmínek v rámci override jazykové konstanty Souhlasu obchodních podmínek
2. OPC Rupostel - již existuje funkční řešení
3. Virtueplanet
4. Složitější úprava přidání duplicitní funkce pro GDPR do core kódu VM
5. JA GDPR, která řeší i automatické věci okolo

Jiné možnosti jsem nehledal a netestoval, kromě další aplikace, které jsme si koupili:
- GDPR od Richiho - www.richeyweb.com/software/joomla/134-gdpr-bundle

Ahoj všem, obracím se na vás, protože už nevím kde by mohl být zakopaný pes. Stránky mi běží relativně "v pohodě" vzhledem k tomu, že na hlavní stranu webu stahuji videa z YouTube a myslím, že zatím nevím jak je ještě výrazněji zrychlit. Mám JCH optimizer (zatím bezplatnou verzi) a Jot cache. Učím se s tím a zatím nijak neexperimentuji. Co mě však trápí, že se mi před několika dny "z ničeho nic" začala velmi zpomalovat komponenta K2 v administraci. Čekání na vytvoření článku přes administraci trvalo věčnost a zaznamenal jsem hodně krát chybu 503 (backend). K tomu se čas od času přidala i chyba 500 na hlavní straně webu (frontend). No a teď se to šíří jako nemoc a a už se v administraci velmi obtížně pohybuji v čemkoliv (vše hrozně dlouho trvá). Díval jsem i na databázi a tu mám 10 MB a a měla být v pohodě (tabulky jsem překontroloval a promazal jen inteligentní indexování dotazů - search, protože tam bylo 16 MB).

Napsal jsem i na hosting a tam mi bylo řečeno:

Větší počet PHP procesů není cesta, protože neefektivní web by vyčerpal
jakýkoliv sebevětší limit. Nicméně momentálně ani nemáte nastartovaný
maximální počet procesů. Memory_limit nemá na rychlost žádný vliv, má
vliv tehdy, kdy stránka přímo píšeš, že je problém s memory allocation.
Ale není to o rychlosti.

Problém je ve Vašem tvrzení, že frontend funguje dobře. Tak to bychom se
rozhodně neshodli. Ten web je neskutečně pomalý. A to jsem jej opakovaně
zkoušel spolu s jinými weby na stejném serveru, a to i s weby na WP a na
Drupalu. V tomto bude zakopaný pes. Pravděpodobně jste na stránkách
udělali nějakou úpravu nebo použili nějaký modul, který má vliv na
výkon. Máte v provozu cachovací plugin? Mám dobrou zkušenost s WP
Supercache (neprojeví se pro přihlášené uživatele, ale frontend velmi
radikálně zrychlí).

Problém je, že jsem nic "neinstaloval" nebo myslím, protože problém jsem zaznamenal až za poslední tři dny. Navíc jsem vypnul i ty poslední dvě instalované komponenty a stejně se nic nevyřešilo. Dále k žádné větší úpravě taky nedošlo, pokud neberu v úvahu drobné úpravy v customu pro šablonu (to přece nemá žádný vliv na zpomalení administrace). Stránky jsou pomalejší, ale nám to tolik nevadí, když se tam nahrávají a spouštějí videa. No a já teď nevím kde je vlastně ten problém. Řešil někdo něco podobného a nebo ví někdo kde by mohl být problém a jak to opravit?

Díky všem za radu.

Ďakujem Vám všetkým za príspevky, ďakujem veľmi pekne za nájdenie chyby a aj za všetky informácie.

V prvom rade chcem zdôrazniť, že ak aj ide o chybu includeitem.php = pluginu shortcodes od Linelabu, s prácou a podporou Linelabu som veľmi spokojný a môžem ju len odporúčať.
To, že sa po rokoch vyskytla nejaká chyba vplyvom ďalšieho pluginu (pravdepodobne zásielkovne, ako tu už bolo spomínané), navyše s neaktuálnou Joomlou..

Určite by som za nič nevinil Linelab a ďakujem im za ich prácu, podporu a pomoc (pred pár rokmi, keď bol môj web skutočne opakovane napadnutý nejakými spam/hackerskými robotmi tak mi linelab dali web do poriadku behom dňa núdzovú verziu a behom pár dní komplet celý web..).

S najväčšou pravdepodobnosťou to môže byť tak ako píše pán Zirhut, že fungovanie pluginu nejako ovplyvnila inštalácia Zásielkovne => Zásielkovňu som síce hneď potom odpublikoval a následne aj vymazal, no problém stále ostal (ale tak ja neviem nakoľko sa vymažú všetky dáta zásielkovne pri odinštalovaní, pretože na ftp aj v databáze som aj po odinštalovaní nejaké dáta o zasielkovni našiel). Pred inštaláciou Zásielkovne všetko v poriadku fungovalo, pokazilo sa to až inštaláciou zásielkovne (po cca 18 hodinách). - mimochodom keď som nad tým rozmýšľal tak posledné úpravy, ktoré som pred pokazením webu spravil bolo publikovanie 3 nových článkov v ktorých som použil plugin shortcodes s odkazovaním na najnovšie produkty.. To bolo prvý krát po inštalácii Zásielkovne, čo som pridal nový článok s shortcodes, takže teoreticky by to mohlo zapadať do tejto hypotézy..

Faktom však ostáva, že aj po odinštalovaní zásielkovne sa problém neodstránil - pomohlo len vypnutie pluginu shortcodes - alebo nahodenie zálohy webu z času pred inštaláciou zásielkovne (zatiaľ len na testovacom webe, aby som neprišiel o administratívne práce vykonané na webe).

Takže zatiaľ to je v takomto stave + mi linelab prisľúbil pomoc s opravou pluginu shortcodes, aj keď používam zastaralú verziu, ktorej podpora už skončila - čo ma prekvapilo a veľmi potešilo a veľmi pekne za to ďakujem.

Pán Zirhut, ďakujem Vám takisto za návod na opravu chyby modulu menulinelab - postupoval som podľa Vášho návodu a chyba je už odstránená - ďakujem veľmi pekne, vážim si Vašu pomoc a Váš čas, ktorý ste mi venovali, ďakujem.

[hr]
Mimochodom pri vytváraní testovacej verzie webu som si všimol, že na webe mám v hostingu nastavenú verziu PHP 5.6 a dostupné sú tam už aj 7.0 - 7.3 = napadlo mi, či by som mal vyskúšať zvýšiť verziu, či by to mohlo v niečom pomôcť, alebo naopak skôr uškodiť? Mohlo by to mať vplyv na vyriešenie chyby pluginu, alebo skôr nie?

Ešte raz všetkým veľmi pekne ďakujem za každý príspevok. Pre mňa osobne bol každý váš príspevok obrovským prínosom, ďakujem.

Krásnu sobotu prajem

pravdepodobne to spravim aj na ostrej verzii webu - obnovim zo zalohy, pridem o dva dni administrativnej prace ale vyriesim problem s includeitem.php a blank page

Toto mi přijde zbytečné, protože pokud je pravda co píšete hned v úvodu (že jste v posledních dnech kromě Zásilkovny nic jiného neinstaloval / neaktualizoval), tak v tom pluginu je pravděpodobně nějaká chyba a byla tam i před dvěma dny.... jen jste ji nevyvolal. Tudíž pokud vrátíte administrační práci o dva dny zpět a pak zopakujete stejné úpravy (články, produkty, apod.), tak je tu šance, že se problém objeví znovu .

Doporučuji se soustředit na tu chybu v pluginu a opravit ji. Případně pokud ho moc nevyužíváte a nechce se Vám platit za aktualizaci/podporu (nevím jaké máte možnosti, ale předpokládám, že jde o produkt Shortcodes Plugin for VirtueMart od Linelabu, že?), tak plugin vypnout.

Plugin nemusí být nutně špatně napsaný (jak tu někteří straší ), ale může tam být nějaká dosud neobjevená a neošetřená logická chyba (např. se snažíte zobrazit v článku produkt, který jste smazal), může jít o nekompatibilitu s něčím dalším co tam máte a nebo můžete mít jen starou neaktualizovanou verzi a plugin je tedy nekompatibilní s Joomla! nebo VM.

Nic konkrétního nelze poradit, to by člověk musel ten problém vidět, ale když opravíte/vypnete plugin, tak věřím, že máte po starostech a ušetříte dva dny práce...

Ano, děkuji za vysvětlení, ale to je nepodstatné.

Pohledem do kódu šablony:

Vůbec přeci není důležité kdy jste zakoupil šablonu. Šablona s tím nemá co dělat, to jen je utkvělá představa lidí co pracují s joomlou že zakoupí šablonu a tím mají o vše vystaráno a vše bude fungovat.
Víte kolik prodejců šablon jsou programátoři na baterky, kdy po zakoupení je nutné šablony opravit od jejich chyb?

Vidím co vidím a první chyba na ráně je plugin od K2 - plgUserK2, který je neustále aktivní (i když jak říkáte je vypnutý - pak je špatně naprogramovaný - pokud je vypnutý nemá přeci hlásit chybu) a je psaný pro php nižší než php7.
Je to na výpise viz příloha.

A jestliže máte pořád aktivní plugin na synchronizaci uživatelů Joomla do K2 (jinak by mi to při přihlášení tuto chybu nehlásilo), je velmi pravděpodobné že to souvisí s přihlášením, které děláte přes frontend.

Může to být také vymazaný uživatel nebo vypnutý bývalý admin, který psal články

Až se vyřeší tohle, je také velká pravděpodobnost, že se objeví další chyby a konečně projeví Vaše první hlášená chyba. A je taky velká pravděpodobnost, že již strávený čas diskusemi by se finančně vyplatil převést raději na objednání práce od profesionála - to už si musíte zhodnotit sám.

Tak zkouším (jak mi doporučil Noro) komponentu EasyArticles. Pro klienty, co si chtějí vkládat články sami, se mi to zdá jako nejlepší řešení, aby mi to neprasili (resp. zatím jsem lepší řešení nenašel). Navíc je nemusím pouštět do backendu a mohou nové články dělat na základě templates v EA, což je super.

Jedna věci mi tam ale nefunguje podle mých představ, a to jsou obrázky. Chci udělat šablonu článku, kde např. v levé polovině (50%) bude obrázek a v pravé polovině obtékající text, ale nevím jak správně na to.

Pokud otevřu v EasyArticles "normálně" udělaný článek s obrázkem pomocí tagu img, tak ho EA nevidí stejně jako když ho vložím přímo v EA pomocí ikony Media - nenabízí zarovnání, smazání,... A pokud obrázek vložím přímo v EA, přijde mi že to vygeneruje dost podivný kód.

A Templates mají udělané pomocí tabulek - to si taky nejsem jistý jestli je ten správný postup a zda to používat.

Máte někdo nějaké tipy a triky jak zmáknout EasyArticles? Díky.