This commit is contained in:
2
Makefile
2
Makefile
@@ -13,7 +13,7 @@ help: ## show this help
|
||||
|
||||
|
||||
docker-up: ## bring docker compose stack up in background
|
||||
$(DOCKER_COMPOSE) --profile tibi up -d
|
||||
$(DOCKER_COMPOSE) --profile tibi --profile docpress up -d
|
||||
|
||||
docker-up-tibi-dev: ## bring docker compose stack up in background with tibi-dev
|
||||
$(DOCKER_COMPOSE) --profile tibi-dev up -d
|
||||
|
||||
@@ -10,7 +10,7 @@ xs:
|
||||
height: 90
|
||||
width: 90
|
||||
resampling: lanczos
|
||||
quality: 75
|
||||
quality: 90
|
||||
skipLargerDimension: true
|
||||
skipLargerFilesize: true
|
||||
s:
|
||||
@@ -18,7 +18,7 @@ s:
|
||||
height: 300
|
||||
width: 300
|
||||
resampling: lanczos
|
||||
quality: 75
|
||||
quality: 90
|
||||
skipLargerDimension: true
|
||||
skipLargerFilesize: true
|
||||
m:
|
||||
@@ -26,7 +26,7 @@ m:
|
||||
height: 600
|
||||
width: 600
|
||||
resampling: lanczos
|
||||
quality: 75
|
||||
quality: 90
|
||||
skipLargerDimension: true
|
||||
skipLargerFilesize: true
|
||||
l:
|
||||
@@ -34,7 +34,7 @@ l:
|
||||
height: 1200
|
||||
width: 1200
|
||||
resampling: lanczos
|
||||
quality: 75
|
||||
quality: 90
|
||||
skipLargerDimension: true
|
||||
skipLargerFilesize: true
|
||||
xl:
|
||||
@@ -42,7 +42,7 @@ xl:
|
||||
height: 2000
|
||||
width: 2000
|
||||
resampling: lanczos
|
||||
quality: 75
|
||||
quality: 90
|
||||
skipLargerDimension: true
|
||||
skipLargerFilesize: true
|
||||
xxl:
|
||||
@@ -50,6 +50,67 @@ xxl:
|
||||
height: 4000
|
||||
width: 4000
|
||||
resampling: lanczos
|
||||
quality: 75
|
||||
quality: 90
|
||||
skipLargerDimension: true
|
||||
skipLargerFilesize: true
|
||||
|
||||
xs-webp:
|
||||
- fit: true
|
||||
height: 90
|
||||
width: 90
|
||||
resampling: lanczos
|
||||
quality: 90
|
||||
skipLargerDimension: false
|
||||
skipLargerFilesize: true
|
||||
lossless: false
|
||||
outputType: webp
|
||||
s-webp:
|
||||
- fit: true
|
||||
height: 300
|
||||
width: 300
|
||||
resampling: lanczos
|
||||
quality: 90
|
||||
skipLargerDimension: false
|
||||
skipLargerFilesize: true
|
||||
lossless: false
|
||||
outputType: webp
|
||||
m-webp:
|
||||
- fit: true
|
||||
height: 600
|
||||
width: 600
|
||||
resampling: lanczos
|
||||
quality: 90
|
||||
skipLargerDimension: false
|
||||
skipLargerFilesize: true
|
||||
lossless: false
|
||||
outputType: webp
|
||||
l-webp:
|
||||
- fit: true
|
||||
height: 1200
|
||||
width: 1200
|
||||
resampling: lanczos
|
||||
quality: 90
|
||||
skipLargerDimension: false
|
||||
skipLargerFilesize: true
|
||||
lossless: false
|
||||
outputType: webp
|
||||
xl-webp:
|
||||
- fit: true
|
||||
height: 2000
|
||||
width: 2000
|
||||
resampling: lanczos
|
||||
quality: 90
|
||||
skipLargerDimension: false
|
||||
skipLargerFilesize: true
|
||||
lossless: false
|
||||
outputType: webp
|
||||
xxl-webp:
|
||||
- fit: true
|
||||
height: 4000
|
||||
width: 4000
|
||||
resampling: lanczos
|
||||
quality: 90
|
||||
skipLargerDimension: false
|
||||
skipLargerFilesize: true
|
||||
lossless: false
|
||||
outputType: webp
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
quickEdit: # Erlaubt das Bearbeiten von Einträgen in der Listenansicht, ohne dass eine neue Seite geöffnet wird
|
||||
enabled: true
|
||||
fields: # felder, die in dieser Ansicht bearbeitet werden können
|
||||
- title
|
||||
- alt
|
||||
- file
|
||||
enabled: true
|
||||
fields: # felder, die in dieser Ansicht bearbeitet werden können
|
||||
- title
|
||||
- alt
|
||||
- file
|
||||
|
||||
@@ -216,7 +216,23 @@ Für type Object[] gibt es im Meta objekt das direction attribut, dies kann entw
|
||||
## metaElements
|
||||
|
||||
Möchte man bestimmte Elemente über das Zahnrad greifbar machen (bei type: Object[]), so kann man dies über dieses Attribut tun. Es ist entweder über eine Liste, oder über tablist möglich.
|
||||
!!!include(../api/collections/fields/info.yml)!!!
|
||||
Das kann Beispielsweise so aussehen:
|
||||
```yaml
|
||||
metaElements:
|
||||
tablist:
|
||||
tabs:
|
||||
- name: allgemein
|
||||
label: Allgemein
|
||||
subFields:
|
||||
- xtest
|
||||
- paymentValue
|
||||
|
||||
- name: allgemein2
|
||||
label: Allgemein2
|
||||
subFields:
|
||||
- source: ytest2
|
||||
```
|
||||
|
||||
|
||||
## folding
|
||||
|
||||
|
||||
@@ -103,15 +103,25 @@ Dieses Widget erfordert die weitere Angabe von subFields, die außerhalb des met
|
||||
Für Datentyp object[], dient als übersichtliche object[] alternative, speziell für pagebuilder entwickelt.
|
||||
!!!include(../api/collections/fields/rows.yml)!!!
|
||||
|
||||
## jsonField
|
||||
|
||||
Wird für Daten genutzt, wo man die Struktur nicht absehen kann.
|
||||
!!!include(../api/collections/fields/form.yml)!!!
|
||||
## previewBasedObjectArray
|
||||
Das ist eine Darstellung für object[], in der Verschachtelung durch überlagerung unterbunden wird. Dies ist Insbesondere für die Content Collection vorgesehen, und ist stark abhängig von der Zeilenvorschau via reingerenderten Svelte Komponenten.
|
||||
|
||||
## tabs
|
||||
|
||||
Dieses Widget hat im Prinzip die gleiche Funktion wie dasjenige in der Collection Meta-Konfiguration, ist jedoch etwas anders strukturiert. Ähnlich wie beim object Widget werden subFields verwendet, wobei das label von jedem subField der jeweilige Tab-Name ist. Würde man type auf number setzen, so hätte man in diesem Fall einfach einen Tab mit dem Namen "xyz" und ein number Feld im Tab mit dem gleichen Namen. Sinnvoller ist es natürlich, type auf object zu setzen, um mehrere Felder in einen Tab zu packen.
|
||||
|
||||
# useDefaultArray
|
||||
|
||||
Wenn ein belibiger Datentyp in einem Array gefordert ist, so kann man jedes beliebige Widget dafür nutzten, indem man useDefaultArray: true benutzt. Damit kann jedes widget in das defaultArray widget gepackt werden. Wird Object[] in kombination mit useDefaultArray verwendet, so wird die einfache Objektdarstellung in diese darstellung implementiert.
|
||||
|
||||
|
||||
|
||||
!!!include(../api/collections/fields/emailCC.yml)!!!
|
||||
|
||||
## jsonField
|
||||
|
||||
Wird für Daten genutzt, wo man die Struktur nicht absehen kann.
|
||||
!!!include(../api/collections/fields/form.yml)!!!
|
||||
```yml
|
||||
type: object
|
||||
name: formular
|
||||
@@ -122,10 +132,7 @@ meta:
|
||||
widget: jsonField
|
||||
```
|
||||
|
||||
# useDefaultArray
|
||||
|
||||
Wenn ein belibiger Datentyp in einem Array gefordert ist, so kann man jedes beliebige Widget dafür nutzten, indem man useDefaultArray: true benutzt. Damit kann jedes widget in das defaultArray widget gepackt werden. Wird Object[] in kombination mit useDefaultArray verwendet, so wird die einfache Objektdarstellung in diese darstellung implementiert.
|
||||
|
||||
|
||||
|
||||
!!!include(../api/collections/fields/emailCC.yml)!!!
|
||||
|
||||
|
||||
@@ -29,3 +29,4 @@ Folgende Attribute können Filter-Eintrage haben, wobei `fit` und `fill` exklusi
|
||||
| `quality` | number | Ausgabequalität 0..100 |
|
||||
| `skipLargerDimension` | boolean | Bild wird nicht manipuliert, wenn es kleiner ist als das angegebene Rechteck |
|
||||
| `skipLargerFilesize` | boolean | Bild wird nicht manipuliert, wenn das Zielbild eine größere Dateigröße hat als das Original |
|
||||
| `outputType` | string | zur automatischen Umwandlung in bspw. WebP |
|
||||
@@ -1,10 +1,10 @@
|
||||
# meta Objekt
|
||||
|
||||
Wie bereits an anderer Stelle beschrieben, dient das `meta` Objekt zur Definition von Merkmalen, die im _tibi-admin_ finden. Zum Anlegen der Struktur in der Datenbank und Definition der API haben diese Angaben keine Relevanz.
|
||||
Wie bereits an anderer Stelle beschrieben, dient das `meta` Objekt zur Definition von Merkmalen, die Sie im _tibi-admin_ finden. Zum Anlegen der Struktur in der Datenbank und Definition der API haben diese Angaben keine Relevanz.
|
||||
|
||||
Folgende Angaben sind auf Collectionebene möglich:
|
||||
|
||||
Folgende Angaben sind möglich:
|
||||
|
||||
!!!include(../api/collections/democol/meta.yml)!!!
|
||||
|
||||
## views Liste
|
||||
|
||||
@@ -67,6 +67,118 @@ Der mutliupload kann bei jedem view type verwendet werden. Über $file kann man
|
||||
|
||||
!!!include(../api/collections/medialib.yml)!!!
|
||||
|
||||
## Singleton
|
||||
|
||||
Für Collections, welche nur einen Eintrag haben dürfen, gibt es das singleton Objekt. Dabei wird im Tibi Admin automatisch beim ersten Öffnen der Collection ein Eintrag erzeugt, und anschließend ebenfalls automatisch immer dieser Umgehend geöffnet, sodass die "Entry" Übersicht wegfällt.
|
||||
|
||||
```yaml
|
||||
singleton:
|
||||
enabled: true
|
||||
```
|
||||
|
||||
## hideInNavigation
|
||||
|
||||
Für Collections, welche nicht in der Seitennavigation auffindbar sein sollen, kann man dieses Attribut verwenden.
|
||||
|
||||
```yaml
|
||||
hideInNavigation: true
|
||||
```
|
||||
|
||||
## allowExportAll
|
||||
Wenn dieses Attribut auf true gesetzt wird, so kann der Nutzer alle Einträge auf einmal Herunterladen, in einem Format, welches er in einem anderen Server wieder hochladen kann.
|
||||
|
||||
```yaml
|
||||
allowExportAll: true
|
||||
```
|
||||
|
||||
## multilingual
|
||||
|
||||
Dieses Attribut ist für die Content Collection vorgesehen. Dabei hat man eine Möglichkeit, zwischen den Verfügbaren Sprachen für diesen Eintrag hin und her zu wechseln, sowie Fehlende Sprachen anzulegen. Dabei Referenzieren sich die unterschiedlichen Sprachversionen gegenseitig. Über das Select oben Rechts im Admin kann zwischen den Sprachen gewechselt werden. Über den Button in der Fußzeile könnte man manuell eine Sprache verknüpfen, was aber bei regulärer Nutzung nicht notwendig sein sollte.
|
||||
|
||||
```yaml
|
||||
multilingual:
|
||||
enabled: true
|
||||
defaultLang: de
|
||||
pathToLanguageSelect: generalDetails.lang
|
||||
pathToLanguageReferences: generalDetails.languageReferences
|
||||
```
|
||||
|
||||
```yaml
|
||||
- name: languageReferences
|
||||
type: string[]
|
||||
meta:
|
||||
label:
|
||||
de: Sprachreferenzen
|
||||
en: Language References
|
||||
widget: foreignKey
|
||||
hide: true
|
||||
foreign:
|
||||
collection: content
|
||||
subNavigation: 0
|
||||
id: id
|
||||
render:
|
||||
defaultCollectionViews: true
|
||||
```
|
||||
|
||||
```yaml
|
||||
name: lang
|
||||
type: string
|
||||
meta:
|
||||
label:
|
||||
de: Sprache
|
||||
en: Language
|
||||
widget: select
|
||||
choices:
|
||||
- name:
|
||||
de: Deutsch
|
||||
en: German
|
||||
id: de
|
||||
|
||||
- name:
|
||||
de: Englisch
|
||||
en: English
|
||||
id: en
|
||||
|
||||
- name:
|
||||
de: Französisch
|
||||
en: French
|
||||
id: fr
|
||||
|
||||
- name:
|
||||
de: Schwedisch
|
||||
en: Swedish
|
||||
id: se
|
||||
|
||||
- name:
|
||||
de: Dänisch
|
||||
en: Danish
|
||||
id: dk
|
||||
```
|
||||
|
||||
|
||||
## Information Guide
|
||||
Um ein Projekt direkt im TibiAdmin zu dokumentieren, kann man den information Guide verwenden. Dazu wird ein .md dokument in ein Modal hineingerendert:
|
||||
|
||||
```yaml
|
||||
informationGuide:
|
||||
title:
|
||||
de: Links Guide
|
||||
en: Links Guide
|
||||
content:
|
||||
path:
|
||||
eval: $projectBase + "_/assets/information/static_frontend_links.md"
|
||||
```
|
||||
|
||||
## noDB
|
||||
Wenn eine Collection nur einen get Hook hat, welcher bspw xml (wie die Sitemap collection) zurückgibt, so kann man noDB aktivieren. Dabei werden dann keine Einträge gerendert, sondern dass, was von der Collection zurückgegeben wird:
|
||||
|
||||
```yaml
|
||||
noDB:
|
||||
enabled: true
|
||||
xmlPreview: true
|
||||
```
|
||||
|
||||
|
||||
## backups
|
||||
|
||||
im meta Objekt einer collection können backups für diese collection konfiguriert werden. Die backups werden in der Datenbank gespeichert und können über das tibi-admin in der selben collection angewandt werden. Wird ein collectoneintrag gelöscht, kann man diesen über den gelöschte einträge checkbox wiederherstellen.
|
||||
|
||||
@@ -88,8 +88,6 @@ Diese Konfigurationsdatei ist für einen Apache Webserver bestimmt und beinhalte
|
||||
- Clientseitige Fetch-Request-Optimierung
|
||||
- Überprüfung, ob die aktuelle Anfrage bereits im window.**SSR_CACHE** vorhanden ist.
|
||||
- Bei vorhandenen Anfragen wird der gespeicherte Wert über Promise.resolve() zurückgegeben, um redundante Anfragen zu vermeiden.
|
||||
- Deaktivierung von SSR-Caching für spezielle Seiten
|
||||
- Für Seiten wie Produktseiten wird empfohlen, das SSR-Caching über den Boolean zu deaktivieren, um zu verhindern, dass solche Anfragen in den Cache gelangen.
|
||||
- Finalisierung des HTML-Dokuments
|
||||
- Das Standard-spa.html-Dokument wird verwendet und mit den ermittelten Werten für Head, Body, Fehlermeldungen und Kommentaren ergänzt.
|
||||
- Das resultierende HTML-Dokument wird in der SSR-Collection gespeichert und als Response an den Client gesendet.
|
||||
@@ -98,10 +96,15 @@ Diese Konfigurationsdatei ist für einen Apache Webserver bestimmt und beinhalte
|
||||
|
||||
## Teil 3: SSR-Cache-Management
|
||||
|
||||
- Cache-Management in der Content-Collection
|
||||
- Löschung der SSR-Collection bei jedem POST und PUT-Request.
|
||||
- Workflow-Integration
|
||||
- Als Teil des Workflows wird der SSR-Cache gelöscht, um die Auslieferung veralteter Seiten zu verhindern.
|
||||
Ein effektives Cache-Management ist essenziell, da häufiges Löschen des SSR-Caches die SEO-Performance negativ beeinflussen kann. Webcrawler verfügen über ein begrenztes Crawl-Budget – ist dieses aufgebraucht, werden keine weiteren Seiten indexiert. Daher sollte der Cache automatisiert und intelligent gepflegt werden.
|
||||
|
||||
Eine bewährte Methode zur automatischen Cache-Befüllung ist die Nutzung der Sitemap. Diese sollte jedoch mit Bedacht eingesetzt werden, da sie insbesondere bei großen Projekten mit hohem Rechenaufwand verbunden sein kann.
|
||||
|
||||
Zur Effizienzsteigerung wird bei jedem SSR-Eintrag protokolliert, welche Datenquellen (z. B. Einträge) für den Seitenaufbau verwendet wurden. Wird ein solcher Eintrag später verändert, werden automatisch alle davon abhängigen SSR-Caches invalidiert und die betreffenden URLs in eine „Recalculation Queue“ eingetragen, um eine zeitnahe Neubefüllung sicherzustellen.
|
||||
|
||||
Zusätzlich existiert eine SSR-Flags-Collection, mit der gesteuert werden kann, ob alle SSR-Einträge über Nacht neu generiert werden sollen. Dabei wird der SSR-Cache unmittelbar geleert, der Wiederaufbau erfolgt jedoch aus Performancegründen zeitversetzt in den Nachtstunden. Diese Flag wird bspw automatisiert in der Pipeline gesetzt.
|
||||
|
||||
|
||||
|
||||
### Dokumentation: SSR in der Entwicklungsumgebung
|
||||
|
||||
|
||||
Reference in New Issue
Block a user