Problem/Motivation

We wanna improve the UX (usability) to allow users to be warned when a block that is supposed to be shown is not going to do it. The feedback to the user will be done using warning messages

A language switcher block would not show any language if:

A. There is only 1 language configured (no languages to switch between).
B. There is no URL detection method configured (no method to switch languages via links).

This is correct. However users still enable the language switcher block and then get confused that it does not display. People assume it may be due to visibility settings, permissions, etc.

Proposed resolution

Add some helpful hint/text to the block config form that says why it would not show.

  1. (no) When user goes to the block layout and add the block, a warning message is showed in the modal window.
    That way will warning the user before add the block
  2. (yes) When the user goes to block layout, the block will not be able to be added. Could be showed with a tooltip or we could show a warning in the page or we could update the page description explaining this behavior.
    That way warning the user from the beginning.
  3. (yes) When user goes to the block layout and add a block, after submitting the configuration modal page, a warning message will be showed in the top of block layout page.
    That way will warning the user after add it.

whynoshow.png

Remaining tasks

We need to add the patch the availability to show both message if both are happening. Right now, just show one of them.

 

Contributor tasks needed
Task Novice task? Contributor instructions Complete?
Create a patch Instructions
Reroll the patch if it no longer applies. Instructions
Update the issue summary Instructions Yes
Update the issue summary noting if allowed during the beta Instructions
Add automated tests Instructions

User interface changes

A new hint on why the block would not show.

API changes

No.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Task, because we are adding string messages in the UI to clarify the blocks behavior.
Issue priority Normal, because we are improving the usability only in one small part, and not across many parts of core.
Prioritized changes This issue improve the UX (usability).
Disruption Not disruptive because we are changing LanguageBlock::constructor and LanguageBlock::create methods and its scope are just the language block, so will no affect to other classes, D8 beta sites or documentation (just the constructor comment block)
Files: 
CommentFileSizeAuthor
#79 explain_why_the-2019511-79.patch5.23 KBfran seva
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 97,239 pass(es), 3 fail(s), and 0 exception(s). View
#79 interdiff_76-79.txt2.5 KBfran seva
#76 interdif_72-76.txt2.16 KBfran seva
#76 explain_why_the-2019511-76.patch5.51 KBfran seva
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 97,148 pass(es), 3 fail(s), and 0 exception(s). View
#72 interdiff54-72.txt1.12 KBfran seva
#72 explain_why_the-2019511-72.patch3.36 KBfran seva
#54 reroll-2019511-33.patch3.19 KBfran seva
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,494 pass(es). View
#53 only_test-2019511-53.patch1.87 KBfran seva
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,459 pass(es), 3 fail(s), and 0 exception(s). View
#33 explain_why_the-2019511-33.patch3.15 KBjlbellido
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,414 pass(es). View
#33 interdiff.txt865 bytesjlbellido
#31 explain_why_the-2019511-31.patch3.15 KBjlbellido
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,402 pass(es). View
#31 interdiff.txt3.63 KBjlbellido
#28 explain_why_the-2019511-28.patch1.37 KBjlbellido
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,406 pass(es). View
#23 drupal8-d8mi-2019511-switcher-configure.png140.33 KBKristen Pol
#23 drupal8-d8mi-2019511-switcher-configure2.png98.09 KBKristen Pol
#11 2019511-11.patch1.36 KBrpayanm
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,024 pass(es). View
#11 2019511-interdiff.txt959 bytesrpayanm
#9 2019511-9.patch1.36 KBrpayanm
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,010 pass(es). View
#4 language-show-warning-switcher-block-2019511-1.patch1.06 KBe0ipso
PASSED: [[SimpleTest]]: [MySQL] 58,441 pass(es). View
#4 Configure_block___Site-Install.png104.5 KBe0ipso
#2 Welcome_to_Site-Install___Site-Install.png52.78 KBe0ipso
#2 Detection_and_selection___Site-Install.png171.2 KBe0ipso
whynoshow.png224.47 KBYesCT

Comments

e0ipso’s picture

Assigned: Unassigned » e0ipso
e0ipso’s picture

Status: Active » Needs review
FileSize
171.2 KB
52.78 KB

I don't think this is an issue anymore. Please, re-check.

Detection_and_selection___Site-Install.png

Detection_and_selection___Site-Install.png

e0ipso’s picture

Status: Needs review » Needs work

I see now that if you have session enabled, then you also see the block.

Updating issue description.

e0ipso’s picture

FileSize
104.5 KB
1.06 KB
PASSED: [[SimpleTest]]: [MySQL] 58,441 pass(es). View

First patch attempt.

Configure_block___Site-Install.png

e0ipso’s picture

Status: Needs work » Needs review
seutje’s picture

Removing JavaScript tag, as this only touches PHP.

Adding usability review tag because the wording could probably use some work.

"You do not have any language detection method enabled that provide URL based detection. The language switcher module will not be shown."

Not a native speaker, but I'm fairly certain it should to be "provides".

e0ipso’s picture

Can someone provide a better wording?

e0ipso’s picture

Issue summary: View changes

Add session detection to summary.

jhedstrom’s picture

Issue summary: View changes
Status: Needs review » Needs work
Issue tags: +Needs reroll

Patch no longer applies.

rpayanm’s picture

Status: Needs work » Needs review
FileSize
1.36 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,010 pass(es). View
jhedstrom’s picture

+++ b/core/modules/language/src/Plugin/Block/LanguageBlock.php
@@ -95,4 +97,20 @@ public function build() {
+      drupal_set_message($this->t('You do not have any language detection method enabled that provide URL based detection. The language switcher module will not be shown.'), 'warning');

As per #6, this should be provides.

Is there anywhere in the system we could link to in this text to ease the enabling of language detection?

rpayanm’s picture

FileSize
959 bytes
1.36 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,024 pass(es). View

fixed :)

e0ipso’s picture

Assigned: e0ipso » Unassigned
jhedstrom’s picture

Issue tags: -Needs reroll

I think we should link language detection method to the configuration page at admin/config/regional/language/detection so people can see exactly where they need to go to make the change.

Gábor Hojtsy’s picture

Issue tags: +Needs tests

Needs tests. Additionally to that:

+++ b/core/modules/language/src/Plugin/Block/LanguageBlock.php
@@ -95,4 +97,20 @@ public function build() {
+      drupal_set_message($this->t('You do not have any language detection method enabled that provides URL based detection. The language switcher module will not be shown.'), 'warning');

"No language detection method is enabled that would provide URL based detection. Therefore the language switcher block will not be shown."

Ie. module to block and instead of talking to the person, explaining the site config.

Gábor Hojtsy’s picture

Gábor Hojtsy’s picture

Issue tags: +SprintWeekend2015Queue
YesCT’s picture

Issue summary: View changes
Issue tags: +Needs issue summary update

since this is a minor task, would be good to document in the issue summary why this is allowed at this point in the beta. added link to instructions to do beta evaluation.

Gábor Hojtsy’s picture

As per https://www.drupal.org/contribute/core/beta-changes usability is prioritized. This is usability.

develCuy’s picture

Gábor Hojtsy’s picture

@develCuy: are you working on this one? The tag is supposed to be on issues someone is working/worked on.

develCuy’s picture

Issue tags: +SprintWeekend2015Queue

Removed tag by mistake.

develCuy’s picture

Removed tag by mistake.

Kristen Pol’s picture

Thanks for the patch in #11.

I have confirmed that it does show up when configuring the block once placed in the region.

Should it also show up as soon as you click the block on the right side of the block layout page (e.g. /admin/structure/block/list/bartik) and before it is placed anywhere? It currently does not. I think this would be useful to see before it is placed so the user will know what to expect before placing it.

Kristen Pol’s picture

Status: Needs review » Needs work

Also, I realize the text is not correct. Needs to be updated per #14.

Kristen Pol’s picture

Based on the issue:

#1082902: Improve language switcher usability

I think the patch for this issue should differentiate between:

1) switch links aren't showing up because there is only one language

2) switch links aren't showing up because language negotiation settings

and then we can close:

#1082902: Improve language switcher usability

See comments here: https://www.drupal.org/node/1082902#comment-9524351

Gábor Hojtsy’s picture

Title: help confusion about why language switcher blocks do not show, even when placed, when url detection method not selected » Explain why the language switcher would not show under some configurations

Shorter description.

jlbellido’s picture

Assigned: Unassigned » jlbellido

I'll work in this issue

jlbellido’s picture

Status: Needs work » Needs review
FileSize
1.37 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,406 pass(es). View

I add a new patch rerolling the previous one (#11) because it didn't apply.

Gábor Hojtsy’s picture

Status: Needs review » Needs work

@jlbellido: thanks, the concerns raised from #14 onwards still apply, so needs work for those :)

Gábor Hojtsy’s picture

Priority: Minor » Normal
Issue summary: View changes
Issue tags: -JavaScript

Updated summary, made much shorter.

jlbellido’s picture

Status: Needs work » Needs review
FileSize
3.63 KB
3.15 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,402 pass(es). View

I've updated #28 with the following:

* Updated message with #14 in case of no language method detection are enabled.
* As sugested in #25, I've introduced a different message when links are not showed because only 1 language is enabled and when no language method detection is enabled.

Tests still needed.

fran seva’s picture

Status: Needs review » Needs work

Hi @jlbellido!
Just a minor change in a comment.

$languages = $this->languageManager->getLanguages();
    // Warn the user that if only one language is enabled the block won't appear
    if (count($languages) == 1) {
      drupal_set_message($this->t('Only one language is enabled. Therefore the language switcher block will not be shown.'), 'warning');
    }

The one line comments should end with "."

I have tested the UI and it's working and the code is good for me.

jlbellido’s picture

Status: Needs work » Needs review
FileSize
865 bytes
3.15 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,414 pass(es). View

Thanks @fran for review it. I add a new patch fixing it.

fran seva’s picture

Status: Needs review » Reviewed & tested by the community

For me is RTBC.

fran seva’s picture

Assigned: jlbellido » Unassigned
fran seva’s picture

Issue tags: +drupaldevdays
alexpott’s picture

Status: Reviewed & tested by the community » Needs work

This is a block that uses a deriver - see Drupal\language\Plugin\Derivative\LanguageBlock. I think we can put this logic there and just not display the block in the list of available blocks if this is the case.

rodrigoaguilera’s picture

@alexpott Then you have to explain why is not listed since people are going to look for the block and a message on the blocks page is too much.

fran seva’s picture

Thinking in the user, I believe we should show that something is happening with that block but if we set the block not available the user will not know the reason, the user needs a feedback from UI.

I propose the following possibilities:

  1. When user goes to the block layout and add the block, a warning message is showed in the modal window.
    That way will warning the user before add the block
  2. When user goes to the block layout and add a block, after submitting the configuration modal page, a warning message will be showed in the top of block layout page.
    That way will warning the user after add it.
  3. When the user goes to block layout, the block will not be able to be added. Could be showed with a tooltip or we could show a warning in the page or we could update the page description explaining this behavior.
    That way warning the user from the beginning.
fran seva’s picture

Issue summary: View changes
fran seva’s picture

Issue summary: View changes
fran seva’s picture

Issue summary: View changes
fran seva’s picture

Issue summary: View changes
fran seva’s picture

Issue summary: View changes
fran seva’s picture

Issue summary: View changes
fran seva’s picture

Issue summary: View changes
fran seva’s picture

Issue summary: View changes
Issue tags: -Needs issue summary update
fran seva’s picture

Issue summary: View changes
YesCT’s picture

Issue summary: View changes

I think we should show the block is available so it is discoverable. But I agree maybe we should not allow them to do something that will not have an effect.
I think that if they meet the conditions for the block to show, and then place it, and then later the conditions for having the block are not correct, we need to be careful and not remove settings they had on the block, but they should be warned about why the block disappeared. So:

I think we should try and do these two:

When the user goes to block layout, the block will not be able to be added. Could be showed with a tooltip or we could show a warning in the page or we could update the page description explaining this behavior.
That way warning the user from the beginning.

When user goes to the block layout and add a block, after submitting the configuration modal page, a warning message will be showed in the top of block layout page.
That way will warning the user after add it.

(I put them in the issue summary.)

---
Note @fran seva read https://www.drupal.org/core/issue-priority and put Major in the beta evaluations, but I do not think this is "important by community consensus". So I think normal is the right thing, because the effect is isolated to just the language switcher block and does not effect across many places in Core.

YesCT’s picture

Issue tags: -medium
+++ b/core/modules/language/src/Plugin/Block/LanguageBlock.php
@@ -116,4 +128,23 @@ public function getCacheMaxAge() {
+    // Warn the user that if only one language is enabled the block won't appear.
+    if (count($languages) == 1) {
+      drupal_set_message($this->t('Only one language is enabled. Therefore the language switcher block will not be shown.'), 'warning');
+    }
+    // Warn the user that if there are no links to show because language-url
+    // method detection isn't enabled, the block won't appear.
+    elseif (!$this->negotiator->isNegotiationMethodEnabled('language-url')) {
+      drupal_set_message($this->t('No language detection method is enabled that would provide URL based detection. Therefore the language switcher block will not be shown.'), 'warning');
+    }

I know the code will change much if we go in the new direction, but I wanted to document feedback on the previous patch ...

That we should show both warnings if both conditions exist.

In the current code,
if there is only one language and a non url negotiation method, only the one language warning would be shown.
What should happen is they should be able to see both if both conditions are there.

---

Also removing medium, because I think this get more difficult if we go do one of the new proposals.

fran seva’s picture

Working on it :)

fran seva’s picture

Implementing tests in #DrupalCampsEs2015

fran seva’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests +Needs reroll
FileSize
1.87 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,459 pass(es), 3 fail(s), and 0 exception(s). View

Attach the test for the issue.
I'm implementing the changes that @YesCT proposed.
Also add the needs reroll tag and remove the Needs tests tag

fran seva’s picture

FileSize
3.19 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,494 pass(es). View

attach reroll.

The last submitted patch, 53: only_test-2019511-53.patch, failed testing.

gauravjeet’s picture

Issue tags: -Needs reroll
FileSize
3.19 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,506 pass(es). View

Applied this patch in #54 to a local branch, applied and auto-merged successfully. Removing Needs re-roll tag from the issue, also changed the name of patch to a standard name.

gauravjeet’s picture

Status: Needs review » Reviewed & tested by the community

changed to RTBC

fran seva’s picture

Status: Reviewed & tested by the community » Needs work

Hi!
The issue is not fixed, we need to apply the changes that @yesCT proposed.
Change the status to needs work

fran seva’s picture

I'm looking where I should implement the changes @YesCT proposed in #49 and I see that:

1. The user goes to block layout
1.1 Show a tooltip in the language Switcher: Reviewing the code I saw that the link and its attributes are added in BlockListBuilder::buildForm and I don't see the way to add it from LanguageBlock class. I think we should not change the BlockListBuilder:buildForm code, isn't it?

1.2 Change the page description:
This change have to be done in language.module in language_help, checking the route_name, block.admin_display and block.admin_display_theme, but my question is, Should this text be rendered just when language Switcher will not be able to be added? I think the text should be always present explaining how the language switcher should be configured to be added.

2. After add the block: Currently, the system is showing a message depending the user has just one language or URL detection is not enable. I think could be good show this messages (as you commented in #50) instead show a single message. I'm not sure if the message @YesCT refers in #49 are the same that #50.

YesCT’s picture

I'm looking at this now.

While I was looking, noticed: #2500607: Some block categories are not translatable

YesCT’s picture

FileSize
1.42 MB

ok. I see the warning after adding the block, when returning to configure it. Seems fine.

I wanted to see the warning in the modal... before placing it, and thought that the warning didn't show at all, but it does! page just scrolls to where the change is in the block ordering, and so did not see the message at the top.

YesCT’s picture

Issue summary: View changes
FileSize
301.05 KB

So @fran seva and I talked in IRC

Here are some screenshots to hopefully clarify things.

with language module enabled (and only one language and/or url language detection disabled)

on admin/structure/block

there is a link to add a language switcher block

S1: I suggest we leave that UI alone there. (Not add any warning, and not take away the link to the language switcher block. Leaving the link there, gives people a way to discover the block and when we add the warning messages, how to make it show.)

After clicking on that link, a modal dialog popup appears to configure the block and with a button to save, which adds the block.

S2: I suggest that we have a warning in that modal.

S3: I suggest the warning contain a link to where a language can be added.
"Only one language is enabled. Therefore the language switcher block will not be shown."

S4: I suggest we do NOT disable the save block button to prevent adding the block. (Because, there is a scenario where the conditions are correct and it gets added, but then config changes and it wont show, but is still placed... and, it doesn't really hurt to place the block and then add more languages... and we are putting messages in so people will know to do that.)

Only local images are allowed.

After save, it goes to admin/structure/block/list/bartik?block-placement=languageswitcher

Then... instead of a drupal set message which puts something at the top of that block ordering page (which gets automatically scrolled right past. See #61)

S5: I suggest we put a warning in the row in the table for the language switcher block. (because it autoscrolls to that place anyway. and hopefully would be there not just after the save, but anytime returning to that blocks page.)

Only local images are allowed.

S6: I suggest we keep the warnings the patch adds to the configure page admin/structure/block/manage/languageswitcher

YesCT’s picture

Issue summary: View changes
FileSize
314 KB

strange, those files I added ... did not get listed on that comment.
here is the last one.

gauravjeet’s picture

Issue tags: +SrijanSprintDay
FileSize
8.64 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,618 pass(es). View

@YesCT,
I suggest we can leave the warning messages as is and give a link to where user can add a new language to the site, in the warning message itself.

gauravjeet’s picture

Status: Needs work » Needs review

Changed issue status

fran seva’s picture

@gauravjeet could you add an interdiff between your pach and the the #56?
If you need more info about it you can get it in [1]

[1] https://www.drupal.org/documentation/git/interdiff

gauravjeet’s picture

@fran seva,
I made these changes only :

--- a/core/modules/language/src/Plugin/Block/LanguageBlock.php
+++ b/core/modules/language/src/Plugin/Block/LanguageBlock.php
     if (count($languages) == 1) {
-      drupal_set_message($this->t('Only one language is enabled. Therefore the language switcher block will not be shown.'), 'warning');
+      drupal_set_message($this->t('Only one language is enabled. Therefore the language switcher block will not be shown. To add a new language on the site, go to @language-link.', array('@language-link' => \Drupal::l(t('Language list'), Url::fromRoute('entity.configurable_language.collection')))), 'warning');
     }
fran seva’s picture

@gauravjeet, checking your last patch It seems that there are more changes and seems to be related to other issue (I think).
For example, I see the patch add this change

   /**
-   * {@inheritdoc}
-   */
-  public function register($id, $class = null) {
-    if (strtolower($id) !== $id) {
-      throw new \InvalidArgumentException("Service ID names must be lowercase: $id");
-    }
-    return parent::register($id, $class);
-  }
-
-  /**
-   * {@inheritdoc}
-   */
-  public function setParameter($name, $value) {
-    if (strtolower($name) !== $name) {
-      throw new \InvalidArgumentException("Parameter names must be lowercase: $name");
-    }
-    parent::setParameter($name, $value);
-  }
-

why?

In other hand, every time a patch is post it, have to be posted an interdiff file. In [1] you can get how create the file
The reason for it, is that the reviewer could check just the last changes and not all the changes in a patch.

[1]https://www.drupal.org/documentation/git/interdiff

fran seva’s picture

Status: Needs review » Needs work
deepakaryan1988’s picture

Removing sprint weekend tag and other irrelevant tags!!
As suggested by @YesCT

deepakaryan1988’s picture

Issue tags: +SprintWeekend2015

Sorry, these issues were actually worked on during the 2015 Global Sprint
Weekend https://groups.drupal.org/node/447258

fran seva’s picture

FileSize
3.36 KB
1.12 KB

@gauravjeet I have cleaned your patch because there was changes not related to the issue (the clean patch with your proposal is explain_why_the-2019511-72.patch. I also attach the interdiff with the last patch (interdiff-54-72).

Reviewing the interdiff I see your proposal is not what @YesCT describe in the issue and its what is supposed to do but I think could be a good idea show the link to configure it.

I also see that the patch is not including the tests and should be. As conclusion the pending task are:

- Improve tests
- implement @YesCT proposal
- add test to main patch.

I have hidden the wrong patches and I have added the clean version.

fran seva’s picture

Status: Needs work » Needs review

ups...the status

fran seva’s picture

fran seva’s picture

Status: Needs review » Needs work
fran seva’s picture

Status: Needs work » Needs review
FileSize
5.51 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 97,148 pass(es), 3 fail(s), and 0 exception(s). View
2.16 KB

Attach patch with tests and interdiff.
The patch should be red

jhedstrom’s picture

  1. --- /dev/null
    +++ b/.idea/misc.xml
    

    This file should be removed from the patch.

  2. +++ b/core/modules/language/src/Plugin/Block/LanguageBlock.php
    @@ -118,4 +130,23 @@ public function getCacheMaxAge() {
    +      drupal_set_message($this->t('Only one language is enabled. Therefore the language switcher block will not be shown. To add a new language on the site, go to @language-link.', array('@language-link' => \Drupal::l(t('Language list'), Url::fromRoute('entity.configurable_language.collection')))), 'warning');
    

    The call to the t('Language list') function should be replaced by $this->t().

  3. +++ b/core/modules/language/src/Tests/LanguageSwitchingTest.php
    @@ -283,6 +283,37 @@ function testLanguageBodyClass() {
    +      $warning_bool = ($warning->__toString() == 'The block Language Switcher cannot be added.')? true : false;
    

    Small nit: there needs to be a space between ) and ?, and true and false should be upper cased.

    Also, instead of manually calling the __toString() magic method, casting to a string might be more clear: (string) $warning === '...'

Status: Needs review » Needs work

The last submitted patch, 76: explain_why_the-2019511-76.patch, failed testing.

fran seva’s picture

Status: Needs work » Needs review
FileSize
2.5 KB
5.23 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 97,239 pass(es), 3 fail(s), and 0 exception(s). View

@jhedstrom thanks for review.
Attach the patch with the fixes.

I'm working in @YesCT proposal.

Status: Needs review » Needs work

The last submitted patch, 79: explain_why_the-2019511-79.patch, failed testing.

fran seva’s picture

@YesCT I'm having some problems to show the message in the modal form.

Currently the code is using drupal_set_message in LanguageBlock::blockForm to render the message but this happens after submit the form and that is not what we want.

I'm not sure how do it because I see problems in all solutions I think:

1. in LanguageBlock::blockForm add an form item to show the message. This is not good because we are not using the drupal way to show messages. AFAIK we wanna show the drupal_set_message style but we could show the message just as a text without the drupal_set_message.

2. I think the message should be "done" from language module, which is the module that generate the block. But if we wanna show the message with drupal_set_message we should do before generate the modal form. make that sense?

3. Another option could be add the message using JS. The JS file could be in language module and when the form where loaded will check the number of languages and the language-url configuration. Is this the way to do it?

Are there in D8 a way to show messages in modal forms? I'm looking in code a similar use case.

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.

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

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should 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.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.