Jetzt legst einen Menüeintrag in Joomla vom Typ "URL" an, der auf die Galerie-Subdomain zeigt. Der bleibt von jedweden SSL-Umleitungen Joomlas unbeeinflusst. Oder täusche ich mich?
Habe Deinen Vorschlag gestestet um die Frage noch zu beantworten:
Ein Eintrag http://... führt zum "unsicheren Eintrag" der Verbindung,
ein Eintrag https://... zu dem im obigen Spoiler notierten SSL-Fehler.
KarEm
Hallo Re:Later,
Wenn du jedoch nur auf die Galerie per Menü verlinken willst, sollte das nach meiner Denke wurst sein, ob du http oder https in der URL verwendest.
Habe ich gerade noch einmal getestet:
Aufruf der Galerie per Joomla-Menüeintrag: https://subdomain.example.org/.....:
Nötig wäre hier ein "Wildcard-Zertifikat" des Hosts für Subdomains.
Aufruf der Galerie per Joomla-Menüeintrag: http://subdomain.example.org/.....:
Keine Fehlermeldung, Galerie wird aber nicht angezeigt. Den Grund kenne ich noch nicht, habe den Ansatz wg. htaccess-Anfrage beim Host nicht weiter verfolgt.
KarEm
Hallo,
vielen Dank für Euren Support.
Was hat denn der Hoster dazu gesagt?
Der Host gibt beim Webhosting die nachgefragten Wert (Allow-Override-Wert der Serverkonfig und die für die Options FollowSymlinks und Indexes) "nicht heraus". Unverständlich, erschwert nur die Suche nach Fehlern.
wwwrun-Problem
Das sind wohl diese beiden Werte:
Webserver Apache/2.4.33 (Unix)
PHP-Interface für den Webserver cgi-fcgi
Platzproblem
Speicherplatz zu 87% noch frei.
Galerieordner der benachbarten Subdomainordner zeigt
Dieser Ansatz (parallele Subdomainordner und SSL auch beim Zugriff auf die Bilder aus dem Joomla-Menü heraus) wäre meine Präferenz (war bisher eigentlich nur als Test gedacht um den Fehler näher einzugrenzen).
bei STRATO wenigstens via PHP das Anlegen von SymLinks möglich ist/war
Muss ich klären, nach den bisherigen Erfahrungen .....
Hallo,
SymLinks, na dann hier lang: Phoca Gallery - Bilder außerhalb der Joomla-Installation
Liebe Grüße
Christine
Danke für den Link.
VG
KarEm
Hallo,
daran hatte ich anfangs auch schon gedacht und kann das nach etlichen Tests als Ursache ausschließen.
Trotzdem danke.
VG
KarEm
Hallo zero24,
Update (Problem ist noch nicht erledigt):
Was hat denn der Hoster dazu gesagt?
habe heute eine weitere Anfrage an ihn gestellt. Die bisherigen Antworten waren schlicht nicht zielführend, ich hatte nicht den Eindruck, dass die sich damit näher beschäftigt haben, eher dass sie Standardantworten versenden. Die Frage nach Servereinstellungen haben sie bisher jedesmal "überlesen". Sehr "zäh" das Ganze.
Die testweise Anordnung der Galeriefolder paralell zu denen von Joomla (htaccess) haben sie garnicht kommeniert.
VG
KarEm
Hallo,
ich habe die Galerie-SW sowie die Bilder auf einer Subdomain eingerichtet und einige Tests durchgeführt. Alle Tests mit dem FE der Galerie-SW waren fehlerfrei, keine Meldungen, keine Duplikate. Die Folderstruktur der Galerie liegt nun auf gleicher Ebene wie joomla, die htaccess-Files sind damit nicht mehr hierarchisch angeordnet. Weitere Änderungen habe ich noch nicht gemacht.
Kann man nun davon ausgehen, dass bestimmte Einträge in den beiden htaccess-Files diese Probleme verursacht haben? Wenn ja, wie kann ich herausbekommen welche (die einzige Änderung ist ja die SSL-Umleitung)?
Wie oben beschrieben, gibt es einen Joomla-Menüeintrag damit Besucher in die Galerie navigieren können. Trage ich in dem Menüeintrag (Details) die Subdomain (http://...) ein, wird die Webadresse nicht gefunden da die SSL-Umleitung in der Joomla htaccess noch aktiv ist. Wie kann ich testweise die Subdomain aus der SSL-Umleitung entfernen (ich möchte noch testen, ob ich als Besucher die Galerie über Joomla ansteuern kann)? Z.Z. nutzen wir für die SSL-Thematik ein im Tarif von Strato enthaltenes Inklusiv SSL-Zertifikat, das allerdings nicht für Subdomains gilt.
Ich habe versucht heraus zubekommen, ob die beiden o.g. Optionen FollowSymlinks und Indexes schon durch den Host gesetzt werden und ggf. mit welchen Werten, allerdings bin ich nicht fündig geworden. Komme ich an diese Werte irgenwie heran?
KarEm
Meine Intention war auf dem selben Server mit der selben PHP / MySQL Konfiguration nur eben ohne Joomla das ganze zu testen.
Ok, muss ich testen, ob die Lizenz für die Galerie-SW mitspielt.
Habt Ihr die beiden Zeilen aus der Joomla htacess schon mal auskommentiert?
Options +FollowSymlinks habe ich mit dem X3-Entwickler diskutiert und der hat die definitiv ausgeschlossen (..."this is still entirely unrelated to errors on upload...").
Options -Indexes, nein nicht diskutiert oder auskommentiert.
Habt Ihr auch schon mal die .htaccess von Joomla ganz abgestellt also die .htaccess in htaccess.txt umbenennt?
Die .htaccess von Joomla habe ich am 25.03.18 erweitert (SSL-Umleitung nach Anleitung hier im Forum) und aktiviert und im BE URL-Rewrite auf Ja gesetzt . Anfang April habe ich dann von den beiden Content-Contributoren die ersten Meldungen zum Upload-Fehlverhalten bekommen. Könnte ein (nicht nur zeitlicher) Zusammenhang bestehen - oder?
KarEm
Hallo,
Wenn ich das richtig Verstanden haben gibt es diese Fehlermeldungen beim hochladen über eine Funktion der Galerie-SW richtig?
Korrekt, wobei m.E. nicht unbedingt das Hochladen (als Funktion der Galerie-SW) die Ursache ist, sondern in dem gesamten Hochladeprozess (s.o.) irgendwo der Wurm drin ist. Die Tests wurden von 4 verschiedenen Rechner-/Internetumgebungen (Orten) aus durchgeführt und führen zu unterschiedlichen Ergebnissen (fehlerfrei, Warnungen, Duplikaten).
Hast du es schon beim Hersteller der Galerie-SW versucht?
Ja, ich bin auch mit dem Hersteller der Galerie-SW (X3) in Kontakt und habe in Absprache umfangreiche Tests durchgeführt. Außerdem hat er selbst Bildmaterial von mir erhalten und auch selbst Uploads durchgeführt. Zuletzt habe ich Zugang zu einem Server des Herstellers bekommen (auf dem kein Joomla läuft) und dort verschiedene Testuploads durchgeführt. Alle diese Tests waren fehlerfrei, es wurden keine der o.g. Warnungen ausgegeben und es wurden auch keine Duplikate der hochgeladenen Bilder erzeugt. Für die Uploadfunktion in der Galerie-SW wird https://github.com/blueimp/jQuery-File-Upload eingesetzt. Er vermutet ein Zusammenwirken der o.g. PHP-Einstellungen und keinen Feher in der Uploadfunktion. Im Moment haben wir weitere Aktivitäten unterbrochen um zuerst weitere Meinungen/Hinweise auch für eine Meldung an den Host zu bekommen.
Ist die Galerie-SW auf dem aktuellen Stand? Sind die Einstellungen richtig?
Ja und verifiziert durch den X3-Entwickler.
Wenn ich das richtig verstanden haben liegen Joomla und die Galerie-SW zwar im selben Webroot aber sind nicht irgendwie gekoppelt?
Ja, unterhalb des Folders joomla auf der gleichen Ebene wie z.B. administrator oder templates gibt es eine Folderstruktur, die die Galerie-SW, Einstellungen (incl. der Galerie .htaacess) sowie alle Bilder der Galerie enthält. Für die Besucher der HP gibt es im Hauptmenü einen Eintrag um in die Galerie zu navigieren. Für den Upload von Bildern ist keine Kopplung mit Joomla nötig. Dazu stellt die Galerie-SW ein BE (ähnlich Joomla) zur Verfügung. Nach dem Einloggen in das Galerie-BE kann dann die Uploadfunktion angewählt werden.
Die Uploadfunktion kann also autonom ohne vorheriges Einloggen in das Joomla-BE genutzt werden.
Hast du die Möglichkeit ein Backup der Galerie-SW auf einer subdomain zu testen also ohne den kram mit Joomla drum?
Zuletzt habe ich Zugang zu einem Server des Herstellers bekommen (auf dem kein Joomla läuft) und dort verschiedene Testuploads durchgeführt. Alle diese Tests waren fehlerfrei, es wurden keine der o.g. Warnungen ausgegeben und es wurden auch keine Duplikate der hochgeladenen Bilder erzeugt.
Wäre das ein gleichwertige Ansatz oder hast Du eine andere Intention mit der Frage?
ggf. kann es helfen die Joomla regeln zum testen via htaccess auf die Joomla Ordner zu begrenzen? Habt Ihr das schon probiert?
Nein, dazu reicht mein Wissen um die Einträge in den htaccess-Files und insbesondere das Zusammenwirken/die Wechselwirkung verschiedener in einer Hierarchie angeordneten htaccess-Files noch nicht aus. Die Joomla .htaccess liegt in dem o.g. Folder joomla, die Galerie .htacces im Folder: joomla\imagevuex\x3. Für Support in diesem Punkt wäre ich sehr dankbar.
Welche genauen Regel habt Ihr eingesetzt?
Den Spoiler mit der htaccess der Galerie-SW kommt (wg. einer Längenbegrenzung für einen Beitrag) in einer 2. Antwort.
Vielen Dank für Deine Unterstützung
KarEm
Hallo,
wir haben seit Anfang April eine Problem, bei dem wir nicht mehr so recht weiterkommen.
Es geht um die Homepage eines Fotoclubs, die neben Jommla auch eine Galerie-Sw zum Verwalten der Bilder einsetzt.
Joomla: 3.8.7
PHP: 7.0.29
Galerie-SW: Imagevue X3 (mit javascript-based multi-file uploader)
Host: Strato, shared hosting
Upload-Prozess: Client->router->firewall->network->server
Die Galerie-SW sowie die Bilder liegen in einem Folder (und etlichen Sub-Foldern), der in der Joomla-Folderstruktur auf der selben Ebene wie z.B. der Folder administrator liegt.
In Joomla ist eine .htaccess activ, die die Joomla-Standard htaccess um SSL-Umleitung (301) erweitert. Die Galerie-SW nutzt ebenfalls eine htaccess.
Fehlverhalten:
Beim Hochladen von Bildern mit einer Funktion der Galerie-SW auf den Server kommt es je nach genutztem Client (Firefox, Edge, IE) zu unterschiedlichen Fehlern. Diese Fehler sind rekonstruierbar und durch Sreenshots dokumentiert. Die Fehler reichen von der Ausgabe von Warnungen/Errormeldungen (z.B. Bad Gateway, Unknow Error, Request Timeout) und dem Abruch des Uploads bis zur Durchführung des Uploads bei gleichzeitiger Erzeugung einer unterschiedlichen Anzahl von Dubletten der hochgeladenen Bilder. Fehlerfrei Uploads sind bei einer geringeren Anzahl von Bildern (< 10) möglich aber nicht garantiert.
Lediglich mit dem IE unter Win7 gelang ein Upload von 40 Bildern fehlerfrei, unter Win10 mit dem IE wurden die Bilder hochgeladen aber trotzdem Warnungen ausgegeben.
Bisherige Tests:
- Upload einer Bildanzahl < 20 und > 20 mit verschiedenen Betriebssystemen und Browsern unter Joomla 3.8.5 sowie 3.8.7 und der o.g. Galerie-SW (keine Unterschiede im o.g. Fehlerbild), Dateinamen sind überprüft, kein Zip o.ä.
- Standalone-Test mit der Galerie-SW auf einem vom Hersteller bereitgestellten Server mit verschiedenen Clients (keine Fehler)
Wir können die Fehlerquelle im gesamten Upload-Prozess noch nicht festmachen, vermutet wird ein Zusammenwirken von PHP-Einstellungen (z.B. PHP Memory Limit, Upload Max File Size, Post Max Size, Max File uploads), evtl. auch Querwirkungen der beiden htaccess-Dateien.
Ein erster tel. Kontakt mit dem Host-Support war nicht sehr vielversprechend, allerdings wollen sie sich das Fehlerbild auch ansehen.
Meine bisherigen Recherchen im Forum haben noch keine Lösung aufgezeigt, wobei ich auch das Problem habe, nicht genau zu wissen wonach ich suchen soll.
Wer kann hier bitte weiterhelfen und welche Infos werden ggf. noch benötigt?
KarEm
Hallo,
ok, war mir nicht bewusst. Dann warte ich mal ab, wie sich das bei den nächsten Updates entwickelt.
Besten dank an alle, die mir geholfen haben.
Grüße
KarEm
Hallo,
hat niemand einen Tipp für mich zum Wiederherstellen der Aktualisierungsquellen?
Danke
KarEm
Hallo Christiane,
vielen Dank für die Erläuterungen.
Ich habe die Liste mit den Einträge die über "Erweiterungen: Überprüfungen" angezeigt werden (21) mit einer anderen Joomla-Install. (ist noch 3.8.3 im Testmodus) verglichen.
In der 3.8.3 ist die Liste leer und alle 21 sind installiert und via Verwalten sichtbar.
Einige werden in der 3.8.3 im Gegensatz zur 3.8.6 als "geschützte Erweiterung" dargestellt, sie wurden aber alle bei der Neu-Installation der 3.8.3 automatisch installiert, im Gegensatz zu den Updates der anderen Installation bis zur aktuellen 3.8.6 und dem "Drüberbügeln" des Fullpackages.
Offensichtlich sind dies doch Erweiterungen, die zu Joomla gehören (obwohl ID>10000) und offensichtlich gibt es Unterschiede zwischen einer Joomla-Neuinstallation und einem Updatepfad.
In der 3.8.6. habe ich daraufhin alle 21 Erweiterungen installiert, alle fehlerfrei, damit ist die Liste leer.
Ich habe auch einige Tests gemacht und dabei ist mir noch eine Sache aufgefallen:
Wähle ich "Sprachen installieren" wird die
"Warnung
Die Aktualisierungsquellentabelle ist nicht auf dem aktuellen Stand. Bitte die Aktualisierungsquellen wiederherstellen."
ausgegeben.
Das Wiederherstellen der Aktualisierungsquellen funktioniert aber nicht, auch mit Löschen und Wiederherstellen werden die möglichen installierbaren Sprachen nicht angezeigt (in der 3.8.3 keine Probleme).
Muss ich da an anderer Stelle noch etwas aktivieren oder einstellen?
Danke vorab.
KarEm
Ja, DB habe ich (mehrfach) repariert. Caches geleert.
Konfig gespeichert (hatte ich letztens auch schon mal gemacht (nach einem Beitrg hier im Forum)).
Nein, JCE Pro habe ich als einziges Element nicht installiert, wird nach wie vor aber als Update angezeigt.
Gruß
KarEm
Hallo,
Zwischenstand:
- auf die Live-Kopie (3.8.5) auf xampp habe ich, wie vorgeschlagen, das Full-Package (ohne "installation") drüberkopiert.
- die DB aus dem Live-System dann auf xampp eingespielt
- configuration.php angepasst and BE aufgerufen, ok, keine FM
- dann DB repariert, keine FM
- Erweiterungen: Aktualisieren zeigt jetzt alle (bis auf 3.8.6 DE-Sprachpaket) verfügbaren Erweiterungen an
- auf J3.8.6 aktualisiert, die Manifest-Cache Meldung wurde wieder ausgegeben
- danach JEM, Kunena Elemente aktualisiert, keine FM
- das DE-Sprachpaket für die 3.8.6 wird noch nicht angezeigt, der Aktualisierungsserver fehlt noch
- manuell das Sprachpaket heruntergeladen und installiert, keine FM
- danach/dadurch (?) wurde der Aktualisierungsserver in die Liste der Aktualisierungsquellen eingetragen
- unter Erweiterungen: Warnungen - keine Meldungen
Offen ist jetzt noch:
- die Ausgabe der Manifest-Cache-Meldung
- Die Erweiterungen (in den PDF's) werden noch nach "Überprüfen" angezeigt
Ich kann die Erweiterung in dieser Liste nicht einordnen. Alle haben eine ID>10000 (m.W. sind das damit keine Core-Erweiterungen - oder?).
Re:Later hat ja vorgeschlagen, "den ganzen Kram unter Überprüfen schrittweise installieren.", habe ich noch nicht gemacht, weil mir nicht klar ist, ob diese Elemente benötigt werden und wenn sie benötigt werden, weil Core-Elemente, wieso tauchen die dann auf dieser Liste auf?
Diese Liste war ursprünglich noch umfangreicher, weggefallen sind Einträge von Elementen die wir heute nicht mehr benötigen.
Wie kann ich mit den beiden offenen Punkten weitermachen?
Danke
KarEm
Hallo Elwood,
PHP 7.0 ist eingestellt und lokal 7.0.26.
VG
KarEm
Hallo zusammen,
vielen Dank für die guten Ratschläge und Empfehlungen. Nur zur Einschätzung: Ich bin Joomla-"Lehrling" und habe die Betreuung der Seite erst vor einer kurzen Weile übernommen. Nach einer ersten Einarbeitungszeit war mir dann schon klar, dass viel zu ändern und zu aktualisieren ist (Startpunkt war die 2.5.18 mit ALLEN Komponenten outdated, das Template inkompatibel,.... hatte keine Ahnung wie man lokal mit xampp die Sache angehen kann.
Mittlwerweile habe ich mich etwas eingearbeitet und die laufenden Arbeiten bekomme ich hin. Dann fallen mir aber wieder Probleme auf, die ich dann hier recherchiere bzw. nachfrage. Für Euch ist das vmtl. eher langweilige Routine (nicht abwertend gemeint), für mich zunächst wieder ein Stück Neuland.
Zum Thema.
Ich habe jetzt unter xampp eine identische Kopie des Live-Systems angelegt und bin dabei die Updates durchzuführen, bis jetzt soweit ok, 3.8.6 läuft.
Zu den Problemen, die ich eingangs beschrieben habe melde ich mich noch einmal, wenn ich durch bin.
VG
KarEm
Ich habe das vielleicht nicht klar genug ausgedrückt. Ich vermute, dass in der DB noch Einträge aus den früheren Joomla-Versionen und früheren Erweiterungen enthalten sind, die nicht mehr benötigt werden. Auf diese bezog sich meine Frage wie man die am besten löscht.
Tut mir leid, wenn Du das als Zeitverschwendung empfindest. Die Vorschläge haben mir schon ein Stück weit geholfen, obwohl ich noch nicht verstehe, wieso zwei nahezu identische Installationen sich in diesem Punkt unterschiedlich verhalten.
Die Live-Version kann ich wie erwähnt derzeit nicht verändern, das ist mir einfach zu heikel und das Risiko zu hoch das laufende Voting zu unterbrechen.
Die vorgeschlagene Alternative kann ich in der xampp-Inst. durchführen und dann auf den Server laden.
Erstmal danke für Eure Beiträge.
KarEm
Hallo,
die Installer sind auf 3.6.0, Überprüfen, Aktualisierungen suchen habe ich im Laufe der letzten Stunden schon mehrfach gemacht. Auch die Aktualisierungsquellen habe ich gelöscht und wieder erzeugen lassen.
Bisher habe ich Aktualisierungen entweder über die Paket-spezifischen Aktualisierer oder über "Aus Verzeichnis installieren" durchgeführt und das hat immer problemlos funktioniert. In der Live-version habe ich gerade die beiden Installer installiert und die Suche noch einmal angestoßen. Leider werden nicht alle Aktualisierungen gefunden.
Auffällig ist, dass "Aktualisierungen suchen" deutlich länger auf dem Server benötigt als auf der xampp-Inst.
Auf dem Server wird z.B. für JEM die folgende Meldung ausgegeben:
Update: Die Aktualisierungsquelle #52 „JEM Update Site“ konnte nicht geöffnent werden! URL: http://www.joomlaeventmanager.…check/update_pkg_jem.xmlt
der selbe Link auf xampp findet sofort die neue Version.
Mit dem 3.8.6 drüberbügeln geht derzeit nicht, da ein Voting über ca. 200 Fotografien läuft.
Wie bekomme ich bei einer 3.8.6 Inst. die vermutlich noch in der DB befindlichen Altlasten am sichersten gelöscht, wie ist da die beste Vorgehensweise?
Danke
KarEm
Da wäre es nett, wenn du sagst, was schon alles gemacht wurde, bevor man hier neu anfängt.
Vor dem Update:
System->System->Globales Einchecken
System->Cache leeren
System->Abgelaufenen Cache leeren
Ich habe nach jedem erfolglosen Update nach weiteren Hinweisen gesucht, kann die aber nicht mehr alle rekonstruieren.
Bedeutet einfach, du hast eine Joomla-Core-Erweiterung irgendwann mal DEINSTALLIERT, statt nur DEAKTIVIERT. Bspw. Template Protostar oder Beez3 sind oft Kandidaten. Geh unter Erweiterungen > Überprüfen. Da steht dann meist, welche Erweiterungen das sind (nicht immer).
Die beiden genannten Templates sind nach wie vor vorhanden, beez3 nutze ich für den Adminbereich, Protostar habe ich kopiert und leicht erweitert. Bei jedem Update aktualisiere ich die Kopie.
Ich habe die Betreuung der Seite vor einer Weile übernommen und schrittweise von 2.5.18 über 3.8.1, 3.8.2, 3.8.3. 3.8.5 aktualisiert.
Die Ausgangsversion 2.5.18 habe ich um alle nicht Core-Elemente abgespeckt, die DB bereinigt, auf die 3.8.1 migriert und dann schrittweise die nötigen Komponenten etc. wieder versions-passend hinzugefügt und danach die jeweiligen Versionshübe (fast alle) durchgeführt.
Ich bin mir allerdings ziemlich sicher, dass noch Altasten in der DB vorhanden sind. Meine Joomla-Kenntnisse sind noch eher bescheiden, daher teste ich nahezu alles erst in meiner xampp-Umgebung und da ist mir das unterschiedliche Verhalten erst aufgefallen. Bisher habe ich lokal die Aktualisierungen durchgeführt und dann auf den Server hochgeladen.
Die Liste Erweiterungen->Überprüfen beinhaltet noch die folgenden Einträge:
