😍

Das ist ⭐️ ⭐️ ⭐️ ⭐️ ⭐️ Arbeit. STELLAR Mockups, ich liebe es. Dies ist genau die Art von reichhaltigem Layout, von der wir hoffen, dass eine Block-First-Benutzeroberfläche erreicht werden kann.

CC: @melchoyce Sie werden dies später im Jahr für den Anpassungsfokus sehen wollen.

Für den V1-Editor fürchte ich, dass Spalten wie diese außerhalb des Geltungsbereichs liegen. Das ist kein „Nein“ – vielmehr brauchen wir erst ein paar technische Grundlagen, um solide zu sein, bevor wir uns auf die wirklich interessanten Dinge einlassen. Aber es könnte eine V1.1 sein, oder zumindest etwas für die Anpassungsleute später im Jahr. Schon vorher wäre es gut, diese Benutzeroberfläche im Hinterkopf zu behalten, damit ein Plugin dies vielleicht noch früher hinzufügen kann.

Danke dafür!

Mein Feedback wäre, dass dies den Editor zu einem Layout-Tool und nicht zu einem Inhaltsbearbeitungstool macht. Dinge wie Responsive Design machen die Layoutkontrolle in CMSs sehr schwierig und sollten IMHO am besten dem Theme-Designer / -Entwickler überlassen werden. Ich könnte sicherlich Optionen wie "2-col" sehen, aber das Ziehen von Trennern, um Benutzern im Grunde das Layout von Inhalten zu ermöglichen, scheint mir außerhalb des Rahmens eines Inhaltseditor-Tools zu liegen.

Sie sind sich nicht sicher, ob diese Philosophie mit dem Selbstverständnis von Project Gutenberg übereinstimmt?..

Ich denke, das sind auch interessante Ideen für Galerien. Wir möchten möglicherweise nicht den aktuellen Ansatz mit festen Spalten beibehalten und zulassen, dass Zeilen unterschiedliche Anzahlen von Spalten haben. Genau wie Textspalten klingt ein guter Galerieblock nach etwas, das sehr komplex werden kann.

Sie sind sich nicht sicher, ob diese Philosophie mit dem Selbstverständnis von Project Gutenberg übereinstimmt?..

Später in diesem Jahr wird der Customizer im Fokus stehen:

Der Customizer wird dem Editor zunächst helfen und dann diese grundlegenden Bausteine ​​in etwas umwandeln, das eine Anpassung von post_content „out of the box“ ermöglicht, einschließlich Seitenleisten und möglicherweise sogar eines ganzen Themas.

Säulen gehören sehr wahrscheinlich dazu.

Gutenberg ist in erster Linie dafür da, einen Beitrag zu schreiben und zu gestalten. Das müssen wir richtig machen. Aber der Editor wird wahrscheinlich später etwas DNA mit dem Customizer teilen, insbesondere wenn es um einige der Blöcke und wahrscheinlich auch Kontrollen geht. Als solches ist dieses Mockup immer noch hilfreich für den Anpassungsfokus.

Sehr elegante Lösung. Fühlt sich viel besser an, als in eine Reihe von Spaltenblöcken fallen zu lassen, IMO. Ich kann auch sehen, dass die Spaltenbreiten in bestimmte Prozentsätze einrasten (also 50 % / 50 % oder 33 % / 66 % oder 25 % / 75 % usw.). Spalten werden mit ziemlicher Sicherheit ein Feature im aktualisierten Customizer sein :)

@jasmussen freut
@simonrjones Erweitern von WordPress über die Standard-Blog-Posts hinaus erfordert automatisch mehrspaltige Layouts für Präsentationsseiten. Ich würde diese Funktion lieber im Voraus in Angriff nehmen, als jeden Entwickler alleine machen zu lassen (siehe die Vielzahl von Page Builder-Plugins).
@melchoyce auf jeden Fall sollten die Spaltenbreiten an bestimmten Schritten ausgerichtet werden (auch wenn dies ein 6- oder 12-Spalten-Stepper wäre).

Ich frage mich, ob wir einen Weg finden können, das Einrasten von Spalten themenabhängig zu machen. Etwas, über das wir in den nächsten Monaten nachdenken sollten, während Gutenberg voranschreitet.

Es sollte einen Standard sowohl in Bezug auf das Spalteneinrasten als auch für das CSS-Raster (einschließlich des responsiven Teils) geben. Dann sollte das Theme in der Lage sein, sie zu überschreiben.

Wir arbeiten bereits an einem in TinyMCE Editor integrierten Plugin, das einige dieser Verhaltensweisen teilt – nur dass es kein Drag&Drop-Block basiert, sondern ein Zeilen-/Spalten-Ansatz ist. Es heißt Gridable und es könnte sich lohnen, es auszuprobieren.

+100 von mir. Die Idee mit den Säulenblöcken gefällt mir sehr gut.

Ist dies ein Kandidat für CSS-Grids?

https://css-tricks.com/getting-started-css-grid/

Danke für die Erläuterungen zu meinen Kommentaren.

CSS-Raster wären fantastisch und passen sehr gut zu Spaltenlayouts. Ich vermute jedoch, dass die breite Browserunterstützung noch einige Zeit entfernt ist, was ein Problem für WP sein kann (funktioniert heute im neuesten Firefox). Einige sehr gute Ressourcen zu CSS-Grids auf der Site von Rachel Andrew und einige nette Sachen auf Jen Simmons .

Das Hinzufügen von Spalten bedeutet auf die eine oder andere Weise sowohl CSS als auch HTML, daher benötigen wir idealerweise einfache und auf Standards basierende Muster dafür, um es den Theme-Entwicklern zu erleichtern. Dies könnte in Code gekapselt werden, so dass ein Standardstartpunkt definiert werden kann, der dann überschrieben werden kann (zB wenn jemand Foundation zum Erstellen seiner Site verwenden möchte und Spalten auf Foundation-Art eingerichtet werden müssen).

Ich habe eine gute Faustregel gehört, die lautet:

• Raster für Site-Struktur/Layout
• Flexbox für Inhalte innerhalb dieses Layouts

Ein guter Artikel über Flexbox vs. Grid von Rachel Andrew: https://rachelandrew.co.uk/archives/2016/03/30/should-i-use-grid-or-flexbox/

Basierend auf den aktuellen Browserkompatibilitätsanforderungen von WordPress denke ich, dass ein Standardraster "Zeile + Spalten" als Standardsystem (zB Bootstrap oder Foundation) die beste Balance zwischen Einfachheit und Flexibilität bieten würde.

Ich stimme zu, dass die standardmäßige Zeilen- und Spaltenstruktur der richtige Weg ist.

Es wäre schön, wenn es in den WordPress-Einstellungen die Möglichkeit gäbe, das Rastersystem auszuwählen:

• Standard
• Bootstrap
• Stiftung
• Brauch

Das Standardrastersystem würde die Unterstützung von CSS beinhalten (als Teil des TwentyEighteen-Themas?), während die anderen Optionen auf dem CSS-Thema basieren. Im Wesentlichen gibt WordPress die Rasterklassen aus und das Theme stellt die Stile bereit.

Mit der benutzerdefinierten Option können Sie die Klassennamen für die Zeilen und Spalten festlegen. Ein enger Vergleich der Benutzeroberfläche für das, was ich beschreibe, ist der Bildschirm mit den aktuellen Permalink-Einstellungen.

Mehrspaltige Layouts sind ein Muss! Im Moment löst Gutenberg kein Problem. Am Ende haben Sie immer noch eine lange Inhaltsspalte. Der einzige Grund, warum Seitenersteller so beliebt sind und warum Hunderttausende von Menschen sie verwenden, liegt darin, dass sie die Möglichkeit bieten, einfach mehrspaltige Layouts zu erstellen. Ohne diese Funktionalität liefern Sie keinen Grund, Gutenberg über ein Page Builder-Plugin zu verwenden.

@maddisondesigns Ja, mehrspaltige Layouts sind für V2 geplant. Die grundlegende Arbeit dafür wird jetzt in V1 geleistet. Tatsächlich unterstützt der zugrunde liegende Parser für Blöcke die Verschachtelung, aber die Benutzeroberfläche zum Anzeigen verschachtelter Blöcke wurde noch nicht implementiert. Siehe auch #428.

@westonruter Toll zu hören, dass es in Planung ist. Würde aber gerne sehen, dass es in V1 implementiert wird. Ich bin zuversichtlich, dass dies eines der ersten Dinge sein wird, über das sich die Leute beschweren, wenn es zum Kern hinzugefügt wird, ohne mehrspaltige Layouts erstellen zu können. Im Moment macht Gutenberg nichts, was im bestehenden TinyMCE nicht möglich ist. Sicher, es sieht auf jeden Fall viel hübscher aus und hat einige coole Funktionen, wie zum Beispiel die Möglichkeit, Textblöcke einfacher nach oben und unten zu verschieben, aber auch hier ist dies im Grunde dasselbe wie das Kopieren und Einfügen eines Textblocks in TinyMCE. Etwas umständlicher, sicher, aber das Endergebnis ist das gleiche. Ich dachte, das Hauptziel von Gutenberg war es, eine deutliche Verbesserung des Layouts von Inhalten zu erzielen, und nicht nur einen schöneren Editor bereitzustellen. Es scheint nicht intuitiv zu sein, eine blockbasierte Schnittstelle zu haben, wenn Sie nur einen Block pro Zeile / Zeile haben können. Es versteht sich natürlich von selbst, dass ich den damit verbundenen zusätzlichen Aufwand verstehe, aber ich denke, die Leute würden diese Art von Funktionalität viel lieber beim ersten Rollout sehen, selbst wenn dies bedeutet, dass sie nicht für ein paar weitere Releases zum Core hinzugefügt werden.

Ich schätze die Aufregung und Dringlichkeit, Kolumnen zu wollen. Wir empfinden die gleiche Dringlichkeit. Es geht nicht darum, keine Spalten zu wollen, sondern an dieser Stelle nur darum, Ressourcen zu verwalten. Wir werden es schaffen, das ist absolut ein Meta-Ziel. Wenn wir nur mit den Fingern schnipsen und es möglich machen könnten ;)

Auch ohne Spalten ist Guttenberg ein großer Schritt nach vorne und ich bin sehr beeindruckt, aber ich stimme zu, dass deren Einbeziehung für V1 unerlässlich ist und es sich lohnen würde, V1 zu verschieben, bis dieses Feature fertig ist.

Wenn Sie die aktiven Installationen für die Top drei Page Builder und die erste Seite der Spalten-Plugins von .org hinzufügen, erhalten Sie mehr als 1,5 Millionen ... und wenn Sie Premium hinzufügen, ist das nicht die Hälfte. Der Punkt ist, dass ein Editor ohne Spalten meiner Meinung nach den aktuellen Anforderungen nicht gerecht wird. Wenn Guttenberg ohne Spalten veröffentlicht wird, würde ich mir vorstellen, dass am ersten Tag ein Dutzend Plugins auftauchen, um sie hinzuzufügen. Beim nachträglichen Hinzufügen hat der Benutzer dann etwas zu verwalten.

Guttenberg wird wunderbar störend sein, aber ich möchte dringend darauf hinweisen, dass alle wesentlichen Bausteine ​​vorhanden sind. +1 zur Aufregung und Dringlichkeit.

Ich möchte die Vorstellung in Frage stellen, in Gutenberg Unterstützung für komplexe Layouts zu "brauchen".

Die vorgeschlagene Kombination aus Spalten und Verschachtelung ist ein Kaninchenloch, das nicht endet, bis die Benutzererfahrung für Leute, die tatsächlich Inhalte schreiben, wirklich schlecht ist. Jeder "vollwertige" Seitenersteller ist ein Beweis dafür.

Nicht jeder erstellt Layouts mit Page Buildern, und eine solche Seitenstruktur in der Datenbank ist sehr problematisch. Es wäre viel besser, sich auf eine gute API zur Erweiterung von Gutenberg zu konzentrieren und beim Hinzufügen komplexer Funktionen zum Kern von Gutenberg sehr vorsichtig zu sein.

@khromov - Es sieht so aus, als ob Sie auf meinen Kommentar antworten. Ich befürworte Spalten, keine komplexen Layouts, Verschachtelungen oder einen vollständigen Seitenersteller. Ich benötige manchmal Spalten, wenn ich Inhalte schreibe. Ich weigere mich, Shortcodes zu verwenden, daher habe ich zwei Möglichkeiten: verschachtelte Divs von Hand erstellen, was eine schreckliche Benutzererfahrung ist und eine große Ablenkung vom eigentlichen Schreiben von Inhalten ist, oder einen Page Builder verwenden, der normalerweise übertrieben ist. Ich denke, dass die Verwendung von Spalten sehr verbreitet ist, vielleicht häufiger als das Einbetten eines Videos.

Auf jeden Fall ist mein Verständnis, dass Spalten auf der Roadmap stehen. Ich würde sie gerne in V1 statt in V2 sehen. Wie Sie weiß ich es zu schätzen, dass darauf geachtet wird, ein gutes Fundament zu legen.

Einer der Aspekte, die man bei "Spalten" beachten sollte, ist, dass es nicht nur um Desktop-Layouts geht. Es verfügt über ein System, das von Mobilgeräten bis hin zu Desktops skaliert.

Ist es column-count in CSS? Wenn wir das verwenden würden, wäre es sehr einfach, schnell etwas ansprechendes zu erstellen, aber dann könnten Sie den Inhalt nicht in der gewünschten Spalte an bestimmten Haltepunkten anordnen.

Ist es CSS Grid oder Flexbox? Dann möchten wir sicherstellen, dass die Benutzer über die richtigen Reaktionsoptionen verfügen, damit die Ergebnisse auf allen Geräten vorhersehbar sind, und nicht nur das, sondern wir möchten auch WordPress-Themes über diese Funktionen informieren, damit sie sich entsprechend anpassen können.

Wir wissen, dass wir Spalten wollen. Tatsächlich können Plugins von Drittanbietern heute Spaltenblöcke erstellen. Aber es ist ein kompliziertes Feature mit einer Reihe von Aspekten, die richtig vorhanden sein müssen, damit es funktioniert, und ohne weitere Mitwirkende am Projekt ist es unwahrscheinlich, dass es in V1 passiert.

@jasmussen - Ja. Ich weiß es zu schätzen, dass Spalten auf der Roadmap stehen und vielleicht gibt es einige Erkenntnisse aus dem Galerieblock, die helfen werden.

Diese Funktion sollte unter Berücksichtigung moderner Layout-Tools erstellt werden. Wenn Sie jetzt unnötige Container erstellen, um Spaltenlayouts zu erstellen, werden unsere Möglichkeiten, moderne Technologien in Zukunft zu verwenden, eingeschränkt.

Für einfache eindimensionale Layouts wie Spalten können wir entweder Flex oder Grid verwenden. Ich tendiere zum Raster aus dem einfachen Grund, dass, während wir heute nur über Säulen sprechen, die Verkehrsteilnehmer eine fortschrittlichere Rastersteuerung wünschen, also sollten wir jetzt die Grundlage schaffen.

Was die Browser-Unterstützung betrifft, so bieten sowohl Flex als auch Grid eine breite Unterstützung in modernen Browsern und fallen in älteren Browsern sauber zurück. Es ist auch relativ einfach, Fallbacks für ältere Browser bereitzustellen.

Ich rate dringend davon ab, einen klassischen Framework-Ansatz zum Verschachteln von Elementen zu verwenden, damit dies funktioniert. Dies wird fast sofort zu Altlasten führen und zukünftige Layoutarbeiten behindern.

Die Übernahme von Raster hier öffnet die Tür zu unerforschtem Terrain, wenn es um Layouts geht. Ich werde versuchen, nächste Woche Zeit zu finden, um etwas umfassenderes darüber zu schreiben, was hier möglich ist. In der Zwischenzeit ist dies relevant: https://rachelandrew.co.uk/archives/2017/07/01/you-do-not-need-a-css-grid-based-grid-system/

Meine Sorge dabei ist, dass es Benutzer an eine bestimmte Art von HTML-Struktur bindet. Alle Themen müssen sich dann anpassen, um diese Struktur zu unterstützen. Ist es verschachtelte div s? Verschachtelte section s? Verwenden wir float s für die Rückwärtskompatibilität (weil viele Sites das brauchen? Win7 hat immer noch einen riesigen Marktanteil, was bedeutet, dass IE11 immer noch genauso gut funktioniert und IE11 nicht gut mit flexbox ? ) oder gehen Sie mit flexbox/grid für die Zukunft. Geben wir Benutzern die Möglichkeit, Änderungen vorzunehmen (und sie dann wieder mit CSS vertraut zu machen)? Das kann schnell gefährlich werden.

Der Inhalt würde die verschachtelten Blöcke enthalten, aber das zum Rendern generierte Markup könnte möglicherweise durch das Thema bestimmt werden.

Ich denke, Gutenberg sollte sich stattdessen darauf konzentrieren, die Funktionalität und die Benutzeroberfläche zum Hinzufügen verschachtelter Blöcke bereitzustellen, die es Entwicklern ermöglichen würden, benutzerdefinierte Blöcke für Dinge wie eine Spalte zu erstellen. Gutenberg sollte sich nicht um das Raster kümmern, da ein Thema die Kontrolle darüber haben sollte.

@westonruter +100000 dazu. Ich denke, Gutenberg könnte eine Standardmethode zum Markieren des Rasters und seiner Stile bieten, aber es ist wichtig, dass es von Themen überschrieben werden kann, beispielsweise durch add_theme_support() .

Riesiges +1 von mir, das wäre ein sehr beliebtes Feature.

Dies ist ein großartiges Beispiel dafür, warum Gutenberg-Daten einfach nicht als rohes HTML gespeichert werden sollten ... wenn sie in einer standardkonformen Methode wie mobiledoc gespeichert würden, wären Spalten einfach Objekte und das Rendern wäre leicht überschreibbar durch irgendein Thema. Wenn Designs eine Legacy-Struktur wie Zeile/Spalte verwenden wollten, könnten sie dies tun. Wenn sie Raster verwenden wollten, könnten sie das. wenn sie flex verwenden wollten, könnten sie das. Wenn sie die Technologie nutzen wollten, die als nächstes kommt, könnten sie das tun. Eine echte Objektspeichermethode würde Inhalte zukunftssicher machen. HTML + Kommentare einfach nicht.

+1 Diese Funktion ist für alle sehr wichtig.

Ich bereite mich darauf vor, eine große B2B-Website neu zu gestalten. Im Moment verwendet es Divi und ich würde gerne Gutenberg für das Redesign verwenden oder ich bleibe noch einige Jahre bei Divi.

Wenn Spalten nicht angesprochen werden, werden wir gezwungen sein, mit dem "Nicht-WordPress"-Ansatz beim Aufbau unserer WP-Site fortzufahren. Ich bin auch gespannt, ob Gutenberg ein paar "Seitenlayout"-Voreinstellungen hinzufügen wird, um inkompatible Themen zu überschreiben und Basislayouts einzubeziehen.

Raster basierend auf Flexbox, bitte. Nicht CSS Grid, da es für alle Änderungen ein Container-CSS-Update erfordert. Flexbox funktioniert durch einfaches Hinzufügen von Blöcken. Danke.

Würde diese Funktion auf jeden Fall lieben. Tolle Diskussion hier, bin gespannt, wie es sich entwickelt.

Ich liebe es. Vor allem die Möglichkeit, die Spaltengröße zu ändern. Besonders gut gefällt mir, dass Sie das Layout steuern können. Ich denke, das ist überhaupt keine Schwäche. Es ist genau das, was ich in Gutenberg wollte und frustriert, dass ich es nicht bereits tun kann, da so viele andere ähnliche Tools diese Funktion bieten.

Also habe ich gerade das Gutenberg-Plugin aktualisiert und versucht, mit Spalten darin herumzuspielen. Ich habe einen neuen Beitrag erstellt und einen Spaltenlayoutblock hinzugefügt und versucht, ihn mit dem Schieberegler zu vergrößern. Jedes Mal, wenn ich dies versuche, wird der Fehler angezeigt: "Dieser Block ist auf einen Fehler gestoßen und kann nicht in der Vorschau angezeigt werden."

Danke für den Fehlerbericht, @mhenrylucero — Ich habe ein separates Ticket dafür geöffnet #3710.

3745 wurde Anfang dieser Woche fusioniert, was den Vorschlag hier teilweise umsetzt.

Soweit ich das beurteilen kann, sind die verbleibenden Aufgaben weitgehend verbesserte UX rund um die Neuanordnung von Blöcken in Spaltenlayouts, habe ich Recht? Liege ich richtig in der Annahme, dass dies nach einem ersten Zusammenführungsvorschlag besser für den Anpassungsfokus geeignet wäre?

Ich werde dies schließen, das als Referenz für weitere Verbesserungen bei der Anpassung dienen wird.