Beiträge von bembelimen

Tatsächlich ist Wordpress kein wirklicher modularer Baukasten mehr. Viele Funktionen die Joomla für die Verwaltung mitgeliefert werden (User + Permission System) gibt's so in Wordpress nicht, die werden dann von Agenturen dran getackert und wenn man bisschen skaliert wird wieder getackert. Alles im Hintergrund als Blackbox.

Abgesehen von den ganzen Problemen wie Performance etc.

Eins muss man aber klar anerkennen, Wordpress ist eine Gelddruckmaschine. Im weniger als ein Tag bekommt man eine Wordpress-Seite rausgeschossen, die irgendwie läuft. Und dann bleibt man idealerweise als Agentur entweder ganz weit weg davon oder verkauft weitere Funktionen.

Ich finde tatsächlich den Vergleich mit Wordpress bisschen müßig. Ich denke nicht, dass man als Joomlaagentur hier groß in Konkurrenz treten kann oder soll. (Ich denke aber auch, dass jeder der auf WordPress wechselt lieber zu Wix oder Jimbdo oder du wechseln sollte).

Die Kundengruppe für Joomla sind Unternehmen die wachsen. Die meisten Kunden von mir haben vor x Jahren ein Joomla 3 bekommen, haben einen SLA und rufen mich regelmäßig an, da sie beide Sachen haben wollen, sei es ein Newsletter-System, plötzlich mehrere User etc. Jetzt mit Joomla 4 habe ich schon vor 3 Jahren angefangen zu informieren, dass eine Migration nötig ist. Letztes und dieses Jahr sind viele der Kunden sogar dann alleine auf mich zu gekommen und haben gemeint, dass wir über die Migration reden sollten, da das die Gelegenheit ist auch ein Relaunch des alten Designs durchzuführen.

Man muss halt mit deinen Kunden reden, dieser früh genug transparent informieren und die Vorteile aufzeigen. Barrierefreiheit, bessere Performance, neues Design, aufgeräumtes Backend, verbessertes SEO, uvm ist super überzeugend.

Damit man das Anbringen kann, verweise ich auf meinen Post von zuvor: man muss bisschen Verantwortung für sein Business übernehmen, sich engagieren und auf dem neuesten Stand bleiben, alles andere ist rumgepansche.

Zitat von flotte

Dann frage ich mal ganz konkret nach: Ist es geplant, das Joomla ein automatisches Update einführt? Bei Wordpress kam man ja einstellen ob der Core, welche Plugins/Erweiterungen automatisch geupdatet werden sollen.

Ich weiss natürlich das dies Gefahren mit sich bringt und nach einem solchen Update die Seite plötzlich nicht mehr laufen könnte. Bei Wordpress kommt dies allerdings extrem selten vor. Ich will Wordpress gar nicht so hochloben, nenne es hier nur immer wieder als Beispiel, weil ist sehe wie sich viele User genau dorthin orientieren und das ärgert mich. Durch sinnvolle Backupstrategieren kann man die Probleme bei autom. Updates einfach minimieren.

PS:
Es gibt auch einige andere CMS wie z.B. Conato, die sich immer weiter von den Wünschen normaler User und die typischen Infrastruktur vieler Hoster entfernen. So weit ist Joomla allerdings noch nicht und ich bin auch kein Joomla-Hasser. Das nur zur Klarstellung.

Ich bin zwar nicht Christiane, aber bin so frei darauf zu antworten (+ schamlos SniperSister zu mention, da der hier unfassbar viel Wissen zu hat, was ich nicht habe):

Automatische Updates sind ein Feature, was schon lange diskutiert wird und eigentlich schon seit Joomla! 4.1 konkret auf der Wunschliste stand.

Nun könnten wir es uns natürlich relativ einfach machen und es wie Wordpress implementieren (Theoretisch reicht es ja, den "Klick" im Updater zu automatisieren). Praktisch tun sich nun aber viele Herausforderungen auf, die man ignorieren kann, aber nicht sollte:

• Ist die Update-Datei den eine reguläre Update Datei oder wurde z.b. durch eine Man-in-the-middle-Attack die ausgetauscht/verändert? Auch der Updateserver könnte kompromitierte Daten enthalten, wenn dieser gehackt wird (Worst-Case-Szenatio)
• Wer darf den Updates veröffentlichen? Bei Joomla haben z.b. mehrere Leute Commit-Rechte die aber nicht zum Release-Team gehören.
• Ist die Person, die dieses Update scheinbar erstellt hat auch tatsächlich die Person oder gibt sich nur jemand dafür aus?
• Gibt es ein Zwei-Augen-Prinzip
• Wenn jemand das Relase-Team verlässt, wie stellen wir sicher, dass die Person nicht weiter Updates herausgeben kann?

Hier könnte man natürlich recht relaxed den Wordpress-Weg fahren und sagen: das meiste ist uns egal und wir gehen das Risiko ein. Aber ich persönlich denke, dass man den Updateprozess definitiv absichern muss.

Nun die gute Nachricht: das alles wurde (besonders von David & Team) mittlerweile gelöst: es gibt ein komplettes Konzept wie man all die Sicherheitsaspekte beachtet und was dann zu einem automatisierten Updateprozess führen kann. (hier, hier und hier gibts Informationen). Und nun zur dunklen Seite: nur alleine um auf diesen Stand zu kommen haben mittlerweile ca. 10 Leute auf 3 Treffen (ein vierter ist geplant) ca. 500+ Stunden kostenlos investiert (zzgl. mehrstündige Zugfahrten etc.). Gäbe es nun jemand der das sponsern würde, wäre es bedeutend einfacher.

TL;TR: ja, automatische Updates sind geplant, es ist aber noch ein Weg dahin, insbesonders da es an allen Ecken und Enden an Ressourcen mangelt.

Ich finde ja, das größte Problem sind die Dienstleister, die zwar Joomla einsetzen aber absolut nicht auf dem Laufenden bzgl. der aktuellen Entwicklung sind. Ich mein, da ist Joomla die Existenzgrundlage (sei es nun als Extensionentwickler, Dienstleister, Templateschmiede, etc.) und man schert sich 0 um den Zustand von Joomla selbst. Die "Core-Entwickler" kümmern sich eh drum, sind dann aber die ignoranten Vollidioten, wenn etwas nicht mehr funktioniert.

Es ist mittlerweile dank Akeeba, Docker, Xampp, und all den anderen Tools so einfach automatisiert zu testen, ob ein Update funktioniert.

Insbesonders da mittlerweile auf Jahre hin alle Releasetage im voraus bekannt sind (wenn es nicht dringendes Security-Release ist).

Das heißt, mindestens 1,5 Wochen vor dem Release wird die RC1 veröffentlicht, die man testen kann. (zur Info: alle 2 Jahre ein neues Major-Release (4.x, 5.x, 6.x, ...), alle 6 Monate ein neues Minor-Release (4.1, 4.2, 4.3, 4.4) und alle 6 Wochen ein Bugfix-Release (4.3.1, 4.3.2, 4.3.3, ...). Dazu werden für jede Major-Version monate vorher regelmäßig Testversionen veröffentlicht. (siehe auch hier die Roadmap)

Es ist auch möglich z.b. die Nightly-Builds in den Joomla!-Updater einzufügen (unter Optionen) und automatierst immer auf dem aktuellen Entwicklungsstand zu sein (natürlich alles auf einer Kopie der Live-Site). Dazu lässt man dann einen regelmäßig einen 404-Crawler über die Testseite laufen um sofort festzustellen, falls irgendwas kaputt geht.

Ich würde behaupten, wenn man das einmal für eine Webseite eingerichtet hat, ist es eine Kleinigkeit das ganze für alle anderen Kundenseite zu replizieren.

Mir ist durchaus bewusst, dass Joomla! bei den Releases ein Qualitätsproblem hat und die schlechte Nachricht ist: diese Probleme sind in den letzten 10 Jahren enorm gewachsen und lassen sich nicht über Nacht lösen. Wenn man aber sieht, wie die Struktur beim Joomla! 4 Release aussahe (es gab keine) und was sich seit dem verbessert hat (Release-Daten vorher bekannt, standardisierte Prozesse wurden implementiert etc.) ist das Problem bekannt und es tut sich was.

Eine Aussage ärgert mich tatsächlich immer wieder wenn ich sie höre: Joomla! ändert andauernd seine Oberfläche und Wordpress ist dazu auch noch viel besser strukturiert mit seinem Menü und so. Ich mein, Joomla! 3 gibts nun mittlerweile seit 11 Jahren und die Oberfläche hat sich da (außer dass die Buttons bisschen modernisiert wurden) nicht geändert. Jetzt mit Joomla! 4 wurde tatsächlich das erste große Design-Update seit 11 Jahren durchgeführt und 11 Jahre sind eine Ewigkeit im Internet. Ich würde behaupten, all die Gutenberg-geschädigten Wordpress-Nutzer träumen davon.

Um auch mal ein bisschen die Relationen zu vergleichen: das Budget einer Wordpress-Worldconference ist fünf mal so hoch wie das Jahres-Gesamtbudget von Joomla selbst. Und wir sprechen hier von nur EINEM Wordpress-Event. Da kann man sich vorstellen, wie viele Millionen mehr Wordpress pro Jahr über Sponsoring, etc. zur Verfügung hat.

Es fühlt sich bisschen an wie ein Mantra was ich immer wiederhole: solange viele nicht die Verantwortung für ihr Business übernehmen und völlig blind durch die Joomla-Welt stolpern wird sich die Release-Qualität nur sehr langsam verbessern. Weil nach dem Release dann aufzuploppen und zu meckern ist halt einfach zu spät. Vorher brauchts die Tester, denn nur vorher kann ein Release qualitätsgesichert werden.

Zusätzlich würde es auch ungemein helfen, wenn Dienstleister Test-Cases als Cypress-Tests einreichen würden, die dann automatisch für jede Code-Änderung ausgeführt werden. (zum lesen und selbst umsetzen).

Ein guter Schritt ist schonmal zu erkennen, dass etwas nicht gut läuft bei Joomla!, aber solange man sich dann nicht dagegen stemmt und mithilft das Problem zu lösen wird sich nichts ändern.

</rant>

Im Prinzip ist es mit Joomla! 4 relativ einfach, wenn du als Aufgabe hast, den Benutzername komplett nicht mehr zu verwenden sondern rein auf die Email zu gehen:

- Override von Language Strings (Username => Email)

- Override von Registrierung (Username rausnehmen)

- kleines Plugin was u.a. folgendes macht:

    public function onContentBeforeValidateData(EventInterface $event): void
    {
        $form = $event->getArgument(0);
        $data = $event->getArgument(1);

        $contexts = [
            'com_users.registration',
            'com_users.profile',
        ];

        $formName = $form->getName();

        if (!$this->app->isClient('site') || !in_array($formName, $contexts))
        {
            return;
        }
        $data['username'] = ArrayHelper::getValue($data, 'email1');

        $event->setArgument(0, $form);
        $event->setArgument(1, $data);
    }

Das wars schon.

Interessant dürfte sein, dass Anfang Mai vom Board beschlossen wurde, einen kostenpflichtiger "Extended Security Support" für Joomla! 3 anzubieten.

Beschreibung, Motion.... wer (noch) nicht migrieren will muss halt zahlen für Sicherheit.

Einfacher ist es auch, wenn du dich an die Datei-/Klassenstruktur von Joomla hälst (was jetzt nicht unbedingt dein Problem löst):

- CamelCase statt Snake_Case

- Subscriber-Interface für das Plugin

Siehe auch: Code Standard

und persönliche Meinung: ich bin ja ein Fan davon, dass der Code auch bisschen atmen darf, sprich vor/nach if-statements eine Leerzeile, vor return statements eine Leerzeile und auch wenn es verschiedene Blöcke gibt, die unterschiedliche Aufgaben haben diese mit Leerzeilen trennen (nach der Namespace-Definition, vor dem ersten "use" und vor dem defined etc.).

Zitat von Roxena

Aber die Grundfrage - woher der basetag kommt - ist leider noch nicht geklärt. Das würde mich schon interessieren, da ich eine Lösung jetzt nur "um das Problem herum" gebaut habe... Kannst Du mir denn mal eine URL nennen, die auf Joomla 4 läuft, wo KEIN base Tag drin ist? Das wäre zum Testen mal hilfreich.

Danke und Grüße

Home - Cassiopeia Demo

Wie gesagt, es ist in ALLEN aktuellen Joomla! 4.3 Installationen so...eventuell hast du auch eine alte Version?

Klick mich zum testen

Klick mich

Zitat von georgffm

Frage 1: Verstehe ich das richtig, Lösung erst in Joomla 5 verfügbar?

Ja, du kannst aber in Github auf "Files changed" klicken um die Änderungen zu sehen und diese z.B. in deine Joomla! 4 übernehmen (vorher Backup etc.)

Zitat von georgffm

Frage 2: Gibt es eine Möglichkeit. Beiträge sicher und dauerhaft aus der Suche auszuschließen? Ich denke, dass ein Verfahren wie "Löschen aus dem Index" nicht dauerhaft funktioniert, weil dieser ja immer mal wieder neu aufgebaut wird, wahrscheinlich auch automatisch, oder?

Du kannst nach dem Indexieren beim "indexierten Content" den Status deaktivieren, sodass die Ergebnisse dann nicht mehr angezeigt werden.

Das verhindert Joomla! von von alleine.

Joomla! 4 hat keinen Base-Tag mehr, also entweder fummelt da irgendeine Extension mit rein oder .... irgendwas geht schief.

Da du Cassiopeia nutze wäre eine Möglichkeit folgende:
- https://www.image-map.net/ bastel dir eine Image-Map für das Bild mit Titel Tags

- Nutze Tooltips oder Popovers um die Titel schön anzuzeigen.

Alles ohne Extension, nur ein bisschen Handarbeit. Über Google gibts auch einige Tutorials, wie man solch eine image-map responsive hinbekommt (u.a. mit prozentuellen Größen)

Du kannst ja einfach ein Custom Field für Nutzer anlegen, das eine Nummer bei der Registrierung abfragt.

Szenario 2 würde ich eher nicht nehmen, da der Aufwand auf Seiten des Admins nicht weniger wird aber bei der Integration und Pflege der Nummern ein großer Aufwand ansteht, also einfach Textfeld (Pflichtfeld?) für die Nummer anlegen.

Um Ladezeit zu reduzieren, kannst du im Mediamanager-Plugin "Filesystem - Lokal" die Option aktivieren, Thumbnails für die Vorschau zu generieren:

Abgesehen davon, dass 40€ für das Plugin wirklich geschenkt sind und man heutzutage auf keinen Fall mehr Re-Captcha nutzen sollte, würde ich sogar soweit gehen, gar kein Captcha mehr einzusetzen.

Zum einen liefern die Kontakteinstellungen von Joomla schon "Banned Subject" und "Banned Text" Optionen mit, mit denen ein einfaches "https" als Eintrag schon Wunder wirkt, zum anderen helfen Zeitsperren, Honeypots (und damit meine ich die Technologie, nicht den Service) etc. weiterhin auf den meisten Seiten Spam zu vermeiden.

Womit wir wieder bei ECC+ wären...für 40€ bietet es das auch mit an...echt geschenkt, nur schalte nicht das Rechen-Captcha ein das ist einfach nervig, wenn dich jemand kontaktieren will.

Zitat von Obi

Es wäre großartig, wenn jemand eine Idee dazu hat

Guter Fund, leider wurde da beim Erstellen des Plugins nicht dran gedacht und ohne Komprimierung wirds tatsächlich groß.

Wenn du bisschen PHP kannst, könntest du eine Kopie des bestehenden Plugins machen und diese Zeile anpassen: Link, der (fehlende) dritte Parameter würde eine Komprimierungs-Option erlauben.

Alternativ auch gerne selbst im Core vorschlagen.

Zitat von CurlY BracketS

Kann man machen, aber ...

Also es spricht wahrscheinlich nichts dagegen, mehrere hundert Stile zu nutzen, "aber..."

Alternatividee: Mach ein Override von z.B. mod_custom mit folgenden Code:

use Joomla\CMS\Factory;

$app = Factory::getApplication();

$option = $app->input->get('option');
$view = $app->input->get('view');
$id = (int) $app->input->getInt('id');

if ($option == 'com_content' && $view == 'article') :
    $article = Factory::getApplication()->bootComponent('Content')->getMVCFactory()->createModel('Article', 'Site', ['ignore_request' => true])->getItem($id);

    // Hier kannst du nun mit dem Artikelbild machen was du willst
    print_r($article->images);

endif;

Dann brauchst du genau ein Stil und ein Modul

Weder die Template-Stile noch die Bilder sollen ein Problem machen, aber für mich erschließt sich nicht ganz warum du die Template-Stile brauchst? Du hast doch Module, die du nutzen könntest.

Alternativ kannst du auch im Menüpunkt selbst eine Seitenklasse setzen mit der du per CSS dann individuelle Bilder setzen kannst oder viele Templates setzen selbst eigene Klassen, ne nachdem auf welcher Seite du bist.

Last but not least würde ich nochmals auf die Artikelbilder zurückkommen, mit einem geschickten override + CSS sollte es doch auch damit möglich sein.

Zitat von Kubik-Rubik

Hey Ben,

weißt du zufällig, was genau kaputt ist? Ich habe gerade mit der Änderung einer Zeile im Build-Skript die Update-Pakete wieder ganz normal generieren können:

Edit: Hehe, sehe gerade, dass du diese Zeile modifiziert hattest!

LG

Alles anzeigen

Ja, es sind nur die Updatepakete innerhalb der Minor kaputt, da dort immer der Media-Ordner fehlt (die Updatepakete werden über Git-Diff generiert und der Media-Ordner ist seit 4.0 nicht mehr versioniert).

Die Lösung ist wie geschrieben das Build-Script anzupassen. Hierbei (genau an der Stelle die du erwähnt hattest, die ich "deaktiviert" habe) muss man "einfach" für die zu kompilierende Version (sagen wir 4.3.2) die entsprechende 0er Version (wäre hier 4.3.0) ziehen (aus GIT), Composer + NPM drauf und dann alles wegwerfen was noch gleich in der 4.3.2 ist. Theoretisch ganz einfach...

Zitat von -OJ-

Besteht eigentlich die Möglichkeit, Touren zu exportieren und diese in einer anderen Installation zu importieren?

Aktuell nicht (außer direkt über die Datenbank), es war auf der Roadmap sowas anzubieten, aber wurde dann nicht eingebaut. Vielleicht gibt es das ja in einer zukünftigen Version, wenn sich jemand drum kümmert...