Steps to reproduce:

  1. Go to admin/structure/menu/manage/navigation
  2. move both Article and Basic page (on a default install) out from under Add content
  3. The page will lie to you, claiming: "You have not created any content types yet. Go to the content type creation page to add a new content type."

Good news: If you move the entire Add content menu item with its children from navigation to, another menu, the node/add page still works...

Bad news: ...the node/add page still works but includes options only for any "Add {content_type}" sub-menu that its respective menu item was moved along with the parent Add content menu item. Any custom content types created after the move of the menu keep adding their respective "Add {content_type}" menu items under the Navigation menu. So, the effect caused is that people wonder why their custom content types don't get a "Add {content_type}" entry in the "Add content" page and a submenu under the "Add content" menu item.

Also, you can disable the Add content link in Navigation, its children still show up there and on node/add.

Bad news: If you disable a node/add/[content-type] menu link, it disappears from the node/add page too.

This is a regression from Drupal 6, as i remember disabling less important content types from the menu and still being able to access them on the node/add page.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mlncn’s picture

Title: Removing node/add/[content-type] link from beneath "Add content" in the navigation menu also removes it from the navigation page » Removing node/add/[content-type] link from beneath "Add content" in the navigation menu also removes it from the Add conten page

corrected title

montesq’s picture

confirmed here

cweagans’s picture

Also can confirm.

David D’s picture

I can confirm this. I posted about it here: http://drupal.org/node/550254#comment-4046256

lightstring’s picture

I'm also comfirming. I'm confused on this issue as it seems like the "Add content" page get the links from unlocked items of navigation menu.

Itangalo’s picture

Title: Removing node/add/[content-type] link from beneath "Add content" in the navigation menu also removes it from the Add conten page » The "node/add" page shows child menu items for "node/add", rather than create links for all content types
Version: 7.x-dev » 8.x-dev
Category: bug » feature

What seems to happen is that the node/add page displays any child menu items found under the "node/add" menu link – which in a standard installation corresponds to the create links for all content types, but can be changed manually.

I would say that this is an unexpected behaviour, since all students I've had expects to find links for each content type on node/add (even if they have messed around in the Navigation menu).

This is close to a bug, but I'm marking this as a feature request. And forwarding it to Drupal 8.

Steps to reproduce:
* Clean install
* Edit the Navigation menu: disable one of the creation links
* Edit the Navigation menu: add a random child item to the node/add item
--> The node/add page reflects these changes

cweagans’s picture

Category: feature » bug

I don't think this is a feature request. This is a major problem for anyone that rearranges their menus a little bit. The content type page should always list all the content types. I agree with the other metadata changes though - we should fix this in D8, then backport.

mkadin’s picture

I agree that this counts as a bug. It came up for me during a D6 > D7 upgrade - I had messed with the menu structure in D6 months earlier. I'd be willing to work on the code if someone can point me in the right direction. I found this original issue: http://drupal.org/node/113898 which I think is the source of this problem.

klaasvw’s picture

Status: Active » Needs review
FileSize
1.1 KB

Here's a patch against 8.x-dev.

Instead of using the system menu this will use node_type_get_types for finding the node types to list on the "Add content" page. It only loads node types the user has node create permissions for and like in the original version it will forward to the node form if there's only one node type defined.

I'm not 100% sure about using the same data structure as menu items though. I did this to minimize the changes needed for themes that override theme_node_add_list. Maybe it's better to use the raw node type instead of building a new array?

klaasvw’s picture

After discussing this with c31ck I decided to get rid of the menu item data structure and simply passed the raw node type data structure to the theme.

kgordon’s picture

I am very much a beginner. Is this patch usable for Drupal 7.10? If so how does one apply it? I would like to try if it is a fix.
Many thanks,
Kevin

mkadin’s picture

@kgordon, the patch passed automated testing (that's why its green). But notice how this issue is marked as 'needs review', this means that very few people (if anyone) have confirmed that its a ggood patch. Use it at your own risk.

As for how to apply the patch, take a look at these docs about patches in general, http://drupal.org/node/367392 and do some Googling. There's a lot of good info out there.

c31ck’s picture

Status: Needs review » Needs work
+++ b/core/modules/node/node.pages.incundefined
@@ -31,12 +31,19 @@ function node_page_edit($node) {
+  // Only use node types the user has access to.
+  foreach (node_type_get_types() as $type) {
+    if (node_access('create', $type->type)) {
+      $type_url_str = str_replace('_', '-', $type->type);
+      $content[$type->type] = $type;

The line with $type_url_string can be omitted.

+++ b/core/modules/node/node.pages.incundefined
@@ -31,12 +31,19 @@ function node_page_edit($node) {
+    drupal_goto('node/add/'.$type_url_str);

Needs a space character before and after the dot.

+++ b/core/modules/node/node.pages.incundefined
@@ -57,9 +64,10 @@ function theme_node_add_list($variables) {
+      $output .= '<dt>' . l($type->name, 'node/add/'.$type_url_str) . '</dt>';

Needs a space character before and after the dot.

+++ b/core/themes/seven/template.phpundefined
@@ -40,10 +40,11 @@ function seven_node_add_list($variables) {
+      $output .= '<span class="label">' . l($type->name, 'node/add/'.$type_url_str) . '</span>';

Needs a space character before and after the dot.

Other than that the patch looks great and works as expected for me. I've manually tested that all the node types are listed, that the access permissions are enforced and that the node/add listing page gets bypassed if only one content type is available.

klaasvw’s picture

Status: Needs work » Needs review
FileSize
2.5 KB

Thanks for the review!

Here's a new patch that also contains the issues raised in #13

hefox’s picture

It works, but I'm also on the "this is both a feature request more than a bug". I've used being able to manipulate the menu to include new links and exclude others to customize this page, and changing it like this makes that a lot harder. Could override it, but imagine if multiple modules were doing that.

Note that also fixes that the the fall through text doesn't check permission, shows for people who can't create content types, leading to access denied upon clicking the create content type link.

gpk’s picture

hefox’s picture

The situation occurs also when just moving around the menu links purposefully, so nope.

sun’s picture

Title: The "node/add" page shows child menu items for "node/add", rather than create links for all content types » node/add page misses content types when menu links are moved or disabled
Component: menu system » node.module
Status: Needs review » Needs work
Issue tags: -user experience

Confirming this bug report and proposed solution.

The menu links should not have an impact on the node/add page content. If people want to hide a content type on that page, then they should configure appropriate user permissions instead.

Introduced in D6 via #167109: Split up node module (a testament to how many different changes one was able to sneak and squeeze into a single patch back in good ol' 2007 times! ;))

Although the current behavior is bogus, this cannot be backported to D7.

On the patch:

+++ b/core/modules/node/node.pages.inc
@@ -31,12 +31,18 @@ function node_page_edit($node) {
+    if (node_access('create', $type->type)) {

_node_add_access(), the menu access callback for node/add performs this check:

    if (node_hook($type->type, 'form') && node_access('create', $type->type)) {

Since we still did not remove hook_node_info() yet, it is possible for a node type to be defined without an actual add/edit form (Don't ask me, I've no idea what that was or is good for...), so we better copy that and use the identical condition here.

+++ b/core/modules/node/node.pages.inc
@@ -31,12 +31,18 @@ function node_page_edit($node) {
+      $content[$type->type] = $type;
...
+    $type_url_str = str_replace('_', '-', $type->type);

@@ -57,9 +63,10 @@ function theme_node_add_list($variables) {
+      $type_url_str = str_replace('_', '-', $type->type);

+++ b/core/themes/seven/template.php
@@ -40,10 +40,11 @@ function seven_node_add_list($variables) {
+      $type_url_str = str_replace('_', '-', $type->type);

Let's prepare and set a $type->url_string property when initially iterating over the content types, so we do not have to repeat this all over again.

That said, it does not make sense to look further into moving the URL string munging deeper into the node type API, since #617562: Remove underscore-to-dash conversion in path arguments for content types will remove that horrible string replacement altogether.

+++ b/core/modules/node/node.pages.inc
@@ -31,12 +31,18 @@ function node_page_edit($node) {
   return theme('node_add_list', array('content' => $content));

While being here, let's convert this into a render array, so contributed and custom modules can adjust, enhance, and manipulate the list and page content at will. (e.g., when configuring user permissions is not sufficient or inappropriate for a specific use-case)

klaasvw’s picture

Thanks very much for the review sun!

The attached patch adds the following changes:

klaasvw’s picture

Status: Needs work » Needs review
sun’s picture

Status: Needs review » Reviewed & tested by the community

Passing raw node type objects into a theme function is a bad practice, but since that was the case before already, and because this patch only intends to fix the bogus data source, we're good to go.

Itangalo’s picture

Yay!

catch’s picture

Status: Reviewed & tested by the community » Fixed

This looks good, I have no idea why we were using system_admin_menu_block() in the first place, but the less uses there are of that the better. Committed/pushed to 8.x.

andypost’s picture

This introduces regression - no way to sort node/add links. Also there should be follow-up to fix inconsistency between menu links and node/add page

cweagans’s picture

Status: Fixed » Needs work

A few things:

1) Since this is a bug, I'm pretty sure we need a test to make sure that we don't have to fix this again in the future.
2) I see no reason that this cannot be backported to Drupal 7. It's a bug fix, and the patch in #19 seems harmless enough.
3) @andypost, Why would you want to sort node/add links by anything other than alphabetical? And the entire point of this issue is that the menu links should have absolutely no bearing on what's on node/add.

hefox’s picture

As far as this breaking anything, what I mentioned before: if you have a node type that you want people to create but do not want to appear in the listing, you were able to do that for d7 and less before by removing it from the menu. The answers module (which has an answer node type that is not usable without first having a question) does that. With entities now those type of things are less likely to be nodes, but nodes are still the easiest to make in d7 (imho), so weird content types.

You were also able to do other things like adding new links to create other types of things or even adding a link to a view (which I did, for the answers case also -- added a view of questions to answer), or change the description of the menu item.

This is why I still this isn't quite a bug. So yea, backporting is not harmless; as far as how many it'd effect negatively effect (who were doing stuff mentioned above) vs. how many it'd help (who suffer the menu item problems), no idea.

sun’s picture

Issue tags: +Needs tests

1) You're right. I've no idea why we didn't notice that there are no tests ;)

2) As @hefox outlined, this would be a unexpected behavior change and thus cannot be backported.

3) Any customizations to this page should be done in the same way you do customizations to other pages. That's why we changed the return value to a render array. (I'd even would have wanted to remove the theme function, but alas, there's no theme_definition_list yet.)

cweagans’s picture

Hmm. Can we figure out a way to get this fix cleanly into Drupal 7? It's kind of a dumb behavior for that page - I'd even be okay with having a variable that you can set to make it work correctly (even though that seems like kind of a hack).

andypost’s picture

3) @andypost, Why would you want to sort node/add links by anything other than alphabetical? And the entire point of this issue is that the menu links should have absolutely no bearing on what's on node/add.

This was very useful to move some of the menu-links (to create some node-types) to different menus to display their blocks on different pages a-la context-admin module could.
Also sorting was very useful to move upper the most usable content types

The regression I point is different source of menu-links and /node/add page

andypost’s picture

Suppose we could just add a sorting to admin/structure/types for usability also this require #1589838: Add weight field to node type and sorting for admin/structure/types and usability team review

anrikun’s picture

Related issue: #550254: Menu links are sometimes not properly re-parented
Patches for D8 and D7 are provided there. Please review them.

catch’s picture

jenlampton’s picture

Hi Guys, sorry I missed the work going on over here when I started #1844342: Links on node/add page generated from menu?!, but I need a 7.x patch since my curent node/add page is all SNAFU (so just cross posting previous patches).

Links on the node page started being built from the menu in D6. Since I am upgrading from a D5 site where the menu was conveniently rearranged to match my use case (and the node/add page was *not* broken) upgrading to either 6, or in my case 7, makes node/add useless.

It looks to me like the unexpected change happened way back in D6, and this is just putting things back the way they were - the way they should have stayed IMO - and fixing a huge upgrade bug in the process! :)

If modules are doing something special to node types and how they are added, they should have another way to change the links that appear on this page. Using the menu system is just asking for trouble. It's the wrong tool for the job. Can we just add a drupal_alter or something instead?

jenlampton’s picture

reroll D7 version, patch didn't apply cleanly to 7.18.

mkadin’s picture

I'm on hefox's side for the D7 backport - I'm not sure a back port is a good idea. Folks may have customized the node/add page (I.e. hiding certain content types from novice users), and I don't think we want an upgrade to make them suddenly reappear.

paul_constantine’s picture

FileSize
226.36 KB
285.37 KB

I don't know if my problem applies here, but my node/add (Drupal 7.18) page seems to be very buggy too.

When changing content types (i.e. the descpription of a content type) these changes are nowhere to be seen.

The attached screenshots show that the "edit node type page" and the "add node page" do not match. Some of the names and node types on the "node add page" apply to an earlier version of the website that was changed long ago.

Note that there is even a forum topic on the "node add page" even tough the forum module is disabled.

When checking the SQL database I noticed that everything is as it should be.

So where are these faulty node entries coming from? Does anyone know?

Regards,
Paul

anrikun’s picture

Bob123’s picture

Version: 8.x-dev » 7.19

Same issue

You have not created any content types yet. Go to the content type creation page to add a new content type

after moving "add content" to a different menu, with Drupal 7.19 (16 January 2013).

The problem persists...

bjobra’s picture

I am not proud of myself, often reading and getting help, never contributing. I Think it is time now. This happened me after disabling what i thought was unnecessary as i do not use navigation menu. The cause for this was that i installed menu block which helped me very well to duplicate my horizontal and vertical menu. Had no idea that the disapperance could be a menu problem.

try to be more active futurewise

klonos’s picture

Version: 7.19 » 7.x-dev
Issue tags: +Needs backport to D7

I am using Content Menu in order to provide site owners with the ability to easily manage menus and add menu items that link to content without using the non-intuitive weight method offered by core (#1101600: Users need to be able to select from list when adding menu items to a menu). This module does not mess with the core menus - it only takes over the edit form of any custom menus. But I needed a way to expose the "Add content" menu to the site owners. Proper node access permissions would take care of offering them only the submenus for content types they actually had permissions for. So I moved the entire "Add content" menu item along with any submenus available at that time to a custom "Site administration" menu. And all was fine...

...until I started noticing that any newly created content types would not get an entry in the "Add content" page and they would not get any submenu items under (the now moved) "Add content" menu item. I started blaming other contrib menu-related and content-type-related modules and went into disable-uninstall-test-reinstall frenzy to no avail. Two weeks later I finally noticed that the "Navigation" menu I had deprecated (because I was using custom menus that Content Menu would handle) contained the links to all the content types that did not get menu and page entries under the "Add content" menu/page. WTF?!?

So, here I am after I wasted so much time and energy reading through this issue (and #1009982: node/add page misses content types when menu links are moved or disabled) seeing people suggesting that this is not a bug and insisting that it should not be backported because it will potentially break contrib. Let me tell you: If it so happens that certain modules depend on this bug to offer functionality, then tough.

This is definitely a bug - not a feature request! The way things work now is neither proper (and thank God it's now fixed in D8) nor expected by users. Here's a list with various posts around d.o filled with comments from frustrated users to back my case up (I'm sure I haven't spotted all of them - there must be more around):

https://groups.drupal.org/node/280868
https://drupal.org/node/613292
https://drupal.org/node/997444
https://drupal.org/node/1073994
https://drupal.org/node/1166416
https://drupal.org/node/1218606
https://drupal.org/node/1233092

PS: people that have seen me post around the queues in d.o for years now know that I don't mess with the issues' priority, but boy do I want to set this to 'major' ...at the very least.

klonos’s picture

@jenlampton: Jennifer you're my hero!!

Your patch in #34 works perfectly when it comes to adding an entry under the /node/add page for newly created content types. What would be really cool now is if you could make it "track down" the "Add content" menu item (wherever that may have been moved to) and add the "Add {content_type}" menu items there instead of the "Navigation" menu.

Thank you 1 mil.

amateescu’s picture

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

This needs to be done in 8.x first.

klonos’s picture

Well, by reading this issue I got the impression that this was actually fixed in D8 from #23. I gave it a quick spin over at simplytest.me and here's what I did:

1. Visit the "Add content" page and made sure that entries for the two content types "Article" and "Page" provided by the standard profile were listed there.
2. Edited the "Tools" menu since that's where the "Add content" menu item is in D8 and then moved it under the "Main navigation" menu.
3. Checked the "Add content" page again and made sure that the entries for the two content types "Article" and "Page" were still there.
4. Created a new custom content type called "Test content type".
5. Checked the "Add content" page again and made sure that the newly created content type "Test content type" had an entry there along with the "Article" and "Page" content types.
6. Created a new custom menu called "Test menu".
7. Moved the "Add content" menu item from the "Main navigation" menu to the newly created custom menu "Test menu".
8. Checked the "Add content" page again and made sure that the entries for all the content types ("Article", "Page" and "Test content type") were listed there.
9. Created yet another custom content type called "Test content type 2".
10. Checked the "Add content" page one final time to make sure that the new custom content type "Test content type 2" entry is still added to the page (now that it was moved under a custom menu).

So, I guess that this pretty much covers just about anything. The only thing I noticed was that the "Tools" menu included two menu items without any label (before start moving things around and creating content types and menus):

Two empty menu items under the Tools menu

When I went into edit mode, it turned that they didn't have a path either:

menu items have empty label and path

My initial reaction was that this was a whole different issue, but their number made me think that these could be some sort of leftovers from removing the "Add article" and "Add page" menu items. I honestly don't know, but there were no extra (blank or otherwise) menu items created there for the two custom types I created during my testing.

Anyways, it seems that if there's anything left to do for D8 is:

- add back the menu items for "Add article" and "Add page" (and/or remove the two blank items depending on whether these are related)
- figure out a way to track the menu under which the "Add content" item is and add "Add {content_type_name}" menu items for newly created content types under it.

klonos’s picture

Issue summary: View changes

...updated issue summary.

xjm’s picture

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

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

jenlampton’s picture

patch in #34 still applies cleantly to 7.32

calbasi’s picture

I agree with Klonos... I think it's unbelievable this issue can not be considered a bug !

jenlampton’s picture

patch in #34 still applies cleantly to 7.34

jenlampton’s picture

patch in #34 still applies cleantly to 7.43

ajalan065’s picture

test for the bug in Drupal 8

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.

  • catch committed c74aa1e on 8.3.x
    Issue #1009982 by klaasvw: Fixed node/add page misses content types when...

  • catch committed c74aa1e on 8.3.x
    Issue #1009982 by klaasvw: Fixed node/add page misses content types when...
jenlampton’s picture

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

two commits to D8, does that mean we can move this back to D7 now? patch in #34 still applies (with some fuzz) to 7.50

aerozeppelin’s picture

Added tests to #34.

The last submitted patch, 54: test-only-fail-1009982-54.patch, failed testing.

  • catch committed c74aa1e on 8.4.x
    Issue #1009982 by klaasvw: Fixed node/add page misses content types when...

  • catch committed c74aa1e on 8.4.x
    Issue #1009982 by klaasvw: Fixed node/add page misses content types when...
jenlampton’s picture

Status: Needs review » Reviewed & tested by the community

Patch in #54 applies cleanly, and still fixes the issue. Thanks @aerozeppelin!

The last submitted patch, 34: core-rebuild_node_add_page-1009982-34-do-not-test.patch, failed testing.

The last submitted patch, 33: core-rebuild_node_add_page-1844342-1.patch, failed testing.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review

There are a LOT of people above arguing that the current behavior is a feature, and that backporting this change would break things. This needs more discussion.

Personally, I lean towards seeing it as a feature also. The node/add page looks just like the admin/structure page (for example) so it's consistent for it to be built off a menu just like that page is.

I definitely get why people want to change the behavior on some sites, but I think we're going to need to a way to do that which preserves backwards compatibility.

jenlampton’s picture

The node/add page looks just like the admin/structure page (for example) so it's consistent for it to be built off a menu just like that page is.

I think you are comparing apples to oranges here. The node/add page isn't an administrative page, like admin/structure. Creating content is not an administrative task in Drupal. I can understand why people would want admin pages match the admin menu, that makes sense, but that's not what's going on here.

The add content page was intended to be a page that non-admins can use to create content. The name of the page does not contain "Administer", and the the path does not contain "admin". That decision was intentional.

If I'm not an admin, and don't have access to the admin-only menu, this page is how I create content in the majority of cases. If someone moves around the links in the menu (which, shouldn't affect me at all, cause I don't use the admin menu) but then the links mysteriously disappear from this page too - the site is broken for me.

I definitely get why people want to change the behavior on some sites, but I think we're going to need to a way to do that which preserves backwards compatibility.

I ran into this because I'm upgrading a site from Drupal 6. Backwards compatibility was broken for me - and everyone else coming from D6 - when this change was introduced in D7.

We could add a setting somewhere (maybe admin/config/content/create?) that provides an option to let people choose whether they want this non-admin page to match their admin menu, or allow people to create whatever content they have permission to create, but that seems like "a feature" better suited to contrib.

For now: Patch in #54 still applies cleanly, and still fixes the issue in Drupal 7.56.

jenlampton’s picture

Patch in #54 still applies cleanly to Drupal 7.58.

jenlampton’s picture

Patch in #54 still applies cleanly to Drupal 7.59.

hey-pingu’s picture

I`ve been having a similar issue as described here: https://www.drupal.org/project/admin_menu/issues/2950890

jenlampton’s picture

Patch in #54 still applies cleanly to Drupal 7.63.

As If’s picture

Patch in #54 still applies cleanly to Drupal 7.64.
Note: The admin_menu module misses it.

  • catch committed c74aa1e on 9.1.x
    Issue #1009982 by klaasvw: Fixed node/add page misses content types when...
joseph.olstad’s picture

Thanks for the patch, I also need this patch

joseph.olstad’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs tests, -Needs backport to D7 +Pending Drupal 7 commit, +Drupal 7.71 target

Rationale:
1) Same fix exists in D8 (already committed)
2) Backport has tests
3) Backport works on latest D7 core

mcdruid’s picture

Issue tags: -Pending Drupal 7 commit, -Drupal 7.71 target

Removing the "Pending Drupal 7 commit" tag for now per my comment #1007746-215: Reordering fails with more than 100 items in a menu which I won't repeat in full here.

poker10’s picture

Status: Reviewed & tested by the community » Needs work

My opinion to #61 and:

The node/add page looks just like the admin/structure page (for example) so it's consistent for it to be built off a menu just like that page is.

This is wrong and the issue should be considered as a bug in D7. The node/add page shoud list all content types user has create access to and it should definitely not depend on some admin menu structure. This page is intended to list content types, not custom menu links which admins want there.. Therefore I support the approach in the patch #54.

Anyway, after the #54 review, I think it will be better to create a separate issue for D7 patch (as per current backport policy), because the D7 patch is not ready yet. It seems to me that the patch is not a straight backport and contains multiple unrelated changes comparing to the D8/D9 code.

1.

+++ b/modules/node/node.pages.inc
@@ -22,14 +22,33 @@ function node_page_edit($node) {
-  return theme('node_add_list', array('content' => $content));
+
+  if (isset($items)) {

In D8/D9 the theme_node_add_list() usage was preserved, in D7 patch is removed and it is now impossible to override template of that list by themes. This is BC breaking change as multiple themes have their own implementation of theme_node_add_list(). It needs to be preserved like in D8 patch. Ideally the new code in node_add_page() should prepare the same structure of $content variable, so that theme_node_add_list() does not have to be changed at all (otherwise we will risk that we will break existing themes).

2.

+++ b/modules/node/node.pages.inc
@@ -22,14 +22,33 @@ function node_page_edit($node) {
+    if (user_access('administer content types')) {
+      $output = '<p>' . t('You have not created any content types yet. Go to the <a href="@create-content">content type creation page</a> to add a new content type.', array('@create-content' => url('admin/structure/types/add'))) . '</p>';
+    }
+    else {
+      $output = '<p>' . t('No content types available.') . '</p>';
+    }

The else block is unrelated change, as this is not currently in D7, nor in D9 code.

3.

+++ b/modules/node/node.pages.inc
@@ -22,14 +22,33 @@ function node_page_edit($node) {
-  // Bypass the node/add listing if only one content type is available.
-  if (count($content) == 1) {
-    $item = array_shift($content);
-    drupal_goto($item['href']);

I do not know why this drupal_goto() was removed - D8/D9 still has that.

--------

I am changing status to Needs work (temporarily). Once the child issue will be created this can be closed for D8 as Fixed.

poker10’s picture

Version: 7.x-dev » 8.0.x-dev
Status: Needs work » Fixed

I have created an issue for D7 backport, so closing this as fixed for D8.

#3304385: [D7] node/add page misses content types when menu links are moved or disabled

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

mlncn’s picture

There is now a best solution in contrib (Drupal 7 and modern Drupal) that makes it easy again to modify the links on the node/add page if you want to, providing a separate menu to power a replacement "Add content" page:

https://www.drupal.org/project/custom_add_content

(Glad i found that module as i was about to make the equivalent, since it was my fault it got difficult by reporting this bug!)