Beiträge von SniperSister

  • Smart Search Index per CLI

    Erklärkontext:

    Es gibt zwei verschiedene Versionen des Programms „PHP“.


    Die eine Version ist spezifisch für die Nutzung auf der Kommandozeile, also dem Command Line Interface (kurz CLI) gedacht.

    Die andere Version soll direkt vom Webserver verwendet werden, wenn der Server die Aufgabe bekommt, einen Webseitenbesucher eine PHP Seite auszuliefern. Die Kommunikation mit dem Webserver geht dabei über das CGI Protokoll und zeichnet sich dadurch aus, dass nicht nur die Ausgabe des Scripts übergeben werden, sondern auch HTTP-Header.


    Genau diese Header sieht man in Deiner Beispielausgabe. Daher lag die Vermutung nahe, dass in deinem Fall der Befehl „PHP“ auf der Kommandozeile mit der falschen Variante (nämlich CGI statt CLI) des Programms verknüpft ist.

  • Akeeba AdminTool Anmeldeverfahren

    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.

  • Zwickmühle: Joomla4-Upgrade dringend geboten, aber nicht möglich, weil wichtige Extensions noch nicht mitspielen. Ideen?

    Zitat von WM-Loose

    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.

  • JoomlaCamp & Joomla-Agenturtag am 27./28.05 in Essen

    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

  • Sicherheitslücke 4.0.5

    Zitat von flipper

    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.

  • Sicherheitslücke 4.0.5

    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.

  • Joomla API

    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.

  • Customfields in E-Mail-Template

    Zitat von sloeser

    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.

  • JCE Editor - veraltete Architektur und Technologie - wie gehts weiter?

    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:

    Zitat von Re:Later

    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.