Beiträge von SniperSister

    Kann es sein dass du eine Weiterleitung auf eine bestimmte Subdomain (z.B. mit oder ohne www) oder Protokoll (http vs https) erzwingst? Das ist oft die Ursache, denn der vorgeschaltete Schutz muss für jede Domain und jedes Protokoll neu eingegeben werden.

    Upgradekompartibilität ist das was Joomla einfach fehlt. Immer wieder gibt es bei Versionswechseln das gleiche Problem. Templates und Erweiterungen sind nicht mehr kompartibel.

    Dazu mal noch ein bisschen Kontext: Die Joomla-Versionspolicy besagt, dass bei einem Wechsel von einer Major-Version zur nächsten (also z.B. 3.x auf 4.x) kein Code entfernt werden darf, der in 3.x noch nicht als "veraltet" (deprecated) markiert war. Der "Lebenszyklus" eines Code-Schnipsels in Joomla sieht also z.B. so aus:


    - Einführung von Code in 3.x

    - Markierung als "deprecated" in 4.x

    - Entfernen in 5.x


    Das bedeutet auch, dass eine Erweiterung, die in der jeweils aktuellen Joomla-Version keinen "deprecated" Code benutzt in der jeweils nächsten Version (zumindest in der Theorie) lauffähig sein müsste.


    In der Praxis passiert aber sehr oft folgendes:

    - eine Erweiterung wird für 3.x neu geschrieben

    - eine Erweiterung wird für 4.x "angepasst", was konkret bedeutet dass Entwickler genau die Anpassungen machen, die notwendig sind damit die Extension wieder läuft, ohne die Nutzung von "deprecated"-Code konsequent abzuarbeiten

    - dann kommt 5.x und der Entwickler stellt mit Schrecken fest, dass ja nichts mehr funktioniert weil Joomla den ganzen schönen Code rausgelöscht hat, der als Deprecated markiert war und den der Entwickler bis zum Schluss genutzt hat



    Die spannende Frage ist für mich eine andere: Wie "progressiv" will man als System sein, wieviel Code wird also als "deprecated" markiert und wird immer sinnvoll abgewogen, ob eine Änderung soviel Mehrwert bringt, dass die sich daraus ergebenden Folgen (=Arbeit für Drittdevs) das rechtfertigen. Da kann man in der Tat vorzüglich drüber streiten.

    Ich erlaube mir mal einen Hinweis auf zwei Joomla-bezogene Veranstaltungen, die Ende Mai anstehen:


    Am 27. und 28.05 finden in Essen der Joomla Agenturtag und das JoomlaCamp statt. Beide Veranstaltungen sind sog. Unkonferenzen im Barcamp-Format, haben alsom kein festes Programm sondern die Vorträge werden am Veranstaltungstag adhoc aus den Wünschen und Vorschlägen der Teilnehmenden zusammengestellt.


    Die Tickets sind mit 40€ erschwinglich und ich würde mich freuen, möglichst viele von euch da zu sehen.


    Mehr Infos gibt es unter:
    joomlacamp.de
    joomla-agenturtag.de

    In meinem Fall machen die Patches Sinn, wenn es an Manpower fehlt oder ich gerne die CO2-Emissionen tief halten will.

    Wenn die Manpower fehlt kann ich ein solches System nicht betreiben. Ich darf ja auch ein Auto ohne TÜV nicht fahren - egal ob es daran liegt, dass mir die finanziellen oder zeitlichen Ressourcen für die Abnahme fehlen.


    Das CO2 argument ist schlicht Blödsinn. Der Energieverbrauch des zusätzlichen Serverdienstes liegt vermutlich sogar deutlich höher als der Verbrauch durch das „richtige“ Update.

    Die Technik hinter der Meldung entwickelt der Hoster nicht selber, sondern da kommt der Dienst Patchman zum Einsatz. Patchman schaut sich neue releases von populären Webapps an, versucht die relevanten Security-Patches des jeweiligen Release zu extrahieren und pflegt die Infos zur Lücke sowie zum Patch in eine Datenbank ein. Hoster kaufen das Tool und installieren auf dem Server einen Dienst, der diese Datenbank ausliest, nach Software Versionen mit bekannten (!) Lücken sucht und versucht diese Lücken mit dem offiziellen Patch gezielt zu patchen.


    Was das Tool also umgekehrt nicht leisten kann:

    - neue Lücken finden

    - Bugfixes installieren

    - die Kompatibilität der Patches mit dem Restsystem gewährleisten

    - Erweiterungen patchen


    Es ist also eine nette Spielerei aber keinesfalls ein Ersatz für eine ordentliche Betreuung der Seite mit kontinuierlicher Installation der Security Updates. Man darf sich als Seitenbetreiber also nicht fälschlich in Sucherheit wägen.

    Es gibt keine REST API dafür, nur die erwähnten CLI scripts. Plan B könnte die Ausführung der CLI tasks wie SSH sein, das geht ja in Zweifelsfalle auch aus deinem PHP Script heraus.


    Grundfrage wäre für mich, ob sich der Aufwand angesichts existierender Tools lohnt.

    Ich suche nun schon seit Tagen, wie ich die Customfields nicht als kompletten Klotz, sondern diese Felder einzeln an verschiedenen Stellen im E-Mail-Template plazieren kann.

    Die Kontakt-Komponente übergibt leider nicht die einzelnen Felddaten, sondern nur die Gesamtausgabe der Fields:
    https://github.com/joomla/joom…ontactController.php#L272

    Du hast somit in der aktuellen Version keinen Zugriff. Der Usecase ist aber super nachvollziehbar, von daher kannst du sehr gerne ein Ticket im Bug Tracker erstellen, damit hier Abhilfe geschaffen wird. Eine triviale Lösung wäre, die Felder über {customfields.fieldname} aufrufbar zu machen.

    Erstmal ein Wortbeitrag zur eigentlichen Kernfrage: der JCE setzt in der Tat auf einer veralteten TinyMCE Version auf, wird aber aktiv betreut und von einem Entwickler weiterentwickelt, der damit seine Brötchen verdient. Er muss fraglos auf eine neuere tiny version umgestellt werden, allerdings nicht akut, weshalb ich hier keinen Blocker für den Produktiveinsatz sehe.


    Und jetzt mal noch ein paar Worte zu diesem Spannungsfeld:

    Grammatiko ist ein notorischer Nörgler aus der überdrehten, selbstverliebten JavaScript-Szene. Wenns nach ihm ginge, wäre Joomla längst kein PHP-System mehr und dann aber der Code undurschaubare "Chain Hell", die wöchentlich rückwärtsinkompatibel "modernisiert" wird. Und 99% der Erweiterungen würden aus dem JED verschwinden, weil sie sich erdreisten JQuery zu verwenden (wie übrigens auch das Astroid-Framework oder Shaper etc.).


    Dimitris ist begeisterter Anhänger des „nur the latest und greatest“-Lagers und schießt mit einigen Inhalten und insbesondere mit seiner Art gerne übers Ziel hinaus.

    Dennoch trifft er bei Joomla einen wunden Punkt: wir bewegen uns, gemessen an der Schnelllebigkeit des Webs, insbesondere im Bereich Frontend in Schildkrötentempo. Das merkt man insbesondere auch beim Reizthema „JQuery“: hier gibt es viele Extensionentwickler, die „JavaScript“ und „JQuery“ gerade zu als Synonym verstehen und aus Trägheit und „Das haben wir schon immer so gemacht“-Nostalgie eine Umstellung verweigern. Das kostet dann letztlich beim Endnutzer kostbare Performance.


    Die Wahrheit liegt da also, wie so oft, irgendwo in der Mitte.

    Der erste Artikel, der als Einzelbeitrag im Menü steht, wird namentlich in der URL nicht genannt, die Folgeartikel, die über Schaltflächen aufgerufen werden können, hingegen schon.

    Ja, natürlich. Der erste Artikel hat einen Menüeintrag, der direkt darauf verweist - dadurch braucht es in der URL kein zusätzliches Merkmal (sprich, den Artikel-Alias) zur Identifikation. Anders bei den anderen Artikeln: hier muss der Name mit rein, denn jeder der Artikel braucht ja eine eindeutige URL.

    > Nur wie verstecke ich den Menüpunkt jetzt?

    Schau mal im Reiter "Linktyp" des Menüeintrags, dort gibt es den Schalter "Im Menü anzeigen", den kannst du auf "Nein" setzen. Dann ist der Eintrag vorhanden und aufrufbar, wird aber nicht im Menü sichtbar.

    Reicht es aus, einen Menüeintrag als Kategorieblog zu definieren und diesen im Menü zu verstecken? Oder muss ich doch für jeden einzelnen Artikel eine Doppelstruktur im Menü aufbauen?

    Wenn die Beiträge, um die es hier geht, alle in der selben Kategorie sind (so verstehe ich dich) dann reicht es, einen Menüeintrag als Kategorieblog für diese fragliche Kategorie zu definieren.