Gutenberg: Eine Möglichkeit, den Gutenberg-Editor im Code zu deaktivieren?

Siehe auch:

• https://github.com/WordPress/gutenberg/blob/master/docs/faq.md#will -i-in der Lage sein,-von-gutenberg-for-my-site-abzumelden
• https://wordpress.org/plugins/classic-editor/

Hi @aduth hat den Titel aktualisiert, um mehr Sinn zu machen - auf der Suche nach Code-Optionen :) Danke

Ich denke, dies wäre eine sehr nützliche Funktion für viele Entwickler. In der Tat würde ich so weit gehen, was darauf hindeutet , dass ich glaube , Gutenberg nur auf Neuinstallationen von Wordpress aktiv sein soll , die Version sind 5,0 anstatt auf Websites , aktiv , die ein Upgrade auf Wordpress - Version 5.0 - wenn die Zusammenführung in dem Kern passiert.

Wenn dies mit einer Möglichkeit zum Aktivieren / Deaktivieren des Codes kombiniert wurde, können Entwickler ihn aktivieren, wenn er bereit ist.

Können Sie erläutern, warum Sie dies per Code erreichen müssen?

Wenn es um die Sichtbarkeit / Kontrolle des Clients geht, können Sie das oben genannte Plugin jederzeit als "Must Use Plugin" installieren: https://codex.wordpress.org/Must_Use_Plugins

Da eine Codeänderung schnell und einfach ist - das Aktivieren eines Plugins ist 1) nicht mein Code und 2) nicht so einfach wie das Hinzufügen eines Codes - ist das Hinzufügen zur Liste der Abhängigkeiten weder eine praktische noch eine sinnvolle Methode, um dieses Problem anzugehen.

Das Definieren einer Konstante mag Ihr Code sein, aber die Logik, die mit dieser Konstante arbeitet, wäre genauso wenig Ihr Code wie das offiziell gepflegte "Classic Editor" -Plugin.

Ich sollte klarstellen, dass ich nicht versuche, argumentativ zu sein, sondern ein besseres Verständnis dafür zu erlangen, warum diese Ansätze attraktiv sind, um sicherzustellen, dass ausreichende Optionen vorhanden sind, und nicht so viele anzubieten, dass sie übermäßig zu pflegen sind.

Warum kann die Plugin-Funktionalität nicht Teil des Kerns sein? Ich frage nur, wie ich neugierig bin :)

Ich möchte die Notwendigkeit widerspiegeln, den Gutenberg-Editor ein- und ausschalten zu können. Meine besondere Situation ist, dass eine meiner WordPress-Sites auf einem Thema basiert, das einen benutzerdefinierten Editor hat (z. B. Avia Editor im Enfold-Design).

Wenn Gutenberg aktiviert ist, ändert sich der Workflow für unsere Editoren. Sie müssen zu Alle Beiträge> oder Seiten> gehen und auf "Klassischer Editor" klicken und dann auf die Schaltfläche für den erweiterten Layout-Editor klicken, der den integrierten Design-Editor aufruft, anstatt einfach auf der Seite, die sie bearbeiten möchten, auf "Bearbeiten" zu klicken oder von der Vorschauseite. Wir benötigen diesen Editor, da das Erscheinungsbild unserer Website anhand der Vorlagen standardisiert ist, die wir mit diesem Editor erstellt haben.

Während der Prozess für die meisten trivial erscheint, würde die Änderung des Workflows für Dutzende von Editoren einige Support-Kopfschmerzen verursachen.

Meine 2 Cent.

Ich denke, der Unterschied ist nur "psychologisch". Wenn wir es in Core haben, haben wir es auf unbestimmte Zeit, was der Gutenberg-Einführung schadet. Wenn wir es als Plugin haben, werden wir es für einige Zeit unterstützen (ich glaube, Matt sagte mehrere Jahre) und irgendwann würden wir aufhören.

Ich weiß nicht, ob dies in ein separates Problem ausgegliedert werden muss oder nicht, aber ich möchte meine Unterstützung für die Idee von @wpmark zum Neuinstallationen von WordPress 5.0 zu aktivieren und als anzubieten eine Option für Benutzer beim Upgrade (es sei denn, das Classic Editor-Plugin oder eine andere "Deaktivierungs" -Funktion wird verwendet).

Wenn Sie es lesen möchten, finden Sie meine Gründe dafür in einem Blog-Beitrag, den ich geschrieben habe. Dies ist eine Kombination aus der großen Änderung der Benutzeroberfläche für meine Kunden und den Codeänderungen, die möglicherweise erforderlich sind, um Gutenberg ordnungsgemäß zu unterstützen (welche in Bei meinen Kunden gibt es möglicherweise kein Budget für).

Es fühlt sich so an, als wäre Gutenberg großartig für Leute, die WordPress noch nicht kennen, ein neues Blog installieren und loslegen. Und es wird großartig für Leute sein, die ein Upgrade durchführen und denken "Yay - neuer Editor - das werde ich bitte haben". Aber für andere wird es ein großer Schock sein. In einigen Anwendungsfällen ist GB möglicherweise keine gute Schnittstelle zum Bearbeiten eines benutzerdefinierten Beitragstyps, oder "Blöcke" sind möglicherweise kein gutes Datenmodell für die zu bearbeitenden Informationen.

Es scheint auch, dass die Stimmen von Entwicklern und Kleinunternehmern zu diesem Thema gehört werden müssen. Ich kenne viele kleine WordPress-Entwicklungsläden und diese Änderung wird aus all den Gründen, die in meinem Blogbeitrag beschrieben werden, schmerzhaft sein. Ich habe noch keinen Entwickler oder eine kleine Agentur sagen hören, dass die automatische Aktivierung von GB für aktualisierte Websites eine gute Idee ist. Ich habe viele Rückschläge bei der Idee gehört.

Diese Art von WordPress-Benutzern (und Entwicklungs-Shops wie meine sind große Unterstützer und Befürworter von WordPress, also hoffen wir wirklich, dass Sie zuhören) versteht ihre Benutzer gut, wir wissen genau, was wir auf WordPress aufgebaut haben und ob es passt ohne Änderungen gut in die GB-Benutzeroberfläche, und wir MÜSSEN die Möglichkeit haben, diese Änderung im Auftrag unserer Kunden zu verwalten.

Ich weiß, dass wir das Classic Editor-Plugin installieren können, und wir müssen dies möglicherweise noch tun, um die Möglichkeit auszuschließen, dass unsere Clients GB selbst aktivieren. Und wenn sich herausstellt, dass GB für aktualisierte Sites optional ist, muss natürlich Code vorhanden sein, um es im Core zu deaktivieren. Das würde @ smp303 (und andere, die es im Kern deaktivieren möchten) auch glücklich machen!

Ich hoffe, dass die Ansichten von Entwicklern und kleinen WordPress-Unternehmen wie meinem gehört werden, wenn der Plan zur Fusion mit dem Kern erstellt wird. Unser Lebensunterhalt kann von dieser Veränderung betroffen sein, und einige Menschen haben das Gefühl, dass diese Veränderung ihnen zu schnell aufgezwungen wird. Bitte geben Sie uns mehr Optionen für die Verwaltung des Übergangs und denken Sie daran, dass GB nicht für jeden das Richtige sein wird, wenn es zum ersten Mal zum Kern hinzugefügt wird.

Ein Filter im WP-Kern oder eine Konstante für wp-config.php scheint zwei solide Optionen zu sein.

Echoing @rosswintle und sein ausgezeichneter Blog-Beitrag, der oben verlinkt ist: Wir sind eine von vielen, vielen Agenturen, die benutzerdefinierte Felder und Metaboxen (insbesondere ACF) verwenden, um ein wirklich reichhaltiges Bearbeitungserlebnis zu bieten. "WordPress als Plattform" war das Versprechen, und das haben wir alle in den letzten Jahren getan.

Es muss einen Weg geben, Gutenberg für diejenigen zu aktivieren, die es wollen, aber es nicht für diejenigen durchzusetzen, die es nicht wollen. Ich bin mir ziemlich sicher, ob dies im Code oder über ein Plugin geschieht. Als jemand, der mehr als 50 WordPress-Sites über eine Verwaltungskonsole verwaltet, wäre eine Massen-Plugin-Installation zum Deaktivieren von Gutenberg praktischer (wenn weniger Geek-Sinn). aber meh, solange es geht. Sogar eine Einstellungsoption im Dashboard wäre in Ordnung, IMO - eine Standardeinstellung von "Gutenberg: Aus" noch besser ...

Ross 'Aussage über rückwärts passende Stellen mit Gutenberg ist ebenfalls gültig. Praktisch jeder, der für Kunden baut, weiß, dass die überwiegende Mehrheit sein Budget für den Start ausgibt und danach kein Budget mehr hat. Gutenberg nachrüsten, Kunden neu schulen, eine andere Benutzeroberfläche - zu denken, dass jeder außer Entwicklern und Geschäftsinhabern dafür bezahlen wird, ist Fantasieland.

Ich möchte nur die Gefühle von @ smp303 , @dmje und @rosswintle wiedergeben.

Die Möglichkeit, eine einfache Aktion in functions.php auszuführen, um Gutenberg zu deaktivieren, scheint die einfachste und naheliegendste Aufgabe zu sein.

Ich kann nicht anders, als das Gefühl zu haben, dass der Plugin-Ansatz gewählt wurde, um es ein wenig schwieriger zu machen, Gutenberg zu umgehen, als es sein muss.

Ich weiß, dass das Kernteam Gutenberg viel Mühe gegeben hat, aber sein Erfolg sollte von seinen Verdiensten abhängen, nicht von der Einschränkung der Fähigkeit, dies zu vermeiden. Denken Sie außerdem daran, dass WP-Entwickler für einen völlig neuen Editor entwickeln müssen, lernen, zu reagieren und dennoch Legacy-Inhalte zu entwickeln und zu warten - der Overhead ist RIESIG.

Ich möchte dies ebenfalls wiederholen - ich möchte auch die Option, den Gutenberg-Editor über Code und nicht über das Plugin zu deaktivieren.

Siehe auch dieses Trac-Ticket, das erstellt und jetzt als wontfix : # WP43068 geschlossen wurde

Per @ dd32 in https://core.trac.wordpress.org/ticket/43068#comment : 6

Ich glaube nicht, dass wir eine Konstante dafür unterstützen und stattdessen einfach die Leute auf das Plugin und vielleicht einen mu-plugin Wrapper dafür hinweisen, einfach weil das vorhandene Plugin nicht nur ein Schalter ist, sondern es geht Code einbeziehen, der nicht im Kern verwendet wird.

WordPress hat versucht, sich von Konstanten zu entfernen, da sie später sehr schwer zu ändern sind. "Oh, ich möchte Gutenberg, warum ist es deaktiviert? Oh, mein zufälliges SEO-Plugin (oder Ex-Entwickler) dachte, ich würde es nicht tun." Ich will es und habe es gewaltsam deaktiviert. Großartig. Wen kann ich jetzt dazu bringen, das Problem für mich zu beheben?

Ich kann sehen, warum manche Leute es deaktivieren möchten, aber ich kann nicht sehen, dass es so gemacht werden muss.

Ich denke, wir können dies sicher als wontfix , was sich später ändern kann (und wir werden es dann erneut besuchen), aber ich erwarte es nicht.

Vielen Dank für das Feedback an alle. Ich verstehe, dass die Entscheidung, das Classic Editor- Plugin für die vollständige Deaktivierung des Blockeditors zu benötigen, kontrovers diskutiert wird. Daher möchte ich über die verschiedenen Optionen sprechen.

In den kommenden Jahren wird das "Block" -Konzept für die Verwaltung von Standortdaten zur primären Methode zum Nachdenken, Auslegen, Interagieren und Bearbeiten von Daten. Der Blockeditor in WordPress 5.0 ist der erste große Schritt in diese Richtung. Der Fokus auf die Gutenberg-Anpassung in diesem Jahr ist neben dem Gutenberg-Thema der nächste Schritt.

Natürlich wird nicht jeder zu 100% für den Blockeditor bereit sein, wenn WordPress 5.0 ausgeliefert wird. Das ist eine praktische Realität, die jedem bekannt ist, und wir möchten den Menschen keine Möglichkeit geben, auf WordPress 5.0 zu aktualisieren. In diesem Sinne gibt es je nach Anwendungsfall verschiedene Möglichkeiten, Gutenberg zu deaktivieren.

Wenn Sie Meta-Boxen registrieren, die nicht mit dem Block-Editor funktionieren, können Sie diese Meta-Box einfach

In ähnlicher Weise wird diskutiert, ein ähnliches Flag für CPTs (# 2457) hinzuzufügen, damit CPTs, für die die Blockeditorfunktion nicht erforderlich ist, dieses Flag deaktivieren können.

Dies sind die beiden wichtigsten langfristigen Anwendungsfälle zum Deaktivieren des Blockeditors - Situationen, in denen er nicht funktioniert oder nicht zu den Verwendungsmustern passt.

Lassen Sie uns vor diesem Hintergrund über die nächsten Jahre nachdenken, wie sich WordPress möglicherweise entwickeln wird (beachten Sie, dass ich hier sehr stark in eine Kristallkugel blicke - Dinge auf dieser Liste werden nicht unbedingt in dieser Reihenfolge, in diesem Zeitrahmen oder in dieser Reihenfolge geschehen sogar überhaupt - es ist nur ein potenzielles Szenario, das stark davon abhängt, wie die WordPress 5.0-Version funktioniert.

• Der Customiser verwendet das Blockkonzept für alles. Für 99% der neuen Sites sind die Blöcke das einzige, was zum Erstellen ganzer Sites benötigt wird. Bei der Blockmanipulation werden Websites erstellt.
• Neue Themen werden sich rund um Baustellen ausschließlich aus Blöcken entwickeln. Die Standard-WordPress-Benutzererfahrung besteht aus Blöcken.
• Gleichzeitig beginnt wp-admin mit der Übernahme der von Gutenberg bereitgestellten JavaScript-App-Oberfläche. Ein Wechsel zum Classic Editor ist natürlich weiterhin möglich, passt aber nicht zum Rest der WordPress-Oberfläche.

Ich werde wiederholen, dass dies im Laufe mehrerer Jahre geschehen wird. Es wird Plugins wie Classic Editor geben, um die älteren Schnittstellen wiederherzustellen, aber es wird nicht unbedingt möglich sein, diese Schnittstellen in Core zu verwalten. Es ist zwar eine vernünftige Option, den Blockeditor in WordPress 5.0 zu deaktivieren, aber Sie würden Ihren Clients einen großen Nachteil erweisen, wenn Sie WordPress 5.5 oder 6.0 verwenden und weiterhin den klassischen Editor verwenden würden. Um ein Beispiel zu nennen: So wie sich die Best Practices für das Site-Layout von Tabellenlayouts zu mehreren Iterationen von CSS-Layouts und jetzt zu Rasterlayouts entwickelt haben, entwickeln sich auch Best Practices für die WordPress-Entwicklung.

Um auf die ursprüngliche Frage zurückzukommen: Eine einzelne codebasierte Option zum Deaktivieren des Blockeditors ist keine praktikable langfristige Lösung. Sie kann nicht erweitert werden, um geeignete Optionen für die zukünftige Entwicklung von WordPress Core bereitzustellen. Sie ist wirklich ein schlechter Dienst an alle hier, wenn wir diese Option schaffen würden. Das Classic Editor-Plugin kann sich jedoch weiterentwickeln, um in jedes Paradigma der Zukunft zu passen. Es bietet eine entspanntere Umgebung, in der es speziell entwickelt werden kann, um die Bedürfnisse der Leute zu erfüllen, die es benötigen, anstatt sich an die allgemeineren Bedürfnisse der gesamten WordPress-Welt anpassen zu müssen.

Das Problem mit dem Gutenberg-Editor sind nicht Blöcke oder das Konzept von Blöcken - es ist, dass der Editor selbst kein guter ist. Es ist derzeit um ein Vielfaches verwirrender als der vorhandene Editor - der selbst alles andere als perfekt ist. Und wenn wir uns der Zeit nähern (voraussichtlich im April, denke ich?) Und die Leute immer mehr Bedenken äußern, lautet das Feedback nie "Sie haben Recht, so wollen wir das angehen", so wie Sie es getan haben oben "Nun, das passiert, also steigen Sie besser ein."

Das Interesse an der Deaktivierung von Gutenberg, zumindest mein Interesse, ist nicht die Zukunft von Blöcken gegen Widgets und die langfristige Roadmap des Customizers - es ist, dass der eigentliche Editor wirklich scheiße ist. Ich will es nicht benutzen. Meine Kunden wollen nicht verwenden. Es ist keine schöne Sache zu benutzen. Und der Grund, warum es nicht sehr gut ist, ist das Grundkonzept, dass jeder Absatz und jeder Text ein "Block" ist, und das hassen wir alle.

Aus diesem Grund möchten wir dies deaktivieren. Nach Gutenberg zu gehen ist für viele eine äußerst unangenehme Erfahrung und sowohl für die Kunden als auch für die Entwicklung äußerst beunruhigend.

Die zukünftige Roadmap ist mir egal. Es ist mir wichtig, meine Kunden und mein Geschäft zu verlieren, und bisher scheint niemand im Gutenberg-Team diese Besorgnis zu teilen. Was sollen wir tun, wenn die Kernplattform unseres Einkommens mit Volldampf in eine Richtung geht, in die wir nicht wollen? Und was sollen wir tun, wenn unsere Bedenken im Namen der "zukünftigen Roadmap" beiseite geschoben werden?

Ich bin alle dafür, Widgets, Einfügungen und Shortcodes in ein universelles Blocksystem zu ersetzen. Ich denke, das ist eine gute Idee - ich stecke dahinter. Ich versuche gerne, den Benutzern mehr Kontrolle über ihr Site-Layout zu geben - warum nicht?

Ich mache mir Sorgen, weil das eigentliche Tool zur Erstellung von Inhalten derzeit ein heißes Durcheinander ist, das kein einziger meiner Kunden (über 300) verwenden möchte. Sie sehen es tatsächlich entsetzt an und all die netten kleinen YouTube-Demos und -Videos und aufgezeichneten WordPress-Gespräche zeigen ihnen nur, wie sehr sie es hassen.

Sie wollen nicht in Blöcken schreiben! Sie wollen keinen blockbasierten Editor! Sie alle hassen das - sie möchten, dass es wie MS Word oder Google Docs funktioniert, weil sie das normalerweise verwenden, um Dinge zu schreiben. Das wollen sie.

Wie kann ich ihnen das geben, wenn WordPress nur Blöcke in die Kehle schieben will?

Die einzige Alternative, die ich habe, ist, Gutenberg auszuschalten. Ich möchte also eine zuverlässige Methode dafür. Zumindest bis dieser Entwicklungszug zur Besinnung kommt und etwas schafft, das es tatsächlich wert ist, verwendet zu werden - nicht als Blockmechanismus, sondern als wirklicher verdammter Editor.

Ich brauche einen funktionalen Editor, in dem der Text NICHT auf Blöcken basiert. Wann wird Gutenberg das bereitstellen? Beantworten Sie das und ich sage Ihnen, wir brauchen keine Möglichkeit mehr, Gutenberg zu deaktivieren. Haben Sie bis dahin ein gewisses Einfühlungsvermögen und kümmern Sie sich um die Millionen von WordPress-Benutzern und -Unternehmen und bieten Sie eine Möglichkeit, Gutenberg auszuschalten, auf die wir vertrauen können - das bedeutet Code, kein anderes Plugin.

Es muss eine Möglichkeit geben, Gutenberg auf Codeebene zu deaktivieren. Bitte tun Sie uns diese Höflichkeit. Geben Sie keine weitere Plattitüden-Antwort - geben Sie uns nur eine Möglichkeit, das verdammte Ding auszuschalten, wenn alles seitwärts geht.

@pento , Jahrelang gab es eine einfache Option pro Benutzer, um tinymce zu deaktivieren, und während viele Entwicklungen tinymce-spezifisch waren, hatte niemand vorgeschlagen, die Option zu entfernen.

Ich habe noch niemanden gehört, der vorschlägt, diese Option als Teil von gutenberg zu entfernen, und es macht für mich nicht viel Sinn, dass Sie von gutenberg zu einem textbasierten Editor wechseln können, ohne den aktuellen tinymce-Editor weiter verwenden zu können. Wenn man bedenkt, dass tinymce weiterhin als Teil des Text-Widgets und der wp_editor-API unterstützt werden muss, ist es weder für die Entwicklung noch für die Benutzeroberfläche sinnvoll, Benutzer zur Installation von Plugins zu zwingen, um aktiv gewartete Kern-APIs verfügbar zu machen.

Auch wenn Sie aus irgendeinem Grund diese Benutzeroption nicht so ändern möchten, dass sie eine Einstellung für Gutenberg enthält, sollte es sich bei einem Softwareentwicklungs-POV um eine API handeln, die Teil von Gutenberg ist und als gepflegt wird, solange Sie das Deaktivieren von Gutenberg unterstützen Teil seiner Entwicklung. Wie das Importer-Plugin zeigt, sind selbst "Core" -Plugins nicht mehr synchron und werden unbrauchbar, hauptsächlich weil sie nicht Teil der eigentlichen Core-Entwicklung sind.

Die Weigerung, eine solche API als Teil des Kerns beizubehalten, bedeutet, dass es keine Verpflichtung gibt, Menschen die Möglichkeit zu geben, gutenberg auch in 5.1 zu deaktivieren, eine Veröffentlichung, die voraussichtlich im Jahr 2018 erscheinen wird. Sie können nicht erwarten, dass Menschen in der Lage sind, mittelfristige Pläne mit solchen zu erstellen Unsicherheit.

@ Pento Danke für die lange und detaillierte Antwort. Ich denke nicht, dass dies nur ein Problem ist, wie Gutenberg deaktiviert werden kann, sondern auch, ob und wie es standardmäßig aktiviert wird. Ich denke, Ihre Antwort deckt beides ab, aber es beunruhigt mich auch.

Ich für meinen Teil bin sehr überrascht , dass die Implikation hier und anderswo ist , dass der klassische Editor von WP und der „Classic Editor“ Plugin wird es fügen Sie in wieder entfernt wird. Ist das ein korrektes Verständnis? Das scheint mir eine wirklich schlechte Idee zu sein, aber ich kann momentan nicht artikulieren, warum.

@markkap macht auch einen guten Punkt über das Text-Widget und die wp_editor API - wie werden diese im Kern beibehalten, wenn TinyMCE entfernt wird?

Und das Bearbeiten von meta_box / CPT-Code, um das Laden von Gutenberg zu verhindern, ist in Ordnung, aber eigentlich bin ich ein einsamer Freiberufler, der wahrscheinlich etwa 60-80 Websites für Kunden erstellt. Ich werde nicht den ganzen Code bearbeiten und viele dieser kleinen Kunden werden mich nicht dafür bezahlen wollen. Ich würde es VIEL vorziehen, wenn dies ein Opt-In als ein Opt-Out ist: Gutenberg sollte aktiviert sein, wenn ich die Unterstützung dafür erkläre. Die Standardeinstellung ist hier wiederum rückwärts. Sie zwingen die Leute, Änderungen vorzunehmen, um zu verhindern, dass sich Dinge ändern / brechen (ich freue mich, bei Bedarf ein separates Problem dafür anzusprechen).

Sie würden Ihren Kunden einen großen Schaden zufügen, wenn Sie WordPress 5.5 oder 6.0 verwenden und weiterhin den klassischen Editor verwenden würden

(Ich benutze auch meine Kristallkugel) Ich glaube nicht, dass ich dem unbedingt zustimmen muss. Ich denke, es ist unmöglich zu sagen, dass Gutenberg und Blöcke in Zukunft ein besseres Bearbeitungserlebnis für alle Anwendungsfälle darstellen werden.

Ich bin auch ein bisschen verwirrt über die Natur der "Blöcke". Dies ist wahrscheinlich eine Terminologiesache, impliziert jedoch, dass eine oder mehrere der folgenden Aussagen zutreffen:

• Es gibt einen Paradigmenwechsel, um den ich mich bemühe oder den ich falsch verstanden habe
• Das neue Paradigma wird nicht sehr gut kommuniziert
• Die Art und Weise, wie Entwickler wie ich WordPress verwenden, um Content-Management-Tools für Kunden zu erstellen, ist nicht genau bekannt
• Die Art und Weise, wie Entwickler wie ich WordPress verwenden, um Content-Management-Tools für Kunden zu erstellen, ist gut verstanden und wird ignoriert

Du hast gesagt:

In den kommenden Jahren wird das "Block" -Konzept für die Verwaltung von Standortdaten zur primären Methode zum Nachdenken, Auslegen, Interagieren und Bearbeiten von Daten.

Das macht mir ein wenig Angst und ich werde darauf zurückkommen.

Die Gutenberg-Seite unter https://wordpress.org/gutenberg scheint dieser Beschreibung nicht zuzustimmen. Es nennt Blöcke "Inhaltsblöcke" und erklärt Folgendes:

[Blöcke] sind eine einheitliche Methode zum Stylen von Inhalten

_Hinweis: Ich bin ein Back-End-Entwickler und denke sehr viel über Daten nach: Welche Daten sind in einem System vorhanden, welche Eigenschaften haben Datenelemente, wie hängen Datenelemente zusammen und wie werden Daten abgefragt und bearbeitet.

Mein Verständnis ist, dass "Blöcke" Inhaltsbereiche sind, die verwendet werden können, um einen Beitrag, eine Seite oder was auch immer zu umfassen. Sie werden hauptsächlich in Post-Inhalten in der Datenbank mithilfe von HTML-Kommentaren gespeichert, um die Abwärtskompatibilität zu gewährleisten. Sie können jedoch auch Blöcke konfigurieren, um Daten an anderen Orten wie post_meta zu speichern. (Hinweis: Dies fühlt sich wie ein Hack an, um Leute wie mich mit dem Einfügen von Metadaten in Blöcke zufrieden zu stellen. Es fühlt sich nicht nach einer durchdachten Entwurfsentscheidung über die Art der Blöcke an.)

Ihre Implikation in dem, was Sie sagen, ist, dass Blöcke _jedes_ fahren sollen. Sie sind, wie "Site-Daten" verwaltet werden. Dies und andere Dinge, die Sie gesagt haben, implizieren, dass Blöcke nicht nur Abschnitte des Inhalts sind, sondern eine Art Benutzeroberflächengerät, das mit allem verbunden werden kann: Site-Optionen, Anpassungen, Metadaten zu Posts, Widgets, Menüs, Benutzerprofilfelder, alles.

Ich denke, wir müssen die Natur eines "Blocks" klären.

Wenn das, was Sie implizieren, richtig ist, dann denke ich, dass dies ein grundlegendes Missverständnis darüber darstellt, wie WordPress von Leuten wie mir verwendet wird. Und ich denke, dieser Ansatz wird mich dazu bringen, aus dem WordPress-Zug auszusteigen und für einige Projekte ein alternatives CMS zu finden. WordPress wird für Blogs und Magazine gedacht sein, aber viele der Möglichkeiten, die benutzerdefinierte Beitragstypen bieten, werden wegfallen.

Metadaten in WordPress sind wie beschrieben: Daten über Daten. Diese Informationen verleihen Inhaltselementen zusätzliche Eigenschaften. Metadaten sind NICHT Inhalt. Und IMO ist nicht dazu geeignet, in "Blöcken" platziert zu werden, wie ich sie verstehe. Einige der von mir erstellten Beitragstypen haben keinen anderen Inhalt als einen Titel: Sie haben nur Eigenschaften / Felder / Metadaten.

Wenn das, was Sie hier beschreiben, wahr ist, frage ich mich, warum der Post-Status kein Block ist. Warum werden Kategorien und Tags nicht blockiert? Warum ist der Auszug kein Block?

Ich persönlich denke nicht, dass dies "Blöcke" sind, wie ich sie verstehe, weil sie nicht zufrieden sind, sondern Informationen über den Inhalt. Ihre Position in der Benutzeroberfläche ist wichtig. Es ist wichtig, wie der Benutzer mit diesen Informationen interagiert.

Einige der von mir erstellten post_meta sind gleich.

Ich (denke ich werde) mag Gutenberg und Blöcke zum Erstellen von Posts und Seiten. Aber entweder verstehe ich "Blöcke" falsch oder das Projekt hat falsch verstanden, wie Leute Daten verwenden, die nicht für "Blöcke" geeignet sind.

Ich bin froh, dass dies geklärt wurde, und ich bin bereit, mich überzeugen zu lassen. Aber Blöcke als "primäre Methode zum Nachdenken, Auslegen, Interagieren und Bearbeiten von Daten" zu haben, scheint nicht zu den Dingen zu passen, die ich in WordPress erstellt habe.

Wenn ich dies hier auf das Hauptproblem zurückziehe, glaube ich nicht, dass der klassische Editor aus dem Kern entfernt werden sollte, und deshalb möchte ich nicht, dass meine Benutzer Gutenberg automatisch aktivieren, wenn ich sie auf Version 5 aktualisiere .0.

@rosswintle Sie haben das in jeder Hinsicht absolut perfekt zusammengefasst und so ziemlich jeder Entwickler, mit dem ich gesprochen habe, fühlt sich genauso. Ich hoffe nur, dass jemand auf diese Bedenken hört und wir für jeden eine Lösung finden können.

Hinzufügen von +1, um Gutenberg zum Standard-Bearbeitungserlebnis nur für Neuinstallationen zu machen.

Wie @rosswintle bereits sagte, gibt es Hunderttausende von WP-Entwicklern mit Kunden, die nicht daran interessiert sind, für die Rückkehr zum Classic Editor Zeit zu zahlen. Lassen Sie vorhandene Websites unverändert fortfahren (stellen Sie natürlich den neuen Editor zur Verfügung, wechseln Sie aber auch zurück, wenn dies nicht den Erwartungen entspricht) und führen Sie Gutenberg mit neuen Installationen aus.

Denken Sie an alle Kleinunternehmer mit WP-Sites. Websites, die vor Jahren entwickelt wurden und nur ohne Neuentwicklung gut laufen. Plötzlich wird diesen Benutzern Gutenberg aufgezwungen und sie müssen nicht nur eine neue Benutzeroberfläche erlernen (diese Benutzer sind möglicherweise überhaupt nicht sehr technisch versiert und Gutenberg ist für sie möglicherweise intuitiver oder nicht intuitiver), sondern es kann auch verhindern sie von der Bearbeitung ihrer Website-Inhalte.

Es ist auch der Ruf von WordPress zu berücksichtigen, bei dem wir immer noch versuchen, die Meinung abzuschütteln, dass WP voller Sicherheitslücken ist. @wpmark und ich hatten Anfang der Woche sogar ein zufälliges Gespräch mit jemandem, bei dem eines der ersten Dinge, die sie erwähnten, als sie wussten, dass wir mit WordPress entwickelt haben, "Wie sichern Sie Ihre Websites?" war.
Besteht das Risiko, dass Benutzer ihre Websites als defekt oder schwierig zu bearbeiten empfinden? Wie wird sich das in den kommenden Jahren auf den Ruf von WP auswirken?

Ich denke definitiv, dass neue Sites Gutenberg-fähig sein sollten, und dies kann eine große Funktion sein, die während der 5-minütigen Installation von den Dächern gerufen wird, aber bitte lassen Sie ältere Sites so wie sie sind fortfahren.

Ich wollte nicht, dass die Frage, Gutenberg nur für Neuinstallationen einzuschalten, in dieser ebenfalls berechtigten Sorge um die einfache Deaktivierung verloren geht. Hier ist ein spezielles Problem dafür https://github.com/WordPress/gutenberg/issues/4423

Bitte fügen Sie Ihre Gedanken, Stimmen und Ihr Feedback hinzu. @joffff @wpmark @rosswintle @markkap @dmje

Spot on @rosswintle.

Gutenberg sollte eingeschaltet sein, wenn ich die Unterstützung dafür erkläre. Die Standardeinstellung ist hier wiederum rückwärts. Sie zwingen die Leute, Änderungen vorzunehmen, um zu verhindern, dass sich Dinge ändern / brechen (ich freue mich, bei Bedarf ein separates Problem dafür anzusprechen).

Könnte dem nicht mehr zustimmen, wenn ich es versuchen würde. Ich glaube nicht, dass die Jungs und Mädchen, die Gutenberg drängen, das verstehen.

Nur um das zu ergänzen, was Ross aus unternehmerischer Sicht gesagt hat (er hat die kleine Seite der Freiberufler gut abgedeckt): Die Standorte, die ich für eine multinationale SPS verwalte, sind wie Öltanker. Grundlegende Änderungen wie diese dauern sehr lange. Durch Tests müssen sie durchgeführt werden, und selbst dann müssen sie in einen wöchentlichen Veröffentlichungsplan aufgenommen werden, der Teil eines detaillierten Codeüberprüfungs- und Genehmigungsprozesses ist.

Dies wird mir und meinem Team massive Kopfschmerzen bereiten. Wahrscheinlich bleiben wir am Ende auf 4.9.x, bis wir Gutenbergs Auswirkungen nach der Veröffentlichung des endgültigen RC für 5.0.0 gründlich überprüfen konnten. Dies kann Wochen oder sogar Monate dauern. Dies ist keine schnelle Lösung.

Ich bin auch ein bisschen verwirrt über die Natur der "Blöcke". Dies ist wahrscheinlich eine Terminologiesache, impliziert jedoch, dass eine oder mehrere der folgenden Aussagen zutreffen:

• Es gibt einen Paradigmenwechsel, um den ich mich bemühe, oder ich habe etwas falsch verstanden.
• Das neue Paradigma wird nicht sehr gut kommuniziert.
• Die Art und Weise, wie Entwickler wie ich WordPress verwenden, um Content-Management-Tools für Kunden zu erstellen, ist nicht genau bekannt.
• Die Art und Weise, wie Entwickler wie ich WordPress verwenden, um Content-Management-Tools für Kunden zu erstellen, ist gut verstanden und wird ignoriert.

Ich habe absolut das Gefühl, dass es das letztere ist. Ich habe keinen Zweifel daran, dass die Mitglieder des Gutenberg-Teams wissen und verstehen, wie die meisten professionellen Entwickler Websites mit WordPress erstellen.

Dieser Ansatz ist jedoch völlig inkompatibel und bewegt WordPress in Richtung eines Site-Builder-Ansatzes, den Automattic benötigt, damit WordPress.com weiterhin gegen Unternehmen wie Squarespace, Wix et al.

WordPress kann nicht gleichzeitig ein Site Builder und ein professionelles CMS sein. Das geht einfach nicht. Es ist eine feine Linie zwischen den beiden gegangen, so dass Benutzer es durch Plugins in beide Richtungen bewegen können. (Auf dem Weg zu einem Site-Building mit Beaver Builder, Divi et al. Und zu einem professionellen CMS mit Plugins wie ACF und CMB). Jetzt ist jedoch klar, dass sich das CMS fest in Richtung Site Builder bewegt. Websites, die benutzerdefinierte Felder verwenden, sind verdammt.

Schließlich ist Ihr Punkt über Blöcke und die Datenbank genau richtig.

Ich denke, es deutet auf viele Probleme hin, die das WordPress-Team zuerst angehen sollte, bevor es sich mit Dingen wie Gutenberg befasst:

• Aktualisierung der Min-Version von PHP
• Implementieren nativer semantischer Daten (über benutzerdefinierte Felder) und Ändern der DB-Struktur, um dies zu berücksichtigen.

Abschließend haben die Jungs von Statamic gezeigt, wie dies mit ihrem neuen Bard-Feldtyp hätte gehandhabt werden sollen. Eine optionale Editor-Oberfläche, die dieselben Probleme wie Gutenberg löst, jedoch viel intelligenter und weniger störend.

Es macht keinen Sinn, meine Meinungen zu wiederholen, sie wurden bereits oben geäußert. Ich stimme dem allgemeinen Konsens zu - es sollte eine in Betracht gezogene Option sein, Gutenberg zu aktivieren, das beim Wechsel von 4.x auf 5.0 nicht obligatorisch ist.

Da die meisten Entwickler hier eine Reihe von Kunden betreuen, von denen einige sehr technisch versiert sind, andere nicht, aber wenn ich sie in diese Richtung drücke, wird dies meiner Meinung nach nur bei der Mehrheit Verwirrung stiften.

In Bezug auf alles, was brechen könnte; Aus Kundensicht haben sie bereits ein Budget für die bereitgestellte Lösung erstellt und ausgegeben. Sie werden nicht zu schätzen wissen, dass sie möglicherweise ein anderes Budget für den Support oder zur Behebung von Problemen benötigen, die durch etwas verursacht wurden, das nicht von ihnen oder mir stammt.

Zwischen dem Entwickler / Designer oder Anbieter der sorgfältig überlegten Lösung, die ihm gegeben wurde, sollten der Kunde und der Anbieter entscheiden, wann eine so große Änderung aktiviert werden soll, ohne dass etwas Obligatorisches eingehalten werden muss.

Nur um es da rauszuwerfen. Obwohl WordPress nicht strikt dem semantischen Versionsansatz folgt, ist Version 5.0.0 eine bahnbrechende Änderung.

Wenn Automattic nicht bereit ist, seine Strategie in Bezug auf Gutenberg zu ändern - und seien wir ehrlich, das wäre das Richtige -, dann ist die einzige andere Option, 4.9 zu einer LTS-Version zu machen.

Auf diese Weise könnten Sicherheitspatches für die nächsten 5 Jahre auf 4.9 angewendet werden. Das ist genug Zeit für Website-Entwickler, um ihre Websites nach Gutenberg oder vollständig von WordPress zu migrieren (was meiner Meinung nach die beliebteste Option sein wird).

Nun, jeder schreibt hier gerne lange Kommentare. 😉 Es ist Abend für mich, also werde ich nicht alles ansprechen, aber ich möchte ein paar Themen ansprechen.

Ich bin sehr überrascht, dass sowohl hier als auch anderswo impliziert wird, dass der klassische Editor aus WP entfernt wird und das Plugin "Klassischer Editor" ihn wieder hinzufügt. Ist dies ein korrektes Verständnis?

Das stimmt nicht In meinem vorherigen Kommentar habe ich erwähnt, dass Meta-Boxen und CPTs automatisch auf den Classic Editor zurückgreifen können - dies wäre nicht möglich, wenn der Code des Classic Editors entfernt würde. 🙂

TinyMCE wird von Gutenberg verwendet, um die bearbeitbaren Textblöcke mit Strom zu versorgen - das geht nirgendwo hin. Funktionen wie wp_editor() können in Core relativ einfach verwaltet werden, ohne dass sie auf ein Plugin verschoben werden müssen - ich würde erwarten, dass sie auf unbestimmte Zeit weiter funktionieren.

Ihre Implikation in dem, was Sie sagen, ist, dass Blöcke alles antreiben sollen. Sie sind, wie "Site-Daten" verwaltet werden. Dies und andere Dinge, die Sie gesagt haben, implizieren, dass Blöcke nicht nur Abschnitte des Inhalts sind, sondern eine Art Benutzeroberflächengerät, das mit allem verbunden werden kann: Site-Optionen, Anpassungen, Metadaten zu Posts, Widgets, Menüs, Benutzerprofilfelder, alles.

Genau das sage ich. Nun, Metadaten sind kein Block, obwohl sie möglicherweise darüber informieren, wie ein Block verwendet oder angezeigt wird.

Ich denke, wir müssen die Natur eines "Blocks" klären.

Sicher. Ein Block ist ein HTML-Knoten, der mit anderen Blöcken zusammenpasst. Es gibt eine Reihe von APIs, die das Arbeiten mit Blöcken einfach und angenehm machen, aber darauf kommt es an.

Ein Block ist nicht:

• Ein in post_content gespeicherter HTML-Knoten (obwohl einige Blöcke diese Speichermethode verwenden).
• Statisch (obwohl einige Blöcke sind).
• Dynamisch generiert (obwohl einige andere Blöcke vorhanden sind).

@rosswintle , Sie haben einige Male Metadaten erwähnt, und ich möchte klarstellen, worauf Sie sich dort beziehen. Können Sie mir einige Beispiele geben, die Sie als Metadaten betrachten?

Wenn das, was Sie hier beschreiben, wahr ist, frage ich mich, warum der Post-Status kein Block ist. Warum werden Kategorien und Tags nicht blockiert? Warum ist der Auszug kein Block?

Nur ein Vorschlag und ich bin mir nicht sicher, ob es sich um eine Themenoption handelt oder handeln sollte, aber warum nicht unter add_theme_support (), da die meisten neu entwickelten Funktionen in der Vergangenheit waren?

Auf diese Weise könnten Sicherheitspatches für die nächsten 5 Jahre auf 4.9 angewendet werden.

Angesichts der Tatsache, dass WordPress 3.7 vor etwas mehr als 3 Jahren veröffentlicht wurde und die letzte Sicherheitsversion vor 6 Wochen veröffentlicht wurde, kann man davon ausgehen, dass WordPress 4.9 noch lange Sicherheitspatches erhalten wird.

@eirichmond : add_theme_support() möglicherweise für den Fokus auf die Gutenberg-Anpassung benötigt, aber die meisten Themen unterstützen blockeditorbasierte Inhalte ohne Änderungen.

add_theme_support () wird möglicherweise für den Gutenberg-Anpassungsfokus benötigt, aber die meisten Themen unterstützen blockeditorbasierte Inhalte ohne Änderungen

@pento Was genau ist der Schwerpunkt der Gutenberg-Anpassung? Was bedeutet das? Sie erwähnen, dass _most_ Themes blockbasierten Inhalt unterstützen. Können Sie daher angeben, warum ein Theme diesen nicht unterstützt?

Ich sehe Themen mit Seitenleisten, die bestimmte Blöcke nicht unterstützen, da der Block anzeigt, dass er die volle Breite hat, z. B. Titelbild.

Was genau ist der Schwerpunkt der Gutenberg-Anpassung? Was bedeutet das?

Matt sprach im State of the Word darüber - die drei Schwerpunkte für dieses Jahr sind:

• Gutenberg-Herausgeber
• Gutenberg-Anpassung
• Gutenberg-Thema

Gutenberg-Editor ist das, was in WordPress 5.0 kommt. Die Gutenberg-Anpassung beginnt gerade erst und befasst sich mit der Anpassung von Websites und deren Funktionsweise im Blockparadigma. Das Gutenberg-Thema wird das diesjährige Standardthema sein und voraussichtlich im Laufe des Jahres beginnen.

Können Sie daher angeben, warum ein Thema es nicht unterstützen würde?

Hoffentlich funktionieren alle Themen einfach. 🙂 Mit einigen Blöcken ist CSS verknüpft (Titelbilder sind dort ein gutes Beispiel), sodass die Möglichkeit besteht, dass etwas nicht genau richtig aussieht. Es gibt jedoch nichts, was dazu führen würde, dass ein Thema nicht mehr funktioniert.

Kann ich die Leute daran erinnern, dass Gutenberg kein Automattic-Projekt ist, lassen Sie uns die Anstrengungen und die Arbeit von Nicht-Automattikern, die dazu beitragen, nicht abwerten

Ich bin mir auch immer noch nicht sicher, warum ein Plugin nicht ausreicht. Die Argumente, die ich gesehen habe, sprechen dafür, dass die Leute Gutenberg nicht mögen oder dass sie bereits einen Workflow eingerichtet haben, alle zuvor erwähnten Probleme und alle behoben durch Installieren und Aktivieren des klassischen Editor-Plugins.

Beachten Sie, dass das Links-Plugin auch Präzedenzfälle enthält.

Aber lassen Sie uns trotzdem konstruktiv sein:

Ich habe ein Upgrade auf WP 5.0 durchgeführt und Gutenberg hat meinen benutzerdefinierten Editor ersetzt. Ich mag es nicht. Ich brauche mehr Zeit mit Kunden

Was mache ich?

Installieren Sie das klassische Editor-Plugin und aktivieren Sie es, Problem behoben. Jetzt wird Gutenberg durch den klassischen Editor ersetzt, den wir in 4.9 haben

Nachteile?

Sie werden keine der neueren Gutenberg-Funktionen erhalten, und neue Funktionen in der Zukunft sind im klassischen Editor möglicherweise nicht sinnvoll. Wenn beispielsweise Zeilen- und Spaltenblöcke in 5.1 angekommen sind, sehe ich im klassischen Editor keinen Sinn

Ich habe viele Client-Sites, ich installiere und aktiviere nicht auf jeder Site. Was ist, wenn ein Client deaktiviert wird?

Verwenden Sie es als MU-Plugin:

• Legen Sie den Plugin-Ordner in wp-content/mu-plugins
• Legen Sie eine Datei in Ihrem Ordner mu-plugins , die Folgendes enthält:

<?php
require( 'classic-editor/classic-editor.php' );

Jetzt ist das Plugin immer geladen und kann nicht deaktiviert werden. Es sind keine weiteren Schritte außer dem Platzieren der Dateien erforderlich. Sie können die Datei und den Ordner dann einmal auf jede Site hochladen und müssen sich nicht erneut darum kümmern.

Lehren aus dem Classic Editor Plugin

In diesem Plugin gibt es viele hilfreiche Funktionen, um beispielsweise zu erkennen, ob Gutenberg aktiviert ist, und der Großteil davon besteht darin, Haken zu entfernen und zu ersetzen.

Es wird sogar ein Einstellungsbereich mit der Option hinzugefügt, sich für die "klassischen Editor-Links" zu entscheiden, sodass Sie anstelle von Gutenberg das erhalten, was Sie sehen, wenn das Gutenberg-Plugin aktiviert ist, das über den Link "klassischer Editor" im Beitragsbildschirm aktiviert ist gibt Ihnen 3 nicht 2 Optionen.

Ich empfehle dringend, dass sich die Leute das Plugin ansehen, es testen und sehen, wie es aufgebaut ist.

Denken Sie daran, wir sind eine Community und nicht die Themen eines Automattic-Produktteams. Wenn es kaputt geht, haben wir einen ganzen WP-Release-Zyklus, in dem wir es testen und reparieren können. Ich sehe viele Stakeholder in diesem Thread, die über die technischen Fähigkeiten verfügen, um das Plugin zu reparieren, und noch einige mehr. Wenn es wirklich eine so große Sache ist, dann bin ich sicher, dass jemand aufsteigen wird, genau wie die Leute, die am Kern arbeiten, aufgestiegen sind

@rosswintle , Sie haben einige Male Metadaten erwähnt, und ich möchte klarstellen, worauf Sie sich dort beziehen. Können Sie mir einige Beispiele geben, die Sie als Metadaten betrachten?

@ Pento Sicher:

Länderbeispiel:

Ein Beitragstyp "Land" mit einem Namen (Titel), einer Beschreibung (Inhalt) und dann:

• Population
• URL des Flaggenbildes
• Ranking (und andere Faktoren, möglicherweise in irgendeiner Weise codiert)
• verwandte "Communities" (Beziehungen zu Posts eines anderen Typs)

Siehe: http://peoplesunderthreat.org

Immobilienbeispiel:

Ein "Eigenschaftstyp" mit:

• Preis
• Art
• Anzahl der Räume
• Datum des Baus
  usw.

Ereignisbeispiel:

Ein "Ereignis" -Typ mit:

• Datum
• Zeit
• Wiederholungsdetails
• Standort
  usw

Es gibt viele.

Nachdem ich es aktiviert und ein bisschen damit gespielt habe, habe ich einige große Bedenken ... Ich werde mich vorerst auf das Hauptproblem konzentrieren:

WooCommerce bricht komplett zusammen ... als wäre es nicht einmal da, wenn ein Produkt bearbeitet wird. Und ich kann mir vorstellen, dass noch viele weitere Plugins komplett kaputt gehen werden. Was ist der Plan, um der Community zu helfen, kompatibel zu sein? Und wie lange werden wir noch?

@ Tomjn

Die Argumente, die ich alle gesehen habe, argumentieren, dass die Leute Gutenberg nicht mögen oder dass sie bereits einen Workflow eingerichtet haben

"mag nicht" ist möglicherweise der falsche Begriff. Ich denke, die Leute machen gute Argumente dafür, dass Gutenberg für viele Anwendungsfälle von WordPress nicht geeignet ist. Es geht nicht um Vorlieben oder Geschmack, sondern um Eignung.

Und Entwickler wollen nur Optionen dafür. Ich kann andere wichtige Funktionen wie Debugging, Code-Editoren, Multisite, automatische Updates und Post-Revisionen in wp-config.php umschalten. Einige Funktionen werden nur von Themen aktiviert, die sie mit add_theme_support . Warum können wir keine In-Code-Optionen haben, um Gutenberg auf die gleiche Weise umzuschalten, damit Entwickler einen Workflow verwenden können, der für eine so große Änderung geeignet ist?

Eines der Probleme hierbei ist, dass Entwickler (nicht unbedingt ich, aber andere) nicht das Gefühl haben, gehört zu werden, wenn sie Bedenken über Gutenberg äußern. Wenn Sie dies als Token-Geste hinzufügen, um ihnen zu helfen, können Sie sie ein bisschen mehr auf die Seite bringen. Auch wenn Sie aus eigenen philosophischen Gründen nicht der Meinung sind, dass dies das Richtige ist, betrachten Sie es als einen Olivenzweig, der Entwicklern angeboten werden kann, die nicht glücklich sind.

Beachten Sie, dass das Links-Plugin auch Präzedenzfälle enthält.

Das Links Plugin ist hier ein schlechtes Beispiel. Vorhandene Funktionen im Core wurden beibehalten, wenn Sie sie verwendet haben, und nur die Funktionen für Neuinstallationen entfernt (oder wenn Sie sie nicht verwendet haben).

Ich mag diesen Präzedenzfall.

Dafür wird in # 4423 argumentiert

Was mich wirklich bewegt, ist, dass die Kernentwickler und Matt davon ausgehen, dass die ganze Welt das "Blocks" -Konzept und den Gutenberg-Editor ohne Frage vollständig übernehmen wird. Ich denke, es ist alles schön und gut, aber dieser "unser Weg oder der hohe Weg" -Ansatz, den sie mit Gutenberg verwenden, ist nicht nur nicht benutzerfreundlich, sondern kann den Zustand von WordPress insgesamt ernsthaft beeinträchtigen.

Es gab im Laufe der Jahrhunderte viele wirklich großartige Ideen, die einfach nicht klebten, weil sie einfach nicht von den Massen adoptiert wurden. Betamax war ein weit überlegenes Format, aber es blieb einfach und VHS gewann. Was ist, wenn Gutenberg und Blöcke einfach nicht kleben? Was wird dann mit WordPress passieren?

Dann gibt es den Vertrauensfaktor. Die überwiegende Mehrheit der WordPress-Benutzer versteht nicht einmal, was WordPress ist. Sie benutzen es nur, weil die Marke WordPress beliebt ist, und egal wie man es betrachtet, WordPress ist für die meisten Menschen nur eine Marke. Marken leben und sterben im Vertrauen der Verbraucher.

Wenn das 5.0-Update endlich veröffentlicht wird und eine Million WordPress-Sites dies plötzlich dramatisch ändern, wie werden dann die Endbenutzer reagieren, die nichts über die WordPress-Welt wissen?

Die meisten meiner Kunden sind sozusagen "kaum in der Lage, einen Computer einzuschalten" oder wollen nur, dass das, wofür sie bezahlt haben, wie versprochen funktioniert. Dies sind die Leute, die WordPress vertrauten, um das zu tun, was es versprochen hatte. Wenn eines Tages dieses Versprechen aufgrund eines völlig neuen Formats für die Verwaltung des Inhalts ihrer Website gebrochen wird, ändert sich dies plötzlich. Dann wird ihr Vertrauen in WordPress gebrochen und die Leute werden einfach aufstehen und etwas fallen lassen, wenn sie ihm nicht mehr vertrauen.

Ich glaube, hier kommt der größte Teil der Besorgnis der Entwickler her. Wir erstellen großartige benutzerdefinierte WordPress-Sites, die genau so funktionieren, wie es unsere Kunden wollen, und jetzt wird aufgrund von Gutenberg alles "kaputt", und wir haben keine Möglichkeit, eine möglicherweise große Katastrophe zu verhindern.

Der einzige Zweck von Gutenberg besteht darin, den Anteil von WordPress Marke zu erhöhen, aber es kann sehr leicht genau das Gegenteil bewirken. Es kann tatsächlich Leute von WordPress vertreiben. Gutenberg könnte die neue Cola für WordPress werden, und WordPress ist nicht so groß wie Cola, dass es sich genauso erholen könnte wie Cola. Die Leute werden zu etwas anderem übergehen und nicht zurückblicken.

Sie fahren fort über "Es würde die Zukunft der Gutenberg-Adoption beeinflussen, bla, bla, bla", aber es ist wirklich so einfach. Entweder wird es jeder lieben und die Notwendigkeit, es entweder per Code oder Plugin zu entfernen, oder was auch immer irrelevant wird, oder Gutenberg wird einfach zu einer seltsamen Funktion, die niemand wirklich nutzt, wie Press This.

Nach dem derzeitigen Stand wird die Richtung entweder so sein, dass Gutenberg ein Erfolg wird, oder WordPress als Ganzes könnte scheitern. Wir, die Entwickler mit den Bedenken, versuchen nur, ein großartiges Tool für das Content-Management nicht völlig durcheinander zu bringen. Wir wissen besser als jeder andere, wie unsere Kunden mit WordPress umgehen und es nutzen. Die Kernentwickler und Matt betrachten nur Statistiken und Marktanteile, und wissen Sie, was uns das gebracht hat? Die Ghostbusters werden neu gestartet.

Wir möchten wirklich mit Ihnen zusammenarbeiten, um dies zu erreichen, aber es wäre besser, wenn wir steuern könnten, wie dies in die Welt eingeführt wird, als es ahnungslosen Benutzern aufzuzwingen. Wir fordern lediglich eine Möglichkeit, unseren Kunden den Einstieg in den neuen Editor zu erleichtern. Es ist wirklich nicht viel zu verlangen.

Wenn Gutenberg wirklich die Innovation sein wird, die es versprochen hat, dann großartig! Alle steigen in den Gutenbergzug. Wenn nicht, bitten wir nur um die Option, es nicht zu einer großen Katastrophe zu machen.

Es ist, als ob Sie wissen, dass es nicht gut aufgenommen wird, und Sie möchten dies so schlecht machen, dass Sie das Gefühl haben, dass es nur dann erfolgreich sein kann, wenn es nur allen aufgezwungen wird. Es ist so, als würden Politiker Ihnen eine kühne Lüge darüber erzählen, wie eine Steuergesetzgebung, die allen zugute kommt, um sie zu verabschieden, wenn in Wirklichkeit nur die Superreichen tatsächlich davon profitieren.

Es ist wie das, was der große Dr. Cox einmal gesagt hat.

Hilf mir, dir zu helfen.Hilf mir, dir zu helfen.Hilf mir, dir zu helfen.Hilf mir, dir zu helfen.

WooCommerce bricht komplett zusammen ... als wäre es nicht einmal da, wenn ein Produkt bearbeitet wird. Und ich kann mir vorstellen, dass noch viele weitere Plugins komplett kaputt gehen werden. Was ist der Plan, um der Community zu helfen, kompatibel zu sein?

@ smp303 Nicht der WooCommerce-Entwicklerblog im Auge.

Vielleicht ist Windows 8 eine bessere Analogie als "New Coke".

Das war eine kühne neue Vision für eine mobilere Computer-Denkweise, die furchtbar fehlschlug, weil sie zu viele Annahmen zur Basisnutzung veränderte. Ja, tief in den Einstellungen konnte ein Benutzer einen Großteil seiner früheren Windows-Erfahrung zurückgewinnen, aber wenn er nicht in den Fachzeitschriften war, hatten die Benutzer keine Ahnung, wie das geht. Das Ergebnis war eine Katastrophe für Windows.

Gutenberg geht sehr schnell den gleichen Weg. Es macht eine ungeheure Veränderung, die vollständig von der Firma und nicht von der Community vorangetrieben wird, und es hinterlässt (ich nehme an, ich sehe nur wenige Details dazu) einen ziemlich dunklen Weg über ein externes Plugin, um für diese zum traditionellen Editor zurückzukehren die diese neue Methodik nicht mögen.

Ich denke, wenn Automattic / WordPress in den Einstellungen keine Möglichkeit bietet, Gutenberg für die Millionen von gelegentlichen WordPress-Benutzern zu deaktivieren, werden sie es zutiefst bedauern. Gutenberg ist eine enorme Veränderung. Es wird eine Menge Push-Backs von Benutzern geben.

In diesem Thread versuchen wir Sie davor zu warnen und weisen darauf hin, dass ein externes Plugin NICHT ausreicht. Sie müssen den Benutzern ein "out" für Gutenberg bieten, auch wenn sie nur eine gewisse Anpassungszeit haben. Wenn wir es per Code in unsere vorhandenen Themen aktivieren können, können wir möglicherweise eine Katastrophe auslösen.

Wir versuchen verzweifelt, hier zu helfen. Ein externes Plugin wird NICHT ausreichen. Eine Option zum Zurücksetzen auf den Classic-Editor muss integriert sein. Entweder als Teil der Version oder als Möglichkeit, dies über Code zu tun, den wir in unsere Themen einbauen können.

Aus logischer Sicht versuche ich, die Philosophie zu verstehen, Entwicklern zu erlauben, eine Metabox innerhalb der add_meta_box () zu deklarieren, um Gutenberg NICHT zu unterstützen, was dann dazu führt, dass der Editor-Bildschirm überall dort, wo Metabox verwendet wird, die "klassische Version" anzeigt. des Editor-Bildschirms. Warum sind dann einige Entwickler gegen eine in der Datei wp-config.php definierte Konstante? Wenn ich deklarieren kann, dass das Gutenberg-Material NICHT in einem Codebereich verwendet wird, warum können wir dann nicht deklarieren, dass es in anderen Bereichen verwendet wird, wie wir derzeit definierte Anweisungen festlegen?

Beachten Sie, dass für eine Konstante das klassische Editor-Plugin mit WordPress und einem benutzerdefinierten Loader gebündelt werden muss und auf Dauer dort bleibt. Es könnte in 10, 15 Jahren noch da sein, wenn alles, durch das Gutenberg ersetzt wird, kommt.

Selbst dann, für diejenigen, die beide Editoren benötigen oder wollen, ist das Plugin trotzdem erforderlich.

Vergessen Sie nicht, dass Sie das Plugin in Version 4.9 weiterhin installieren und einrichten können, bevor Gutenberg eintrifft.

Ich denke, wenn Automattic / WordPress nicht bietet

@robmcclel Automattic ist nicht WordPress, WordPress.org! = WordPress.com, eine ist eine Open-Source-Community, die andere ist ein kostenpflichtiger Drittanbieter-Service. Automattic veröffentlicht keine Versionen von WordPress, WordPress ist kein internes Automattic-Produkt und Gutenberg auch nicht. Es gibt viele Nicht-Automattic-Mitarbeiter, Release-Leads usw., die Dinge außerhalb von Automattic tun.

"Selbst dann ist das Plugin für diejenigen, die beide Editoren benötigen oder wollen, trotzdem erforderlich."

Nach dem, was hier und anderswo besprochen wurde, fällt der Editor-Bildschirm automatisch zurück, wenn ein benutzerdefinierter Beitragstyp oder eine benutzerdefinierte Metabox erklärt, dass Gutenberg nicht unterstützt wird ... ohne dass das Plugin "Classic Editor" erforderlich ist. Dies ist eines der Probleme, die viele mit dem aktuellen Stand des Gutenberg-Projekts haben. Es gibt viele Meinungen / Aussagen darüber, was in bestimmten Situationen passiert, und oft unterscheiden sich diese Aussagen / Meinungen von anderen.

Beachten Sie, dass für eine Konstante das klassische Editor-Plugin mit WordPress und einem benutzerdefinierten Loader gebündelt werden muss und auf Dauer dort bleibt.

@ Tomjn Warte! Wollen Sie damit sagen, dass das gesamte Meta-Box-System aus dem Kern entfernt wird?

Nein, ich habe Metaboxen überhaupt nicht erwähnt. Beachten Sie jedoch, dass es in Gutenberg Metaboxen gibt. Wenn Sie darauf hinweisen, dass sie entfernt wurden, bedeutet dies, dass Sie Gutenberg nicht getestet haben, und ignoriert, dass ein großer Teil des Ökosystems auf sie angewiesen ist. Das wäre ein großes Problem für wordcamp.org, wordpress.org usw.

Als Referenz bin ich kein Mitglied des Gutenberg-Teams, ich beobachte und wende einfach den gesunden Menschenverstand an. Nur weil ich bei Automattic arbeite, heißt das nicht, dass ich mit Gutenberg besondere Kräfte habe. Ich habe genauso viel Mitspracherecht wie alle anderen hier, und wenn ich das ändern wollte, würde ich es tun, indem ich Code beisteuere und Probleme behebe, so wie es jeder andere tun würde.

@tomjn Also, was du gesagt hast, ergibt für mich keinen Sinn. Der "Classic Editor" ist im Grunde nur eine Administrationsseite mit Meta-Boxen und Funktionen zum Speichern und so weiter. Das bedeutet, dass zum Umschalten zwischen Gutenberg und Classic Code in den Kern integriert werden muss, der die beiden Optionen ermöglicht und der gesamte Code für die Classic-Funktionalität erhalten bleibt.

Das würde bedeuten, dass das Classic-Plugin nichts anderes als eine Möglichkeit ist, den Switch auszulösen. Es scheint viel einfacher zu sein, eine konstante oder themenbezogene Unterstützung im Kern zu erstellen, als ein Plugin erstellen und warten zu müssen.

Wenn alles für Classic noch im Kern ist, warum ein Plugin erstellen, um es zu aktivieren?

Und was ist, wenn es an Ort und Stelle bleiben muss? Es gibt bereits eine Menge alten und veralteten Codes im WordPress-Kern. Ein eingebauter klassischer Abzug würde im großen Schema der Dinge überhaupt keinen großen Unterschied machen.

Seien wir hier nicht unaufrichtig, Tom. Automattic ist die treibende Kraft hinter Gutenberg. Keine Menge von "aber nicht" von Automattic-Mitarbeitern wird die Tatsache ändern, dass es an einem klaren Tag so offensichtlich ist wie die Sonne am Himmel.

Gutenberg ist sehr Matts Baby; wie ist Automattic. Er hat das Projekt vorangetrieben. Er war seine größte Cheerleaderin.

Gutenberg hat ernsthafte betriebliche Vorteile für Automattic - nämlich ein Produkt, das das Spielgefühl mit seinen größten Konkurrenten in Einklang bringt. Das Gleiche gilt nicht für den Rest der Gemeinde.

Ja, viele WordPress-Benutzer verwenden Seitenersteller über Plugins. Ein anderer großer Teil nutzt jedoch häufig benutzerdefinierte Felder über Plugins wie ACF und CMB (und seine vielen Gabeln). Dieser Teil der Community hat jahrelang nach dem WordPress-Projekt gesucht, um benutzerdefinierte Felder als native Funktion zu implementieren.

Es ist jedoch nicht zum Tragen gekommen, weil die Finanzierung nicht vorhanden war, um dies zu erreichen, und jedes Mal, wenn sie zur Sprache gebracht wurde, hat sie das ach so häufige Open-Source-Problem der Debatte über den Tod durch das Komitee erlitten.

Viele andere, viel mehr Presseprobleme haben das gleiche Schicksal erlitten - wie zum Beispiel die Min-PHP-Version auf etwas zu stoßen, das seit über 7 Jahren nicht mehr am Lebensende ist.

Dies sind nur einige Beispiele von Dingen, die vor Jahren hätten getan werden sollen und die noch nicht erreicht wurden, weil der Hauptfinanzierer des Projekts dies nicht unterstützt hat.

Automattic hat sein Gewicht hinter Gutenberg geworfen - hauptsächlich als direkte Folge davon, dass Matt auf dem Fahrersitz sitzt. Eine große Anzahl von Geschäftszeiten wurde darauf verwendet, dies zu verwirklichen. Dies bedeutet eine direkte Finanzierung durch den Hauptfinanzierer des WordPress-Projekts - Automattic.

Ich sehe nicht, wie dies für das Ticket relevant ist.

@rosswintle Das ist sehr relevant. Es gibt viele Entwickler, die eine einfache Möglichkeit wünschen, Gutenberg auszuschalten. Es ist ziemlich offensichtlich, dass die Mächte uns dies nicht geben und es so unpraktisch wie möglich machen wollen, Gutenberg auszuschalten.

Die treibende Kraft hinter dieser Entscheidung ist die Agenda von Matt und Automattic, ihren Marktanteil auf der DIY-Website zu erhöhen. Es ist klar, dass die Bedenken der Community aufgrund des Einflusses von Matt und Automattic auf das Projekt nicht berücksichtigt werden. Hier kommt 100% der Frustration der Gemeinden über Gutenberg her.

Da die Richtung des Gutenberg-Projekts weitgehend von Matt und Automattic beeinflusst wird, ist es in dieser Diskussion wie in allen Diskussionen über das Projekt relevant.

@ Tomjn

Ab Gutenberg und dieser kommenden Version ist WordPress ein Produkt von Automattic. Alles andere zu glauben ist Dummheit. .Com oder .Org spielen keine Rolle - das WordPress-Programm ist jetzt ein Produkt von Automattic. Entwickler und solche, die daran arbeiten, sind nicht mehr als unbezahlte Praktikanten für Automattic.

Die Community will Gutenberg als Plugin. Matt nicht. Matt ist der Leiter von Automattic. Matt ist der selbsternannte Lead für diese Veröffentlichung. Die Leute, die die Entwicklung von Gutenberg leiten, sind Automattic-Mitarbeiter. Matt erzwingt dies. Es gibt keine andere Entscheidung oder Debatte - er hat 51% der Stimmen und übt sie aus.

Machen Sie sich keine Gedanken darüber, dass WordPress in irgendeiner Weise ein demokratisches oder gemeinschaftliches Produkt ist. Es ist jetzt das Produkt von Automattic, wurde jedoch in der Vergangenheit gerahmt oder vermarktet, und sie steuern jetzt den Entwicklungsfokus, das Tempo und die Entscheidungen.

@rosswintle , es ist für das Ticket

Matt und Automattic setzen diesbezüglich ihre Autorität durch. Sie können dieses Ticket genauso gut schließen und alle anderen mögen es, weil unsere Stimme nicht mehr relevant ist, als Sympathie zu vermitteln und uns einen Platz zum Entlüften zu geben. Dieses Ticket könnte genauso gut gar nicht existieren.

Automattic ist dafür verantwortlich, nicht die Community. Wir müssen uns dem stellen und uns auf die Auswirkungen einstellen, denn dies geschieht und die einzige Rampe ist das Classic Editor Plugin, und selbst das ist ein bisschen wohltätig. Es wird nichts anderes geben.

Ich persönlich sehe nicht, wie die Diskussion darüber, wer hier die Entscheidungen trifft, dazu beiträgt, das Problem voranzutreiben. Es wird als Open-Source-Projekt entwickelt, und das bedeutet, dass Sie eine Stimme haben können. Ich möchte die Leute dazu ermutigen, ihre Stimmen konstruktiv zu nutzen, indem sie bei der Entwicklung von Optionen und einer Begründung für die Implementierung dieser Optionen helfen.

Der letzte Beitrag zum Thema der Anfrage war von @tomjn , gefolgt von einigen relevanten Fragen von @wpstudio und @jawittdesigns

Beachten Sie, dass für eine Konstante das klassische Editor-Plugin mit WordPress und einem benutzerdefinierten Loader gebündelt werden muss und auf Dauer dort bleibt. Es könnte in 10, 15 Jahren noch da sein, wenn alles, durch das Gutenberg ersetzt wird, kommt.

Wurde eine Konstante nie veraltet? (Echte Frage) Sieht aus, als wäre WPLANG in Version 4.0 gewesen? Ist das eine philosophische Sache über die Natur von Konstanten? Wäre ein Filter besser? Wäre ein Filter für @ smp303 akzeptabel?

Selbst dann, für diejenigen, die beide Editoren benötigen oder wollen, ist das Plugin trotzdem erforderlich.

Warum ist das so?

@jawittdesigns Zu Recht fragt:

Wenn alles für Classic noch im Kern ist, warum ein Plugin erstellen, um es zu aktivieren? Und was ist, wenn es an Ort und Stelle bleiben muss? Es gibt bereits eine Menge alten und veralteten Codes im WordPress-Kern. Ein eingebauter klassischer Abzug würde im großen Schema der Dinge überhaupt keinen großen Unterschied machen.

und @pento hat das Entfernen des größten Teils davon so gut wie ausgeschlossen :

TinyMCE wird von Gutenberg verwendet, um die bearbeitbaren Textblöcke mit Strom zu versorgen - das geht nirgendwo hin. Funktionen wie wp_editor () können in Core relativ einfach verwaltet werden, ohne dass sie in ein Plugin verschoben werden müssen - ich würde erwarten, dass sie unbegrenzt weiter funktionieren.

Schließlich:

Vergessen Sie nicht, dass Sie das Plugin in Version 4.9 weiterhin installieren und einrichten können, bevor Gutenberg eintrifft.

Das ist uns allen bewusst. Wir versuchen, für verschiedene Methoden einzutreten, die Entwicklern mit unterschiedlichen Workflows Optionen bieten.

@rosswintle - Es ist wichtig, darüber zu diskutieren, da letztendlich das Wissen darüber, wer die Entscheidungen trifft, formuliert .

Ja, Sie haben jedoch Recht, dass dieses spezielle Thema nicht der richtige Ort ist, um darüber zu diskutieren. Die Weigerung, sich auf unsere Anfragen einzulassen, zeigt jedoch, dass wir im Vergleich zu denjenigen, die die Entscheidung treffen, in einer schwachen Position sind.

Wie auch immer. Sie machen einige gute Punkte im letzten Beitrag. Lassen Sie mich Ihr Zitat aufgreifen:

Beachten Sie, dass für eine Konstante das klassische Editor-Plugin mit WordPress und einem benutzerdefinierten Loader gebündelt werden muss und auf Dauer dort bleibt. Es könnte in 10, 15 Jahren noch da sein, wenn alles, durch das Gutenberg ersetzt wird, kommt.

Sollen wir davon ausgehen, dass wir, sobald was Gutenberg ersetzt, nicht mehr dieselbe Diskussion führen werden? Der große USP von WordPress war schon immer das Engagement für Abwärtskompatibilität im Vergleich zur Konkurrenz. Das hat bis jetzt gut funktioniert. Wie wir alle betont haben, bricht Gutenberg das. Es gibt kaum eine andere Wahl, als bei dem zu bleiben, was wir jetzt haben, abgesehen davon, was tatsächlich ein offiziell sanktionierter Hack ist.

Tatsache ist, dass der Code immer noch im Kern ist. Es ist ein viel intelligenterer und geeigneterer Ansatz, die Verwendung einer Konstanten - einer einzelnen Codezeile - über ein Plugin zu ermöglichen, das separat verwaltet werden muss und am Ende Hunderte von Codezeilen umfasst.

Tatsache ist, dass der Code immer noch im Kern ist. Es ist ein viel intelligenterer und geeigneterer Ansatz, die Verwendung einer Konstanten - einer einzelnen Codezeile - über ein Plugin zu ermöglichen, das separat verwaltet werden muss und am Ende Hunderte von Codezeilen umfasst.

Das ist ganz und gar mein Punkt ... Es ist nicht nur eine Nischenmenge von Menschen, die dies brauchen werden. Aufgrund der Tatsache, dass Gutenberg derzeit richtig ausfällt, bricht eine große Anzahl von Plugins und Themes usw. usw. ... Ein anderes Plugin ist kein Fix, es ist ein Hack, eine Abhängigkeit. Nicht der richtige Weg, um ein Problem zu beheben, das einen Kern von Leuten vertreiben könnte, die die besten WordPress-Sites da draußen machen.

Die andere Option, die mich am meisten erschreckt, ist, dass die Leute einfach bei 4.9 bleiben und keine Websites aktualisieren. Diese werden dann instabil und offen für Hacking und bringen den Namen WordPress herunter.

Ich habe einfach nicht das Gefühl, dass genug darüber nachgedacht wurde, und daher ist ein Plugin die Endlösung.

Wenn TinyMCE für bestimmte Blöcke weiterhin "unter" Gutenberg sein wird, warum nicht wie folgt vorgehen:
Vor 5.0 (auch bekannt als aktuelle Websites mit WordPress) wäre Gutenberg standardmäßig mit einem Filter / einer Konstante deaktiviert, was die Aktivierung von Gutenberg vereinfacht.
Bei 5.0+ (auch bekannt als WordPress-Sites, die auf und nach 5.0 installiert sind) ist Gutenberg standardmäßig mit einem Filter / einer Konstante aktiviert, die das Deaktivieren vereinfacht.

Auf diese Weise fällt es jedem, der Gutenberg verwenden möchte, leicht, diese Wahl zu treffen, und jedem, der nicht bereit oder bereit ist, Gutenberg zu verwenden (aus welchem ​​Grund auch immer), fällt es ihm leicht, diese Wahl zu treffen. Es scheint nur manchmal, dass einige auf dem Gutenberg-Hügel sterben wollen, wenn es (kurzfristig) praktischere Lösungen zu geben scheint.

@wpstudio Das ist so ziemlich das, wonach # 4423 fragt.

Wie bei @rosswintle denke ich, dass es wichtig ist, dieses Problem wieder auf den richtigen Weg zu bringen, für diejenigen, die es gemacht haben und sich über die letzten Kommentare gefreut haben. Vielen Dank für diejenigen, die mit Respekt diskutieren.

Es muss jedoch gesagt werden, dass viele Menschen, unabhängig von Ihrer Meinung zu einem Unternehmen und seinen Motivationen, in vielen verschiedenen Unternehmen an Gutenberg arbeiten. Genau wie bei WordPress besteht dies aus Community-Beiträgen (nicht nur einem Unternehmen). Umfassende Aussagen zu machen, ist für diejenigen, die daran arbeiten, nicht fair. Es ist auch nicht fair für diejenigen, die dieses Problem gestartet haben und eine Lösung wünschen.

Ich hoffe, dass dieses Thema wieder auf Kurs kommt und den Punkt dieses Themas weiterhin mit Respekt diskutiert.

@karmatosed , @ntwb , @tomjn und andere in diesem Thread. Wenn mein kleiner Scherz oben Anstoß gab, entschuldige ich mich dafür. Dies ist ein äußerst wichtiges Thema, das es wert ist, diskutiert zu werden - wenn wir es tatsächlich diskutieren werden.

Aus den obigen Threads geht hervor, dass Gutenberg in Core deaktiviert werden kann, da die anderen Komponenten als Teil von Core verbleiben müssen, sodass Gutenberg nur deaktiviert wird. Was Sinn macht, da es derzeit als Plugin existiert und viele Sites es gut ausführen können. Abgesehen von einem bisher nicht dargestellten technischen Grund bedeutet dies, dass diese Entscheidung keine technische, sondern eine philosophische Entscheidung ist.

Und das ist das wahre Herzstück. Ich denke nicht, dass die gesamte Gemeinschaft in dieser Hinsicht einer Meinung ist. Nicht einmal annähernd. Dies ist der Grund, warum die Entscheidung bei Matt getroffen wird (ich habe gesagt "platziert", nicht "beschuldigt"), weil er die treibende Kraft dahinter zu sein scheint. Und anscheinend hinter der unerschütterlichen Entscheidung, Gutenberg in Core und die Version 5.0 aufzunehmen.

Die Frage ist "Warum?"

Ich kann sicherlich die Gründe sehen, warum Gutenberg gezwungen wurde, im Kern zu sein. Ich denke, dass "Blöcke" sehr wichtig für das zukünftige Überleben und die weit verbreitete Verwendung von WordPress, .org oder .com sind. Ich mache. Ich bin zu 100% hinter "Blöcken".

Ich denke jedoch nicht, dass Gutenberg selbst als Übermittlungsmethode dieser "Blöcke" ein gut durchdachtes System ist. Nur von diesem Thread gibt es 3 verschiedene Anwendungsfälle (ich, @rosswintle und @ smp303 ) und Gutenberg scheint keinen von uns zufrieden zu stellen. In der Tat macht es uns einige Sorgen - für uns, unser Unternehmen und unsere Benutzer.

Die Entscheidung, Gutenberg in Core zu integrieren, ist für Automattic sinnvoll, da jeder Plugin-Entwickler gezwungen ist, sich darauf einzulassen und seine Plugins neu zu schreiben, um damit zu arbeiten. Dies ist sehr gut für WordPress.com und möglicherweise auch für WordPress.org. Aber auch hier werden einige Anwendungsfälle nicht von Blöcken profitieren, aber hoffentlich wird die Existenz von Blöcken sie auch nicht verletzen.

Dies bedeutet jedoch, dass eine sehr kleine Gruppe von Menschen für eine sehr große Anzahl von Menschen ziemlich mächtige wirtschaftliche und geschäftliche Entscheidungen trifft. Für mich allein bedeutet der Wechsel zu Blöcken Hunderte von Stunden und Tausende von Dollar sowie die verlorene Entwicklungszeit, Ressourcen von meinen geplanten Zielen (die die Community, die ich betreue, tatsächlich möchte) wegnehmen zu müssen, um wichtige Teile meines Systems zu überholen um die Anforderungen dieser unbekannten Entscheidungsträger zu erfüllen (ich gehe wieder davon aus, dass Matt ein großer Teil dieser Entscheidungsgruppe ist).

Ich würde mich nicht so schlecht fühlen - oder ehrlich gesagt so verängstigt -, wenn Gutenberg Probleme für mich lösen würde. Aber das ist es nicht. Bisher macht es mein Leben viel schlimmer. Die Dinge mögen sich verbessern, aber ich sehe keine große Verschiebung in der Entwicklungsrichtung. Es scheint, dass 95% der Entscheidungen über Verwendung, Implementierung, UI / UX sowie Mittel und Methoden von einer kleinen Gruppe anderer ohne viel Debatte oder Input getroffen wurden.

WordPress versorgt mehr als 25% des gesamten Internets. Das bedeutet Millionen von Websites, Milliarden von Webseiten und möglicherweise Hunderte von Milliarden Dollar. Von der New York Times bis zu einer Handvoll Buchblogger in meinem Netzwerk. Von massiven E-Commerce-Websites bis hin zu den einzelnen signierten Büchern, die von den von mir betreuten Autoren verkauft werden. Das ist massiv - MASSIV. Es ist praktisch ein weltweiter globaler Versorger.

Die Entscheidung, einen wesentlichen Teil der Grundlagen für all dies neu zu schreiben - was viele Millionen Menschen betrifft - wurde offenbar ohne Debatte getroffen. Alles von der Benutzeroberfläche bis zum Vertrauen in REACT (kontrolliert von Facebook, das sich als äußerst räuberisch erwiesen hat, fragen Sie einfach SnapChat). Alle diese Entscheidungen wurden größtenteils einseitig getroffen.

Wenn dies alles nur dazu dienen würde, ein Modul in JetPack mit Strom zu versorgen, würde es niemanden wirklich interessieren. Das ist WordPress.com-Geschäft. Aber das ist es nicht. Es verändert die Grundlagen des gesamten Internets.

Was mich genau hierher und jetzt führt. Die Community, definitiv die Community-Mitglieder in diesem Thread, bittet um Kontrolle über das Produkt und das Geschäft, das sie mithilfe von Open Source und öffentlich verfügbarem WordPress.org-Code erstellt haben. Wir bitten um die Fähigkeit, uns und unsere Benutzer zu schützen, und der einzige Weg, den wir uns vorstellen können, besteht darin, nach einer Möglichkeit zu fragen, Gutenberg auszuschalten. Wir bitten um diese Fähigkeit, ein Teil von Core zu sein, genauso wie das Hinzufügen von Gutenberg ein Teil von Core sein soll.

Kann die Fähigkeit, Gutenberg auszuschalten, zu Core hinzugefügt werden? Wer trifft diese Entscheidung und weist die Leads dazu an? Was ist der Mechanismus, um diese Frage zu stellen? Steht die Antwort zur Debatte? Wird es zur Abstimmung gestellt? Gibt es einen Kommentarprozess? Wenn ja, wo?

Und @karmatosed , Sie haben zu 100% Recht, dass der Abschnitt "Probleme" von Github nicht der beste Ort ist, um diese Debatte zu führen. Ich bin damit einverstanden, dass dieses Repo weitgehend seinem beabsichtigten Zweck überlassen wird, technische Probleme zu identifizieren und zu lösen, die in direktem Zusammenhang mit dem Gutenberg-Plugin stehen.

Leider scheint es keinen anderen Ort für diese Diskussion zu geben. Ich meine, es gibt den Reviews-Bereich des Gutenberg-Plugins, aber das ist ein ziemlich begrenztes Forum für diese Art von Konversation.

Wird es eine Website geben, auf der Gutenberg besprochen werden kann? Nicht nur die Implementierung, sondern auch die Schnittstelle zu kommentieren und zu diskutieren? Der Release-Zeitplan? (Welche Kriterien bestimmen beispielsweise, ob Gutenberg und WP5.0 "fertig" und zur Veröffentlichung bereit sind? Wer trifft diese Entscheidung? ") Wird die Gutenberg-Oberfläche von Benutzern getestet? Gibt es eine Möglichkeit, Daten und Feedback von @ zu sammeln?

Auf YouTube gab es ein interessantes Video, in dem die Leute gebeten wurden, Gutenberg zu verwenden und seine Intuitivität zu bewerten (Link hier: https://youtu.be/7iWRBLCP-l0) - gibt es noch andere davon? Gibt es große Anstrengungen, um Gutenberg zu testen? Wenn ja, wo werden diese Daten aufbewahrt? Wie werden diese Daten geteilt? Kann die Community es sehen? Wird es verwendet, um das Design voranzutreiben?

Das Problem, mit dem wir jetzt bei Gutenberg konfrontiert sind - und das tatsächlich die treibende Kraft hinter diesem Faden ist - ist, dass sich die Community von diesem Prozess sehr isoliert fühlt. Wir haben das Gefühl, dass es uns passiert. In der Tat wird uns das aufgezwungen. Die Öffnung des Prozesses für Kommentare und Debatten, das Zulassen neuer Stimmen und Ideen zu Themen wie Benutzeroberfläche, Austausch von Daten und Benutzererkenntnissen würde diese Ängste und Bedenken erheblich lindern.

Und Blocks zu einer Kernfunktion zu machen, aber Gutenberg als Plugin beizubehalten, könnte alles viel weniger beängstigend und für die gesamte Community viel schmackhafter machen. Ich würde das persönlich lieben. Geben Sie der Community Zeit, alternative Ansätze für Gutenberg zu erforschen und zu entwickeln - verschiedene Schnittstellen und Anwendungsfälle - und fördern Sie dennoch die Entwicklung und Zukunft von Blöcken.

Das war also ziemlich lang, aber wo sollen wir diese Debatte außer hier noch führen? Und diese Debatte ist SEHR wichtig. Angesichts der Anzahl der betroffenen Personen und Unternehmen ist dies derzeit möglicherweise die wichtigste Diskussion im Internet.

Nachdem Sie ein wenig darüber recherchiert haben, scheint es, dass Sie in einer mu-plugin -Datei nur Folgendes benötigen, um Gutenberg mit Code zu deaktivieren, es sei denn, ich habe etwas verpasst - was wahrscheinlich ist!

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

Für den Kontext habe ich das Gutenberg-Plugin aktiv und den obigen Code in einer Datei im Ordner mu-plugins . Jetzt verwenden alle Nachbearbeitungsbildschirme den klassischen Editor.

Ein paar Dinge, die Sie dazu beachten sollten:

• gutenberg_can_edit_post_type ist nicht der endgültige Filtername - gutenberg Namen werden vor dem Zusammenführen in Core umbenannt.
• Dieser Filter bedeutet nur "Blockeditor nicht laden", nicht "Klassischen Editor verwenden". Es funktioniert im Moment, aber es ist nicht garantiert, dass es in Zukunft funktioniert. Wenn klassikspezifischer Code (z. B. edit-form-advanced.php ) in das Plugin für den klassischen Editor verschoben wird, wird nicht mehr auf den klassischen Editor zurückgegriffen, und es wird ausdrücklich erwartet, dass Sie Ihren eigenen Editor laden.

@rosswintle : Den Thread der letzten Woche aufgreifen :

Der einfachste Weg, darüber nachzudenken, ist "Wenn die Daten zwischen <body> und </body> , sind sie inhaltlich und passen letztendlich in einen Block". Für WordPress 5.0 ist dies etwas eingeschränkter - nur was zwischen <article> und </article> liegt, sind Blöcke. 😉

Ein Beispiel ist ein Post-Typ für Immobilien. Der Preis ist in Postmeta gespeichert, aber es ist Inhalt. Möglicherweise haben Sie einen Block namens "Property Lede", der einige Elemente ausfüllt - den Preis, die Adresse, den Gebäudetyp, die Anzahl der Schlafzimmer / Badezimmer / Garagen usw. Sie werden wahrscheinlich auch andere Blöcke haben - Inspektionszeiten, Funktionen, Fotos, Grundrisse, Agent usw. Mithilfe von Blockvorlagen richten Sie den Blockeditor so ein, dass beim Bearbeiten des Post-Typs property Die Blöcke befinden sich bereits und können nicht verschoben werden. Der Workflow für den Endbenutzer unterscheidet sich nicht von dem, wie ein vorhandener Metabox-basierter Workflow jetzt aussieht, ähnelt jedoch viel stärker der endgültigen Ausgabe.

Das war ein wenig langwierig, aber es bestimmt hoffentlich die Szene - alles, was wie Inhalt aussieht, ist Inhalt, unabhängig davon, wo die Daten gespeichert sind oder wie sie manipuliert oder formatiert werden könnten, bevor sie im Frontend angezeigt werden. Einige Blöcke speichern ihre Daten möglicherweise in post_content , aber das ist nicht das bestimmende Merkmal dafür, was sie zum Inhalt macht - die Anzeige im Frontend macht sie zum Inhalt.

Was ist also mit Informationen, die nicht im Frontend angezeigt werden? Der Name des Besitzers? Beziehungen zum Anzeigen von Terminen? Ist das "Inhalt"? Soll das in einen "Block" eingetragen werden?

Kategorien / Tags / Taxonomien können im Frontend angezeigt werden oder nicht. Sind sie "Blöcke"?

Der Post-Status wird möglicherweise im Front-End angezeigt, dies ist jedoch definitiv kein Block.

Sie haben zuvor gesagt:

Metadaten sind kein Block, können jedoch darüber informieren, wie ein Block verwendet oder angezeigt wird.

Welches ist in Ordnung. Aber warum wird Entwicklern dann gesagt, dass in Zukunft Metadaten über die Blockschnittstelle bearbeitet werden sollen?

Das ist die wahre Verwirrung für mich. Ich verstehe, warum Gutenberg-Blöcke gut zum Bearbeiten von Elementen zwischen den body -Tags geeignet sind, aber ich verstehe nicht, warum Blöcke zum Bearbeiten anderer Daten geeignet sind, die nicht zwischen diesen Tags liegen.

Es scheint mir, dass es diese Verwirrung ist, die Entwickler dazu veranlasst, Gutenberg auszuschalten. Einige unserer Anwendungen von WordPress enthalten viele Informationen, die nicht im Front-End angezeigt werden, und dennoch wird uns mitgeteilt, dass wir in Zukunft einen Front-End-Editor als Schnittstelle für diese Daten verwenden sollten.

Ich hoffe das kommuniziert die Verwirrung.

Also über diese Möglichkeiten, es zu deaktivieren ...?

@pento Der Doc-Block für diese Funktion zeigt überhaupt nicht an, dass dieser Filter temporär ist:

/**
 * Filter to allow plugins to enable/disable Gutenberg for particular post types.
 *
 * <strong i="7">@since</strong> 1.5.2
 *
 * <strong i="8">@param</strong> bool   $can_edit  Whether the post type can be edited or not.
 * <strong i="9">@param</strong> string $post_type The post type being checked.
 */

Was ist der Zweck dieses Filters, wenn er nicht wie beschrieben funktioniert?

Zusätzlich @pento dazu:

Dieser Filter bedeutet nur "Blockeditor nicht laden", nicht "Klassischen Editor verwenden". Es funktioniert im Moment, aber es ist nicht garantiert, dass es in Zukunft funktioniert. Wenn klassikspezifischer Code (z. B. edit-form-advanced.php) in das Plugin für den klassischen Editor verschoben wird, wird nicht mehr auf den klassischen Editor zurückgegriffen, und es wird ausdrücklich erwartet, dass Sie Ihren eigenen Editor laden.

An einigen Stellen wurde uns mitgeteilt, dass der klassische Editor geladen wird, wenn Post-Typen show_in_rest => false deklarieren oder ein Meta-Feld auf dem Post-Bearbeitungsbildschirm '__block_editor_compatible_meta_box' => false, deklariert. Es scheint, als ob Sie von oben sagen, dass dies nicht Teil des Kerns sein wird. Wie kann dies der Fall sein, wenn Sie das klassische Editor-Plugin nicht aktiviert haben?

Um auf den Classic-Editor zurückzugreifen, wird etwas erkannt, das Gutenberg nicht unterstützt. Dann muss der Classic-Editor sicherlich Teil des Kerns bleiben. Daher benötigen wir das Plugin sicherlich nicht, um diese Funktionalität aufzurufen.

Was ist also mit Informationen, die nicht im Frontend angezeigt werden? Der Name des Besitzers? Beziehungen zum Anzeigen von Terminen? Ist das "Inhalt"? Soll das in einen "Block" eingetragen werden?

Natürlich gibt es auch Platz für Metainformationen - das wird in # 3330 besprochen. Das Wichtigste, was ich beachten wollte, ist, dass vieles, was als "Metadaten" bezeichnet wird, tatsächlich Inhalt ist.

Kategorien / Tags / Taxonomien können im Frontend angezeigt werden oder nicht. Sind sie "Blöcke"?

Nun, sie sind Meta für den Beitrag, aber möglicherweise Inhalt für die Website. Der Gutenberg-Anpassungsfokus wird wahrscheinlich einen Block enthalten, der diese Metadaten zur Erstellung von Inhalten verwendet. 🙂 Es ist jedoch unwahrscheinlich, dass ein Block im Blockeditor sie als Inhalt verwendet. Daher befinden sich Taxonomien in der Seitenleiste und nicht in einem Block.

Welches ist in Ordnung. Aber warum wird Entwicklern dann gesagt, dass in Zukunft Metadaten über die Blockschnittstelle bearbeitet werden sollen?

Wir sagen nicht, dass alle Metadaten in die Blockschnittstelle passen. Einige mögen, aber sie müssen nicht. Der Punkt ist, dass die meisten vorhandenen Verwendungen von Meta-Boxen in die Blockschnittstelle passen. Der einfachste Weg, sie voneinander zu unterscheiden, besteht darin, darüber nachzudenken, ob sie im Front-End angezeigt werden oder nicht. In # 3330 werden Konzepte zum Bearbeiten von Metadaten ausführlicher erläutert.

Ich kann Ihnen kategorisch sagen, dass Metadaten in der Blockeditor-Oberfläche nicht bearbeitet werden müssen. Wenn es kein Inhalt ist oder sich nicht auf Inhalt bezieht, gehört es nicht dorthin - es gibt andere Stellen, an denen die Schnittstelle zum Bearbeiten dieser Metadaten eingefügt werden kann.

Also über diese Möglichkeiten, es zu deaktivieren ...?

Wenn Sie Websites erstellen, verwenden Sie das Classic Editor-Plugin. Wenn Sie Plugins erstellen, verwenden Sie die CPT- und Meta-Box-kompatiblen Flags. 🙂

Wenn Sie Websites erstellen, verwenden Sie das Classic Editor-Plugin. Wenn Sie Plugins erstellen, verwenden Sie die CPT- und Meta-Box-kompatiblen Flags. 🙂

Dies ist in Ordnung für Websites, die wir in Zukunft erstellen, oder für Kunden, die wir "in den Büchern" haben und die sich um ihre Websites kümmern. Was ist jedoch mit Clients, deren Websites wir in der Vergangenheit erstellt haben und die einwandfrei funktionieren, die automatisch aktualisiert werden usw. Sie werden wahrscheinlich auf Aktualisieren auf WordPress v5.0 klicken.

Auf diesen Websites ist das Classic Editor-Plugin nicht installiert, und auf diesen Meta-Boxen / CPTs sind keine Flags vorhanden, da sie codiert wurden, als Gutenberg nicht verfügbar war. Diese Websites werden Probleme haben und ihre Besitzer verwirrt und ehrlich gesagt ziemlich verärgert lassen. Bitte korrigieren Sie mich, wenn ich hier falsch liege.

@wpmark hat es genagelt.

Ich werde das Classic Editor Plugin verwenden, wenn ich es in Zukunft brauche. Ich werde die CPT- und Meta-Box-kompatiblen Flags verwenden, wenn ich dies in Zukunft tun muss. Aber ich habe Dutzende von Einzelpersonen, Unternehmen und Wohltätigkeitsorganisationen / gemeinnützigen Organisationen in allen Formen und Größen, für die ich bereits Websites erstellt habe. Mit einigen von ihnen habe ich noch Arbeitsbeziehungen. Andere sind weitergezogen und führen die Site entweder nur selbst aus oder arbeiten mit einem anderen Entwickler oder gar keinem Entwickler zusammen.

Es ist unrealistisch, Codeänderungen oder eine Plugin-Installation auf jeder Site zu erwarten, die dies benötigt.

Dies ist wirklich das Gebiet Nr. 4423.

Für alle wichtigen Gespräche hat dieses Ticket keine Etiketten oder Besitzer. Wenn es nicht passieren wird, gibt es irgendeinen Grund, es offen zu halten?

gutenberg_can_edit_post_type (oder wie auch immer es in Core heißt) und '__block_editor_compatible_meta_box' => false greifen auf die klassische Oberfläche in WordPress 5.0 zurück. Zukünftige WordPress-Versionen können dieses Verhalten jedoch ändern.

gutenberg_can_edit_post_type kennzeichnet nur, ob der Blockeditor geladen werden soll oder nicht. Derzeit wird standardmäßig Classic geladen, wenn der Blockeditor nicht geladen wird. Bei diesem Filter wird jedoch davon ausgegangen, dass Sie, wenn Sie den Blockeditor nicht laden, eine eigene Schnittstelle bereitstellen. Das könnte das Classic Editor Plugin sein, es könnte eine benutzerdefinierte Oberfläche sein. Es ist jedoch wahrscheinlich, dass in einer zukünftigen WordPRess-Version der Classic-Code in den Classic-Editor verschoben wird.

Eine ähnliche Situation besteht für das Flag __block_editor_compatible_meta_box . Es wird vorerst auf die Classic-Oberfläche zurückgegriffen, aber in einer zukünftigen Version von WordPress wird möglicherweise das Standardverhalten geändert, um im Blockeditor zu bleiben, und es wird eine Warnung angezeigt, wo sich die Meta-Box befinden würde.

Natürlich wird keine dieser Änderungen ohne Recherche und Kontaktaufnahme mit den Website-Eigentümern stattfinden. Mein Punkt ist, dass diese Einstellungen hauptsächlich für den Übergang zu Gutenberg vorhanden sind. Das Classic Editor-Plugin ist die stabile Option, um die Verwendung der Classic-Oberfläche zu erzwingen.

Weitere Informationen zu diesen Themen finden Sie unter # 3902.

Zum Thema der Information der Websitebesitzer wird WordPress 5.0 nicht in ein Vakuum entlassen. Es gibt viele Tools, mit denen wir Websitebesitzer über die bevorstehenden Änderungen informieren und sie wissen lassen können, ob ihre Website funktioniert oder nicht. Zukünftige Versionen von WordPress 4.9.x werden Informationen zum Blockeditor enthalten. Es ist geplant, Daten zur Plugin-Kompatibilität (sowohl automatisiert als auch Crowd-Sourcing - # 4072) zu sammeln, und wir sind offen für andere Optionen, um sicherzustellen, dass Websitebesitzer davon Kenntnis haben was kommt

Für alle wichtigen Gespräche hat dieses Ticket keine Etiketten oder Besitzer. Wenn es nicht passieren wird, gibt es irgendeinen Grund, es offen zu halten?

Ich hatte kein Problem damit, es offen zu halten, während wir diese Diskussion hatten, aber an diesem Punkt sehe ich keine Notwendigkeit, es weiter offen zu halten. Um die ursprüngliche Frage zu beantworten, ist eine codebasierte Option, auf den klassischen Editor zurückzugreifen, nicht vorgesehen.

@pento Warum hast du das geschlossen? Das Problem wurde noch nicht behoben.

Sie beweisen nur, dass die Community nicht gehört wird, indem Sie dies schließen.

Ich denke wirklich, dass Sie es wieder öffnen sollten, damit wir zu einer Lösung kommen können.

Die Auflösung war nein - sie werden keine Möglichkeit ermöglichen, Gutenberg im Code zu deaktivieren. Sie müssen sich auf ein Plugin verlassen.

Völlig unglücklich und unzufrieden damit, aber zumindest habe ich es versucht.

Die Auflösung war nein - sie werden keine Möglichkeit ermöglichen, Gutenberg im Code zu deaktivieren. Sie müssen sich auf ein Plugin verlassen.

Wo und wann ist das passiert? Eine Entscheidung wird hier nicht erwähnt.

Oder ist dies nur die typische Reaktion des Kernteams, indem man vorgibt, zuzuhören und sie dann einfach herunterfährt?

Welche Art von Auflösung möchten Sie an dieser Stelle?

Wenn Sie Gutenberg mithilfe einer Konstante deaktivieren möchten, wird dies nicht passieren. Wir wurden angehört und die Idee wurde abgelehnt.

Ich hatte kein Problem damit, es offen zu halten, während wir diese Diskussion hatten, aber an diesem Punkt sehe ich keine Notwendigkeit, es weiter offen zu halten. Um die ursprüngliche Frage zu beantworten, ist eine codebasierte Option, auf den klassischen Editor zurückzugreifen, nicht vorgesehen.

Von @pento - deshalb wurde es geschlossen

Nun, ich hoffe, sie veröffentlichen das Plugin zumindest vor dem Update, damit wir es installieren und aktivieren können, damit die Benutzererfahrung nicht beeinträchtigt wird.

Ich meine, die Meta-Box-Unterstützung ist in 2.0 immer noch kaputt und ich bin nicht wirklich zuversichtlich, dass es zu diesem Zeitpunkt jemals funktionieren wird.

Das Plugin existiert bereits: https://wordpress.org/plugins/classic-editor/

Um die ursprüngliche Frage von @ smp303 zu beantworten.

1. In wp-config.php hinzufügen

define( 'ENABLE_GUTENBERG', false );

1. In einer Datei mit dem Namen my-hacks.php im Ordner mu-plugins , in der Sie möglicherweise Code erstellen müssen

<?php // (C) Bobbing Wide 2015-2018
if ( defined( "ENABLE_GUTENBERG" ) && !ENABLE_GUTENBERG ) {
    add_filter( 'gutenberg_can_edit_post_type', '__return_false' ); 
}   

Requisiten @tomjn @wpmark

Sie können dies heute tun, ohne Gutenberg oder den klassischen Editor installiert zu haben.
Beachten Sie jedoch, dass sich der Filtername ändern kann, wenn der Code in den Core eingefügt wird.
... an welchem ​​Punkt jemand Dokumente schreibt, und dann können Sie eine weitere Zeile hinzufügen.

Anmerkungen: Die Datei mit dem Namen my-hacks.php wurde 2003 eingeführt und 200x veraltet.
Aber nichts hindert Sie daran, es als ein Muss-Plugin in mu-plugins implementieren.

Wenn Sie sehen möchten, wie schwierig es ist, veralteten Code zu entfernen, einschließlich des damit verbundenen Optionsfelds
siehe WordPress TRAC # 33741 - Verweise auf my-hacks.php und die Option

Noch einfacher ... in wp-config.php

$_GET['classic-editor'] = true;

Ich denke, das Konzept des Blocks ist falsch. Meiner Meinung nach sollte ein Block ein Beitrag sein. Wenn wir also mehrere Inhalte in einem Beitrag benötigen, müssen wir untergeordnete Beiträge haben können. Wie Twitter, wo eine Seite von vielen unabhängigen Tweets erstellt wird.

Innerhalb eines Beitrags benötigen wir nur einen Texteditor.

Wir haben kein Budget, um alle unsere Seiten zu aktualisieren. Wenn wp keine langfristige Kompatibilität bietet, werden wir viele Anwendungen in Zukunft nur auf eine stabilere Community umstellen, da die Tür für neue Unternehmen offen wäre.

Jetzt ist WordPress wegen der Community cool. 5.0 bedeutet, bei 0 zu beginnen. Also, wie bei jedem anderen Framework.

Zwei Entwicklungslinien könnten eine gute Idee sein, anstatt sie zu deaktivieren oder nicht. WP normal und WP Gutenberg. Zumindest für die nächsten 5 Jahre. Dann hätte Gutenberg Zeit, stabil zu sein und auch eine Community zu haben, so wie WP.

Es wäre schön, wenn viele von Ihnen als Entwickler ein Problem hätten, warum nicht einfach einsteigen und weitermachen
Github mit einem Ticket, das eine Arbeitsmethode zur Lösung Ihres Problems vorschlägt, anstatt nur endlos zu schreiben, warum Sie nicht anders können, als mit dem aktuellen Gutenberg-Projekt eine Lösung zu finden.

Bringen Sie Ihre Programmierkenntnisse mit, um das Problem zu lösen.

Ich bin ein visueller Designer und plane derzeit, zwei meiner Kunden bei der Verlagerung der Bearbeitungsprozesse nach Gutenberg zu unterstützen. Derzeit entwerfe und baue ich eine neue Site für einen Kunden mit einer mehr als zwanzig Jahre alten Site, die sie nicht pflegen können.

Steigen Sie ein und helfen Sie dabei, WordPress.org als Tool zum Erstellen von Websites voranzubringen.

@ TomDesign hast du überhaupt versucht die Diskussion zu lesen? Das GB-Team möchte die Funktionalität nicht als Teil des Plugins. Wenn Sie also nicht unter "Bringen Sie Ihre Programmierkenntnisse mit, um das Problem zu lösen" meinen, dass jemand seine Konten hacken sollte, um einen Code hinzuzufügen, den er nicht möchte, bin ich mir nicht sicher, wie er Code schreibt ist hier auch aus der Ferne relevant.

@tomdesign Ich habe die Anforderung eines tragfähigen Migrationsplans in # 4981 angesprochen
Ich habe darauf hingewiesen, dass es viel Arbeit sein wird. Und es ist etwas, das ich für notwendig halte.

Ich bin sicher, dass es einige Entwickler gibt, die unsere Programmierkenntnisse nutzen möchten, um eine reibungslose Migration zu gewährleisten. Aber wir wollen unsere Zeit nicht damit verschwenden, etwas zu entwickeln, das sofort abgelehnt wird. Meiner Meinung nach verdient die Migration ein eigenes Projekt , wobei jede Anforderung logisch bewertet wird. Es ist wichtig genug, einen gut dokumentierten Vorschlag zu haben, der uns langfristig dorthin bringt.

Simons ursprüngliche Anfrage war eine kurzfristige Lösung für ein langfristiges Problem.
Ich glaube, dass der Prozess der Inhaltsmigration Jahre dauern wird.

Hallo Leute,
Lesen der Kommentare Ich denke, dies ist der richtige Ort, um ein gutes Plugin über Gutenberg zu teilen.
Ich möchte Ihnen ein kostenloses Plugin vorstellen, mit dem Sie den Gutenberg-Editor verwalten können.
Es heißt Gutenberg Manager und ermöglicht es Ihnen, den Editor in den verschiedenen Beitragstypen (einschließlich Seiten und Beiträge) zu aktivieren / deaktivieren. Es hat mehr Funktionen, aber ich überlasse sie Ihnen.

Wir haben unzählige Posts von Leuten gelesen, die sich über die zukünftige Implementierung von Gutenberg im Kern von WP 5.0 beschwert haben, und dies hat uns dazu gebracht, eine einfache Lösung zu finden.

Gutenberg Manager löst dieses Problem und ermöglicht es beispielsweise, Elementor, Visual Composer, Siteorigin Builder oder Cornerstone auch nach WP 5.0 problemlos weiter zu verwenden.
Nach dem ersten Benutzer-Feedback auf WP.org scheint das Plugin geschätzt zu werden :)

Aus diesem Grund möchte ich Ihnen Gutenberg Manager vorstellen -> https://wordpress.org/plugins/manager-for-gutenberg/

Das Plugin kann von Entwicklern dank einiger nützlicher Hooks in ihren eigenen Themes und Plugins verwendet werden. Es gibt einen Haken zum Ausblenden des Plugin-Optionsfelds, damit der Endbenutzer es nicht im WP-Backend sieht (großartige Funktion für Entwickler, die Gutenberg Manager in ihre Projekte aufnehmen möchten).

Wir treffen auch Vereinbarungen mit den Teams der bekanntesten Bauherren, um Partnerschaften und Kooperationen zu aktivieren. Auf diese Weise hoffen wir, den Übergang nach Gutenberg etwas weniger traumatisch zu gestalten!

Vielen Dank für Ihre Aufmerksamkeit,
Gut gemacht.

@unCommonsTeam Kann ich fragen, wie Sie den Gutenberg-Editor im Plugin deaktivieren, wenn beispielsweise diese Optionen in Ihrem Einstellungsbildschirm ausgewählt sind?

Sicher @wpmark ,

Schauen Sie sich die Zeile 79 an -> https://github.com/unCommonsTeam/gutenberg-manager/blob/master/inc/core.php

Beste

@unCommonsTeam danke, dass du zu mir zurückgekommen bist. Ich liege hier wahrscheinlich falsch, aber wenn es so aussieht, als würde das Plugin nur alle vom Gutenberg-Plugin hinzugefügten Dinge entfernen. Dies ist etwas, das ich oben vorgeschlagen habe, indem ich Folgendes verwende:

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

@Pento teilte jedoch mit, dass dies keine robuste Lösung sei, da ein Editor wieder in WordPress integriert wird. Siehe https://github.com/WordPress/gutenberg/issues/4409#issuecomment -357912790

@wpmark Ja, diese Funktion entfernt alle vom Gutenberg-Plugin hinzugefügten

Beste

@unCommonsTeam es sieht aus wie ein großartiges Plugin, aber ich denke, es würde unter den gleichen Problemen leiden wie meine Lösung, da es wirklich einen Editor wieder in WordPress hinzufügen muss.

@Pento sagte, dass das Entfernen der Gutenberg-Ergänzungen nur besagt, dass der

Wie @pento sagte:

Dieser Filter bedeutet nur "Blockeditor nicht laden", nicht "Klassischen Editor verwenden". Es funktioniert im Moment, aber es ist nicht garantiert, dass es in Zukunft funktioniert.

Daher denke ich (und ich muss natürlich korrigiert werden), dass Ihr Plugin dasselbe tut (aber natürlich viel besser und mit vielen coolen Optionen für Flexibilität usw.) als mein obiger Versuch.

Eine andere Sache, über die ich nachgedacht habe, ist, dass der Name Gutenberg herumhängt, wenn das Projekt in den Kern zusammengeführt wird, oder dass diese Funktion (z. B. gutenberg_init ) in (zum Beispiel) block_editor_init .

@wpmark du hast recht. Wir hoffen, dass sie in WP 5 den klassischen Editor dort lassen. Wir könnten jedoch versuchen, eine Option hinzuzufügen, um den klassischen Editor über das Plugin einzuschließen. Wenn das Entwicklerteam von WP beschließt, den klassischen Editor zu entfernen, wird unser Plugin unserer Meinung nach sehr beliebt sein :)

In Bezug auf die gutenberg-Benennung haben Sie Recht, wahrscheinlich müssen wir unser Plugin reparieren und die Namen der Hooks ersetzen.

Darüber hinaus bietet unser Plugin weitere Funktionen, die auf dem Gutenberg-Editor basieren (Aktivieren / Deaktivieren bestimmter Blöcke, neuer Blöcke usw.). Wir glauben, dass dies auch für die Benutzer nützlich sein wird, die den Gutenberg-Editor verwenden.

Prost

Dies kann eine gute Idee sein, die fast den gesamten Ansturm und die Debatte regeln wird:

Wenn Gutenberg im Kern standardmäßig deaktiviert ist und der klassische Editor weiterhin beibehalten wird, könnte dies dem WordPress-Theme- und Plugin-Markt von ca. 1 Milliarde US-Dollar und dem riesigen Internet eine Menge Ärger, Geldverluste, Support-Vorfälle und viel Einsparung von WP ersparen von Prestige und Vertrauensverlust als Plattform.

Gutenberg, obwohl ein moderner Editor, scheint für die Bedürfnisse von WordPress.com und ähnlichen Verkaufsstellen konzipiert zu sein, die Blogging- / Hosting-Dienste mit WordPress anbieten. Das ist alles gut und gut. Es sollte jedoch nicht zu einem Schock und einem Tritt in die Bälle für den Rest des Ökosystems führen. Ein riesiger Teil des Internets, die Websites der Menschen und ihr Lebensunterhalt werden von der aktuellen Richtung betroffen sein.

Auf WordPress.com kann Gutenberg standardmäßig aktiviert sein, während WP standardmäßig deaktiviert ist, wodurch das gesamte Ökosystem mit den besten Welten ausgestattet wird.

Ich muss Codebard zustimmen, dass Gutenberg standardmäßig deaktiviert ist und der klassische Editor weiterhin beibehalten wird. Aus genau diesem Grund sind derzeit automatische Updates deaktiviert. Ich möchte nicht, dass Bloggern in meinem Multisite-Netzwerk plötzlich dieser Editor vom Typ "Page Builder" angezeigt wird, und ich möchte auf keinen Fall, dass der klassische Editor vollständig ersetzt wird mit gutenberg.

Zumindest sollten wir in der Lage sein, gutenberg mit einer define-Anweisung wie define ('DISABLE_GUTENBERG', true) zu deaktivieren. Ein großes Problem mit einem Plugin zum Deaktivieren von gutenberg ist, dass wir dann darauf angewiesen sind, dass der Entwickler das Plugin bei Bedarf wartet und aktualisiert. Was würden wir in den Tagen oder Wochen tun, in denen das Plugin nicht mehr funktioniert, weil der Entwickler im Urlaub ist oder anderweitig zu beschäftigt ist, um das Plugin zu aktualisieren? Es gibt auch das Problem, dass Benutzer des Plugins das Plugin am Ende aktualisieren müssen.

Es scheint, als würde uns Gutenberg aufzwingen und dann Problemumgehungen finden, um es nachträglich zu deaktivieren, ist eine wirklich rückständige Art, Dinge zu tun. Bitte machen Sie gutenberg standardmäßig deaktiviert. Viele von uns, die nur ein einfaches Blog wollen, finden es immer schwieriger, WordPress zu verwenden, da es sich zu einem Website-Builder zu entwickeln scheint.

Ein weiterer Hinweis: Bei Netzwerken mit mehreren Standorten sollte der Netzwerkadministrator entscheiden können, ob gutenberg im gesamten Netzwerk verfügbar gemacht werden soll.

@WebTrooper Das Classic Editor- Plugin wird vom WordPress-Entwicklerteam (dieselben Leute, die Core verwalten) und die Gutenberg-Rampe von Automattic verwaltet, sodass beide gegen die Faktoren "Entwickler im Urlaub" oder "zu beschäftigt" immun sein sollten.

Beachten Sie, dass VIP dem Gutenberg Ramp-Plugin verpflichtet ist, das auf der Website unserer Kunden und auf unseren eigenen Websites verwendet wird. Im Urlaub zu sein oder zu beschäftigt zu sein, wenn Dinge kaputt gehen, könnte kaputte Kundenstandorte bedeuten, was das Letzte ist, was VIP will.

Ich würde auch bemerken, dass diese Plugins gegabelt werden können, Automattic und die Autoren und des klassischen Editor-Plugins verfügen weder über geheime Kenntnisse, die es ihnen ermöglichten, diese Plugins zu erstellen, noch sind sie technisch groß oder komplex. Es gibt Hunderte von Agenturen auf der ganzen Welt mit Entwicklern, die beide Plugins verwalten können.

Abgesehen davon argumentieren viele Leute, dass gutenberg standardmäßig deaktiviert wird, aber ich habe festgestellt, dass alle ungeachtet der Begründetheit dieser Argumente nicht sagen, wann genau GB standardmäßig aktiviert sein sollte. Die logische Schlussfolgerung ist eine immerwährende klassische Editorsituation.

Es ist 2934, das galaktische Reich ist in das System gesprungen, 300 Schlachtkreuzer. Das lokale planetarische Nachrichtennetzwerk hat den klassischen Redakteur angefeuert, um einen Bericht für die lokalen Bürger zu verfassen. Niemand erzählte ihnen von Gutenberg, bevor sie mit dem Bau des Geländes begannen

Ich habe immer vorgeschlagen, dass es für NEUE Installationen standardmäßig aktiviert ist.

Aber für bestehende Installationen würde ich einen benutzergeführten Ansatz vorschlagen, der es den Nutzern ermöglicht, sich für Gutenberg zu entscheiden, es auszuprobieren, es zu behalten, wenn es ihnen gefällt, und auf den klassischen Editor zurückzugreifen, wenn sie es nicht tun. WordPress könnte dann Statistiken und Feedback sammeln, wenn / wenn Leute zurückwechseln, um bei der Entwicklung und Dokumentation für die Änderung zu helfen.

Wenn eine kritische Masse an aktiven Standorten erreicht ist, können Sie diese standardmäßig aktivieren. Und nein, ich werde keine Nummer aus der Luft holen. Aber wir könnten den Verbrauch messen und angemessen handeln.

Alternativ reicht der 12. April 2020 aus. 😉

Das passiert bei alten PHP-Versionen, oder? WordPress war unermüdlich in seiner Abwärtskompatibilität von PHP 5.2, weil die Leute es immer noch verwenden, in vielen Fällen wahrscheinlich ohne es zu wissen oder sich darum zu kümmern. WordPress analysiert die Statistiken sorgfältig. viel Aufwand in die Koordination mit den Gastgebern stecken und so weiter; und Menschen sanft auf einem Upgrade-Pfad führen. Und vermutlich wird das Projekt irgendwann auf die Nutzungsdaten reagieren, die es für eine Entscheidung benötigt.

Doch mit einer völlig neuen Benutzeroberfläche zum Bearbeiten, die Benutzer kennen und sich für den Ansatz interessieren, ist es, ihn ihnen aufzuzwingen?

So sehr ich mich jetzt in einigen Fällen tatsächlich für Gutenberg einsetze, hoffe ich wirklich, dass der Fusionsvorschlag die Bedenken von Leuten wie mir berücksichtigt, die viele Websites für Endbenutzer verwalten, von denen viele über schlechte IT-Kenntnisse verfügen nicht mit Technologie vertraut, und wird von Gutenberg verwirrt und desorientiert sein.

Ich denke, Gutenberg sollte aus den folgenden wichtigen Gründen auch für NEUE Installationen ausgeschaltet sein:

• Es gibt fast unendlich viele Tutorials, Ressourcen, Anleitungen und alles, was Sie sich vorstellen können, basierend auf dem vorhandenen Editor. Diese machen den Einstieg von Menschen in WordPress SEHR einfach.

• Diese einfache Eingabe ist sehr wichtig, da die Leute, weil sie so einfach anfangen, verstehen, dass "WordPress einfach ist", und die Plattform leicht wahrnehmen, eine akzeptablere und selbstbewusstere Haltung gegenüber dem Erlernen der Plattform einnehmen

• All dies kombiniert sich zu der Wahrnehmung von "WordPress funktioniert einfach" und sie empfehlen es bequem ihren Kollegen. Auf diese Weise konnten wir auf 30% des Internets wachsen.

• Konsistenz der Informationen ist wichtig. Und es gibt keine Möglichkeit, dass jede einzelne Ressource im Internet aktualisiert wird, um gutenberg auch in Zukunft widerzuspiegeln. Es wird viel Verwirrung stiften. Und am unglücklichsten ist die Reaktion eines normalen Benutzers "Ich habe es installiert, aber es funktioniert nicht", nur weil er / sie nicht finden kann, wie man Dinge macht und Dinge nicht so aussehen wie das Tutorial, das er oder sie verwendet. Machen Sie keinen Fehler, kein Aufwand an Updates wird diese Verwirrung in Bezug auf Ressourcen, Tutorials usw. beseitigen.

Daher sollte Gutenberg optional und umschaltbar sein, um die Abwärtskompatibilität nicht nur in Bezug auf Themen, vorhandene, von Seitenerstellern erstellte Inhalts-Plugins usw., sondern auch in Bezug auf die online verfügbaren Ressourcen aufrechtzuerhalten. Eine Plattform ist nicht "so einfach" und Sie können sie nicht Leuten empfehlen, die sagen "Installieren Sie sie einfach und googeln Sie ...", wenn Google viele verschiedene veraltete und aktuelle Ressourcen zusammenbringt. Und wenn Sie SEO-Erfahrung haben, wissen Sie, dass es ...

Mit Gutenberg können wir den angeblich steigenden Markt für Site Builder (Wix, Squarespace usw.) und den potenziellen Markt für einfaches Bloggen (a la Medium usw.) erschließen. Aber wenn wir dabei einen Bruchteil von 30% des Internets oder des Marktes für Themen / Plugins im Wert von ~ 1 Milliarde US-Dollar brechen, wird dies ein massiver Kick in die Eier, von dem wir uns in einem Jahrzehnt möglicherweise nicht mehr erholen können.

Sie können kein klassisches PHP-Plugin installieren, daher ist der Vergleich mit PHP nicht relevant. Dies sind Millionen von Websites, die garantiert kaputt gehen würden, ohne eine WP-basierte Lösung, die dies lösen würde, daher die sorgfältige Analyse. Beachten Sie auch, dass die nächste Version eine Eingabeaufforderung enthält, mit der das klassische Plugin installiert wird. Benutzer werden nicht nur aufgefordert, das Gutenberg-Plugin zu installieren.

In beiden Fällen wurde dieses Problem geschlossen und Entscheidungen getroffen. Ein geschlossenes Thema ist ein schlechter Ort, um zu versuchen, einen Ansatz zu ändern, der an anderer Stelle geplant ist.

Aber denken Sie daran , dass Gutenberg ist Toggle-able, gibt es Plugins für beide aktivieren und deaktivieren es. Es ist Jahre her, seit GB gestartet wurde, mit viel Zeit zum Testen, Zeit zum Trainieren von Kunden, Zeit zum Installieren des klassischen Editor-Plugins usw. Dies ist keine neue Sache, die den Leuten über Nacht aufgezwungen wird

Ich habe festgestellt, dass unabhängig von den Vorzügen dieser Argumente nicht alle sagen, wann genau GB standardmäßig aktiviert sein sollte.

Und selbst wenn die Leute, die diese Argumente vorbrachten, einen Vorschlag gemacht hätten, wann dies geschehen sollte, würde es sowieso abgewiesen werden. Warum also?

Ich weiß, wie geschlossene Tickets funktionieren. Sie haben hier eine ziemlich sarkastische Seite gemacht. Also habe ich versucht, als Antwort etwas Konstruktives anzubieten.

@tomjn Ich werde @rosswintle hier sage , dass wir vorgeschlagen haben, dass es standardmäßig nur für Neuinstallationen aktiviert sein soll - https://github.com/WordPress/gutenberg/issues/4423. Dies ist ein weiteres geschlossenes Thema, das ohne wirkliche Diskussion des Punktes geschlossen wurde.

Sie sind nicht bereit zuzuhören, es gibt ein Plugin, bla bla bla, das ist geschlossen. Bewegen Sie sich entlang nichts zu sehen. Es geht nur um .com. Niemand kümmert sich um .org. Dort gibt es kein Geld für Automatic.

@ smp303 kannst du bitte identifizieren wer sie sind?

@rosswintle Es war kein Sarkasmus beabsichtigt, Gutenberg 0.1.0 wurde vor 14 Monaten veröffentlicht. Die einzige Möglichkeit, zu verhindern, dass Websites, auf denen 5.2 ausgeführt wird,

Sie sind nicht bereit zuzuhören, es gibt ein Plugin, bla bla bla, das ist geschlossen. Bewegen Sie sich entlang nichts zu sehen. Es geht nur um .com. Niemand kümmert sich um .org. Dort gibt es kein Geld für Automatic.

Ich muss zustimmen. Ob hier oder im WordPress-Support-Forum, es scheint, dass sie sich anscheinend überhaupt nicht darum kümmern, obwohl viele Leute in der Community dagegen sind. Da WordPress Open Source ist, möchte ich jedem vorschlagen, eine Petition zu diesem Thema zu erstellen. Ich persönlich glaube und schlage vor, dass GB ein Plugin wie Jetpack sein sollte, anstatt es in den Kern zu integrieren.

Nebenbei bemerkt:

Dieser Thread hat sich von der Diskussion, warum es keine codebasierte Option zum Deaktivieren von Gutenberg gibt, zu impliziten oder direkten persönlichen Angriffen von Sockenpuppenkonten gewendet.

Ich schätze, dass einige Leute sich ziemlich leidenschaftlich für dieses Thema fühlen, und es ist bedauerlich, dass dieser Thread diesen Weg gegangen ist, aber die Entscheidung wird sich nicht ändern.

Das Plugin für den klassischen Editor ist die Option, um auf einer gesamten Site zum klassischen Editor zurückzukehren. Es wird in der kommenden Version von WordPress 4.9.8 als Option für die Installation in Vorbereitung auf WordPress 5.0 prominent angekündigt.

Wenn Sie ein Site Builder sind, der Ihre Kunden vom Blockeditor abmelden möchte, ist die Installation des Classic Editor-Plugins (und die Bereitstellung von Fehlerberichten oder Korrekturen ) die beste langfristige Lösung, um sicherzustellen, dass der Classic Editor weiterhin verfügbar ist.

Bei Metaboxen ist es bereits möglich, den Blockeditor zu deaktivieren. Diese API wird in Core zusammengeführt. Bei CPTs wird der Filter gutenberg_can_edit_post_type beim Zusammenführen umbenannt (wahrscheinlich in block_editor_can_edit_post_type oder ähnliches), ist jedoch auch als codebasierte Option verfügbar.

Um zu vermeiden, dass sich dieser Thread weiter entwickelt, werde ich ihn sperren.

Jeder, der an dieser Diskussion beteiligt ist, ist herzlich eingeladen, weiterhin an der Vorbereitung von Gutenberg auf WordPress 5.0 teilzunehmen. Beachten Sie jedoch, dass persönliche Angriffe absolut nicht erwünscht sind und dazu führen, dass Probleme gesperrt oder Konten gesperrt werden.