Joomla 3.8 - Chyba 500 na vícejazyčném webu

Dobrý den,
mám problém na webu http://www.cech-pivo.cz, který už skoro týden marně řeším, tak se obracím na vás, jestli jste se s něčím podobným někdy nesetkali.

Mám stránky s Joomla 3.8, které provozuji v češtině a angličtině. Je tam jen několik málo článků, které mám zařazené do klasických Joomla kategorií. V češtině funguje všechno bez problémů, v angličtině mi web přestal fungovat. Nevím přesně kdy, ale všimnul jsem si toho minulý týden.

Odkazy z menu přímo na anglické články fungují, ale menu odkazy na anglické kategorie nefungují (viz například screenshot se zapnutým výpisem chyb). Už jsem zkoušel zakázat všechny možné pluginy, přeinstaloval jsem Joomla (včetně downgrade), zkoušel jsem instalovat různé verze komponent, ale všechno je marné.

Smazal jsem i všechny anglické články, kategorie a menu, vytvořil jsem novou anglickou kategorii a nové anglické menu s jednou položkou, ale pořád nefunguje.

Fungující česká verze: https://www.cech-pivo.cz/cs
Nefungující anglická verze: https://www.cech-pivo.cz/en (když stránku obnovuji, zobrazují se různé chyby)


Nemůže to třeba souviset s nějakou konfigurací PHP na serveru? Mě už nic nenapadá


Děkuji,
Martin Březa

Dobrý den,

Váš web se mi momentálně vůbec nezobrazuje, takže chybu nemůžu otestovat. Provádíte na něm nějaké úpravy?

Já ne. Kluci z c4.cz problém vyřešili tak, že databázi smazali. Bez konzultace či upozornění.

Dobrý den,

tak jen bych upřesnil, že "kluci" z C4 k tomu bohužel měli důvod. Byl Vám zaslán následující e-mail.
-------------------------------------------------
Dobry den,

od vcerejsiho dne jsme zaregistrovali velke problemy na nasem
databazovem serveru, kde hostuje databazi Vase domena http://www.cech-pivo.cz.

Postupnym setrenim bylo zjisteno, ze zavadu a padani celeho databazoveho
serveru zpusobuje databaze www-pivo.

Databazi jsme zkouseli opravit, vse se ale jako v poradku.

Nakonec jsme zjistili, ze problem zpusobuje urcity SQL dotaz:


Thread pointer: 0x7fe286f2d4c0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7fe0baa65dc0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fe2789e396d]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x7fe2785f9285]
/lib64/libpthread.so.0(+0xf5e0)[0x7fe277d265e0]
/usr/libexec/mysqld(+0x3962ef)[0x7fe2784ed2ef]
/usr/libexec/mysqld(_Z20get_best_combinationP4JOIN+0x35b)[0x7fe2784f3dcb]
/usr/libexec/mysqld(+0x3b73b3)[0x7fe27850e3b3]
/usr/libexec/mysqld(_ZN4JOIN8optimizeEv+0x675)[0x7fe278511625]
/usr/libexec/mysqld(_ZN13st_select_lex31optimize_unflattened_subqueriesEb+0xc8)[0x7fe2784c0b18]
/usr/libexec/mysqld(_ZN4JOIN8optimizeEv+0x1ec7)[0x7fe278512e77]
/usr/libexec/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0xc8)[0x7fe278513ae8]
/usr/libexec/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x2db)[0x7fe2785145fb]
/usr/libexec/mysqld(+0x36b9d9)[0x7fe2784c29d9]
/usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x45d1)[0x7fe2784cd001]
/usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x125)[0x7fe2784cf8c5]
/usr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1753)[0x7fe2784d1923]
/usr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x1c2)[0x7fe278583632]
/usr/libexec/mysqld(handle_one_connection+0x4a)[0x7fe2785836da]
/lib64/libpthread.so.0(+0x7e25)[0x7fe277d1ee25]
/lib64/libc.so.6(clone+0x6d)[0x7fe27651c34d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7fe068f5e9b8): SELECT a.id, a.title, a.alias, a.introtext,
a.fulltext, a.checked_out, a.checked_out_time, a.catid, a.created,
a.created_by, a.created_by_alias, CASE WHEN c.published = 2 AND a.state
> 0 THEN 2 WHEN c.published != 1 THEN 0 ELSE a.state END as state,CASE
WHEN a.modified = '0000-00-00 00:00:00' THEN a.created ELSE a.modified
END as modified, a.modified_by, uam.name as modified_by_name,CASE WHEN
a.publish_up = '0000-00-00 00:00:00' THEN a.created ELSE a.publish_up
END as publish_up,a.publish_down, a.images, a.urls, a.attribs,
a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference,
a.featured, a.language, LENGTH(a.fulltext) AS readmore,c.title AS
category_title, c.path AS category_route, c.access AS category_access,
c.alias AS category_alias,c.published, c.published AS
parents_published,CASE WHEN a.created_by_alias > ' ' THEN
a.created_by_alias ELSE ua.name END AS author,ua.email AS
author_email,parent.title as parent_title, parent.id as parent_id,
parent.path as parent_route, parent.alias as
parent_alias,COALESCE(NULLIF(ROUND(v.rating_sum / v.rating_count, 0),
0), 0) AS rating, COALESCE(NULLIF(v.rating_count, 0), 0) as
rating_count FROM chg_content AS a LEFT JOIN chg_categories AS c ON c.id
= a.catid LEFT JOIN chg_users AS ua ON ua.id = a.created_by LEFT JOIN
chg_users AS uam ON uam.id = a.modified_by LEFT JOIN chg_categories as
parent ON parent.id = c.parent_id LEFT JOIN chg_content_rating AS v ON
a.id = v.content_id WHERE a.access IN (1,1,5) AND c.access IN (1,1,5)
AND c.published = 1 AND a.state = 1 AND (a.catid = 12 OR a.catid IN (
SELECT sub.id FROM chg_categories as sub INNER JOIN chg_categories as
this ON sub.lft > this.lft AND sub.rgt < this.rgt WHERE this.id = 12))
AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2017-09-17
05:07:17') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down
>= '2017-09-17 05:07:17') AND a.language in ('en-GB','*') ORDER BY
a.created DESC , a.created LIMIT 12
Connection ID (thread ID): 19339
Status: NOT_KILLED

Vzhledem k zavaznosti problemu nebyla jina moznost, nez celou databazi
ze serveru odstranit a spolecne s tim pozastavit protokol http/https u
webu http://www.cech-pivo.cz.

Zalohu SQL dumpu jsem Vam umistil v rootu webu http://www.cech-pivo.cz do
slozky sql_dump/.

--
S pozdravem
Petr Skrabalek

Webhosting C4
ČESKÝ WEBHOSTING s.r.o.
Tel: +420 234 139 876
E-mail: info@c4.cz
http://www.c4.cz
-------------------------------------------------

Tolik k odstavení Vašeho webu.

Pokud se Vám web za poslední dobou začal chovat sám od sebe nestandardně, tipoval bych to na nějaký virus, který se do Joomly dostal přes neaktualizovanou komponentu.

Situaci jsme se nejdříve snažili řešit tak, že jsme Vaši doménu přesunuli na jiný webserver, ale tam začaly okamžitě problémy.

Ale to vše víte, protože probíhá komunikace i přes e-mail.

To se stalo teď nebo je to od začátku? Máte správně .htaccess a SEO URL? Máte tam skryté hlavní menu s nastavenou úvodní stránkou pro všechny jazyky a ostatní jazyky
mají také své úvodní stránky a nabídky?

Můžete to obnovit ze zálohy?

Já vím jedno. O žádných problémech jsem nevěděl a nikdo mě na žádné problémy neupozornil.
Když jsem si všimnul, že anglická část webu nefunguje, nahlásil jsem to na vaši podporu a reakcí bylo smazání webu. Opět bez jakékoliv konzultace či upozornění.

Na webu běžela téměř čistá instalace Joomla se zhruba 20-30 krátkými statickými články. Aktualizaci komponent (včetně samotné Joomla) jsem spouštěl každý pracovní den.

Před tím, než jsem o web úplně přišel a kdy jsem se ještě snažil problém najít, jsem web (mimo jiné) celý oskenoval - žádný virus ani malware jsem nenašel.


Jsem strašně zaskočen vaším postupem - 10 dní (jak říkáte) se bez úspěchu snažíte objevit nějaký problém, abyste celou situaci nakonec vyřešili smazáním databáze. Celých deset dní BEZ JAKÉHOKOLIV UPOZORNĚNÍ.

Můžete mi samozřejmě v odpověď na můj mail (uznávám, že rozezlený, ale kdo by zůstal v klidu?) naházet na hlavu čísel paragrafů ze smluvních podmínek kolik chcete, ale jako seriózní jednání mi to nepřijde ani náhodou.

Ale to, že jste napsal na podporu o problému s jazykovou mutací, nemá s pozastavením žádnou souvislost. Problémy s databází řešil kolega, který je linux administrátor. K tomu se Váš problém vůbec nedostal. Je to shoda náhod, o které si však myslím, že spolu nějak může souviset.

Krizová situace se na databázovém serveru projevila včera. Až po podrobném zkoumání logů bylo zjištěno, že k nějakým drobným problémům začalo docházet cca před týdnem. To, že to způsobuje právě Vaše databáze jsme odhalili dnes a web jsme pozastavili. Takže to není tak, že bychom o problému s Vaší databází věděli týden. Pokud bychom to věděli, tak bychom po Vás již dávno chtěli nápravu.

Již to bylo uvedeno v e-mailu, ale znovu připomínám, že zálohu databáze (před smazáním) máte uloženou na FTP. Stejně tak najdete přes FTP na backup serveru dumpy DB i obsah webu měšíc zpětně.

Skutečně nevím, jak bychom mohli situaci řešit jinak. Databáze měla negativní vliv na provoz celého serveru.

Dobrý den,
zkoušel jsem postupně instalovat zálohy mého webu od 15.9.2017 (jelikož se dle vašich informací problémy začaly objevovat od 17.9.2017) až po úplně první zálohu téměř prázdného webu ze srpna a všechny se chovají stejně - totiž nefunguje anglická verze (zobrazují se různé chyby, převážně "Failed to write session data").

Tak jsem si nainstaloval nejposlednější zálohu (kterou jsem si vytvořil naštěstí pár minut před smazáním databáze) na svůj lokální WAMP server a vše funguje bez problémů...

Proto opakuji svůj úplně první dotaz - nezměnili jste náhodou nějakou konfiguraci? PHP, databáze, server...

Pokaždé, když se snažím na Google dohledat nějaké informace k mému problému (ať už hledám problém s "Warning: session_write_close()", nebo jsem dal do vyhledávače celý ten dlouhý výše zmíněný problémový SELECT), vždy nakonec narazím na informace typu "hosting company has just changed something".

Nejvíce typů se týkalo nedostatku místa na účtu, popřípadě v /tmp...

P.S. Pro jistotu jsem to vyzkoušel na HTTP i HTTPS, ale bez úspěchu.

Dobrý den,

máme ověřeno, že i nejnovější verze 3.8.0 na našich serverech bez problému funguje. Ani s jazykovými mutacemi není žádný problém. A když na Váš web (příp. nějaký testovací) nahrajete čistou instalaci aplikace Joomla a nastavíte dvě jazykové mutace, tak se problém opakuje?