joomla frissítés elakad, majd se backend, se frontend

Internet: PHP, CGI, stb.

Igen.
Így, ahogy a tárgy szóban le van írva.

Állandó internet-kapcsolat, folyamatjelző majdnem a végére ér, majd hófehér üresség a böngészőben, a júzer meg csak nézi a csillogó-villogó CMS-t, hogy mit művel és üvöltve gondol arra, aki 7 évvel ezelőtt lebeszélt a saját cms fejlesztéséről (akkor még volt lelkesedésem).

Nem tudom, fog-e erre valaki bármit is reagálni, de amikor november óta ez már a harmadik hasonló eset, kissé elszáll az agyam tőle.
Ilyenkor ftp, teljes tartalom ismét föl darabonként, majd sql-import (ez utóbbi legalább már rutinszerű, hála a sok anomáliának).

Aztán mivel az ok ismeretlen, az megint jelentkezik, kávé a padlón, feláll, mélyeket lélegez és kimegy sétálni..

  • 3235 megtekintés

( gedez | 2016. 02. 05., p – 20:48 )

Akkor szokott előfordulni, ha rendszer valami miatt nem képes lefrissíteni magát. Ez lehet már egyébként megbuherált, feltört rendszer az oka, vagy éppen a futási idő nem volt elegendő, és csak befejezetlenül leállt, visszagörgetni meg tudja. Ha valamilyen PHP hibát ír, hogy nem találja valamilyen függvényt, akkor általában ezek valamelyikére vezethető vissza.

Előfordulhat, hogy a BME egyik gépéről (sajnálatos módon windowsról) indítva ezt a frissítést megszakad a kapcsolat, majd az amerikai szerver fogja magát és dob engem, joomla kitömörítés balga módon megszakad és amiatt van az agyhalál?

Semmilyen hibaüzenet nincs.
(ixwebhosting...)

---
--- A gond akkor van, ha látszólag minden működik. ---
---

Attól, hogy maga a kapcsolat megszakad, a PHP futhat tovább. A hibaüzenet kiírása ki van kapcsolva, akkor nem jelenik meg, error.log -ot kellene nézni hozzá. A tmp könyvtárba kitömörítés még nem okoz gondot, de ha azokat már elkezdi berakni a helyére, és időlimit miatt a futás megszakad, az már biztosan okozhat gondot.

Osztott a tárhely. A BME olvasótermében meg olyan lassú volta net, mintha eldugult volna a wc.

Sebaj, tegnap más anomália is keletkezett:
minden előzetes ok nélkül az admin elől zárolva lettek cikkek, modulok, mi több, még a saját profilbeállítások is az adminfelületen. Azt hittem megőrülök. Néztem a zárolt cikkeket a phpmyadminban, hátha rájövök hogy abban a sorban a többihez képest változott-e valami, de semmi, a zárolásokat valószínűleg nem a content-be menti el. Még nem jöttem rá hova. A dolog azért izgalmas, mert a kezelőfeleületen nincs ott a "lakat", mégis kijön a 403-as hibakód.

Nos, ez már 2 anomália egyetlen nap alatt, így arra jutottam, hogy a már két hónapja (!) vagy még több ideje tartó költöztetés során egyedül a contenttel foglalkozom, a jomla meg omolgasson össze ahogy tetszik. Amint kész a content, emelek köré egy jumlát óvatosan, majd nem nyúlok hozzá, nem frissítem, befagyasztom, és teszek rá ameddig magától meg nem murdál. Elegem van...

---
--- A gond akkor van, ha látszólag minden működik. ---
---

A zárolás-anomália megoldódott, tekintettel arra, hogy az OSZK olvasótermében nem tudok tombolni és bakancsban tányéron ugrálva levezetni a dühömet mint tegnap otthon.

Tehát a zárolási anomália ott kezdődött, hogy frontenden szerkesztettem egy cikket. Ezután azt rendesen elmentve, majd backenden megnézve már nem tudtam megnyitni. Lakat sehol. Zárolásnak semmi nyoma.

Most olvastam valahol, hogy van egy olyan, hogy globális visszavétel, ott láttam, hogy a contentben 34 tétel szerepel. Egyik fórumon azt írják, hogy a g.visszavétel hidegre vághatja az egészet, másik helyen meg pont ezt cáfolják. Backup all, majd próba. Sikerült. Utánanéztem:

"Általánosságban adatbázisban lévő táblák checked_out, illetve checked_out_time mezőjében szerepel, hogy ki szerkeszti az adott rekordot. A kis lakat akkor jelenik meg, ha ezekben a mezőkben van érték, illetve ezek alapján szolgáltat adatot a Joomla a kivétellel kapcsolatban. Amikor elkezdesz szerkeszteni valamit, akkor ide kerül be a felhasználói azonosítód és a módosítás kezdetének időpontja. Befejezésnél visszaáll 0-ra, illetve 0000-00-00 00:00:00 értékre.
A visszavétel, vagy globális visszavétel ezeket a mezőket nullázza ki.
"
Új ismerettel gazdagodott a hülyegyerek (mármint én)

---
--- A gond akkor van, ha látszólag minden működik. ---
---

( Dwokfur v | 2016. 02. 06., szo – 13:23 )

Azért a Joomla és a saját CMS mellett vannak még működő alternatívák is. Mi a frászkarikáért pont Joomla? Ez valami mazochizmus?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ezt is megkérdezi mindenki, amikor problémám van, de válaszolok.
Azért, mert annak idején ebbe rángatott bele az, akiben megbíztam. 7 évnyi időm elment rá, az első év után már szinte minden bajban egyedül voltam.
Nem fogok cseberből vederbe ugrani csak azért, mert valami más ígéretesebbnek tűnik, mert mindenfelé elveszett a bizalmam.
Ezért.

---
--- A gond akkor van, ha látszólag minden működik. ---
---

Ne vedd sértésnek. Semmi sem tökéletes - ebben teljesen igazad van. Alapvetőleg mindenki szurkol neked - én is.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( Proci85 v | 2016. 02. 06., szo – 13:59 )

Az imént csináltam egy szénné hackelt joomla javítást.
Régit elraktam almappába.
3.4.8 full csomag kicsomagol éles helyre. Régiből config php-t átmásoltam. Errel beröffent az admin oldal. Admin panelon manage -> database -> fix, párszor nyomogatom mire megszünnek a hibák, mivel 3.0.x-ről frissítettem csomó sql tábla nem létezett. Amikor szépen összeszedte magát, a főoldal a látogatók számára elhasalt.
Szerver oldalon nézem # php index.php
A kiiírt hibákat orvosoltam, ami abból állt, hogy az alkalmazott default template-nek kellett pár componens a régi helyről. Ezeket beraktam a component mappába és kész.
Az oldal működik, admin panelon sincs rinya.
+ a régi szénné hackelt oldal mehet a süllyesztőbe, ahol eldugott mappákban ott vannak a csúnya spammelős php-k.