Support » Plugin: Gutenberg » Gutenberg widgets block editor is a mess of errors

  • The new Gutenberg widgets block editor that was included with Gutenberg 9.0.0 had lots of problems which have now gotten worse since the update to 9.1.0.

    1. My theme has 13 registered widget areas (side bars). The new widget block editor only shows the first 9 of them.

    2. I use a plugin (Widget CSS Classes) which adds a custom class field to all widgets. The custom class field is not displayed by the new block widget rendering.

    3. I have an unused HTML widget parked in Inactive Widgets. In Gutenberg 9.0.0 this caused the following errors:

    PHP Notice: Undefined index: before_widget in \wp-includes\widgets\class-wp-widget-custom-html.php on line 168
    PHP Notice: Undefined index: before_title in \wp-includes\widgets\class-wp-widget-custom-html.php on line 172
    PHP Notice: Undefined index: after_title in \wp-includes\widgets\class-wp-widget-custom-html.php on line 172
    PHP Notice: Undefined index: after_widget in \wp-includes\widgets\class-wp-widget-custom-html.php on line 177

    The Inactive Widget Block Area is obviously not defining these entries, yet the WP_Widget_Custom_HTML class’ widget method is expecting them in its $args parameter.

    4. The following php warning is being generated multiple times when the widget block editor is loaded:

    PHP Warning: call_user_func() expects parameter 1 to be a valid callback, cannot access private method WP_REST_Widget_Utils_Controller::is_valid_widget() in \wp-includes\rest-api\class-wp-rest-request.php on line 898

    5. In 9.1.0 when I try Preview a widget, instead of the seeing the rendered widget, I see this:

    PHP Fatal error: Uncaught Error: Call to a member function render() on null in \wp-content\plugins\gutenberg\lib\widget-preview-template.php:37

    When is the development team going to do some proper testing before they inflict this badly coded plugin on users?

    Seems to be still experimental, so I’m pulling the plug on the new Gutenberg widget blocks until I see some real progress towards fixing it.

Viewing 9 replies - 16 through 24 (of 24 total)
  • Thread Starter drtonyb

    (@drtonyb)

    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.

    Plugin Support Paal Joachim Romdahl

    (@paaljoachim)

    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 ?

    Thread Starter drtonyb

    (@drtonyb)

    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.

    Thread Starter drtonyb

    (@drtonyb)

    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.

    Thread Starter drtonyb

    (@drtonyb)

    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.

    Thread Starter drtonyb

    (@drtonyb)

    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.

    Thread Starter drtonyb

    (@drtonyb)

    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.

Viewing 9 replies - 16 through 24 (of 24 total)
  • You must be logged in to reply to this topic.