GZIP/Brotli Vorkomprimierung
Mit mark2web 1.2 können die generierten und vorhandenen Dateien vorkomprimiert werden. Zur Auswahl stehen GZIP- und Brotli-Komprimierung. Die Dateien müssen somit nicht erst bei Abfrage durch den Webserver komprimiert werden, sondern stehen sofort zur Auslieferung bereit.
Die entsprechenden Rewrite-Regeln für den Apache-Webserver erstellt mark2web gleich mit.
Um dieses Feature zu nutzen ergänzen Sie die globale Konfiguration wie folgt:
...
Compress:
Brotli: True
GZIP: True
Extensions:
.html: text/html
.css: text/css
.js: text/javascript
Weitere Dateiendungen können nach Belieben ergänzt werden.
Dateibasierte Collections
Neben den Collections via Webrequest, sind nun auch Collections aus einer Sammlung von Markdown-Dateien möglich.
Eine mögliche Konfiguration innerhalb des content
-Verzeichnisses sieht z.B. so aus:
Template: base_doc.html
This:
Collections:
- Name: doccoll
Directory:
Path: "."
MatchFilename: "^_\\d+(?P<lowdash>_*)(?P<title>.+)\\.md"
ReverseOrder: False
Eine Liste der Dateien innerhalb des gleichen Verzeichnis, wie die config.yml
mit obigem Inhalt wäre z.B. folgende:
_01000_globale Einstellungen.md
_01100__Sektion Webserver.md
_01110___Type.md
_01200__Sektion Assets.md
_01210___FromPath.md
_01220___ToPath.md
_01230___Action.md
_01240___FixTemplates.md
_01300__Sektion OtherFiles.md
_01310___Action.md
_02000_Konfiguration im Content-Verzeichnis.md
_02100__Sektion This.md
_02110___GoTo.md
_02120___Navname.md
_02130___Data.md
_02200__Sektion Meta.md
_02300__Sektion Data.md
Dieses Beispiel entstammt dem website
-Verzeichnis für die Dokumentation der Konfiguration.
Das dazugehörige Template base_doc.html
müsste dem entsprechend etwa so aussehen:
...
{% for e in NavElement.ColMap.doccoll %}
{% with e.FilenameMatch.lowdash|count + 1 as h %}
<h{{ h }}>
{{ e.FilenameMatch.title }}
{% if e.Data.Version %}
<span class="versionBadge">{{ e.Data.Version }}</span>
{% endif %}
</h{{ h }}>
{% endwith %}
{{ e.Body }}
{% endfor %}
...
Im Beispiel wird die Anzahl der Unterstriche (plus 1) als Ordnung der Überschrift gewertet. Die Überschrift selbst ist Teil des Dateinamens. Der Filter count
ist kein Standardfilter. Er wurde über die Möglichkeit eigene Filter in Javascript zu implementieren für diese Website implementiert (siehe Verzeichnis website/templates/filters
).
Die Variable {{ e.Data.Version }}
wird durch den Header der Markdown-Datei befüllt.
z.B.:
---
Data:
Version: "ab 1.2"
---
# Body der Markdown-Datei
Text
Rekursive Webrequest-Collections
Die in der Version 1.1 eingeführten Webrequest-Collections können nun auch rekursiv verarbeitet werden. Bisher waren Collection-Konfiguration nur unter This:
in der Konfiguration möglich. Somit wurden die Webrequests auch nur am aktuellen Punkt im Navigationsbaum ausgeführt.
Den Navigationsbaum dynamisch zu erweitern war also nur mit einer Ebene möglich.
Nun können die Collection-Konfigurationen auch eine Ebene höher, also neben This:
, verwendet werden. Die Konfiguration wird somit weiter vererbt und die Webrequests werden in der entstandenen Unterebene der Navigation wieder ausgeführt.
Um keine Endlosrekursion mit immer den selben Daten auszulösen, ist bei den Abfragen ein Template notig, welches Variablen als Filter in den Webrequest einschleust. Eine Konfiguration, die einen Navigationsbaum via Webrequests ausbaut, sieht beispielsweise so aus:
Collections:
- Name: blog1st
URL: 'https://HEADLESS_CMS_SERVER/api/collections/get/navtree?{% if Data.subnav._id %}&filter[link._id]={{ Data.subnav._id }}{% else %}&filter[link][$exists]=0{% endif %}'
NavTemplate:
EntriesAttribute: entries
GoTo: '{{ title }}'
Navname: '{{ title }}'
Body: '{{ body|safe }}'
Template: base_navtest.html
DataKey: subnav
Hidden: False
Die hier verwendeten Filter in der URL sind Parameter, wie sie z.B. für eine Anfrage an das Content-Management-System “Cockpit CMS” verwendet werden.
Multithreading
Rechenintensive Prozesse, wie das Berechnen von skalierten Bildern oder das Packen von Daten mit GZIP oder Brotli werden ab mark2web 1.2 auf allen CPU-Kernen ausgeführt.
« zurück