WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.48k stars 4.18k forks source link

Distpatching updateEditorSettings does not work #15993

Open patrickgalbraith opened 5 years ago

patrickgalbraith commented 5 years ago

Describe the bug I have a usecase where we need to update the Gutenberg global color palette after the page has loaded using javascript. I am aware of the add_theme_support('editor-color-palette', ...) PHP option but that will not work in this case.

To reproduce Call the following:

wp.data.dispatch( 'core/editor' ).updateEditorSettings( {colors: [{name: 'test', slug: 'test', color: '#00FF00'}]} );

This works to update the editor settings, which can be confirmed using:

wp.data.select( "core/editor" ).getEditorSettings()

However nothing changes in the UI to reflect the new settings.

Expected behavior UI updates with new settings applied.

Additional context Wordpress v5.2.1 and Gutenberg plugin v5.8.0.

Stack overflow issue: https://stackoverflow.com/questions/56438265/updating-gutenberg-global-color-palette-in-javascript

kadencewp commented 5 years ago

With the change over to select( "core/block-editor" ) there doesn't seem to be a way to update editor settings. I'm also looking for a solution to this.

oxyc commented 5 years ago

I think it's now called updateSettings. At least it works the same for templateLock and template asupdateEditorSettings did.

AnthonyLedesma commented 4 years ago

This now works as updateSettings. I was able to configure color controls by passing an array with objects as follows:

        updateSettings( {
            colors: [{...}],
        } );
talldan commented 4 years ago

Confirmed this issue. It looks like both core/editor and core/block-editor have very similar settings state, but many of the settings, like colors, draw from the block-editor state.

I don't fully know why it's this way. Usually core/editor is for more WordPress specific code and the core/block-editor package is for non WordPress generic block editor code.

However, I think it's misleading that they both share the same state while having different purposes, and also that they can become de-synchronized very easily, so I'm tentatively labeling this as a bug.

gwwar commented 3 years ago

Reading your comment, it sounds like we have two data packages that are pretty similar so folks are getting confused on which one to use. (Or there might be some props in the wrong package).

@talldan did we have any suggested next steps here? For example should we clarify package docs, or do we need something like an audit if data is being placed in the wrong store?

paaljoachim commented 3 years ago

I am also wondering if this is something that should be added to the Block Editor documentation. @mkaz

talldan commented 3 years ago

Probably a docs clarification would be good, however I also wonder if there are some APIs here that need to be deprecated if they're no longer useful.

apieschel commented 3 years ago

I don't believe this issue will be solved with a docs clarification. I think it applies to some other properties in core/editor that haven't been reproduced in other data stores. I've been trying to use wp.data.dispatch( 'core/editor' ).updateEditorSettings( { availableTemplates: whitelistedTemplates } ) to restrict certain blocks to certain page templates, but dispatching updateEditorSettings to change the state does not trigger a UI update to actually change which page templates are available to the user.

johnstonphilip commented 2 years ago

The recommended alternative here seems to not be working. The code I am attempting to use:

wp.data.dispatch('core/block-editor').updateSettings({
  colors: [{name: 'test', slug: 'test', color: '#00FF00'}]
})

While this does update the state and can be confirmed by calling:

wp.data.select( 'core/block-editor' ).getSettings()

There is no update/change in the UI.

htmgarcia commented 1 year ago

The custom calls to wp.data.dispatch('core/editor').updateEditorSettings() are executed, however the moment after a new call is triggered overriding our changes.

In the image below, the first one is my call to only allow 2 block types. The second call is triggered right after overriding my changes. Screen Shot 2023-03-28 at 8 24 27

  1. To reproduce, enable script debug by adding this to wp-config.php define( 'SCRIPT_DEBUG', true );
  2. Go to wp-includes/js/dist/editor.js
  3. Add the code below to log any call to updateEditorSettings (around line 4712 using 6.2 RC-4)

console.log('settings',settings);

Line above will log all the editor settings. To only log the settings we're trying to modify, use the appropriate syntax. In my example I'm using: console.log('settings.allowedBlockTypes',settings.allowedBlockTypes);

UPDATE: I must mention this happens when the call is executed on load after wp.domReady

htmgarcia commented 1 year ago

When dispatch is executed after wp.domReady, wrapping the dispatch in a setTimeout function to delay its execution by 1 second and thus bypass the settings override:

setTimeout( function() {
    wp.data.dispatch('core/editor').updateEditorSettings({ allowedBlockTypes: ['core/paragraph','core/heading'] });
}, 1000 );
vivekkotadiya commented 1 year ago

The recommended alternative here seems to not be working. The code I am attempting to use:

wp.data.dispatch('core/block-editor').updateSettings({
  colors: [{name: 'test', slug: 'test', color: '#00FF00'}]
})

While this does update the state and can be confirmed by calling:

wp.data.select( 'core/block-editor' ).getSettings()

There is no update/change in the UI.

have you find any solution to this ?

WebWrotter commented 7 months ago

The recommended alternative here seems to not be working. The code I am attempting to use:

wp.data.dispatch('core/block-editor').updateSettings({
  colors: [{name: 'test', slug: 'test', color: '#00FF00'}]
})

While this does update the state and can be confirmed by calling:

wp.data.select( 'core/block-editor' ).getSettings()

There is no update/change in the UI.

have you find any solution to this ?

I would love to know the answer to this and if it is possible!