Golb Slexa ::

Meine Concrete5 Webseite wurde langsamer und langsamer. Sie wird auf einem Shared Hosting betrieben (was ohnehin nicht die schnellste Option sein kann) - hier kann ich zudem keinen Varnish oder auch nur irgendeinen anderen Caching Dienst installieren und davorschalten, sondern muss mich mit .htaccess und Standard-PHP-Mitteln behelfen können.

Das Initialisieren eines Requests in Concrete5 (Bootstrapping) braucht scheinbar sehr lange. Selbst statische Inhalts-Seiten, die ein aktives Fullpage Cache haben, benötigen für die Verarbeitung am Server mehr als 200 ms. Hinzu kommen für einen kompletten Request dann noch Netzwerkzeiten für Namensauflösung (DNS), Anfrage zum Server senden … und das Ergebnis zum Browser zurücksenden, was der Browser dann rendert. Meine schnellsten Seiten aus dem CMS waren bei 300 ms. Andere brauchten 3 Sekunden und mehr. Concrete5 ist einfach langsam.

Ich habe einen Cache geschrieben, der Concrete5 vorgeschaltet ist und im Filesystem seine Caching-Daten ablegt. Kurz er hat minimalste Anforderungen und arbeitet mit einem Shared Hoster. Dieses “Vorschalten” umgeht die lange Initialisierungszeit von Concrete5 - dies macht die Seite schnell.

Vor einigen Tagen habe ich eine erste Version meines preDispatchers eingespielt. Erwartungsgemäss muss man ein paar Kinderkrankheiten ausmerzen. Aber erste Ergebnisse in der Webseiten-Statistik (Matomo) zeigen, dass es eine gute Entscheidung war: die mittleren Seiten-Generierungs-Zeiten sanken von über 2s auf unter 0.4s

Der PreDispatcher besitzt eine Debugging-Ausgabe, die die Arbeitsweise veranschaulicht und den Unterschied deutlich macht. Das ist ein ungecachter Aufruf einer Seite mit Fullpage Cache in C5 - also inkl. Bootstrapping + Auslieferung einer in C5 gecachten Seite:

Der PreDispatcher speichert den Request, der nicht im Cache ist (oder dessen Caching Zeit abgelaufen ist). Der nächste Request auf dieselbe Seite wird dann schnell. Richtig schnell:

Wie lange eine Seite aus einem Cache kommt? Man definiert einen Default für alle Seiten. Mit einer Liste von Regex für aufzurufende URLS kann man die Standard-Vorgabe übersteuern und einen neuen Wert zuweisen.

Zudem gibt es eine Erkennung, was nicht gecacht werden darf - oder wo ein Cache verworfen werden muss. Ich kann mich im C5 Backend einloggen - und der Cache jeder mit Login aufgerufenen Seite wird verworfen.

Ich bin wohl auf dem richtigen Weg. Aber ein wenig Feintuning braucht es noch. Bei Interesse, schaut auf Github … oder fragt mich an :-)

Der PreDispatcher ist Freie Software - unter GNU GPL 3!

weiterführende Links:

1. Github: pre-dispatcher for more speed
2. Concrete5 webseite

Dieser Blogeintrag ist eine Snippet-Ablage.

Die PHP-Funktion mysql_real_escape() maskierte Sonderzeichen in Werten, bevor man sie für Datenbankabfragen verwenden sollte. Die Funktion arbeitet nur dann, wenn Mysql vorab initialisiert wurde.

/**
* mysql_real_escape for an array of options
* @param array $aParams
* @return array
 */
function escapeAllParams($aParams) {
    foreach (array_keys($aParams) as $sKey) {
        $aParams[$sKey] = escapeParam($aParams[$sKey]);
    }
    return $aParams;
}

/**
* replacement for mysql_real_escape.
* @param string $s
* @return string
*/
function escapeParam($s) {
    $s = str_replace(array('\\', "\0", "\n", "\r", "'", '"', "\x1a"), array('\\\\', '\\0', '\\n', '\\r', "\\'", '\\"', '\\Z'), $s);
    return $s;
}

Mein bisheriger Blog war über Jahre immer ein Custom style … aber eben nicht public.
Nun habe ich meinen erstes Theme für Flatpress veröffentlicht. Vom Look her ist es der klassische Blog Style mit einem hellen Theme als Basis. Wegen der Transparenzen taufte ich es “A Touch Of Glass”.

Warum überhaupt … es gibt ja bereits mehrere Themes?!

1. Mich stört in Flatpress, dass man den Filter auf einen Monat oder eine Kategorie nicht visualisiert hat. Ich hatte es bis anhin mit einem Hack gelöst. In diesem Theme ist es mit Javascript implementiert: In der Widget-Box ist es nun hervorgehoben als auch im Headerbereich sichtbar.
   
2. Mehrere Themes für ein 2 oder 3-Spalten-Layout? Das ist unnötig. Wer mag, darf es gern adaptieren. Im Flatpress-Backend platziert man Widgets in einzelne Bereiche. Von mind. 1 Widget benutzte Spalten werden angezeigt; ungenutzte nicht. Klingt banal. Und ist es per CSS an sich auch.
3. Es fehlen Icons. Naja, an allen Ecken und Enden. Ich habe im Theme per CDN Fontawesome eingebunden und an so einigen Stellen per CSS im Frontend als auch Backend integriert.
4. Ich wollte ein cooleres Backend. Es soll schliesslich auch 2019 Spass machen, einen neuen Blog-Eintrag zu machen.
   

Das Theme gibt etliche Rahmenbedingungen vor. Die Syles - 4 liefere ich einmal mit - sind nur noch extrem einfache CSS Dateien, die einige Default-Farben übersteuern.

Weitere Farb-Schemata zu erstellen wird zum Kinderspiel. Wer mag, kann sich eine style.css eines Farbschemas ansehen: es werden CSS Variablen definiert und diese in denjenigen CSS Selektoren angewendet, die übersteuert werden sollen.

Hey, wenn ihr es für gut befindet, empfehlt/ teilt es weiter :-)

UPDATE

• 19.06.2019: Es sind ein Freitextfilter mit Highligntning bei Kategorieen und auf- und zuklappbare Jahre im Archiv hinzugekommen. Ich hab es nun mal v1.0 genannt :-)
• 06.08.2019: Mein Twitter-Posting wurde auf dem Flatpress Channel eingefügt (s. Link [6])

weiterführende Links:

1. Github: Projekt Seite des Themes
2. Github: Theme A Touch Of Glass als ZIP
3. Flatpress.org Blogging Engine in PHP ohne Datenbank
4. Fontawesome Iconset
5. Twitter: Axels Tweet
6. Twitter: Flatpress Tweet … und Channel

Ich bin leider erst soeben darüber gestolpert: diesen März gab es auf Sourceforge einen absoluten Peak von 565 Downloads im Monat.

Warum habe ich das nicht gesehen?

In die tageweise Statistik reingezoomt … davon waren 500 an einem Tag (19.3.) - ich glaube, da hat sich wer einen Scherz erlaubt und wget bemüht - oder gar öfter F5 im Browser gedrückt.

So schnell kann eine kleine Euphorieblase wieder platzen.

weiterführende Links:

1. Axels Webseite - Docs Pimped Apache Status Get started - hier ist das Youtube Video
2. Github: Pimped Apache Status
3. Sourceforge: Pimped Apache Status

Oh, was für eine kleine nette Überraschung: Das da bin ja ich :-)

Mit dieser Klasse wird bei einem Passwort-Feld ein Div eingeblendet. Darin wird die Erfüllung der vorgegebenen Bedingungen (z.B. Anzahl Zeichen, Gross-/ Kleinschreibung, Anzahl Sonderzeichen) dargestellt - on the fly während der Passworteingabe.

Diese Klasse ist Freie Software und Open Source.

weiterführende Links:

1. Axels Webseite: ahPwcheck
2. Docs: Password checker (en)
3. jsclasses.org: AH JavaScript Password Strength Check: Calculate and display the strength of a password (en)

Ich hatte wirklich seltsame Antwortzeiten mit der Curl-Bibliothek in PHP in meiner eigenen Monitoring-Anwendung.
Bei Verwendung von curl_getinfo($curl) ist der Wert von “total_time” ein Wert in Sekunden. Eigentlich. Bei einer Reaktionszeit von 16ms sollte es 0,016 sein, ich erhielt aber 16000.

Das Problem ist, dass sich die Werte der Curl-Funktion bei Verwendung von PHP mit mod_php korrekt verhalten - nur im FCGI Modus gibt es Zahlenwerte, die Faktor 1 Mio. zu gross sind.

Bei einer Antwort-Zeit von 16 ms sollte der Wert im Feld total_time 0.016 sein - unter FCGI kommt aber 16000 zurück.

Nach einer kurzen Suche, fand ich einen bestehenden Bugreport, wo ich meine Daten ergänzte. Mal schauen, ob da wohl was geht …

weiterführende Links:

1. bugs.php.net- 76438: wrong curl_getinfo time values
2. php.net: Funktion curl_getinfo()
3. Github: IML AppMonitor

Ich weiss ja auch nicht, was mich vor ein paar Jahre geritten hat, Oberfläche und CSS von Hand und selbst erstellen zu wollen. Weil es schlank ist. Aber eben nicht produktiv.

Nun habe ich die GUI auf AdminLTE portiert - und mir für die benötigten Elemente in AdminLTE die notwendigen Abstraktionen geschrieben. Nun ist es deutlich aufgeräumter!

GUI-Kram kann schon ziemlich lästig sein. Ich bin froh, bin ich damit durch. Nun kann ich mich wieder auf das Implementieren echter Features konzentrieren.

weiterführende Links:

1. Github: IML Appmonitor
2. AdminLTE Demo Seite
3. Docs: os-docs.iml.unibe.ch/appmonitor/

Nachdem bei Flatpress über Jahre nicht mehr viel weiterging, habe ich Anpassungen (die in dessen Forum genannt wurden) für mich gemacht und gar angefangen ein anderes Blog Tool zu suchen. In meinem Blog sind Inhalte seit 2008. Die Inhalte zu übernehmen, ist so eine gewisse Hürde, die mich abschreckt.

Aber all das entfällt ja nun :-) Am 22. Februar gab es eine neue Version, die gar PHP 7.3 komptibel ist.

Ein Dankeschön an Arvid und seine Helfer!

Anbei die Beschreibung des Updates von 1.0x auf 1.1 mit Übernahme des Inhalts. Bei der Variante “Überschreiben der bestehenden Dateien” bleibt tendeziell Unnützes über.
Anm.: dies ist inoffiziell - es ist die Beschreibung des Vorgehens auf meiner Installation.

1. Backup: das Verzeichnis des Blogs “/blog/” wurde umbenannt nach “/blog_OLD/”
2. Unzip der version 1.1 nach “/blog/”
3. Beiträge und Bilder: Kopieren des Verzeichnisses /blog/fp-content/
4. Theme: Kopieren des Verzeichnisses /blog/fp-interface/themes/[theme]
5. Plugins: gehe in das Backend des Blogs blog/admin.php?p=plugin … wenn ein fehlendes Plugin gemeldet wird: Kopieren des Verzeichhisses /blog/folder fp-plugins/[pluginname] (Kontrolle mit Reload im Browser)
6. Die Toolbar des Editors habe ich mir erweitert - im BBCode plugin wurden einige weitere Buttons hinzugefügt /blog/fp-plugins/bbcode/tpls/toolbar.tpl
7. Pretty-Urls waren aktiv? dann die /blog/.htaccess übertragen
8. Flatpress-Index neu erstellen: Dazu anmelden, Wartung anklicken und den Link anklicken [Den Flatpress Index neu erstellen]
9. Einmal den Browsercache löschen (Ctrl+Shift+Delete), damit Javascript- und CSS Elemente von der neuen Version geladen werden

UPDATE:
3.3.2019 - Dank an Matthias (Laborix): Neuerstellen des Index wurde hinzugefügt.

weiterführende Links:

1. www.flatpress.org

Ich benötige zum Betreiben von Applikationen keine Dateizugriffe via Mysql. Wenn es weder Dateien vom Server noch vom Client braucht, fühle ich mich wohler, wenn die Funktion komplett deaktiviert ist, weil das ein offenes Scheunentor sein kann.

Um das Laden von Dateien innerhalb SQL zu vermeiden, gibt es in Mysql die Möglichkeit, in der Konfiguration den Dateizugriff zu unterbinden

[mysqld]
local-infile = 0|1 oder ON|OFF
secure_file_priv = [Wert]

Kurz in der Dokumentation die Werte nachlesen, ins Puppet kippen und auf alle Server verteilen.

Als Test, ob ich erfolgreich bin, dient der Aufruf … dieser muss NULL ausgeben und keinen Dateiinhalt.

#  mysql -e "SELECT  load_file('/etc/passwd');"
+--------------------------+
| load_file('/etc/passwd') |
+--------------------------+
| NULL                     |
+--------------------------+

Das war die Idee. Eigentlich klingt es einfach.
Leider verhalten sich aber die Einstellungen von Mysql und MariaDB unterschiedlich.

Der Wert für local-infile muss bei beiden 0 oder OFF sein. local-infile ist aber eine dynamische Variable - das ist aber lediglich der Startwert, der mit einem SQL Befehl in der laufenden Instanz neu gesetzt werden kann.

Heisst: es braucht zwingend den Wert für secure_file_priv, der sich wiederum NICHT zur Laufzeit verändern lässt.

(1)
Variante für Mysql:

[mysqld]
(...)
local-infile = 0
secure_file_priv = NULL
(...)

Danach einmal den Service neu starten systemctl restart mysql … dann habe ich das Verhalten wie in meinem Testaufruf.
Dieses Setup funktioniert nicht auf MariaDB - es wird mit einem Fehler in der Variable secure_file_priv beendet.

Die Dokumentation sagt: wenn secure_file_priv fehlt, würde der Dateizugriff verhindert werden…

Description: LOAD DATA, SELECT … INTO and LOAD FILE() will only work with files in the specified path. If not set, the default, the statements will work with any files that can be accessed.

Aber das ist nicht korrekt! Wenn ich secure_file_priv nicht setze, und es aus der laufenden Datenbank abfrage, ist der Wert leer

# mysql -e "SHOW VARIABLES LIKE 'secure_file_priv';"
+------------------+------------+
| Variable_name    | Value      |
+------------------+------------+
| secure_file_priv |            |
+------------------+------------+

… und ein SELECT load_file(’/etc/passwd’); zeigt mir den Dateiinhalt an!
Wer Percona oder einen anderen Mysql-Abkömmling verwendet, sollte das Verhalten austesten.

MariaDB erwartet einen existierenden Verzeichnisnamen. Ich habe mich entschieden, /dev/null zu nehmen, weil es sowohl existiert als auch ein User hier keine Datei ablegen kann:

(2)
Variante für MariaDB:

[mysqld]
(...)
local-infile = 0
secure_file_priv = /dev/null
(...)

(3)
Bliebe noch die Software-Verteilung… wenn in Puppet die Mysql-Klasse aufgerufen wird, muss diese von irgendwoher wissen, ob das Produkt am Zielsystem MariaDB oder Mysql ist. Die Lazy Variante wäre, auf das OS zu reagieren, weil Defaults in den Repos beispielsweise von Debian oder CentOS sich unterscheiden. Besser und sicherer ist natürlich ein echtes Flag.

Update zu (3):

Meine Variante für ein vom Mysql Daemon nicht verwendbares, aber stets existierendes Verzeichnis für beide Mysql-Varianten ist … “/root”

[mysqld]
(...)
local-infile = 0
secure_file_priv = /root
(...)

weiterführende Links:

1. Golem: Lange bekannte MySQL-Lücke führt zu Angriffen (27.1.2019)
2. secure_file_priv - mysql - Docs (en)
3. secure_file_priv - mariaDB - Docs (en)

Am Wochenende habe ich v0.33 meines Html 5 Audioplayers freigegeben.
Funktional soll es das erst einmal sein, was ich mir für Version 1 vorstelle. Nun erledige ich ein wenig Code Cleanup.

Und vielleicht noch eine kleine Skin Datei. Eine in einer Art flat Design habe ich da schon mal in Vorbereitung:

… und auch ein Dark Theme

Beide sind noch nicht im Repo verfügbar … seht es als Preview :-)

Updates:

1. 22.11.2018 - ein dunkles Theme hinzugefügt

weiterführende Links:

1. Axels Webseite
2. Dokumentation (en)
3. Git-Repository (en)