Beiträge von hrybak

    Erst einmal Dank für die Hinweise.


    Ich habe dann erst einmal alles neu aufgesetzt - also erneut versucht - und erhalte dann in einem neuen Fenster folgende Fehlermeldung:


    Fatal error: Uncaught Error: Failed opening required '/homepages/38/d24081757/htdocs/DaCapoEntw01/installation/framework/autoloader.php' (include_path='.:/usr/lib/php8.0') in /homepages/38/d24081757/htdocs/DaCapoEntw01/installation/index.php:86
    Stack trace:
    #0 {main} thrown in /homepages/38/d24081757/htdocs/DaCapoEntw01/installation/index.php on line 86


    Akkeba Kickstart erscheint parallel sofort mit Punkt 6: Restoration and Cleanup und die Dateien sind alle wieder übertragen, aber die Datenbank ist leer.


    Zunächst aber die Frage, was diese Fehlermeldung aussagt.

    Es geht um Folgendes:


    Unsere Entwicklungsumgebung https://www.entw-tsg-dacapo.de sollte auf den Stand der zuvor aktualisierten Live-Umgebung https://www.tsg-dacapo.de/ gebracht werden. Dazu wurden die Inhalte der Entwicklungsumgbung über Filezilla gelöscht, dann die Datenbank in IONOS gelöscht und dort eine neue Datenbank angelegt.


    Abschliessend (d.h. gestern gegen 19:00) sollte ein Backup der Liveumgebung in die Entwicklungsumgebung übertragen werden mittels Kickstart von Akeeba. Dabei ist überraschenderweise ein Fehler aufgetreten. Leider habe ich in der Hektik bzw. Panik (sowas ist halt in den vergangen Jahren noch nie passiert) vergessen, die Fehlermeldung zu notieren.


    Ergebnis ist, dass ich zwar die Entwicklungsumgebung aufrufen kann (sowohl Frontend als auch Backend als auch über Filezilla), aber scheinbar immer in der Liveumgebung lande. Im Backend der Entwicklungsumgebung ist jedenfalls unter Konfiguration > Server die Datenbank der Liveumgebung eingetragen und ein neu erstellter Beitrag über das Backend der Entwicklungsumgebung ist dann auch in der Liveumgebung zu sehen. Eine kleine Änderunge in der user.css (max. Breite der Einleitungsbilder) bleibt dagegen auf die Entwicklungsumgebung beschränkt, ebenso wie z.B. Änderungen beim Sprachen-Override.


    Die neue Datenbank existiert zwar, ist aber ohne Inhalt (gemäß phpMyAdmin).


    Meine Vermutung ist nun, dass alleDateien, wie z.B. die user.css, übertragen wurden (gemäß Filezilla tragen sie alle das Datum vom 18.1.), aber nicht die Datenbank. Über Kickstart wurde dann wegen des Fehlers die Datenbank der Liveumgebung referenziert bzw. die Referenz nicht auf die neue Datenbank geändert - oder?


    Was kann ich jetzt tun?

    • Export der Live-Datenbank > Import in die neue Datenbank > Änderung der Datenbankeinträge im Backend? oder
    • Erneutes Löschen der Dateien in der Entwicklungsumgebung über Filezilla, neues Backup der Live-Umgebung erzeugen und nochmal über Kickstart alles übertragen in eine ebenfalls neu angelegte IONOS-Datenbank? oder
    • . . .

    Wenn meine obige Vermutung zutrifft, würde ich die 2. Lösung für die richtige halten (?)

    Wir nutzen Flexicontact (free version) in Kombination mit ospam-a-not. Funktioniert einwandfrei. Mir der paid version können sogar unterschiedliche Formulare definiert werden. Werden wir demnächst installieren.


    ReCaptcha haben wir noch nie gebraucht.

    Das kommt ganz auf die Aufgabenstellung an. Ich kann hier nur für JEvents sprechen, das sehr viele Funktionen bietet für größere Mengen an Veranstaltungsterminen und Veranstaltungskategorien, Beschreibung von Veranstaltunegn, Anmeldung von Teilnehmern, Bezahlung von Tickets, Übersicht über Veranstaltungen, verschiedene Kalenderansichten u.v.a.m.. Schau mal unter https://www.tsg-dacapo.de/inde…k.listevents/2022/12/23/-


    Für einfachere Anforderungen hieße JEvents aber mit Kanonen nach Spatzen schießen, zumal einige Features kostenpflichtig sind (z.B. das Reservierungssystem)


    Zu den andern Extentions sollten andere im Forum was sagen können.


    Und Ja, mit Joomla Core dürfte es sehr schwierig werden.

    Ich bin ja für jeden Hinweis dankbar und habe gleich ausprobiert, weiss aber nicht was ich von den Ergebnissen halten soll.


    Vorausgeschickt sei, dass beide Vereinsseiten strukturell, seitens Konfiguration und seitens der Komponenten weitgehend identisch sind.


    IG-Lilienthal ist die einfachere Seite- allerdings mit sehr vielen Bildern: mobil 34% (mal allerinings auch nur 25% odeer sogar 41% - weshalb ???)) / Computer 56% und hier Best Practices sogar 100%


    TSG-DaCapo hat wesentlich mehr Beiträge und JEvents mit unzähligen Veranstaltungen integriert: mobil 65% mit Best Practices 92%, Computer 65% mit Barrierefreiheit und Best Practices jeweils 92%.


    Wieso ist die komplexere Seite dann deutlich besser als die einfachere Seite?


    Abgesehen davon fehlt mir hier die notwendige Sachkenntnis und die Zeit, die Maßnahmen im Einzelnen zu bewerten und dann auch umsetzen zu können. Ich bin halt kein Web-Experte und froh mit Joomla überhaupt zwei Webseiten gestaltet zu haben. die den Vereinsmitgliedern und den Vorständen zusagt. Und bisher hat sich noch kein Besucher der Seite beschwert - weder auf Computer noch Smartphone.


    Es ist halt alles eine Frage der Prioritäten und ob jetzt Google mir die Maßstäbe vorsetzt ist ja auch noch zu diskutieren.



    Noch was: die Hoster sind unterschiedlich - welchen Einfluss das hat kann ich nun erst gar nicht abschätzen und habe da sowiso keinen Einfluss weil nicht zuständig.

    Nur bzgl. "Framework" habe ich eine klare Position: Wannimmer möglich, verzichte darauf ;)

    Kann ich nur bestätigen: habe beim Upgrade von jomla 3 auf Joomla 4 das verwendete Framework "weggeschmissen" mit dem Effekt, das der Gesamtaufwand deutlich weniger wurde. Gleiches gilt für die früher verwendeten Nicht-Standard-Templates. Die wurden durch den neuen Standard Cassiopeia ersetzt.


    Daher kann ich nur empfehlen erst einmal nur mit dem Standard anzufangen: also Cassiopeia als Template (ohne Child-Tempate), keine Overrides, Standard-Editor TinyMCE und Standard-Media-Manager (der ist mit Joomla 4 wirklich gut geworden). Anpassungen nur über user.css und user.js.


    Dass mit einer derartigen "Minimal"-Konfiguration nach wie vor gut gelebt werden kann, zeigen (so glaube ich zumindest) meine beiden mehr oder weniger komplexen Vereinsseiten.

    Ich kann die Vorgehensweise bzw.die Intention nicht nachvollziehen. Was soll erreicht werden? Soll jedes Jahr über einen eigenen Menüpunkt angesprochen werden? Hilfreich wäre hier ein Link zur Webseite.


    Ich kann lediglich zeigen, wie ich das im Backend konfiguriert habe: Komponenten > JEvents > Jevents Konfiguration > (weiter unten) Letztes im Kalender anzuzeigendes Jahr oder Jahr NACH jetzt > 24 (oder halt nur 23). Zu sehen ist das unterhttps://www.tsg-dacapo.de/index.php/jeventstestlistbyday-4/year.listevents/2022/12/10/-


    Ich vermute mal, dass genau diese Einstellung notwendige Voraussetzung ist.

    Der Link verweist auf die Beschreibung zu Phoca Gallery unter Joomla 3.0 (wird auch rechts oben angezeigt). Vieles was da beschrieben wird, läuft unter Joomla 4.x so nicht mehr.


    Aus meiner Sicht ist diese Seite veraltet und sollte nicht mehr als Referenz verwendet werden. Wo eine aktuelle Beschreibung für Joomla 4 zu finden ist, weiss ich allerdings nicht, da die von mir unter Joomla 3 angebote Highslide-Funktionalität unter Joomla 4 nicht mehr angeboten wird (so mein letzteer Stand gemäß Aussage des Entwicklers im Phoca Forum) ) und ich deshalb auf eine andere Lösung umgestiegen bin.

    Liegt wohl daran, dass 16px die voreingestellte Standard-Größe ist - wird in TinyMCE auch so bei Standardtext angezeigt. D.h., 16px läßt sich durch Löschen der Formatierung (Tx) wieder herstellen. So mache ich das jedenfalls, wenn eine geänderte Schriftgröße doch nicht so gepasst hat.


    Und über HTML (<>) kann ich eh' jede beliebige Schriftgröße einstellen.

    Vielen Dank für die ausführliche und gute Antwort.


    Dazu noch folgendes: ich habe bisher auf Overides verzichtet und realisiere alle Anpassungen ausschließlich über die user.css und die user.js. Die Sinnhaftigkeit der Overrides hat sich mir noch nicht erschlossen und der Aufwand ist wahrscheinlich sogar höher (irgendwie bestätigst du das sogar). Der einzige Punkt, der dafür spricht ist die automatische Information, dass sich was geändert hat. Ob das den Aufwand rechtfertigt? Ich habe jedenfalls nach fast einem Jahrzehnt Arbeit mit Joomla noch keine Probleme gehabt, weil ich Ovverides nicht nutze (ausgenommen die Sprach-Overrrides).


    Was mir dagegegen nach Updates sehr hilft sind ausgewählte Tests der kritischen Funktionen. Dadurch wird innerhalb kurzer Zeit klar, ob was hakt oder nicht.


    Übrigens: gemessen an Deinen Einfacheitskriterien sind meine Seiten dann wirklich nicht einfach. Und Deine Erfahrungen teile ich in vollem Umfang

    Neugierige Frage: Gibt es denn eine nennenswerte Anzahl von Joomlanutzer*innen, welche die Joomla-Standardtemplates verwenden?

    Sind das dann nicht eher solche, die Joomla nur zum Experimentieren oder für ganz einfache Webseiten nutzen?

    Ja, gibt es und es wird nicht nur damit experimentiert. Ich bin im Zusammenhang mit Joomla 4 von Nicht-Standard-Templates bei meinen 2 Webseiten auf Cassiopeia umgestiegen, da endlich die Funktionen vorhanden waren, die mir vorher gefehlt haben (z-B. das Grid-Konzept und der Media-Manager) und die Gestaltung wesentlich vereinfacht haben. Beide Webseiten würde ich übrigens nicht als "einfach" bezeichnen - abgesehen davon: was ist eine "einfache" Webseite?


    Meine Wahrnehmung hier im Forum ist auch, dass sehr viele Nutzer vorhanden sind. Andernfalls würde es nicht soviele Beiträge zu Cassiopeia geben.


    Bei der Gelegenheit: ich teile die Ansichten derjenigen, die sich kritisch zum Thema Aufwärtskompatibilität geäußert haben und hoffe, dass der Upgrade auf Joomla 5 nicht so aufwendig wird die vergangenen Upgrades. Vielleicht können sich ja die Joomla- und die Extentionentwickler lägerfristiger und besser abstimmen als dies offenbar in der Vergangenheit geschehen ist (so zumindest mein Eindruck während des Upgrades auf Joomla 4).

    Versuche es mal mit .grid-item1 {text-align: center; . . . .}.


    Ich habe die Vorgehensweise über Grid selbst ausporbiert und bin anfangs auf das gleiche Problem gestossen.


    Im Übrigen denke ich, dass diese Methode für deine Aufgabenstellung die beste ist und deutlich einfacher als über Tabellen. (Anders sieht es nach meiner Erfahrung aus, wenn es sich um strukturierte Tabellen handelt, bei denen Spalten und/oder Zeilen z.B. unterschiedliche Inhalte und unterschiedliche Formatierung haben.)

    Setze über css table tr und table td auf display: block; width: 100% und display: none für table tr > td:nth-of-type(n). n steht hier für die Spalte(n), die ausgeblendet werden soll(en).


    Da sicher nicht alle Tabellen auf die gleiche Art behandelt werden sollen ist zur eindeutigen Identifizierung zusätzlich die Zuordnung einer Klasse sinnvoll wie z.B. table.tablemyclass


    Auf diese Weise können sehr einfach unterschiedliche Tabellentypen für Smartphone angepasst werden. Zwei Beispiele findest Du unter https://www.ig-lilienthal.de/index.php/termine-menu und unter https://www.ig-lilienthal.de/i…-menu/mitgliedschaft-menu am Ende. Einfach mal das Fenster ganz schmal machen.


    Aufwendig kann dabei lediglich die Formatierung der umsortierten Tabelle werden. Aber das muss eh' immer getan werden.


    Noch eine Ergänzung dazu: für alle tr und alle td muss gesetzt werden height: auto;. Ab einer der letzten Joomla-Updates wird bei Tabellen height automatisch auf einen konkreten Wert gesetzt (warum?). Dass ist dann bei responsive gestalteten Tabellen kontraproduktiv.