Wie wählt man zwischen Bean, Boxes und Fieldable Panels Panes?

Bean , Boxen und Fieldable Panels Panes alle eine ähnliche Funktionalität bieten. Ich habe Probleme zu verstehen, was genau die Unterschiede zwischen ihnen sind.

Was sind ihre Vor- und Nachteile im Vergleich zueinander? Sind sie auf unterschiedliche Anwendungsfälle ausgerichtet?

Ich möchte eine Art von Blöcken in Panels verwenden, um benutzerdefinierten Inhalt hinzuzufügen. Inhaltseditoren müssen auch in der Lage sein, Inhalt hinzuzufügen. In diesem Sinne sind die von mir benötigten Blöcke keine reine Konfiguration. Aber ich benutze auch Features ...

Edit: Ich werde hinzufügen, was die Hauptunterschiede zu sein scheinen

Kästen

• Größte Nutzerbasis (~ 11500)
• Behandelt Blöcke als Konfiguration (dh der Inhalt landet in Ihren Funktionen)
• Module, die Integration bieten

Bohnen

• Wurde vor kurzem populär, installiert ~ 1000
• Behandelt Blöcke als Inhalt, ermöglicht jedoch die Exportierbarkeit ihrer Konfiguration über den Computernamen (z. B. über Bean Panels ).
• Module, die Integration bieten

Fieldable Panels Panes

• Kleinste Nutzerbasis (~ 400)
• Vom Autor von Panels / Views / etc.
• Fenster können nicht als reguläre Blöcke in Themenbereichen wie Beans oder Boxen verwendet werden (nehme ich an)
• Ich frage mich, was die Vorteile gegenüber Bean sind, die hier erwähnt werden ("bietet zusätzliche Funktionen, die es einfacher machen, Inhaltsadministratoren zu befähigen, bestimmte Seiten zu gestalten").

Es ist durchaus möglich, eine D7-Site ohne Blöcke zu erstellen, wenn Sie ohne Dashboard leben können. Unsere neue inhaltsgesteuerte Site wird auf Panels mit Workbench als (für uns) geeignete Alternative zum Dashboard aufgebaut. Arjan scheint dies bereits zu verstehen.

Weiter zu den Alternativen. Lesen Sie, dass Ihre Site voller Bohnen sein sollte . Das Problem bei Boxen ist die Gefahr des Überschreibens vorhandener Inhalte bei der Verwendung von Features. Lesen Sie jedoch den Kommentar von Fabian Franz im selben Artikel. Bohnen hat viele Möglichkeiten. Ich fühle mich in Bezug auf Management, Skalierbarkeit und Leistung nicht wohl. Hardcore-Entwickler, die sich mit Panels auskennen, verwenden Fieldable Panels Panes. Feldfähige Panels In Panels fehlen Dokumentation und Beispiele. Was für D8 jedermann den Fokus und die Anstrengung geben sollte, ist die Wscci- Initiative. Es erlaubt REST-Aufrufe, einschließlich zum Beispiel DELETE. Dies könnte das Problem des Überschreibens der Site Builder-Konfiguration bei Code-Rollouts dauerhaft lösen.

Für Ihren Zweck ist es möglicherweise optimal, Ansichten mit einer gewissen Taxonomie zu verwenden: Fügen Sie zu einem Inhaltstyp Begriffe für die Stelle des Bedienfelds hinzu, machen Sie für diese Stelle einen Ansichtsblock mit Filter für diesen Begriff und Inhaltstyp und fügen Sie diesen Ansichtsblock an der Stelle im Bedienfeld hinzu In der Regel erstelle ich für diesen Inhaltstyp ein zusätzliches Feld für die Gewichtung und in Ansichten, die ich nach Gewichtung sortiere, muss der Redakteur das Bedienfeld nie bearbeiten, um Inhalte an diesem Ort hinzuzufügen, zu bearbeiten oder zu entfernen

Schauen Sie sich das Nodeblock-Modul an. Als Knoten exportieren sie nicht über Features, aber Sie werden vielleicht feststellen, dass sie genau das tun, was Sie brauchen.