Beiträge von SniperSister

    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.

    ioster wenn du schon ein bisschen mit Joomla gearbeitet hast, wirst du ja sicherlich schon über die Module gestolpert sein - und gesehen haben, dass man Module zu Menüeinträgen zuweisen kann. Menüeinträge spielen also eine sehr wichtige Rolle bei der Seitengestaltung, weil von ihnen abhängt, welche Module auf einer Seite zu sehen und welche nicht. Daher versucht Joomla bei jedem Seitenaufruf immer herauszufinden, was der aktuelle Menüeintrag für die derzeitige Ansicht sein könnte. Hast du jetzt einen einzelnen Beitrag, den du verlinken möchtest, versucht Joomla nacheinander die folgenden Methoden, um den Menüeintrag zu identifieren:

    a) gibt es einen Menüeintrag vom Typ "Einzelner Beitrag" für genau diesen Beitrag

    b) gibt es einen Menüeintrag vom Typ "Kategorieblog" oder "Kategorieliste" für die Kategorie des Beitrags

    c) gibt es überhaupt irgendeinen Menüeintrag auf der Beiträge dargestellt werden


    In deinem Szenario gibt es jetzt weder einen Menüeintrag für den Beitrag selbst, noch für die Kategorie - im Ergebnis sucht sich Joomla den erstbesten Menüeintrag der Beitragskomponente (das kann dann z.B. die Startseite sein) und zeigt den gewählten Beitrag dort an - allerdings natürlich mit dem Modulen und sonstigen Einstellungen der Startseite, weshalb dann eine Ausgabe zustande kommt, die du vielleicht garnicht haben willst.

    Daher auch der Tipp Kollegen: leg einen Menüeintrag für die Kategorie an, in der du deine Beiträge zuordnest.

    Aber das um ein vielfaches größere und damit auch hilfreichere Asset unter den Nutzern im geografischen Zielgebiet.

    Unbestritten. Und wenn der Verein morgen beschließt das Forum zu löschen und stattdessen Häkeldecken zu verkaufen, fällt das bei einer Backend-Verlinkung aufs offizielle Projekt zurück. Bei DACH ist das Risiko überschaubar, aber bei kleineren Ländercommunities durchaus schon vorgekommen.