Dostepne cyfrowo
strony internetowe
dla kultury i oświaty

Jeśli w panelu administracyjnym Joomli po kliknięciu "Aktualizuj" widzisz błąd 0 Attempt to assign property "last_check_timestamp" on null, a próba jego obejścia przez ręczny upload (com_joomlaupdate&view=upload) kończy się tym samym komunikatem — nie jest to przypadek odosobniony. To jeden z bardziej frustrujących, ale w pełni naprawialnych problemów w Joomli 4.x/5.x, wynikający z rozjechanej bazy danych po nieudanej lub przerwanej wcześniejszej aktualizacji.

Dlaczego to się dzieje

Mechanizm aktualizacji Joomli opiera się na kilku powiązanych ze sobą tabelach w bazie danych:

• #__update_sites — lista źródeł aktualizacji (m.in. wpis dla core Joomla),
• #__update_sites_extensions — tabela łącząca, wskazująca który wpis w update_sites odpowiada za które rozszerzenie,
• #__extensions — rejestr wszystkich zainstalowanych rozszerzeń, w tym pseudo-rozszerzenia files_joomla reprezentującego sam core Joomli,
• #__tuf_metadata — od Joomla 5.1 dodatkowa tabela przechowująca podpisane metadane (TUF — The Update Framework), które zabezpieczają pobierane paczki aktualizacji przed podmianą.

Kod komponentu com_joomlaupdate przy każdym wejściu w ten widok próbuje odczytać powiązanie między update site a rozszerzeniem. Jeśli któreś z tych powiązań jest uszkodzone — np. extension_id w tabeli łączącej wskazuje na nieistniejący lub zły wiersz — zapytanie SQL zwraca null, a kod Joomli, który nie spodziewa się takiej sytuacji, próbuje przypisać właściwość do tego null-a. Stąd błąd "Attempt to assign property... on null".

Krok 1: sprawdź powiązanie update_sites ↔ extensions

SELECT * FROM `xxx_update_sites` WHERE location LIKE '%update.joomla.org/core%';

Zanotuj update_site_id zwróconego wiersza. Następnie znajdź prawidłowy extension_id pseudo-rozszerzenia Joomla core:

SELECT extension_id FROM `xxx_extensions` WHERE element = 'joomla' AND type = 'file';

Porównaj to z tym, co faktycznie jest zapisane w tabeli łączącej:

SELECT * FROM `xxx_update_sites_extensions` WHERE update_site_id = [id z pierwszego zapytania];

Jeśli extension_id w tabeli łączącej nie zgadza się z prawidłowym extension_id z #__extensions — to jest źródło błędu. Napraw prostym UPDATE-em:

UPDATE `xxx_update_sites_extensions` 
SET extension_id = [prawidłowy_extension_id] 
WHERE update_site_id = [id];

Krok 2: jeśli pojawia się "Could not load root metadata"

Ten błąd to już inny etap tego samego problemu, dotyczący TUF-a. Zwykle oznacza, że tabela #__tuf_metadata zawiera wpis powiązany ze starym, nieaktualnym update_site_id (np. z czasów, gdy wpis core miał inne ID w bazie). Rozwiązanie:

TRUNCATE TABLE `xxx_tuf_metadata`;

Po wyczyszczeniu Joomla powinna pobrać świeże metadane (root.json, timestamp.json, snapshot.json, targets.json) przy następnym sprawdzeniu aktualizacji, tym razem z poprawnym powiązaniem.

Kiedy naprawa bazy nie wystarcza

Czasem, mimo poprawionych powiązań, tabela TUF pozostaje pusta po każdej próbie — to sygnał, że problem leży już nie w bazie, tylko w komunikacji serwera hostingowego z zewnętrznymi serwerami Joomli (np. przestarzały cURL, blokada firewalla na ruch wychodzący, problem z certyfikatami SSL). W takiej sytuacji zamiast dalej debugować warstwę sieciową, najszybciej jest ręcznie nadpisać pliki core przez FTP, całkowicie omijając mechanizm TUF:

1. Zrób pełny backup (pliki + baza).
2. Pobierz Upgrade Package dla docelowej wersji ze strony downloads.joomla.org (pakiet "Update Package", nie "Full Package").
3. Wgraj przez FTP do katalogu głównego strony, wybierając opcję scalenia katalogów i nadpisania plików o tej samej nazwie.
4. Wejdź do panelu i sprawdź Komponenty → Baza danych (com_installer&view=database) — jeśli pokaże "Brak pasujących wyników", struktura bazy jest zgodna i aktualizacja core przebiegła poprawnie.
5. Wyczyść cache.

Ta metoda ma dodatkową zaletę: ponieważ podmienia komplet plików core, potrafi przy okazji naprawić inne drobne usterki wynikające ze starszej wersji plików — w jednym z takich przypadków rozwiązała też uporczywy problem z migotaniem (flickerem) edytora TinyMCE, niezwiązany bezpośrednio z samą aktualizacją.

Podsumowanie

Błędy last_check_timestamp i Could not load root metadata wyglądają groźnie, ale w większości przypadków sprowadzają się do rozjechanych powiązań w kilku tabelach bazy danych. Jeśli naprawa SQL nie usunie problemu do końca (bo np. hosting blokuje połączenia do serwerów Joomli), ręczny upload paczki aktualizacyjnej przez FTP jest solidnym, gwarantowanym obejściem — pomija cały łańcuch weryfikacji online i po prostu dostarcza nowe pliki core na miejsce.