Einen eigenen Blocktyp entwickeln
Ein eigener Blocktyp ist sinnvoll, wenn Redakteure strukturierte Werte pflegen sollen, die ein Core-Block nicht verständlich abbildet. Definieren Sie zuerst Felder, Validierung und Bearbeitungsdialog; danach die Ausgabe.
Daten und Dialog vor der Ausgabe festlegen
Ein Blocktyp liegt unter application/blocks/<handle>/ oder packages/<package>/blocks/<handle>/. Üblich sind controller.php, db.xml, add.php, edit.php und view.php. Der Controller verbindet Speicherung, Validierung und Ausgabe. Für wiederholbare Einträge kann eine Tabelle den Block und eine zweite Tabelle die geordneten Einträge speichern. Der Controller deklariert beide Exporttabellen, damit eine CIF-Ausgabe die wiederholbaren Daten mitnehmen kann. Eine Anzahl wird im View aus der Reihenfolge berechnet; Redakteure pflegen keine Nummern von Hand.
Entwerfen Sie zuerst den Dialog: Welche Felder sind Pflicht? Können Zeilen ergänzt, verschoben und entfernt werden? Was bleibt nach einem Validierungsfehler stehen? Für Titel und Text ist eine klar benannte Eingabe besser als ein HTML-Feld für die gesamte Schrittfolge. Testen Sie leere, lange und mehrere Einträge sowie Änderungen an einem bereits gespeicherten Block.
Abbildung 1: Ein Blocktyp wird installiert und ist anschließend gezielt für Seitenbereiche verfügbar.
Controller und View trennen
Der Controller validiert Eingaben vor dem Speichern und stellt dem View bereinigte Werte bereit. Bei einem Block mit wiederholbaren Einträgen kann validate() einen Concrete-Fehlercontainer; save() begrenzt die Titellänge und speichert die sortierten Zeilen. Ausgabe und Escape-Regeln gehören in view.php. Verwenden Sie für Textkontext HTML-Escaping, für URL-Kontext passende URL-Prüfung und für zulässiges Rich Text nur den dafür vorgesehenen sicheren Weg. Das bloße Entfernen einzelner Tags ist keine vollständige Ausgabeprüfung.
Ein Block, der Dateien oder Seiten auswählt, sollte deren Concrete-IDs speichern statt fest verdrahteter lokaler URLs. So bleiben Links beim Domainwechsel und in Exporten stabil. Ein Block-Custom-Template verändert nur die Darstellung; es darf native Abfragen oder Filter eines Core-Blocks nicht still überschreiben. Navigation und Seitenlisten zeigt, warum die gespeicherte Blockkonfiguration Vorrang hat.
Installation und Bearbeitungsmodus abnehmen
Registrieren Sie den neuen Typ über das Paket oder die Anwendung. Prüfen Sie dann Hinzufügen, Bearbeiten, Abbrechen, Speichern, Duplizieren, Seitenversionen und Ausgabe als Gast. Bei wiederholbaren Zeilen gehört die Reihenfolge in den Test. Ein Export/Import auf einer getrennten Installation zeigt, ob db.xml, Exporttabellen, Dateien und referenzierte Seiten wirklich mitkommen. Der Core-Überblick Creating a new block type (EN) (externer Link) zeigt den Dateiaufbau; die konkrete Zieltabelle ist am aktuellen Controller zu verifizieren.
Vergleichen Sie den neuen Block mit den bereits installierten Package-Funktionen, bevor Sie ein ähnliches Modell noch einmal implementieren. Die Verwaltung Blocktypen zeigt, welche Handles schon belegt sind.
Weiterlesen
- Blöcke hinzufügen und anordnen
- Pakete installieren und aktualisieren
- Erweiterungen gegen unbefugte Eingaben absichern
Quelle: Concrete CMS Dokumentation (EN) · Stand: ConcreteCMS 9.5.7