At this moment, blocks using “Block Context” only show the context being used when more than one context is available.

This is confusing for the end-user.

This is a follow-up from #2377757: Expose Block Context mapping in the UI see remarks in #65, #165 and #170. In the original patch there was a solution that added a label with a "context_slot_title". This was removed in https://www.drupal.org/node/2377757#comment-10365663 but never replaced with a something that actually shows the context with > 1 option.

For FacetAPI we are using the block context system. At this moment there is no way to see the facet name being placed by the block, if only 1 facet exists, which is very confusing and requires extra documentation or a form_alter on the block edit form, while this can easily be fixed in core.

As far as I know, the context system is not in use yet by any core feature as long as #2550199: Add a ContextProvider for Feeds is not in yet. This means there is no disruption at all. Edit: At least since #2339151: Conditions / context system does not allow for multiple configurable contexts, eg. language types, the context system is used in core.

Visual changes

Currently in HEAD:

With patch applied:

Why this should be an RC target

  1. Without this patch, there is no mention of the context in the UI with only 1 context created, this is confusing for the user.
  2. There is no disruption or change to current core behaviour, because this is not yet in place for anything in core.
  3. There was similar functionality in core before this originally got comitted.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

StryKaizer created an issue. See original summary.

StryKaizer’s picture

Issue summary: View changes
borisson_’s picture

Status: Active » Needs review
FileSize
1.71 KB

This interdiff is much larger than the actual change, I only removed the if (count($options) > 1 || !$definition->isRequired()) {-statement and reindented the form element definition inside the if statement. So this is actually a 1-line change.

We can remove the entire if-statement because we should always show the dropdown. With the previous solution the dropdown was only shown when either
a) More than 1 condition option was available.
b) The context was not required.

So that means we would only hide the dropdown when there was 1 condition option available and the condition is required.

In this issue, we want that behaviour to change so that the condition is also shown for required conditions with only 1 option.

borisson_’s picture

Status: Needs review » Needs work

The last submitted patch, 3: show_context_in_blocks-2603454-3.patch, failed testing.

borisson_’s picture

Status: Needs work » Needs review
FileSize
864 bytes
2.55 KB

Attached patch fixes the BlockLanguageTest. The ConditionFormTest is still failing but I can't figure out why yet. This patch should come back with 1 failing test.

Status: Needs review » Needs work

The last submitted patch, 6: show_context_in_blocks-2603454-6.patch, failed testing.

borisson_’s picture

Status: Needs work » Needs review
FileSize
1.68 KB
1.58 KB

All tests should be green and the patch is much smaller now.

This makes brings back the if statement surrounding the select element to make sure it doesn't show when no options are selected (because then it's an empty select anyway).

Nick_vh’s picture

Status: Needs review » Needs work

I think this issue could greatly benefit from some screenshots why this is necessary and what impact it has on any existing core features. As I understand it, the context system isn't widely used yet, so the impact is minimal.

borisson_’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
419.71 KB
439.6 KB
dsnopek’s picture

+1 to this issue!

We had similar functionality briefly in #2377757: Expose Block Context mapping in the UI but it was removed before commit. I personally think it made it much easier to understand where block content is coming from.

Fabianx’s picture

Issue tags: +rc target triage
borisson_’s picture

Issue summary: View changes
tim.plunkett’s picture

Issue tags: +Needs usability review
borisson_’s picture

Issue summary: View changes
MustangGB’s picture

So the select list appears if there is only one option to "choose" from, in which case shouldn't it be informational only, i.e. text and not a select list?

borisson_’s picture

@MustangGB, that was the solution in the original patch.

I don't understand why you would do this, this would be the only place I know in core that replaces a select list with an informational text.

Bojhan’s picture

Issue tags: -Needs usability review

This is quite a challenging bit. We don't want to trade the confusion of not knowing what context is being used, for a select list that doesn't actually provide you with options.

Although we don't have a fully established standard yet. I would like to pursue the road of showing the text, when there is only 1 option. This should be a useful standard across core and setting here should be fine.

Arla’s picture

I agree on the main motivation, that it is confusing to not see what context is being used. It is certainly easily misinterpreted as "there's no context".

Replacing a select with text is also a bit confusing IMHO.

How about leaving the select element, but setting #disabled and perhaps adding a note (in #description?) like "This field cannot be changed because there is only one context item available and it is required."

Arla’s picture

Here's an implementation and screenshot of the suggestion in #19.

Status: Needs review » Needs work

The last submitted patch, 20: show_context_in_blocks-2603454-20.patch, failed testing.

Arla’s picture

Issue summary: View changes
Status: Needs work » Needs review

Attempting to fix fails introduced by #2339151: Conditions / context system does not allow for multiple configurable contexts, eg. language types. Seems like that issue has made the statement "the context system is not in use yet by any core feature" false. Updating IS.

Shouldn't we make the mapping visible also in the case where there's only the "None" option? That is, optional context definition with no matching contexts.

Number of matching contexts
0 1 2..
required error? read-only (X) selectable (X, Y..)
optional read-only (None) selectable (None or X) selectable (None, X, Y..)
Arla’s picture

dsnopek’s picture

Shouldn't we make the mapping visible also in the case where there's only the "None" option? That is, optional context definition with no matching contexts.

This issue should have allowed for optional contexts: #2484645: Assigning context mapping: allow empty selection for optional contexts

Is that broken again?

Arla’s picture

Sorry, what I mean is "shouldn't we make the mapping disabled". What we get with the patches in this issue is a select element with only the "None" option, and it is not #disabled so it has the same problem as mentioned in #16.

xjm’s picture

Issue tags: -rc target triage

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andypost’s picture

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tim.plunkett’s picture

When there are no options, it still shows an empty select list if the context is optional.
This was very confusing to more than a couple people in IRC that I talked to this week.

Why not make the condition

if (count($options) > 0) {
benjy’s picture

Yeah that definitely makes the most sense to me. +1

Arla’s picture

Status: Needs review » Needs work

The last submitted patch, 34: show_context_in_blocks-2603454-34.patch, failed testing. View results

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.