Make WordPress Core

Opened 3 years ago

Last modified 3 years ago

#53552 new defect (bug)

Inactive Widgets prevent placement of new widget if `multiple` is false

Reported by: mattyrob's profile MattyRob Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 5.8
Component: Widgets Keywords: needs-testing needs-patch needs-design
Focuses: administration Cc:

Description

In the new Widget page, moving a Widget to Inactive stops placement of a new copy of that widget is 'multiple' is defined as false in the block code.

Change History (12)

#1 @desrosj
3 years ago

  • Keywords needs-testing added
  • Milestone changed from Awaiting Review to 5.8.1

Thanks for the report @MattyRob!

Since 5.8 RC1 is due out shortly and this does not seem like a blocker for that, I'm going to add this to 5.8.1 and flag it for review by the contributors working on the new widget screen.

Would you be able to provide some more precise steps to reproduce your issue? If you could include any code snippets that would also be helpful.

#2 @MattyRob
3 years ago

@desrosj

You can use the example code below, then in the current development code:

1/ Navigate to the new Widget Editor
2/ Paste the code below into the browser console
3/ Place this Widget in your Sidebar
4/ Move the widget to 'Inactive'
5/ Try placing a new copy of the Widget in the Active sidebar - note that you can't do this until the Inactive instance is deleted.

I probably agree that's it's not a blocker but it is likely to create core and plugin support requests while users get used to the new Widget screen and realise they have to tidy up the Inactive Widget lists to add new Widgets that are only allowed a single active instance.

( function( blocks, element, components, editor ) {
        var el               = element.createElement,
                Fragment         = element.Fragment,
                PanelBody        = components.PanelBody,
                PanelRow         = components.PanelRow,
                TextControl      = components.TextControl;

        blocks.registerBlockType(
                'gutenberg/widget',
                {
                        title: 'No Multiple Widget',
                        icon: 'hammer',
                        category: 'widgets',
                        supports: {
                                multiple: false
                        },
                        edit: function( props ) {
                                var title         = props.attributes.title || 'Title'

                                return el(
                                        Fragment,
                                        {},
                                        el(
                                                editor.InspectorControls,
                                                { key: 'gutenberg/widget' },
                                                el(
                                                        PanelBody,
                                                        {
                                                                title: 'Title',
                                                                initialOpen: true
                                                        },
                                                        el(
                                                                PanelRow,
                                                                {},
                                                                el(
                                                                        TextControl,
                                                                        {
                                                                                type: 'string',
                                                                                label: 'Title',
                                                                                value: title,
                                                                        }
                                                                )
                                                        )
                                                )
                                        ),
                                        el(
                                                element.RawHTML,
                                                null,
                                                'Foobar'

                                        )
                                );
                        }
                }
        );
} )(
        window.wp.blocks,
        window.wp.element,
        window.wp.components,
        window.wp.blockEditor
);

#3 @justinahinon
3 years ago

We've triaged this ticket during a test team scrub. For reference, here is the documentation for the multiple attribute: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-supports/#multiple.

According to the documentation:

A non-multiple block can be inserted into each post, one time only. For example, the built-in ‘More’ block cannot be inserted again if it already exists in the post being edited. A non-multiple block’s icon is automatically dimmed (unclickable) to prevent multiple instances.

So if the value of multiple is false, then only 1 instance can be in a single post.

What is reported in the ticket seems to be the expected behaviour then (?).

#4 @MattyRob
3 years ago

@justinahinon

Please review the steps as described already above:

1/ Navigate to the new Widget Editor
2/ Paste the code below into the browser console
3/ Place this Widget in your Sidebar
4/ Move the widget to 'Inactive'
5/ Try placing a new copy of the Widget in the Active sidebar - note that you can't do this until the Inactive instance is deleted.

A single instance Block when moved from an Active Sidebar in the new Widget Editor to the Inactive section should trigger something such that it can now be placed again in an active sidebar, otherwise it a post user experience.

Do you think a single instance widget in the Inactive section should precent it being placed on a live sidebar then? Is that the proposed and expected behaviour of the new Widget Editor?

#5 @andraganescu
3 years ago

  • Keywords needs-patch needs-design added

Howdy @MattyRob and thanks for the ticket. In my opinion the behavior of "multiple" is the reason why this fell through the cracks and landed like this. For the new editor the Inactive area is ... how to put it ... less fake than the one in the classic editor: it really is an "inactive widget area" not an ad-hoc group that WordPress salvaged.

Nevertheless, you are right as this is a very unexpected behavior, mostly b/c widgets can end up in the inactive widgets area automagically, so a user may not even be aware that a configured widget is there already. So this should be addressed, ideally for 5.8.1

I added the "needs-design" keyword, thinking that maybe we'd need some UI to notify the user of the problem or something.

Last edited 3 years ago by andraganescu (previous) (diff)

This ticket was mentioned in Slack in #core-test by hellofromtonya. View the logs.


3 years ago

#7 @MattyRob
3 years ago

@andraganescu

Thanks for the response and acknowledgement that this is unexpected behaviour - I totally accept that the 'multiple' property is a key factor at play here but some kind of workaround that alerts the user to an Inactive Widget instance or the disregards widgets in the Inactive Area when assessing the 'multiple' instance parameter is needed here to provide a good user experience. If this can be address in 5.8.1 that would be brilliant.

This ticket was mentioned in Slack in #core-test by hellofromtonya. View the logs.


3 years ago

#9 @lucatume
3 years ago

Posting a contribution about expected behavior that surfaced while reviewing this ticket in #core-tests:

some kind of workaround that alerts the user to an Inactive Widget instance or the disregards widgets in the Inactive Area when assessing the 'multiple' instance parameter is needed here to provide a good user experience

A question about expected behavior that came up during test triage:

  1. Widget A is not multiple, only one instance of is allowed.
  2. User adds an instance of Widget A, let's call it A.1, to the active Widgets.
  3. User moves A.1 to inactive.
  4. User adds a new instance of Widget A, let's call it A.2, to the active Widgets.
  5. User moves A.1 back to active.

Should 4 be prevented? This would imply that "single instance" means "at most one instance in existence".
Should 5 be prevented? This would imply that "single instance" means "at most one active instance".

Since there is no patch yet, the discussion of this point might be postponed to the first version of such patch to see what option of the two is implemented, how it works, and how it "feels" when put to use.

#10 @circlecube
3 years ago

I lean towards preventing step 4, or not allowing users to add another instance of a widget when multiple is false - even when the existing widget is only in the inactive widget section. To me, that seems more simple and keeps the user from painting themselves into a corner of having an active widget and an inactive widget but not being able to move the second from inactive to active. It seems the error is easier to describe to the user as well, as it can say "only one of these widgets may be used" with no distinction on whether it is active or inactive. Of course, I'd defer to anyone who wants to work on it as I haven't dug into the technical requirements/limitations.

To be considered for the next release (5.8.1) this will need a patch and testing before RC1 which is scheduled for Wednesday, Sept 1.

#11 @desrosj
3 years ago

  • Milestone changed from 5.8.1 to 5.8.2

WordPress 5.8.1 RC is due out in less than 24 hours. Because there is no available fix for this, I'm going to punt to the next minor release.

#12 @circlecube
3 years ago

  • Milestone changed from 5.8.2 to Future Release

There's no tested patch yet and 5.8.2 RC is due out in less than 24 hours. I'm going to punt this to a future release.

Note: See TracTickets for help on using tickets.