Motivation

Some users go to the content section, rather than the structure section, looking for options to edit content types.

Proposed resolution

On the node/add page, add links to edit the content types as well, for users who have the right permissions. This provides another way of navigating to admin/structure/types/manage/[node-type]

Remaining tasks

Summary of API changes
Needs usability review; see #59

User interface changes

Adds links to admin/structure/types/manage/[node-type] for each node type on the node/add page

Screenshot of UI before patch:
UI-before-patch

Latest screenshot of UI after patch (from comment #50):
ui-after-patch.png

Latest screenshot of UI after patch (from comment #61):

Proposed by YesCT in #384150-59: Cross-link content type settings from node add/edit form

Related Issues

Original report by catch

Many users go to the node/add and node/edit forms looking for settings (submitted information, input formats). We should consider adding links there to the admin screens for those form elements when users have the relevant permissions.

CommentFileSizeAuthor
#69 drupal-add-content-description-384150-69.patch1.51 KBzaporylie
#69 Screen Shot 2015-01-17 at 12.11.24.png28.74 KBzaporylie
#69 Screen Shot 2015-01-17 at 12.11.00.png30.34 KBzaporylie
#62 drupal-add-content-description-384150-61.patch1.37 KBaschiwi
#61 add-content.jpg153.91 KBaschiwi
#59 content.png244.8 KBYesCT
#59 emphasis.png173.1 KBYesCT
#59 use_edit_hover_like_blocks.png50.98 KBYesCT
#53 after-patch-51.png28.54 KBmahaprasad
#51 content-type-edit-384150-51.patch3.33 KBmahaprasad
#50 ui-after-patch.png40.69 KBrootwork
#49 Screen Shot 2013-03-10 at 5.36.24 PM.png40.69 KBrootwork
#48 content-type-edit-384150-48.patch2.57 KBrootwork
#48 interdiff.txt1 KBrootwork
#46 UI-before-patch.png65.95 KBpameeela
#46 UI-after-patch.png144.62 KBpameeela
#43 content-type-edit-384150-43.patch2.59 KBmahaprasad
#38 content-type-edit-384150-38.patch2.47 KBpbz1912
#36 content-type-edit-384150-36.patch2.49 KBAnonymous (not verified)
#33 content-type-edit-384150-33.patch2.79 KBjaredsmith
#32 content-type-edit-384150-32.patch2.3 KBAnonymous (not verified)
#31 content-type-edit-384150-31.patch1.64 KBAnonymous (not verified)
#27 content-type-edit-384150-27.patch1.6 KBAnonymous (not verified)
#24 content-type-edit-384150-24.patch1.62 KBAnonymous (not verified)
#22 content-type-edit-384150-22.patch1.57 KBAnonymous (not verified)
#18 cross-link-edit-node-type.patch1.93 KBlucaswoj
#17 CreateContentEditCTLink.png191 KBjpoesen
#15 contenttypes-final.patch1.31 KBlucaswoj
#12 contenttypeslinkf.patch1.31 KBlucaswoj
#11 contenttypeslinkf.patch1.32 KBlucaswoj
#9 contenttypeslink.patch1.25 KBlucaswoj
#5 contenttypeslink.patch1.27 KBlucaswoj
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

catch’s picture

Issue tags: +UBUserTesting2009

Fixing tag.

karschsp’s picture

Issue tags: -UBUserTesting2009

This might be good for the novice queue.

karschsp’s picture

Issue tags: +Novice, +UBUserTesting2009

Sorry, I screwed up the tags.

lucaswoj’s picture

Assigned: Unassigned » lucaswoj

Hey, I'm completely new to Drupal development, but this looks like a great starter project. I'll see if I can get a patch done by tonight.
- Lucas

lucaswoj’s picture

FileSize
1.27 KB

First open source patch!

The method I use to do this is arguably a little hack-ey, but because of the way that drupal handles the node/add page, its the easiest and most efficient way. The node/add page stores the content types as menu items, and displays them back without any knowledge of the content type its describing. For me to provide a link to edit the content type, I have to reverse engineer the URL that goes with the menu item.

lucaswoj’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch failed testing.

lucaswoj’s picture

Status: Needs work » Needs review

Fixed patch. Relative filename problems...

lucaswoj’s picture

FileSize
1.25 KB

Not sure why this failed to attach the first time

Status: Needs review » Needs work

The last submitted patch failed testing.

lucaswoj’s picture

FileSize
1.32 KB

Fixed errors with declaring variables. That will teach me to run my server in E_ALL...

lucaswoj’s picture

FileSize
1.31 KB

Please, please be the last try. I have to manually change the file path because diff is being mean to me.

lucaswoj’s picture

Status: Needs work » Needs review
Dries’s picture

Status: Needs review » Needs work

Hey lucaswoj, your code is not adhering to the Drupal coding standards. If you look at the patch, you'll see that you're using tabs instead of spaces. It would be great if you could re-roll the patch with Drupal's coding standards in mind.

lucaswoj’s picture

Status: Needs work » Needs review
FileSize
1.31 KB

I'm sorry, I thought my IDE was already configured for spaces... I guess I've never really worried about it before.

For the 5th time, here we go....

sheise’s picture

this worked for me.

jpoesen’s picture

Status: Needs review » Needs work
Issue tags: +Usability
FileSize
191 KB

Thanks for your patch. It almost works as advertised - here are some remarks:

Inconsistency:
The patch indicates that line 25 replaces line 23, but they're identical so the patch should not indicate changes.

23:  -      $output .= '<dt>' . l($item['title'], $item['href'], $item['localized_options']) . '</dt>';
24:  -      [...]
25:  +      $output .= '<dt>' . l($item['title'], $item['href'], $item['localized_options']) . '</dt>';

Markup error:
On line 28 of your patch you're adding:

28: +      $output .= '</dt>';

but you really wanted to close the DD element opened on line 26, so line 28 should be:

28: +      $output .= '</dd>';

Usability:
The patch adds an 'Edit Content Type' link to the end of each Content Type definition on /node/add. However I only noticed that link after clicking around trying to find the changes introduced by the patch.

Wouldn't it make more sense to add the edit link next to the Content Type title? See attached screenshot.

Entities / wrapper:

27: +      $output .= isset($item['edit_href']) ? '&nbsp;<small>('.l(t('Edit Content Type'), $item['edit_href']).')</a></small>' : '';

I personally don't like the addition of a non-breaking space entity and wrapping the "Edit Content Type" link in small tags. The entity clutters up the code and by using the small tags we make assumptions on how this link should be displayed.

Adding a meaningful css class name is more versatile and less imposing.

lucaswoj’s picture

Status: Needs work » Needs review
FileSize
1.93 KB

Thanks for the thoughtful feedback jpoesen. I think this updated patch fixes all of your concerns.

Status: Needs review » Needs work

The last submitted patch failed testing.

rschwab’s picture

Version: 7.x-dev » 8.x-dev

This has unfortunately missed the string freeze for 7.

mlncn’s picture

Issue tags: +SettingsAPI

Yes, please.

Anonymous’s picture

Assigned: lucaswoj »
Status: Needs work » Needs review
FileSize
1.57 KB

I was bored this evening, so here's a patch that brings #18 to D8, along with a clarification that the link is to edit the content type, rather than a link to bring up a view or something that would list all nodes of that type available for editing.

Status: Needs review » Needs work

The last submitted patch, content-type-edit-384150-22.patch, failed testing.

Anonymous’s picture

Retry...

Anonymous’s picture

Status: Needs work » Needs review
oriol_e9g’s picture

Status: Needs review » Needs work

Coding standards
http://drupal.org/coding-standards

else if
should be:
elseif

$output .= $item['edit_href'] ? '<span class="node-type-edit">['
  . l(t('Edit content type'), $item['edit_href']) . ']</span>' : '';

Use one line dot concatenation or the operator .=

Same here:

$output .= '<dt>' . l($item['title'], $item['href'],
  $item['localized_options']);

better:

$output .= '<dt>' . l($item['title'], $item['href'], $item['localized_options']);
Anonymous’s picture

Status: Needs work » Needs review
FileSize
1.6 KB

Better adherence to coding standards. (Sorry, got wrapped up in "80 characters per line".)

Kristen Pol’s picture

+++ b/core/modules/node/node.pages.inc
@@ -38,6 +38,12 @@ function node_add_page() {
+    //Generate links to edit content type if user has proper permissions

Based on other patches I've looked at recently, my understanding is that comments are supposed to have a space after the "//" and have sentence formatting, e.g.

// Generate links to edit content type if user has proper permissions.

Note that I applied the patch (in D8) and am not seeing anything come up on the node/add page while logged in as super-admin. I cleared the cache and that had no effect either.

Kristen Pol’s picture

Status: Needs review » Needs work

Drush wasn't working for clearing the caches so I changed the theme to clear the theme registry and now I see the links.

+++ b/core/modules/node/node.pages.inc
@@ -58,7 +64,11 @@ function theme_node_add_list($variables) {
+      if (isset($item['edit_href'])) {
+        $output .= $item['edit_href'] ? '<span class="node-type-edit">[' . l(t('Edit content type'), $item['edit_href']) . ']</span>' : '';

I think it would be good to add a space between the content type name and the "[", e.g.

$output .= $item['edit_href'] ? ' <span class="node-type-edit">[' . l(t('Edit content type'), $item['edit_href']) . ']</span>' : '';
yoroy’s picture

Also, there is no node.css anymore, that bit probably needs to be moved into node.admin.css

Anonymous’s picture

Status: Needs work » Needs review
FileSize
1.64 KB

Updated patch.

Also noticed that the links don't appear when using the Seven theme. Tried applying the patch, creating a new empty database, then installing Drupal, used another browser that had not accessed my dev environment, and still didn't see them on Seven. That *should* rule out caching issues.

Anonymous’s picture

Ahh... there's a template.php override in Seven...

Here's an updated patch...

Also cleaned up the "if" surrounding the addition. When I first worked on this in December, I admit that I was just being introduced to the ...?...:... syntax at the time.

jaredsmith’s picture

I've cleaned up the patch so that it works with modern Drupal 8 code... the previous patch was suffering from some bit-rot. The attached patch is functionally the same as the previous patch.

I've tested the attached patch myself, but would love to see some additional review so that we can get this pushed through.

rwinikates’s picture

Status: Needs review » Reviewed & tested by the community

Applied patch, looks good, works for core and custom content types.

catch’s picture

Status: Reviewed & tested by the community » Needs work

Hmm I think I'd probably place the permissions check directly in the theme function rather than overloading the node type objects. Also is the new CSS absolutely necessary in node.admin.css or could that be put in seven theme instead?

Anonymous’s picture

Status: Needs work » Needs review
FileSize
2.49 KB

This patch moves the CSS to Seven theme since it is not necessary to provide a default here. It also moves the call to user_access() and generation of content type edit links to theme_node_add_list().

pbz1912’s picture

#36: content-type-edit-384150-36.patch queued for re-testing.

pbz1912’s picture

Applied #36 to bc1da65 and rerolled it.

It seems to work.

Status: Needs review » Needs work
Issue tags: -Usability, -Novice, -UBUserTesting2009, -SettingsAPI

The last submitted patch, content-type-edit-384150-38.patch, failed testing.

pbz1912’s picture

Status: Needs work » Needs review

#38: content-type-edit-384150-38.patch queued for re-testing.

YesCT’s picture

YesCT’s picture

Status: Needs review » Needs work

did a standards review. mostly looks good.

+++ b/core/modules/node/node.pages.incundefined
@@ -59,9 +59,17 @@ function theme_node_add_list($variables) {
+      // Generate links to edit content type if the current user has proper permissions.

+++ b/core/themes/seven/template.phpundefined
@@ -44,10 +44,17 @@ function seven_node_add_list($variables) {
+      // Generate links to edit content type if the current user has proper permissions.

comments should wrap at 80 chars. See: http://drupal.org/node/1354

mahaprasad’s picture

Status: Needs work » Needs review
FileSize
2.59 KB

Applied #38 and rerolled it.

Hope it will work.

xjm’s picture

Thanks @mahaprasad!

YesCT’s picture

screenshots embedded in the issue summary with before and after would help. Also it would help to update the issue summary using the issue summary template.

pameeela’s picture

Issue tags: -Needs screenshots
FileSize
144.62 KB
65.95 KB

Did a manual test of this patch. Works well but some minor issues.

1. There are brackets appearing in the output - see screenshot

UI-after-patch.png

2. The hover state for the 'Edit content type' links doesn't work - doesn't get an underline, as it should.

Also uploading a screenshot of the UI before to add to summary.

pameeela’s picture

Status: Needs review » Needs work

Does this patch include any updates to node/edit pages? Couldn't find any, only saw changes to node/add. If there are proposed changes to the edit screen as well can someone provide more detail?

pameeela’s picture

Issue summary: View changes

Updates summary to use template.

rootwork’s picture

Assigned: » rootwork
Status: Needs work » Needs review
Issue tags: +SprintWeekend2013
FileSize
1 KB
2.57 KB

Updated the patch from #43 to remove the extraneous brackets and give it the right span wrapper.

rootwork’s picture

FileSize
40.69 KB

Here's a new screenshot of the add content page with my revised patch.

It looks like the underlines on hover still aren't appearing. I'm going to try to track down what's going on in the CSS.

rootwork’s picture

Status: Needs review » Needs work
FileSize
40.69 KB

Sorry, changing status back to needs work and embedding the new screenshot.

ui-after-patch.png

rootwork’s picture

Issue summary: View changes

Updates [username] with link to OP

mahaprasad’s picture

Status: Needs work » Needs review
FileSize
3.33 KB

Fixed the hover link & aligned the links in one line.

Please find the attached patch.

xjm’s picture

Issue tags: +Needs usability review

Thanks @mahaprasad, @rootwork, and @pameeela! The updates make it much easier to understand the proposed change.

The proposed pattern seems pretty confusing to me, and it's different from any pattern we have elsewhere. We have two links that say "edit content type" with nothing to distinguish them aside from their spacial placement. I would have no idea which link I was supposed to click on when going to this page.

For this to work at all, I think the link texts would need to be more specific, like "Add new basic page" and "Configure basic pages" or something. Also, elsewhere when we have multiple operations related to one thing, we use the dropbutton pattern.

Tagging for the UX team to give feedback.

mahaprasad’s picture

FileSize
28.54 KB

Applied the #51 patch & tested screen shot is attached.

patch-51

oriol_e9g’s picture

Status: Needs review » Needs work

Minor in style.css
\ No newline at end of file

oriol_e9g’s picture

rootwork’s picture

Status: Needs work » Needs review

@xjm (and useability reviewers), what if the pattern was more like the screenshot in #50? I actually thought that's what the previous patch was trying to create. I agree having the two links next to each other, with one in brackets, would be confusing.

What if they were on two separate lines, with the second line saying "Edit article content type," "Edit page content type," etc.?

Another option I could see is tacking it on to the end of the help text. So then it would say something like "Use articles for time-sensitive content like news, press releases or blog posts. Edit this content type." The edit link could be in parentheses, brackets, or italicized, although I think the fact that it's a link would probably set it apart enough.

pameeela’s picture

@rootwork @xjm I also think this is really confusing. I frequently do training for users new to Drupal and the concept of editing content vs editing content types is already hard to grasp. I think this blurs the line even further, by eliminating the content/structure split - which I see as a small hurdle to get over up front, but from there it makes a lot of sense.

I do appreciate this as an attempt to make things less confusing, so I am keen to see what the UX team thinks!

xjm’s picture

@rootwork, #50 is exactly what I found very confusing. My review is about that screenshot.

YesCT’s picture

Issue summary: View changes

updating latest screenshot

YesCT’s picture

FileSize
50.98 KB
173.1 KB
244.8 KB

I'm reading the motivation in the issue summary:

Some users go to the content section, rather than the structure section, looking for options to edit content types.

I've seen this in Usability testing the multilingual stuff.
http://groups.drupal.org/node/285978 (g.d.o post). I have not gone through all the video to make notes yet. I'll come back and provide a specific example when I find it.

But, from memory, I think where they actually went was: admin/content (not the shortcut to add content):

content.png

And then tried the edit link for a particular piece of content when attempting to configure the content type in general.

on the add content page

But back to the add content page...
the text in [ ] reminds me of the [edit] [clone] [delete] links that used to show up when hovering over a view.

Consider:
1. What about using the word *structure*.
2. Also, since this is the add content page. We do not want the main emphasis to appear to be to edit the content type. (which it is I think in the screenshots previously posted)
3. Being specific about the links, so they are not identical.. there might be some code reusable from #1810386: Create workflow to setup multilingual for entity types, bundles and fields because we had to figure out the type of things when building the label for in input items.

a. Article[ Edit Article content type structure ]
b. Article[ Edit Article content type ]
c. Article[ Edit Article structure ]
d. Add an Article[ Edit Article structure ]

this shows a and b:
emphasis.png

but I think my favorite might be:

use_edit_hover_like_blocks.png

I would mark this needs work for that. But I think we still want a Usability review to point this in an acceptable direction.

[edit: added width= on the img's because my retina display yields giant screenshots]

YesCT’s picture

aschiwi’s picture

Status: Needs review » Needs work
FileSize
153.91 KB

Just got to this issue via the Prague code sprint (http://drupalmentoring.org/node/425/). I'm not sure this is still relevant, since the UX team hasn't given any feedback and there's still discussion about it. Also the patch is pretty outdated by now.

I think one major part of the problem is that only the content types are listed here, but not the "action" - in my experience people forget to read the page title, which states "Add content" (that title is also hard to see with Overlay module on). So they click on "Article" thinking they can edit the content type. Proposed quick fix: Make the links say "Add Article" and "Add Page".

Here's a screenshot, what do you guys think?

add content

aschiwi’s picture

Here's a small patch to theme_node_add_list and seven_node_add_list for testing purposes. See comment #61 for a screenshot of the result.

aschiwi’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, drupal-add-content-description-384150-61.patch, failed testing.

rootwork’s picture

I like the idea in #61.

But we still desperately need useability reviewers, for instance for the other ideas in #59.

rootwork’s picture

Issue summary: View changes

added related issues

xjm’s picture

Component: node.module » node system
Issue summary: View changes

(Merging "node system" and "node.module" components for 8.x; disregard.)

rootwork’s picture

Assigned: rootwork » Unassigned
Status: Needs work » Needs review
Issue tags: -SprintWeekend2013 +SprintWeekend2014, +useability, +Needs usability testing

Sorry, didn't realize this was still assigned to me. This still needs a useability review.

rootwork’s picture

Issue summary: View changes
Issue tags: -useability

Updating issue summary and removing my misspelled tag.

zaporylie’s picture

  1. To make it easier to review I've re-rolled patch #62.
  2. Here is how it looks like with that path:
    Seven

    Bartik
  3. I don't like solution proposed by this patch. Feel like this might cause problem for multilingual initiative and people responsible for interface translations. I think we shouldn't add 'Add ' prefix to every content type.
  4. I feel like changing something on node/add might be ok only than, if it won't change anything in main task of that page. So it has to be subtle but visible in the same time. From the list of already proposed solutions I like this one the most...
    Article [Edit structure]
  5. ...althought I would consider one more solution - general link or tab on the top of the list with admin/structure/types path.

Status: Needs review » Needs work

The last submitted patch, 69: drupal-add-content-description-384150-69.patch, failed testing.

rootwork’s picture

There are a lot of proposals here (just look at the issue summary); the reroll in #69 was of #50, but there's also YesCT's idea from #59 (which you might like better zaporylie). Also obviously a lot of things are out of date here since overlay doesn't even exist in D8 anymore.

I wonder if any usability folks can let us know if there are demonstrated problems with this page on recent D8 betas, and if so what they think about some of the solutions in this issue. Otherwise we're just going to keep pushing forward new patches based on an analysis of a Drupal interface that is no longer in place.

So, again, "needs usability review"...

rootwork’s picture

Patrick Storey’s picture

Issue tags: -Novice

I am removing the novice tag.

I am removing the novice tag from this issue because: it was added 6 years ago. It is long, without clearly defined remaining tasks, and in the last few comments it looks like the direction of the issue is lacking consensus.

Novice tag documentation of tasks or issues to avoid: https://www.drupal.org/core-mentoring/novice-tasks#avoid

Bojhan’s picture

Issue tags: -Needs usability review
rootwork’s picture

@Bojhan needs usability review was added because the interface had changed since this was first proposed. I said in #71:

I wonder if any usability folks can let us know if there are demonstrated problems with this page on recent D8 betas, and if so what they think about some of the solutions in this issue. Otherwise we're just going to keep pushing forward new patches based on an analysis of a Drupal interface that is no longer in place.

Are you removing it because you disagree, or because you think there are no longer usability issues with this interface? If it's the latter, maybe we should just close this issue, as plenty has changed on these pages in the meantime.

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.

yoroy’s picture

Version: 8.1.x-dev » 8.2.x-dev
Issue tags: -Needs usability testing, -D8UX usability +ux-workflow

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.

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.