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 | 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)
#2
@
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
@
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
@
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
@
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.
This ticket was mentioned in Slack in #core-test by hellofromtonya. View the logs.
3 years ago
#7
@
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
@
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:
- Widget A is not multiple, only one instance of is allowed.
- User adds an instance of Widget A, let's call it A.1, to the active Widgets.
- User moves A.1 to inactive.
- User adds a new instance of Widget A, let's call it A.2, to the active Widgets.
- 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
@
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.
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.