irishetcher

To be expected, the dev team now have a lot of food for thought to work on.

Yes I did notice the absence of an interface for revisions and glad that it is being considered.

Also, say I have no or very little programming experience, how difficult a task is it to develop blocks? I am only asking out of curiosity.

I won’t be using Gutenberg for the foreseeable future as the as it does not fit with the workflows and use cases I have developed and use in the last ten years I have been using WordPress but I do intend to keep an eye on developments as things go on and send in feedback.

There are many things that could be done to make the transition less painful and less worrisome. And some big opportunities that were missed along the way regarding something that should have been tackled years ago, namely an improved text editing experience for developers, as in a better IDE experience online much in the vain of CodePen or Codeacademy.

On the other end of the spectrum, with all these blocks, I would have thought that using them for page structure and layout we should have a mechanism for sections/columns/rows or flex or grid etc… I know we are not meant to see Gutenberg as a page builder, but why not, Gutenberg seems to be falling between two stools. It could be a basic for foundation for such a thing both as an intro for new users and novices to page building and as something with a good API with which vendors of page builders could add their bells and whistles and interfaces. This would bring a sense of uniformity to this area and make switching themes and builders less of a hassle. And, of course this would be optional, as page builders are not something that everybody likes so turning of the builders and blocks for such a mechanism would return all content to an unadulterated state, ready for reformatting in a different manner.

Hopefully the team are cognisant of all the discussions and pain points that are being discovered as people start to test Gutenberg.

utilisateur -> user -> someone who exploits somebody else. Correct?

• This reply was modified 7 years, 9 months ago by irishetcher.

Technically both the current editor and Gutenberg can exist in core. Gutenberg is just a REACT override of the current editor. The Classic Editor, if activated, prevents this override therefore suggesting that the same thing could be incorporated completely in core with a toggle on/off in Reading settings.

I see and get why those who are able to work with it are having a frictionless experience with it as it fits with their workflow and use case of placing content into a post one block after another. At the same time it removes a lot of the functionality that is catered for in the current editor and this is not just about content creation. A lot of other functionality is happening in that interface. It’s not all about the the content area.

In a addition some obvious improvements that are long called for in the current editor are not being tackled by Gutenberg, namely bringing a better editing experience to the text tab in TinyMCE (or its replacement) in the form of a proper IDE interface with respect for indentation, code hinting, colour coding for syntax, dark mode and respect for indentation of the coed block. On the other end of the spectrum, a structure system for page layout: sections/rows/columns, grid, flex or, whatever you are having yourself. This would be a basic foundation with an API for page builders to integrate with. This would solve the sticky task of dealing with changing themes/builders or turning them of altogether and the need not to have shortcodes as is the case with some of the builders.

It’s surprising why the Gutenberg (classic if you want, plugin) editor choice is being implemented in this way. I think the Gutenberg concept would get a better reception if it wasn’t been touted as the de-facto default editor with a big question mark left over the current editor. As it is, the approach has left a lot of people confused and angry. They could have opted to showcase Gutenberg as the editor in TwentyEighteen and other themes that are developing in that direction. This would have allowed for a narrower but better implementation of features that best show Gutenberg’s potential instead of the scrabble to implement everything for a big waterfall release where issues arise.

The future landscape looks uncertain for developers and users who want and need to still use the current editor with no copper-fast guarantees of how long it will be around for. We don’t know if and when the current (Classic) editor will be ripped out altogether.

It’s the kind of environment where schisms are unavoidable.

• This reply was modified 7 years, 9 months ago by irishetcher.

Cheers Marius,

That helps a lot in how we can mange working with themes and transitions between sites that are partially using Gutenberg and those that need to still work with the current editor.

Hi Marius,

I am reading this with interest. the fact that Gutenberg will fallback to the current editor, if a post type does not conform to certain requirements will happen without the Classic editor installed suggests that the current editor is/will be still present in core but generally overridden by Gutenberg.

Also, if you disable the Editor content text area, as you can do with Toolset Types, you set up your CPT to not conform to the requirements for Gutenberg. You might do this if you want to restrict the backend to a form that takes specific data values for a product or item. Somebody might find this useful.

There is a filter that can be applied to completely disable Gutenberg:

add_filter(‘gutenberg_can_edit_post_type’, ‘__return_false’);

I have tested this and it works.

I understand that the name of this may be changed on the release of WordPress 5. Can you confirm and is there any information on what the filter will be called?

Much appreciated if you can give me an answer. I have been seeking an answer on this for a while.

While I don’t necessarily agree that we should impose a page builder interface as an editor (I know Gutenberg does not purport to be such a thing), Concrete5, from what I can see from their video is way ahead in this aspect, straight in from the front end what you really see is what you get.

Again, forcing Gutenberg as is a the de-facto editor or something like a builder is not a good idea as it is very limiting for those, especially developers, who prefer to work purely in code.

LOL

“Installé, testé, détesté, désinstallé”

Bien dit. C’est comme le phrase: Liberté, Égalité, Frugalité. Gutenberg, un peu comme le “Shock of the New, pour nous, peut-étre.

Désolé, apparement il faut que nous devrions passer un peu plus de temps avec Gutenberg avant de l’envoyer à Madame Guillotene.

It’s not even great as a layout tool. Even the makers of Gutenberg proclaim it not to be, that it is for content creation, whatever they mean by that. There are several very good page builders out there already, if that is way you want to work. If not

It seems Gutenberg has narrowed down the field of opportunity for WordPress users to work in the way that bests suits their workflows and use cases. Boatmik, in the above, demonstrates some of the pain points very clearly.

The current editor, while not perfect, is flexible and functional. Areas where it falls down are in the text tab of TinyMCE which has been in need of some sort of update to make it more developer friendly and useful.

We all have been there. Put all your content together with HTML markup in Sublime text, then copy and paste into TinyMCE and the copy/paste dance goes on until we have the result we want. The work is never exclusively done in TinyMCE unless it is for a trivial amount of content.

For example, the option to give the TinyMCE text tab a bigger canvas on the screen, colour coded syntax, proper indentation respected by copy and paste, code completion and a dark mode, all the little things that would afford a better UX for people who like to code and mark up things is much needed. Sites like Codeacademy have achieved this so its not beyond the bounds of possibility that the same thing could have been done in WordPress. In fact the recent addition of code mirror to WordPress for working on the core files was introduced recently but never made it into the editor. Elegant themes partially implemented it in the code module in Divi so all this is possible.

And that just covers specifically the text area for content entry. There is a lot more on the edit page dashboard other then TinyMCE. There can be many optional tools in the form of metaboxes that are now choked by the Gutenberg experience. The flexibility to arrange, hide or collapse boxes for Yoast, custom field groups, template pickers is now very limited.

Yes I do like the fact that the post updates in Gutenberg are done through AJAX and that working with blocks has the potential to suit a certain type of workflow.

The big issue is how the team are implementing the update by forcing it as the de-facto editor as of WordPress 5. The fact is Gutenberg is a REACT override of the current editor. There are many ways to disable it including the option to use the Classic Editor Plugin. More interestingly Gutenberg can be triggered to fall back to the current editor if were to configure a Custom Post Type or, even regular post or page, so that they don’t conform to certain requirements for the Gutenberg interface to load. There is even a filter you can use in the functions.php file of a child theme that will globally disable Gutenberg without the need to uses the Classic Editor Plugin, though this filter is flagged for a name change on the release of WP5.

This raises the question why Gutenberg is not added as an option in core along with the current editor. Even triggering it on for themes that are built to work well with it (TwentyEighteen etc.). This approach would have prevented much of the criticism and allowed the developers to work on a much narrower set of requirements that didn’t have to make attempts at covering all use cases at once and being compatible with all plugins and themes. As it is it seems that the rush has thrown up all sorts of issues and incompatibilities. It probably has put a lot of pressure on the developers of third party tools when they should have been focusing on future feature releases and efficiencies in their work.

And, some opportunities missed. Namely where page builders are being used for layout. Blocks could have been used to solve the big issue with these and related themes whereby switching between them, if needed, has been problematic. Blocks could be designed for all the major layout structures -> section/row/column, grid and flex. A new editor could have provided the basic foundation for all this with an API for the vendors of page builders to add their own bells and whistles and interfaces.

But no, nothing as intelligent as this. Just a big PR mess.

• This reply was modified 7 years, 9 months ago by irishetcher.