Discussion: Where and how do Blocks present global settings

[fabiankaegy]

Is your feature request related to a problem? Please describe.
I am currently working on modifying an existing Plugin to submit it to the Block Directory. And with that I am wondering wether wether there should be an area within Gutenberg to allow Blocks to put global settings like API Keys into.

In my specific case I am working on a Block for Apple Maps and we have a settings page to store an API key. This is the only real PHP that is used in the Plugin and it is not specifically needed. Whats needed is a way for a user to modify global settings that affect every instance of a block at a later point in time. In my case an API Key to initialize the Apple Map.

My fear is, that there are more blocks / plugins that have similar thoughts / issues right about now with the Block directory coming, and everyone is coming up with their own way of changing global settings. Which would really just adds to the confusion.

Describe the solution you'd like
Having a Slot area somewhere, where blocks / plugins can put their settings in a unified way. This settings area could be displayed under the three dots in the upper right corner of the editor.

Describe alternatives you've considered
An alternative would be having all the settings always be inline for a block. Kind of like changing the default style for any block at the moment. This has the downside though of having to search for a page where you have the block in use or adding a blank page to add the block just to get to the setting. Which in the case of API keys doesn't feel like the perfect workflow to me personally.

I would love to hear your thoughts about where global setting could / should live.

Thanks in advance!

[skorasaurus]

I was wondering about this myself and about to make an issue for this. Has any discussion about this arisen since this issue was made?

My use case is very similar to @fabiankaegy ; it's a URL/API key that would globally apply across each use of that block.

[stokesman]

Does PluginSidebar not fit the use case well?

Vanilla JS example for running in console

( function ( wp ) {
    const registerPlugin = wp.plugins.registerPlugin;
    const PluginSidebar = wp.editPost.PluginSidebar;
    const { createElement:el, Fragment } = wp.element;

    const PluginSidebarContent = () => {
        return el( Fragment, {},                                
            el( 'p', {}, 'Put a bird on it.')
        );
    };

    registerPlugin( 'sidebarino', {
        render: function () {
            return el(
                PluginSidebar,
                {
                    name: 'sidebarino',
                    icon: 'drumstick',
                    title: 'Sidebarino',
                },
                el( PluginSidebarContent )
            );
        },
    } );
} )( window.wp );

[fabiankaegy]

@stokesman That is the way that I ended up doing it. But I don't think it works very well as the best pattern because it takes up a tone of space and means that every plugin has its own sidebar. Looking at my site, for example, there already is the Plugin is for Yoast and for Jetpack and if every plugin/feature adds its own plugin sidebar that becomes very crowded I think.

Something like a slot in the settings modal where you could add your preferences into that would be really cool I think.

[stokesman]

I'd guessed you might have known about it. I agree it could get a bit ugly if lots of plugins are using it.

Something like a slot in the settings modal where you could add your preferences into

Seems worthwhile for consideration. Though it would put a plugin’s settings one level deeper so they might not be quite as discoverable. I don't think that be much of an issue since accustomed users would know where to look.

[youknowriad]

There's an old related discussion about this in #1224
It seems the resolution there was that the "Global Styles" panel would address the use-cases there. That said, API keys are not Styles for me, so there might be more to explore in this area.

[carlomanf]

I was also thinking global styles seems relevant. I left a comment in another issue about how locks seem inappropriate to include in themes, which then led me to think of a "global locks" panel that is not tied to the theme. Perhaps the global styles infrastructure could be re-purposed as a number of panels for different categories of block attributes. (e.g. styles, locks, miscellaneous block attributes)

[skorasaurus]

fyi #38873 could eventually manage this?

[Mamaduka]

There's also #16401.

[skorasaurus]

I was looking into this again for another custom plugin... seems like you can use the Preferences package introduced at #38873
but it only currently support boolean values