Beiträge von Clemens-XS

Unter Systeminfo steht unter PHP-Version:

7.3.2-3+0~20190208150725.31+stretch~1.gbp0912bd

Unter PHP-Informationen findet sich bei Serversystem

xxxxxx.goserver.host 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64

Server Build Date: Feb 8 2019 15:07:25

PHP-API: 20180731

Apache API Version: 20120211

Den Begriff PHP-Interface finde ich nicht. Ich kann aber von dieser Installation (MariaDB und PHP7.3) noch andere Angaben machen, die evtl. weiter helfen:

SQLite3Library 3.16.2

MySQLi API Library Version: mysqlnd 5.0.12-dev - 20150407 -

Ich hoffe, das sind Angaben, mit denen du was anfangen kannst. Wenn nicht: Ich brauch die exakten Begriffe, zu denen ich Angaben machen soll.

Hallo! Fast hätte ich selbst so einen Thread gestartet, da ich ebenfalls Probleme habe, mich in Protostar einzuarbeiten! Bisher hatte ich JYAML als Template verwendet und war fit darin. Es war durchaus ein "Fluid-Design" und brachte gute Ergebnisse auf allen Displaygrößen und Geräten! Aber es wird seit einigen Jahren schon nicht mehr weiter gepflegt und spätestens, wenn es auf Joomla 4 geht, wird das JYAML-Template wahrscheinlich nicht mehr funktionieren.

Nach einiger Suche fand ich das erweiterte / verbesserte Template ProtostarPlus. Im Gegensatz zu "der_kps" will ich möglichst keine Inline-Styles mehr verwenden und alles in den CSS-Dateien definieren. Aber eine CSS-Datei mit fast 170kB Größe und fast 8.000 Zeilen, da hört's bei mir auf mit dem Durchblick. Und diese CSS empfinde ich auch als zu unübersichtlich, als dass es dort Sinn macht, mit Trial 'n Error solange zu probieren, bis ein gewünschter Effekt erreicht wird.

Ich hänge mich deshalb in diesen Thread, weil meine Fragen evtl. auch "der_kps" nützen können.

Was mich am meisten bei Protostar wundert, ist dass alle Schriftgrößen nicht in relativen Maßen sondern als Pixel definiert sind. Wie passt denn das zu einem Template, das auf allen erdenklichen Geräten und Displaygrößen zu gut lesbaren Ergebnissen und zu ähnlicher Anmutung führen soll? Auch line-height, margins und paddings werden fast immer in Pixel definiert. Das verstehe ich einfach nicht!

In JYAML hatte ich alle Werte entweder in Prozent oder em definiert und das Erscheinungsbild war auf allen Geräten und Displaygrößen immer ausgezeichnet!

Müsste ich denn, um eine ähnliche Darstellungsqualität wieder zu erlangen, in der gesamten template.css alle Größenangaben und Abstände von Pixel auf em umstellen? Wenn ja, werde ich schnellstens ein anderes Template auswählen, z.B. wie mir in einem anderen Thread hier empfohlen wurde, eines von Joomla51.com. Einige sind sogar kostenfrei: https://www.joomla51.com/free-joomla-templates

Elwood: Die Installation meiner bisherigen JoomlaSites auf der MySQL-8 geschah mit der Codierung UTF8mb4_unicode_ci

Mir ist einfach deine Frage nicht aufgefallen, sorry.

Mein Provider ist schon etwas merkwürdig mit seinen Vor-Einstellungen, da er das alte PHP 7.1 und zugleich MySQL-8 aktiviert hat. Und außerdem, dass er die Joomla-OneClick-Installationen ohne Empfehlung für die MariaDB, also voreingestellt auf MySQL-8 durchlaufen lässt.

Von diesen gravierenden Unstimmigkeiten abgesehen, habe ich aber bisher nur gute Erfahrungen mit Webgo gemacht: Der Support ist blitzschnell und fast immer sehr kompetent die Server laufen sehr schnell und mit wenig Ausfallzeiten, Let's encrypt ist inklusive, die Server stehen grundsätzlich in Deutschland und das Ganze ist auch noch ziemlich kostengünstig.

@GHSVS: Bei allen Installationen habe ich nie die Demodaten mit installiert. Und: Das einzige, was ich bis jetzt nicht auch noch probiert habe, ist die Installation von Joomla auf MySQL-8 bei gleichzeitig aktiviertem PHP 7.3 - Hab halt wenig Zeit nach all den Problemen und Verzögerungen.

Vielen Dank dir! - Dass du so schnell antwortest, hat ja bald Chat-Qualität! Ein echtes Joomla-Wunder eben!

Na dann ein erfreuliches, angenehmes Wochenende dir!

OK, danke dir.

Nur interessehalber: Worin bestehen denn die Unterschiede der von mir genannten Unicode-Typen?

Hab doch noch ne Frage: Beim Anlegen neuer DBs werde ich nach dem Zeichensatz / Kollation gefragt. Vorgeschlagen wird mir UTF8mb4_unicode_c

Es gibt aber z.B. noch UTF8mb4_unicode_ci und UTF8mb4_german2_ci und viele andere, die aber aufgrund der Sprachbezeichnung nicht infrage kommen dürften.

Welchen Zeichensatz sollte ich denn wählen, wenn alle meine Sites nur deutsch-sprachig sind?

Hab gerade beim ISP nachgeschaut PHP 7.1 ist default und ich konnte jetzt auf 7.3 umschalten.

@Joomla-Wunder: Der Hoster hat 7.3 durchaus im Angebot, war aber so nicht als default eingestellt.

Kurzer Test der jetzigen Websites: Keine Probleme.

Aber die Fehlermeldungen betr. der Datenbank sind auch bei PHP 7.3 gleich geblieben.

Danke für Eure Meinungen!

Ich werde also jetzt alles neu installieren auf Maria-DB. (Schade um meine bisher aufgewendete Zeit!)

hechtnetz:

Zitat

Tu Dir/uns mal den Gefallen. Wenn die Fehlermeldungen da auch kommen, dann können wir weiterreden. Wenn es an Joomla liegen würde, dann wären die Foren davon schon voll. Bisher scheinst Du aber Einzige zu sein.

So schnell kann's gehen. Ich bin sehr wohl nicht der Einzige und das Problem ist jetzt hier vollumfänglich klar geworden.

Diesen Beitrag habe ich heute früh auch gelesen: https://docs.joomla.org/Joomla_and_MySQL_8

Allerdings beantwortet der meine Frage nicht, ob ich weiterhin die MySQL-8 DB nutzen und die Fehlermeldungen ignorieren sollte oder ob es klüger wäre, jetzt alles auf Maria-DB zu ändern.

Der von mir verlinkte Beitrag richtet sich ja auch auf das Thema "Authentication". Witzigerweise habe ich ja genau damit keine Probleme: Der An- und Abmeldevorgang laufen auf allen Websites reibungslos.

Der erste Beitrag im Forum: https://forum.joomla.org/viewtopic.php?t=968242 beschreibt aber anscheinend exakt meine Situation. Auch dieser User berichtet von exakt 19 Fehlermeldungen. Und auch er ist im Zweifel, ob der Rat eines anderen Forummitglied denn wirklich sinnvoll sei, die Fehler einfach zu ignorieren. Statt einer Antwort wurde er nicht ernst genommen und verspottet!

In meinem langen Beitrag oben habe ich genau beschrieben, dass wir alle in eine Update-Falle tappen könnten, wenn das Joomla-Team nicht die MySQL-8 Kompatibilität herstellt: Weichen wir jetzt auf Maria-DB aus und Maria-DB würde ein ähnliches Upgrade erfahren, wie mySQL-8, könnten die Probleme ebenfalls auftreten, dann allerdings ohne jegliche Unterstützung des Joomla-Teams.

j!-n: Da ich gerade erst zu diesem Provider gewechselt bin und von diesem dicken Bug abgesehen bisher sehr zufrieden mit denen bin, sehe ich keinen Anlass, erneut zu wechseln. Zumal ich weder Zeit noch Geld im Überfluss habe. – Und wenn ein neuer Provider dann ebenfalls sich entschließt, alle Server auf MySQL-8 zu ändern? Dein Tipp trägt also nicht zur wirklichen Lösung bei.

Ich wiederhole noch mal meine Frage:

Würdet Ihr an meiner Stelle jetzt alles auf Maria-DB ändern? oder:

Würdet Ihr alles so lassen, wie es ist (mit MySQL-8) und die Fehler einfach ignorieren?

Ich war gestern im See schwimmen, daher erst jetzt meine Antwort.

Ich habe den gesamten Sachverhalt dem Hoster geschildert, er hat alles nachgeprüft und behauptet nun folgendes:

1. Ja es liegt an der Datenbank, weil man grundsätzlich nur noch mySQL Version 8 Datenbanken anbietet.
2. Joomla kommt (zumindest in Versionen unter 4.0) nicht mit diesen mordernen Datenbanken klar.
3. Der Webhoster empfiehlt mir, die alternativ angebotene MariaDB zu wählen, obwohl diese offiziell von Joomla nicht empfohlen oder supported wird.

Meine Schlussfolgerungen:

1. Da MariaDB nicht offiziell von Joomla unterstützt wird, könnte es bereits bei der nächsten Major-Version von MariaDB zu ähnlichen Kompatibilitäts-Problemen kommen, wie jetzt bei mySQL 8.
2. Joomla-User sind, falls sich an der Datenbank-Kompatibilität von Joomla ändert, aktuell zwischen den Stühlen, weil mySQL 8 noch nicht funktioniert und MariaDB wegen mangelndem offiziellen Support von Joomla ein Kompatibilitätsrisiko darstellt. Dies kann leicht geschehen, wenn Joomla mySQL 8 fähig gemacht wird.

Nun nochmals zur Klarstellung meiner Installationen:

Ich habe aktuell zwei seit Jahren laufende Joomla-Sites vom bisherigen Webhoster zum neuen umgezogen. Vorher hatte ich Joomla und alle Extensions auf Aktualität geprüft und die (mySQLi-) Datenbank mit dem Joomla-eigenen Mittel geprüft. Erst als alles sicher OK war, habe ich mit AkeebaBackup gesichert und die Sites auf dem neuen Webspace installiert. Dabei habe ich sicher gestellt, dass in neue Datenbanken installiert wurde, die garantiert keinen Inhalt hatten.

Ferner habe ich aktuell noch eine Joomla-Installation, die über das Installationspaket des Hosters gelaufen ist und drei neue angelegte, bei denen ich das zuvor aktuellste Joomla-Paket entpackt und per FTP hochgeladen habe und ebenfalls streng darauf geachtet hatte, dass die angegebenen Datenbanken absolut leer waren.

Bei allen drei Installationsvarianten ergaben sich immer die gleichen 19 Fehlermeldungen die Datenbank betreffend.

Nach meinen daraufhin heute morgen angestellten Webrecherchen laufen zahlreiche Joomla-Installationen seit Jahren stabil mit MariaDB 5.xx bis 10.xx - Seit Sommer 2018 (?) gibt es aber mySQL-8 und wenn das Joomla-Team wegen seiner Verbundenheit zu mySQL hier künftig die Kompatibilität herstellen wird, kann es sehr wohl mit Maria-DB zu Problemen kommen, für die es dann von Seiten Joomla keinen Support geben wird! Und genau das ist das eigentliche Problem.

Mir wird aktuell nichts anderes übrig bleiben, als alle meine bisher installierten Sites neu zu installieren und dabei MariaDB verwenden, um aktuell stabile Verhältnisse zu bekommen.

Bisher habe ich keine Joomla-Instabilitäten mit mySQL-8 feststellen können (weder bei den alten umgezogenen beiden Sites, noch bei den neu angelegten) außer eben die Fehlermeldungen, die Joomla mir ausgibt. Es mag ja sein, dass ich auch künftig nicht mit Problemen rechen muss, aber ich halte es für riskant, darauf zu spekulieren.

Dem Webhoster werfe ich vor, wenn er schon Joomla-Pakete zur Installatiion anbietet, wenigstens die Information dazu zu liefern, bei Joomla bis auf Weiteres die Maria-DB zu verwenden. Durch dieses Unterlassen hat der Hoster mir rund eine Woche Arbeitszeit vernichtet – gerechnet für die jetzt neu anstehenden Neu-Installationen sowie den bisherigen Aufwand, den Fehler zu finden und zu diskutieren.

Frage hier jetzt noch:

Wie würdet ihr jetzt an meiner Stelle entscheiden – Maria-DB verwenden oder es (zumindest bei den beiden Produktiv-Sites) bei der jetzigen mySQL-8-Nutzung belassen bis evtl. wirklich Fehler auftreten?

hechtnetz Holla! Jetzt wird's aber persönlich statt sachlich.

Morgen kontaktiere ich den Webhoster und wir werden weiter sehen. Bis dahin ist deine Aufregung sicher auch abgeklungen.

Sorry aber da komme ich nicht mit: Ich lege SQLi-Datenbanken an und bei der Joomla-Installation werden diese mit Daten befüllt. Was kann denn da schief laufen?

Meinst du wirklich, man schreibt in die Datenbank was rein und anschließend steht was anderes drin, als reingeschrieben worden ist???

Schade, dieses Thema ist NICHT erledigt!

Ich habe gerade komplett neu installiert, direkt von ttps://downloads.joomla.org und danach das deutsche Sprachpaket. Es erschien die Meldung:

Warnung Achtung: Die Datenbank ist nicht auf dem neuesten Stand!

Und das ergab daraufhin die Datenbank-Prüfung:

    Die Tabelle „'x65qv_languages'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'sitename'“ mit Typ „VARCHAR(1024)“. (Von Datei: „2.5.0-2012-01-14.sql“.)
    Die Tabelle „'x65qv_associations'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'id'“ mit Typ „INT(11)“. (Von Datei: „3.0.3.sql“.)
    Die Tabelle „'x65qv_user_profiles'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'profile_value'“ mit Typ „TEXT“. (Von Datei: „3.3.4-2014-08-03.sql“.)
    Die Tabelle „'x65qv_redirect_links'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'old_url'“ mit Typ „VARCHAR(2048)“. (Von Datei: „3.5.0-2016-03-01.sql“.)
    Die Tabelle „'x65qv_redirect_links'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'new_url'“ mit Typ „VARCHAR(2048)“. (Von Datei: „3.5.0-2016-03-01.sql“.)
    Die Tabelle „'x65qv_redirect_links'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'referer'“ mit Typ „VARCHAR(2048)“. (Von Datei: „3.5.0-2016-03-01.sql“.)
    Die Tabelle „'x65qv_redirect_links'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'new_url'“ mit Typ „VARCHAR(2048)“. (Von Datei: „3.6.0-2016-04-06.sql“.)
    Die Tabelle „'x65qv_newsfeeds'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'link'“ mit Typ „VARCHAR(2048)“. (Von Datei: „3.6.3-2016-08-15.sql“.)
    Die Tabelle „'x65qv_extensions'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'enabled'“ mit Typ „TINYINT(3)“. (Von Datei: „3.7.0-2016-11-04.sql“.)
    Die Tabelle „'x65qv_modules'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'content'“ mit Typ „text“. (Von Datei: „3.7.0-2016-11-27.sql“.)
    Die Tabelle „'x65qv_ucm_content'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'core_body'“ mit Typ „mediumtext“. (Von Datei: „3.7.0-2017-01-08.sql“.)
    Die Tabelle „'x65qv_ucm_content'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'core_params'“ mit Typ „text“. (Von Datei: „3.7.0-2017-01-08.sql“.)
    Die Tabelle „'x65qv_ucm_content'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'core_images'“ mit Typ „text“. (Von Datei: „3.7.0-2017-01-08.sql“.)
    Die Tabelle „'x65qv_ucm_content'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'core_urls'“ mit Typ „text“. (Von Datei: „3.7.0-2017-01-08.sql“.)
    Die Tabelle „'x65qv_ucm_content'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'core_metakey'“ mit Typ „text“. (Von Datei: „3.7.0-2017-01-08.sql“.)
    Die Tabelle „'x65qv_ucm_content'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'core_metadesc'“ mit Typ „text“. (Von Datei: „3.7.0-2017-01-08.sql“.)
    Die Tabelle „'x65qv_categories'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'description'“ mit Typ „mediumtext“. (Von Datei: „3.7.0-2017-01-09.sql“.)
    Die Tabelle „'x65qv_categories'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'params'“ mit Typ „text“. (Von Datei: „3.7.0-2017-01-09.sql“.)
    Die Tabelle „'x65qv_finder_links'“ hat den falschen Typ oder die falschen Attribute für die Spalte „'description'“ mit Typ „text“. (Von Datei: „3.7.0-2017-03-19.sql“.)

Also witzig find ich das nicht und durch die Funktion "Reparieren" tut sich auch nix. Ich glaube sogar, dass es die gleichen Meldungen sind, wie in meinem ersten Beitrag hier.

Vor der Neu-Installation hatte ich natürlich sowohl das Installationsverzeichnis auf dem Server als auch die alte Datenbank sorgfältig gelöscht.

Damit ist dann auch mein Webhoster https://webgo.de aus der Kritik! Dessen Leistungen und Kundenservice fand ich bis jetzt hervorragend! Bin gerade erst zu ihm gewechselt.

Gemäß der bisherigen Diskussion: Muss ich also jetzt nach jeder Neu-Installation einen DB-Dump runterladen, im Editor korrigieren (dann müsste ich aber genau wissen, was ich als Korrektur eintragen müsste) und alles wieder hoch laden. – Also das kann es doch nicht sein mit Joomla!

Ja ich hatte sie für Front- und Backend eingestellt.

Hat sich geklärt! Ich musste unter Benutzer (=Admin) die deutsche Sprache auswählen, obwohl diese dort auf "default" stand und ich deutsch als default ja ausgewählt hatte.

Habe gerade Joomla direkt von der englischsprachigen Joomla-Site installiert und dazu das deutsche Sprachpaket nach-installiert. Danach habe ich das Sprachpaket unter ControlPanel Languages aktiviert und ebenfalls unter ContentLanguages. Keine Reaktion, im Backend bleibt alles englisch, auch nach einem Ausloggen und wieder Einloggen und auch nach Löschen des Cache.

Hab per FTP kontrolliert, dass sowohl im Backend als auch im Frontend die deutschen Sprachpakete installiert sind. Alles OK dort.

Die Site hat noch keinerlei Content und eine URL ist da wenig hilfreich.

Was tun?

OK. Mir ist durch Infos auf zwei anderen Websites klar geworden, dass ich mit einem Link zwar eine andere Website oder sogar ein Video aufrufen kann, nicht aber mit dem Link zusammen bereits Beschreibungen übergeben kann, wie die zu öffnende Seite aussehen soll.

Ich bin halt nicht hauptberuflicher Joomla / CSS / JS -Mensch, sondern in einem Gesundheitsberuf tätig und muss meine Websites selbst erstellen.

Ich habe gerade experimentell heraus gefunden, dass ich mein Vorhaben tatsächlich mit der JCE-Mediabox realisieren kann. Ein mit der Mediabox geöffneter Joomla-Artikel, egal ob der Inhalt per Ajax oder per iFrame in die Lightbox geholt wurde, darf durchaus seinerseits einen weiteren JCE-Mediabox-Link zu einem Video beinhalten - im Sinne einer Kaskade von zwei übereinander liegenden Lightboxen. Das Video wird immer zuverlässig in einer Lightbox geöffnet, bei Ajax mit seinen nativen Videoabmessungen, beim iFrame mit width = 100%.

Damit ist meine Anfrage hier erledigt, weil ich damit eine Lösung gefunden habe.

Danke für eure Geduld!

Mal ins Unreine gedacht:

Ich könnte z.B. einen Link mit der vollen URL zum Video erstellen:

<a href="https://meine-domain.de/images/video-1.mp4"Hier geht's zum Video</a> und setze dann hinter das <a class=" " oder eben style=" " und übergebe so die Definitionen, unter denen das Video dann im Browser laufen sollte.

Natürlich weiß ich, wie ich Videos in HTML-5 einbinde. Hier aber soll folgende Funktion erreicht werden:

Es gibt einen Text oder ein Bild, aus dem heraus auf das Video verlinkt wird. Dieser Link sollte mittels CSS so gestaltet werden, dass das Video vor einem Background einer bestimmten Farbe startet und Video nebst Background über den vorher gesehenen Content zu liegen kommt z.B. durch Nutzung des z-Index. Das ganze wirkt dann ähnlich, wie eine Lightbox, soll aber rein durch CSS entstehen, das in dem Link aktiviert wird und ohne jedes JS.

Frage ist das überhaupt möglich oder lässt der video-Tag gar keine Erweiterung mittels style=" " oder class=" " zu? Wenn doch, wie müsste der Link dann aussehen?

OK, danke, jetzt weiß ich, wie ich DBs lokal öffnen kann.

Die Joomla-Installationen haben mich bisher keinen Zeitaufwand gekostet. Hab sie gelöscht und neu installiert, natürlich jetzt vom frischen Paket. Hätte nicht gedacht, dass die Webhoster so wenig Sorgfalt walten lassen.

Hi!

Die Erst-Installation habe ich aus dem Webpaket Joomla vorgenommen, das mir mein Webhoster https://webgo.de zur 1-click-Installation bereit stellt. Es war Joomla Version 3.9.7 und ich musste nur ein Mal updaten. Das Updaten nahm ich über den Joomla-eigenen Mechanismus im Backend vor, kam also direkt von den Joomla Repositories.

Warum es in der Datenbank Einträge von 2012 gibt, verstehe ich auch nicht. Die DBs waren unbenutzt weil von mir zur Installation angelegt.

Mir ist die Vorgehensweise unbekannt, wie ich in einem HTML_Editor eine Datenbank öffnen kann! Ich arbeite hier mit dem Bluefish-Editor, da ich von Windows 7 auf Ubuntu umgestiegen bin. Aber auch da sehe ich keine Möglichkeit, damit eine Datenbank zu öffnen oder gar zu editieren. Müsste ich dazu einen Dump herunter laden und die DB lokal öffnen?