Widgets editor: "There was an error. object Object" on save

[adam-ma-roberts]

Describe the bug
In the widgets area, I do not get access to the Save button unless i duplicate a whole block and then edit that save everything and then go back and delete the original block.

Since the last gutenberg update even after duplicating the block and editing it, when i get the save button, it changes to Saving ... and in the bottom left i get a very quick error message saying "There was an error. object Object"

Having googled and checked here, i can confirm i get access to wp-json with no issue

and as soon as i deactivate Gutenburg plugin, go back to the block editor ... i paste the text in where i want it, hit save and all done.

To reproduce
Steps to reproduce the behavior:

1. Go to 'widgets'
2. Edit anything ...
3. No access to save button
4. Duplicate block to edit
5. Edit the duplicate block
6. Click save
7. Quickly check for error message in bottom left

Error message : "There was an error. object Object"

and the save button sticks on "Saving"

Expected behavior
Well i have been living with the having to duplicate edit, save, return, delete old copy, save again, check ...

But clearly i would prefer the save to work with out having to go through all of that. Just a working save button after i edit some thing would be better.

Screenshots
If applicable, add screenshots to help explain your problem.

Editor version (please complete the following information):

• WordPress version: 5.5.3–en_GB
• Does the website has Gutenberg plugin installed, or is it using the block editor that comes by default? gutenberg plugin
• If the Gutenberg plugin is installed, which version is it? Version 9.4.1

Desktop (please complete the following information):

• OS: windows 10 latest updates
• Browser chrome
• Version Version 86.0.4240.198 (Official Build) (64-bit)

Additional context
Hosted on 20i's wordpress cloud.
With jetpack installed

• To report a security issue, please visit the WordPress HackerOne program: https://hackerone.com/wordpress.

[mobilemojo]

i can confirm this issue with 5.5.3 german.
It works with classic editor, and deactivated gutenberg blocks 9.4.1

[antonborgstrom]

I can confirm this issue with gutenberg 9.4.1 and WP 5.5.3 when trying to save any type of block in the widget area.

Request headers:
:path: /wp-json/wp/v2/sidebars/header-widget-area?_locale=user

Request payload:
{"id":"header-widget-area","widgets":[null]}

Response:
{"code":"rest_invalid_param","message":"Ogiltiga parametrar: widgets","data":{"status":400,"params":{"widgets":"widgets[0] \u00e4r inte av typen object,string."}}}

[Aljullu]

I can reproduce this issue consistently in master:

What is shown in this GIF:

1. In a widget area with several blocks, adding a new block between existing blocks and saving works as expected.
2. Adding a new block at the end of the list and saving, causes a 400 error and it's not saved.

Investigating this a bit further, the sidebars endpoint expects every item in the widgets array to be a string or object. However, for some reason, blocks added at the end, are null. These are the two API calls to /sidebars/sidebar-1 generated during the GIF above:

When adding the new block between existing blocks:

When adding the new block after existing blocks:

I could reproduce the issue above with themes Twenty Twenty and Storefront with WP 5.6.

[strarsis]

+1, can reproduce this issue with latest WordPress 5.6 and Gutenberg plugin v9.5.2.
Server response: {"code":"rest_invalid_param","message":"Invalid parameter(s): widgets","data":{"status":400,"params":{"widgets":"widgets[0] is not of type object,string."}}}
Related plugin: https://wordpress.org/plugins/disable-widget-block-editor/

[richardtape]

Similar issue here, but maybe I can add a little more context. I've tried with both twentynineteen and twentytwentyone - both with the same error as reported here.

Further, in the sidebar are 2 classic widgets: Search Widget and Recent Posts Widget. (These were in the sidebar before adding and activating the gutenberg plugin)

If I update the title of the Search Widget, the Update button becomes available and clicking on it saves everything as one would expect. If I manually refresh the screen, the adjusted title is present. Nice!

However, if I try to update the title of the Recent Posts widget, the update button becomes available again, but when pressed, a notification of 'widgets saved' is shown, and the update button is stuck on "Saving..." -- nothing appears in the Network tab, so it appears no request to the server is being made. If I refresh the page manually, the edited title is lost. Aww.

If I try to add a new block (seemingly any, I've tried with paragraph, list, image, and another recent posts widget), the block is added to the sidebar. But upon pressing update, I see the error message folks have reported above.

I've tried with WP Core 5.5.2 and 5.6 as well as Gutenberg 9.5.1 from the plugins repo and 9.5.2 available by cloning this repo and running npm run ci and npm run build

[Azragh]

Same issues with version 9.6.2

[noisysocks]

Can confirm that if I load up the Widgets screen, add a paragraph, click Update, I see that error. Happens with image blocks too.

[lionzeye]

When the widget section is in its 'factory state' saving doesn't seem to POST to REST route /wp/v2/sidebars/sidebar-1.

When a Gutenberg text block is added before the existing widgets, saving is successful with the following POST payload:

{id: "sidebar-1", widgets: ["block-1", "search-2", "recent-posts-2", "recent-comments-2"]}

When a Gutenberg text block is added after the existing widgets, the error occurs and the payload is:

{id: "sidebar-1", widgets: ["search-2", "recent-posts-2", "recent-comments-2", null]}

The error is a 400 (rest_invalid_param), stating that array value at index 3 should be an object or a string

[talldan]

I did some debugging—I'm not that familiar with the code, so this requires some further insight.

What seems to be happening:

• When saving a sidebar, the list of widget ids for that sidebar is required first.
  https://github.com/WordPress/gutenberg/blob/master/packages/edit-widgets/src/store/actions.js#L127
• If a widget hasn't been saved yet, it won't have an id, so undefined is set in this array, I think that's what the comment here refers to:
  

  gutenberg/packages/edit-widgets/src/store/actions.js

  Lines 133 to 135 in d94b354

  	// We'll replace the null widgetId after save, but we track it here
  	// since order is important.
  	sidebarWidgetsIds.push( widgetId );

• The widget should be saved here, but in actuality, I never see a request made from the client:
  

  gutenberg/packages/edit-widgets/src/store/actions.js

  Lines 169 to 173 in d94b354

  	// This is a new widget instance.
  	dataDispatch( 'core' ).saveEntityRecord( 'root', 'widget', {
  	...widget,
  	sidebar: widgetAreaId,
  	} );

• After that the sidebar is saved. Because the widget was never saved it has no id and therefore null is sent to the REST API, and the REST API returns an error.

So from what I can tell, the key bit that seems to go wrong is saving new widgets—this might be related to the batching system that widgets seem to use. I'd need to spend some more time looking at the code to understand how it works.

[noisysocks]

Did a little digging as well. Haven't figured out what's causing this yet but I did notice while investigating this that #27885 resets all of the client IDs in BlockEditor which means they no longer match up with the client IDs in clientIdToWidgetId. This breaks updating widgets.

[danielcharrua]

I can confirm this is also happening with Gutenberg 9.7.0 & WP 5.6. When trying to save any widget, no matter the sidebar or position. For this test I have added a paragraph block and try to save on sidebar-1.

Request {"id":"sidebar-1","widgets":[null]}

Response

{
    "code": "rest_invalid_param",
    "message": "Invalid parameter(s): widgets",
    "data": {
        "status": 400,
        "params": {
            "widgets": "widgets[0] is not of type object,string."
        }
    }
}

[strarsis]

+1, this issue currently prevents me from using widgets with Gutenberg.

[noisysocks]

So how this is supposed to work is:

1. saveWidgetArea calls saveEntityRecord for each new widget that needs to be persisted

   gutenberg/packages/edit-widgets/src/store/actions.js

   Line 170 in b3620b5

   dataDispatch( 'core' ).saveEntityRecord( 'root', 'widget', {

2. saveEntityRecord calls apiFetch which is to do the POST /widgets

   gutenberg/packages/core-data/src/actions.js

   Line 514 in b3620b5

   updatedRecord = yield apiFetch( {

3. We intercept the apiFetch call and, instead of making a POST request, we add it to queue of requests to make later on using addToBatch

   gutenberg/packages/edit-widgets/src/store/batch-support.js

   Line 23 in b3620b5

   const { wait } = await addToBatch( options );

4. saveWidgetArea then tells the batch processor to go ahead and flush that queue using processBatch – this should issue all of the API requests at once

   gutenberg/packages/edit-widgets/src/store/actions.js

   Line 183 in b3620b5

   const batch = yield dispatch(

The problem is that, in saveEntityRecord, it attempts acquire a lock so that multiple saves can’t happen at once.

gutenberg/packages/core-data/src/actions.js

Line 352 in b3620b5

const lock = yield* __unstableAcquireStoreLock(

This is totally fine and the the lock is granted right away. But because there’s a yield promise involved, even though the promise is already fulfilled, it sends execution back to saveWidgetArea before the call to apiFetch is made.

This means that by time saveWidgetArea gets to calling processBatch, apiFetch has not been called meaning that the batch is empty.

Introducing any amount of async (think: await Promise.resolve();) before calling processBatch fixes the problem. But obviously that’s hacky.

I have two ideas:

1. Can make __unstableAcquireStoreLock return the lock instead of a promise if it is immediately granted… but this problem could surface once again if there is a new yield promise added to saveEntityRecord down the road.
2. Can add some way of waiting until the batch processor has a certain amount of items in the queue.

[ipatovstyle]

I have the same problem. WP Core 5.5.1 Gutenberg 9.7.0. And have loop saving on button and the text error 'There was an error. object Object'.

[noisysocks]

A temporary fix was added in #28078 which will ship as part of Gutenberg 9.8. Keeping this issue open to track implementing a more permanent fix.