Gutenberg widgets block editor is a mess of errors

Paal, with Guttenberg now at version 9.9.3, it still has at least one unresolved issue that I raised four months ago.

This is still an issue:

I’m also seeing a change in the Inactive Widget area. I placed a Custom HTML widget with some HTML content in the Inactive Widget area using the old widget editor, then went to the new block widget editor page. The content initially showed blank. Clicking in the content section activated the widget and showed the content, but the lines of HTML are now being overlayed by line numbers.

Looking into the html, I find:

<div class="CodeMirror-gutter CodeMirror-linenumbers" style="width: 1px;"></div>

and

<div class="CodeMirror-gutter-wrapper" style="left: 0px;" contenteditable="false"><div class="CodeMirror-linenumber CodeMirror-gutter-elt" style="left: 16px; width: 1px;">4</div></div>

Note the style: width: 1px and the left: 0px. These are obviously wrong

I did this test using a Twenty Twenty-one themes. It is very simple to do, so I don’t understand why it hasn’t been fixed.

Clicking Preview for this incorrectly rendered Edit also displays nothing!

The issue with the plugin Widget CSS Classes not showing the CSS Classes edit boxes still persists. I’m still trying to determine whether this is a plugin problem or a Gutenberg problem.

Hey @drtonyb

I have passed your comment onward. Hopefully you will soon receive a reply.

Have a great day!

Howdy @drtonyb ,

A lot of the problems in the new Widgets editor have been addressed but there is still a lot to solve. Thank you for testing. As the plugin’s descriptions mentions (perhaps too hidden):

The Gutenberg plugin gives you the latest version of the block editor so you can join us in testing bleeding-edge features, start playing with blocks, and maybe get inspired to build your own.

Hence some of the “bleeding-edge features” are prone to have in progress work, and the goal is to collect useful feedback from real world scenarios. Your use of the Gutenberg plugin and reporting of problems IS part of the testing ??

When attempting to update such well established parts of WordPress early feedback is required, that is why the Widgets editor is the default in the plugin. Other features are hidden in the plugin behind an experimental flag, but eventually they too will become a default of the Gutenberg plugin.

Now, back to the recent issue, is this happening while using this plugin ?

Hi Andei,

I’m not using that plugin.

I don’t know if this is related to this issue or not, but I am developing a custom theme and am using the new Block widgets screen from the Gutenberg plugin. New widget areas registered in functions.php will not appear until after I turn on a different theme, then switch back to the theme I am developing. I’m assuming this is a caching issue.

Since I can easily solve it while developing the theme, it’s not a big deal, just thought it might be related. That also may be expected behavior.

I have just updated to Gutenberg 10.1 and there is some progress in the Block Widgets screen.

The good news is that the plugin Widget CSS Classes is now showing the CSS Classes edit boxes.

The bad news is:

1. A Custom HTML widget in the Inactive Widget area still doesn’t render content in its edit field until the field is clicked and then, the line numbering and text lines overlap – bad css.

2. Previewing the Custom HTML widget in the Inactive Widget area still shows nothing.

3. In the backend, the dynamic_sidebar_params hook receives a $params argument like:

array (
  0 => 
  array (
    'name' => 'Footer',
    'id' => 'sidebar-1',
    'description' => 'Add widgets here to appear in your footer.',
    'class' => '',
    'before_widget' => '<section id="-1" class="widget widget_tag_cloud">',
    'after_widget' => '</section>',
    'before_title' => '<h2 class="widget-title">',
    'after_title' => '</h2>',
    'before_sidebar' => '',
    'after_sidebar' => '',
    'widget_id' => -1,
    'widget_name' => 'Tag Cloud',
  ),
  1 => 
  array (
    'title' => 'Tags',
    'count' => '0',
    'taxonomy' => 'post_tag',
  ),
)

In the frontend, the dynamic_sidebar_params hook receives a $params argument like:

array (
  0 => 
  array (
    'name' => 'Footer',
    'id' => 'sidebar-1',
    'description' => 'Add widgets here to appear in your footer.',
    'class' => '',
    'before_widget' => '<section id="tag_cloud-2" class="widget widget_tag_cloud">',
    'after_widget' => '</section>',
    'before_title' => '<h2 class="widget-title">',
    'after_title' => '</h2>',
    'before_sidebar' => '',
    'after_sidebar' => '',
    'widget_id' => 'tag_cloud-2',
    'widget_name' => 'Tag Cloud',
  ),
  1 => 
  array (
    'number' => 2,
  ),
)

Notice the $params[0][‘widget_id’] for the backend is -1, the id for the html in $params[0][‘before_widget’] is -1, but in the frontend these are ‘tag_cloud-2’.

It did my tests with the Twenty Twenty-One theme, adding a dynamic_sidebar_params filter to functions.php to debug the $params argument.

So, there is still more work needed on this feature.

I have just checked Gutenberg 10.5.2 only to find that the Block Widgets screen has taken an unbelievable step backwards.

In 10.1, a plugin I use called Widget CSS Classes was finally showing its CSS Classes edit boxes.

Now, the CSS Classes edit boxes are gone and in its place is just some information showing me what classes are set:

Default classes: class-a class-b whatever

It’s not editable! I can’t change a class, add a class or remove a class.

This is just becoming ridiculous.

For me as a developer, the whole Gutenberg project is becoming a total nightmare. It is slow, painful and won’t easily do what I want, taking 10 times longer to create a page than using the old editor. It seemed like a very good idea at first, but I now feel that it has become a complete time waster. I’m very disappointed.

In my previous post the Default classes: I mentioned is part of my custom widget. So ignore that.

The issue is that the plugin Widget CSS Classes uses the action ‘in_widget_form’ to render its text box html after the widget settings content.

The Blocks Widgets code doesn’t seem to be ‘doing’ the ‘in_widget_form’ action when it renders the widget. It did in 10.1, but not now in 10.5.4.

Just tried the Customizer and found that widgets get rendered with the Widget CSS Classes plugin’s CSS Classes edit box. So at least that works.