Wenn die Seite mit SH404Sef lief, dann erhältst du natürlich andere URLs und wirst um einen Vergleich und Weiterleitungen nicht drum herum kommen. Ich sehe es genauso wie drmenzelit.
Ich habe auch noch nie eine derartige Erweiterung einsetzen müssen und hatte immer vernünftige URLs.
Ich persönlich finde das überhaupt nicht gelungen. Rechtlich weiß ich nicht.
Aber typischerweise legt man doch höchstens auf einer "mehrsprachigen" Webseite das Impressum und Co. in verschiedenen Sprachen an. Hier würde ich deshalb auch sauber trennen, also einen Beitrag z.B. für die deutsche Version und einen Beitrag für die englische Version.
Grundsätzlich kannst du beides aber auch in einen Beitrag schreiben. Worin besteht das Problem?
Macht für mich aber keinen Sinn. Oder verstehe ich deine Frage nicht richtig?
Oder gibt es deine Webseite nur in 1 Sprache und du willst die englische Übersetzung dennoch auch anbieten? Wozu?
Dank an alle. Habs gefunden. Benutze Firefox mit Add-on "Ghostery – Datenschutzorientierter Werbeblocker", und als ich den deaktiviert habe lief es.
Bei solchen Problemen am besten immer mehrere Browser testen. Dann "fliegt" das schneller auf, dass es am Browser bzw. seinen Einstellunge oder Addons liegt.
Es wäre schon hilfreich, wenn man den CallStack angezeigt bekäme. Sollte mit Protostar eigentlich auch kein Problem sein.
Ansonsten denke ich jetzt mal in eine andere Richtung bzgl. 500er:
Wie hast du von PHP 7.4 auf 8.0 gestellt? Direkt beim Hoster oder über einen Eintrag in die .htaccess?
Es ist wichtig, dass die globale Version beim Hoster und ein eventueller Eintrag in der .htaccess nicht auf der gleichen PHP-Version stehen. Dann könnte es merkwürdige Probleme geben. Einen Eintrag in die .htaccess nutzt man nur, wenn man statt der globalen Version beim Hoster beispielsweise für ein bestimmtes Verzeichnis eine andere PHP-Version nutzen möchte. In der Regel lassen sich aber bereits beim Hoster für die verschiedenen Verzeichnisse jeweils andere PHP-Versionen einstellen, so dass ein Eintrag in die .htaccess nicht mehr nötig ist. Überprüfe das mal!
Gibt es weitere YT-Erweiterungen, die du in der DB deaktivieren kannst?
Damit wir nicht aneinander vorbeireden:
Welches Template nutzt du auf der Webseite, wo du den 500er-Fehler erhältst? Protostar?
Und dieser 500er kommt sowohl auf der Webseite und im Backend direkt nach dem Einloggen?
Welche(n) Browser verwendest du zum Testen?
Sind die Browser (einigermaßen) aktuell?
Nutzt du igendeine ungewöhnliche Browser-Einstellung oder ein Browser-Add-On, das da Einluss nehmen könnte?
Dann würde ich dort im Forum auch nach der neuen Fehlermeldung fragen:
Fehlermeldung:
Failed opening required '/is/htdocs/wp12877334_WBU0GAX8RQ/www/www.audiolino.de/joomla/joomla-klon/components/com_jshopping/lib/factory.php' (include_path='.:/usr/share/php8.1')
Dann scheint das Update-Problem ja erledigt zu sein.
Welche PHP-Version läuft bei dir und mit welcher kann Joomshopping "arbeiten"?
In der joomshopping Erweiterung wird mit angezeigt, dass ich die aktuelle für J4 geeignete Fassung installiert habe.
Manchmal kann es sein, dass unter "Aktualisierungen" halt nicht die aktiuellen Updates angezeigt werden. Einfach mal di Update-Quellen wiederherstellen lassen. Wird dann eventuell doch noch was Neueres angezeigt.
Aber wie gesagt: Du kannst deine Versionen ja auch manuell mit denen vergleichen, die auf der Webseite des Anbieters angeboten werden.
Was mit noch aufgefallen ist: Nutzt du eine Testseite oder ist das die produktive Webseite. Kann es sein, dass du die Testseite in einem Verzeichnis direkt unter deiner produktiven Webseite installiert hast?
Muss ich mir da Sorgen machen wenn ich das Plugin benutze?
Bei mir läuft es mit Joomla 4 bisher ohne Probleme. (2.1RC3)
Leider kann ich im Modul selbst auch nicht die Version des Moduls abfragen?
Was wird unter "Verwalten" -> "Erweiterungen" angezeigt?
Ich kenne Joomshopping nicht. Wurden die Module wirklich zusätzlich installiert? Vielleicht sind sie in der neuen Version bereits im Paket enthalten. Nur so einige Ideen.
plugins/system/yt/ habe ich gelöscht - ohne Erfolg!
Mit dem Template "Protostar" laufen zwei Websites - die eine mit PHP 8.0 problemlos, die andere Website stürzt ab (s.o.).
Könnte noch ein paar Tipps gebrauchen, werde aber auch auf Fehlersuche gehen - mal sehen.
PHP 8.0 passt im Normalfall für Joomla und Protostar. Es ist wohl immer noch diese Erweiterung, die Probleme bereitet.
PHP 8.1 solltest du jedenfalls nicht nutzen.
Das Plugin hättest du einfach deaktivieren können oder notfalls zumindest testweise deinstallieren können.
Wenn du da nun nur das Verzeichnis gelöscht hast (besser wäre umbennenen gewesen), dann bereiten womöglich die DB-Einträge Probleme, die ja noch vorhanden sind.
Kannst du mal in die Tabelle _extensions gehen und nach diesem Plugin suchen. Dieses dann mal bei enable auf "0" stellen, um es zu deaktieren!
Ich habe dasselbe Problem; wie wurde es denn gelöst? Der Thread steht auf „erledigt“, aber ohne Hinweis auf die entscheidende Korrektur.
Wenn ein Thema erledigt ist, heißt es nicht automatisch, dass das Problem gelöst wurde. Manchmal ergeben sich beispielsweise andere Möglichkeiten, so dass das Problem gar nicht mehr akut ist.
Und wie mache ich das mit dem verstecken Menueeintrag?
Hast du dir die Einstellungen im Menüpunkt mal durchgeschaut? Da findest du so was wie "Im Menü anzeigen?". wähle einfach "Nein" aus!
Beim Stöbern im Netz fand ich die Info, dass dies ein Fehler bei Joomla 4.2 sei, und es wurde empfohlen in /administrator/cache/ die Datei 'autoload psr4.php' zu löschen. Bei einem anschließenden Reload der Site würde sich diese Datei automatisch wieder (jetzt korrekt) etablieren.
Ich habe das Verfahren noch nicht ausprobiert und frage daher, ob ihr mir die Richtigkeit dieser Auskunft bestätigen könnt.
Die Dateien in den Cache-Verzeichnissen kannst du natürlich löschen. Ob es dein Problem löst, weiß ich nicht. Auf jeden Fall solltest du es versuchen, wenn du diese Info irgendwo erhalten hast.
Nebenbei: Siehe #38! Wenn du AkeebaBackup nutzt, dann solltest du es auch in vollem Umfang nutzen.
Also sagt ihr den Ordner löschen und den neuen rein?
Unabhängig von der eigentlichen Thematik: Beim Testen ist es immer besser, einen Ordner umzubenennen anstatt ihn zu löschen. Wenn gelöscht, dann ist er ganz weg. Beim Umbenennen kann man ihn notfalls wieder reaktivieren.
Werden vielleicht irgendwelche css-Dateien nicht geladen? Analysiere mal mit F12!
Und welche Joomla3-Version hast du?
Die lokale Webseite und die Live-Webseite habe nunmal unterschiedliche Einstellungen bzgl. .htaccess und configuration.php.
Ich mache das immer so:
Bei Nutzung von kickstart.php mit der anschließenden Joomla-Installation werden die wichtigsten Einstellungen (z.B. DB-Zugang) abgefragt. Die configuration.php wird also automatisch geändert. Die SEF-Einstellung behalte ich einfach bei.
Lokal verwende ich auch eine .htaccess, damit SEF reibungslos funktioniert.
In der .htaccess müssen natürlich ein paar Anpassungen für den lokalen Server gemacht werden, also beispielsweise müssten Weiterleitungen wie ohne-www zu mit-www oder http zu https gelöscht oder zumindest als Kommentar gesetz werden. Auch RewriteBase ist, so glaube ich, mit einem Unterordner zu versehen. (Hab da lange nicht mehr reingeschaut).
Diese .htaccess halte ich mir immer bereit, um sie für meine lokalen Seiten zu nutzen und dann schnell anzupassen.
Ein wenig aufpassen muss man bei der Installation wenn gefragt wird, ob man die .htaccess löschen möchte. Ich weiß da nämlich nie, ob die .htaccess aus dem .jpa / .zip oder die .htaccess gemeint ist, die sich möglicherweise in dem Verzeichnis befinden könnte, in welches man Joomla einspielen möchte.
Als "Unwissender" kann ich mir nicht erklären warum eine einfache Kopie (Erstellung des Overrides) schon zu einem anderen Ergebnis führt als das Original...
Kann es sein, dass du einfach nur die falsche Datei kopierst?
Sonst entferne die Override-Datei wieder und benenne testweise die originale Datei mal um! Dann sollte ein Fehler kommen.
Wenn trotzdem alles korrekt angezeigt wird, dann bist du an der falschen Stelle.
Wie gesagt: Caches beim Testen unbedingt deaktivieren!
Die Codes könntest du doch auch manuell auf deiner Webseite irgendwo hinzufügen/verstecken. Wenn man sie dann jeweils anklickt, wird man zum entsprechenden Menüpunkt/Beitrag weitergeleitet. Nutze also einen ganz normalen Link. Diesen Menüpunkt sollte man eventuell von der Indexierung ausschließen.
Ansonsten:
Was genau meinst du mit "Artikel". Etwas ein Produkt, welches du in einem Onlineshop verkaufst? Das wäre dann etwas ganz anderes. Da bräuchte man dann deutlich mehr Infos.
