Updatequelle für sigplus

chr-hl

Ich habe ein Fragezeichen im Gesicht bei folgendem Sachverhalt:
Ich setze auf mehreren Seiten sigplus (https://extensions.joomla.org/extension/sigplus/) ohne Probleme ein.
Auf EINER Seite erhalte ich bei der Prüfung auf Updates folgende Warnung.

Ich kann keine Unterschiede feststellen. Die Updatequellen sehen identisch aus.
Was habe ich bisher ohne Erfolg versucht.

Updatequellen gelöscht und anschließend wiederhergestellt
Erweiterung "rüber" installiert
Erweiterung deinstalliert und neu installiert
Caches gelöscht
Datenbank repariert

Hat Jemand noch eine Idee?

Natürlich ist es nicht "überlebenswichtig", aber es stört mich.

Christian

Elwood

Hallo Christian!

Alle Seiten bei Strato?

Bei Stratoseiten habe ich hin und wieder auch diese Meldung bei einigen Erweiterungen.

Bisher funktioniert es aber mit Updates und es läuft alles normal.

Müsste man mal genauer hinschauen.

chr-hl

Moin Timo,

Funktionieren tut es auf verschiedenen Strato -seiten und ionos. Nur bei einer Strato Seite habe ich die Meldung und deshalb würde mir nicht das letzte Update angeboten.

Was ich erstaunlich finde, dass auch nach Deinstallation und Neuinstallation die Warnung bleibt. Die Seite ist mindestens seit J3 dabei, vielleicht ist da die Ursache 🤔

Rolf Dautrich

Ich habe auch sigplus auf Seiten, die (mindestens) seit J3 bestehen, aber nie ein Problem mit Updates gehabt.

christine2

Hallo Christian,

vergleiche eventuell mit den funktionierenden Seiten:
allow_url_fopen aktiviert?
max_execution_time

Liebe Grüße
Christine

Elwood

Zitat von Rolf Dautrich

Ich habe auch sigplus auf Seiten, die (mindestens) seit J3 bestehen, aber nie ein Problem mit Updates gehabt.

Auch bei Strato?

Elwood

Zitat von christine2

Hallo Christian,
vergleiche eventuell mit den funktionierenden Seiten:
allow_url_fopen aktiviert?
max_execution_time

Kann man bei Strato im normalen Hosting-Paket nicht verändern/einstellen.

Rolf Dautrich

Zitat von Elwood

Auch bei Strato?

Nein!

chr-hl

Sachstand:

Strato
max_execution_time = 240 Sekunden

IONOS
max_execution_time = 50000 Sekunden

Strato IMMER Warnung, bei IONOS keine Meldung
ABER der Aufruf zur Prüfung Updates dauert keine 4 Minuten (= 240 Sek.)

Ich versuche morgen, ob ich den Wert über eine eigene php.ini verändern kann.
Habe bei den Strato-FAQs bisher nichts gefunden, was dagegen spricht.

kitepascal

Hi Christian,

du könntest mal checken und posten, was dieses Diagnose Script, im Basisverzeichnis platziert und im Browser aufgerufen, ausgibt, um der (Ur)sache näher zu kommen.

Anschließend löschen.

chr-hl

Strato:

Code

PHP-Version: 8.4.21
allow_url_fopen: 1
cURL geladen: ja
disable_functions: -
DNS A (IPv4): 178.238.222.53
DNS AAAA (IPv6): -
--------------------------------------------------------------
Standard-HTTP-301 | Fehler: 47 | Maximal 20 Weiterleitungen verfolgt | Bytes: 0
ohne SSL-Prüfung HTTP 301 | Fehler: 47 Maximal (20) Weiterleitungen gefolgt | Bytes: 0
nur IPv4 HTTP 301 | Fehler: 47 Maximal (20) Weiterleitungen befolgt | Bytes: 0
fopen OK (11892 Bytes)
--------------------------------------------------------------
==============================================================
DIAGNOSE: UNKLAR: cURL-Fehler 47 (Maximal (20) Weiterleitungen folgten).
EMPFEHLUNG: Ausgabe oben prüfen.
==============================================================

Alles anzeigen

IONOS:

Code

PHP-Version: 8.4.21
allow_url_fopen: 1
cURL geladen: ja
disable_functions: -
DNS A (IPv4): 178.238.222.53
DNS AAAA (IPv6): -
--------------------------------------------------------------
Standard-HTTP 200 | Fehler: keiner | Bytes: 819
fopen OK (819 Bytes)
--------------------------------------------------------------
==============================================================
DIAGNOSE: ABRUF FUNKTIONIERT von dieser Seite aus.
EMPFEHLUNG: Netz/SSL sind in Ordnung. In Joomla die Updatequelle entfernen, Update-Cache leeren (Erweiterungen > Aktualisierung) und neu prüfen lassen.
==============================================================

Alles anzeigen

kitepascal

Es gibt einen redirect loop.

Wie der ausschaut, prüft diese nächste Variante.

Das Ergebnis davon dann am besten auch mal an support@ sigplus senden - wahrscheinlich nur updateserverseitig lösbar.

Wenn ich es richtig verstanden habe, handelt es sich bei den anderen Strato Seiten, wo es funktioniert, um andere Strato Pakete / IPs?

chr-hl

Nein,
wie ich feststellen mußte, geht es bei allen (!) Strato-Paketen nicht und bei Ionos funtioniert es.

Christian

Rolf Dautrich

Zitat von kitepascal

Es gibt einen redirect loop.
Wie der ausschaut, prüft diese nächste Variante.
Das Ergebnis davon dann am besten auch mal an support@ sigplus senden - wahrscheinlich nur updateserverseitig lösbar.
Wenn ich es richtig verstanden habe, handelt es sich bei den anderen Strato Seiten, wo es funktioniert, um andere Strato Pakete / IPs?

Danke für das nützliche Tool!

chr-hl

Zitat von chr-hl

Ich versuche morgen, ob ich den Wert über eine eigene php.ini verändern kann.
Habe bei den Strato-FAQs bisher nichts gefunden, was dagegen spricht.

Mit einer .user.ini (Punkt vor dem u!) im Verzeichnis der Site ist es mir gelungen, den Wert in der Spalte "Local Value" zu ändern.
Leider hat sich damit nichts geändert (siehe Beittrag #5).

Christian

kitepascal

Was hatte denn #12 ausgegeben?

chr-hl

Sorry Pascal,

ich hatte übersehen, dass Du ein weiteres Script gepostet hattest.

Ergebnis:
=== Redirect-Ketten-Check: https://hunyadi.info.hu/sigplus/extension.xml ===
Zeit: 2026-06-06 19:12:48
Server-IP: - <-- diese IP fragt an (entscheidend!)
PHP/cURL: 8.4.21 / 8.19.0 | OpenSSL: OpenSSL 3.0.20 7 Apr 2026
Ziel-DNS: A=178.238.222.53 AAAA=-
======================================================================
--- 1) Joomla-UA, ohne Cookies (so fragt Joomlas Updater) ---
Hop 1: HTTP 301 [IP 178.238.222.53, 0.13s] -> https://hunyadi.info.hu/levente/415.shtml
Hop 2: HTTP 301 [IP 178.238.222.53, 0.13s] -> https://hunyadi.info.hu/levente/415.shtml
Hop 3: LOOP - URL bereits besucht: https://hunyadi.info.hu/levente/415.shtml

--- 2) Browser-UA, ohne Cookies (testet UA-Weiche) ---
Hop 1: HTTP 301 [IP 178.238.222.53, 0.12s] -> https://hunyadi.info.hu/levente/415.shtml
Hop 2: HTTP 301 [IP 178.238.222.53, 0.13s] -> https://hunyadi.info.hu/levente/415.shtml
Hop 3: LOOP - URL bereits besucht: https://hunyadi.info.hu/levente/415.shtml

--- 3) Joomla-UA, MIT Cookie-Mitfuehrung (testet Cookie-Weiche) ---
Hop 1: HTTP 301 [IP 178.238.222.53, 0.14s] -> https://hunyadi.info.hu/levente/415.shtml
Hop 2: HTTP 301 [IP 178.238.222.53, 0.12s] -> https://hunyadi.info.hu/levente/415.shtml
Hop 3: LOOP - URL bereits besucht: https://hunyadi.info.hu/levente/415.shtml

fopen (Stream-Wrapper, PHP-UA, ohne Cookie): OK, 11926 Bytes
======================================================================
DIAGNOSE: LOOP unabhaengig von UA und Cookie - sehr wahrscheinlich Quell-IP-/Geo-/Reputations-bedingt am Zielserver.
EMPFEHLUNG: Nur serverseitig loesbar. Andere Ausgangs-IP/Node testen, sonst Autor melden.
Loop pendelt zwischen:
- https://hunyadi.info.hu/levente/415.shtml
======================================================================

christine2

Glaube eigentlich schon, dass PHP memory_limit OK ist. Wollt es halt nur auch noch reinwerfen 💁

Liebe Grüße
Christine

Rolf Dautrich

Ich hatte schon öfter Kontakt mit Levente Hunyadi, dem ungarischen Entwickler von sigplus, zuletzt im vergangenen Jahr beim Test von sigplus für J6. Ich schreibe ihn mal an mit Verweis auf diesen Forum-Post (soweit ich weiß, versteht er ein wenig Deutsch) und auf das Tool von kitepascal .

Rolf Dautrich

Hier ist die Antwort von Levente Hunyadi:

"Hi Rolf,

When typed into a browser, the URL https://hunyadi.info.hu/sigplus/extension.xml
returns the Joomla extension update descriptor XML document, which looks as
expected. Its HTTP "Content-Type" is "application/xml", which is again normal.
I believe the German ISP Strato (or some other actor in the request
chain) might be misconfigured because HTTP 415 referenced in cases 1),
2) and 3) above stands for "Unsupported Media Type" but
"application/xml" is an absolutely standard media type. HTTP 301 just
stands for "Redirect", i.e. the <hunyadi.info.hu> server might be
redirecting the requester to one of the standard informative error
pages.

On the other hand, even if automatic updates don't work, users can
still install sigplus to their Joomla instances manually, e.g. by
uploading the extension package directly, or using the install from
external location feature. sigplus no longer receives frequent
updates, only security patches. If a user perceives sigplus updates on
one of their sites but not on the others (blocked by the reported
reason), they can always check and act manually. Unfortunately, I am
not a network engineer and don't have meaningful suggestions how to
resolve the issue, it looks to be specific to the environment rather
than something closely related to sigplus.

Levente"

Hier die (automatische, aber brauchbare) Übersetzung:

"Hallo Rolf,

Wenn die URL <https://hunyadi.info.hu/sigplus/extension.xml> in einen Browser eingegeben wird, liefert sie das Joomla-Erweiterungs-Update-Deskriptor-XML-Dokument, das wie erwartet aussieht. Der HTTP-Content-Type ist „application/xml“, was ebenfalls normal ist. Ich vermute, dass der deutsche Internetanbieter Strato (oder ein anderer Akteur in der Anfragekette) falsch konfiguriert ist, da der in den Fällen 1), 2) und 3) erwähnte HTTP-415-Fehler für „Nicht unterstützter Medientyp“ steht, während „application/xml“ ein absolut gängiger Medientyp ist. HTTP 301 bedeutet lediglich „Weiterleitung“, d. h. der Server <hunyadi.info.hu> leitet den Anfragenden möglicherweise auf eine der Standard-Fehlerseiten weiter.

Selbst wenn automatische Updates nicht funktionieren, können Benutzer sigplus weiterhin manuell auf ihren Joomla-Instanzen installieren, z. B. durch direktes Hochladen des Erweiterungspakets oder Verwendung der Funktion „Von externem Speicherort installieren“. sigplus erhält keine regelmäßigen Updates mehr, sondern nur noch Sicherheitspatches. Falls ein Benutzer sigplus-Updates auf einer seiner Websites, aber nicht auf den anderen (aufgrund des angegebenen Grundes) feststellt, kann er dies jederzeit manuell überprüfen und gegebenenfalls Maßnahmen ergreifen. Leider bin ich kein Netzwerktechniker und habe daher keine konkreten Lösungsvorschläge. Das Problem scheint eher mit der Umgebung als mit sigplus selbst zusammenzuhängen.

Levente"