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.

Comments

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

corrected title

confirmed here

Also can confirm.

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

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.

Title:Removing node/add/[content-type] link from beneath "Add content" in the navigation menu also removes it from the Add conten pageThe "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

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.

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.

Status:Active» Needs review
StatusFileSize
new1.1 KB
PASSED: [[SimpleTest]]: [MySQL] 33,310 pass(es).
[ View ]

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?

StatusFileSize
new2.56 KB
PASSED: [[SimpleTest]]: [MySQL] 33,317 pass(es).
[ View ]

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.

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

@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.

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.

Status:Needs work» Needs review
StatusFileSize
new2.5 KB
PASSED: [[SimpleTest]]: [MySQL] 34,257 pass(es).
[ View ]

Thanks for the review!

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

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.

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

Title:The "node/add" page shows child menu items for "node/add", rather than create links for all content typesnode/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)

StatusFileSize
new2.44 KB
PASSED: [[SimpleTest]]: [MySQL] 36,591 pass(es).
[ View ]

Thanks very much for the review sun!

The attached patch adds the following changes:

Status:Needs work» Needs review

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.

Yay!

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.

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

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.

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.

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.)

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).

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

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

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

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?

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

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.

StatusFileSize
new226.36 KB
new285.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

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...

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

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.

@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.

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

This needs to be done in 8.x first.

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.

Issue summary:View changes

...updated issue summary.

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

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