Steps to reproduce:
- Go to admin/structure/menu/manage/navigation
- move both Article and Basic page (on a default install) out from under Add content
- 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.
Comment | File | Size | Author |
---|---|---|---|
#54 | 1009982-54.patch | 2.96 KB | aerozeppelin |
#54 | test-only-fail-1009982-54.patch | 1.24 KB | aerozeppelin |
#54 | interdiff-1009982-34-54.txt | 2.19 KB | aerozeppelin |
#49 | Test-Patch-Menu-Displacement-Issue-1009982.patch | 1.41 KB | ajalan065 |
#43 | tools_menu-two_empty_items.png | 25.37 KB | klonos |
Comments
Comment #1
mlncn CreditAttribution: mlncn commentedcorrected title
Comment #2
montesq CreditAttribution: montesq commentedconfirmed here
Comment #3
cweagansAlso can confirm.
Comment #4
David D CreditAttribution: David D commentedI can confirm this. I posted about it here: http://drupal.org/node/550254#comment-4046256
Comment #5
lightstring CreditAttribution: lightstring commentedI'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.
Comment #6
Itangalo CreditAttribution: Itangalo commentedWhat 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
Comment #7
cweagansI 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.
Comment #8
mkadin CreditAttribution: mkadin commentedI 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.
Comment #9
klaasvw CreditAttribution: klaasvw commentedHere'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?Comment #10
klaasvw CreditAttribution: klaasvw commentedAfter 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.
Comment #11
kgordon CreditAttribution: kgordon commentedI 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
Comment #12
mkadin CreditAttribution: mkadin commented@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.
Comment #13
c31ck CreditAttribution: c31ck commentedThe line with $type_url_string can be omitted.
Needs a space character before and after the dot.
Needs a space character before and after the dot.
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.
Comment #14
klaasvw CreditAttribution: klaasvw commentedThanks for the review!
Here's a new patch that also contains the issues raised in #13
Comment #15
hefox CreditAttribution: hefox commentedIt 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.
Comment #16
gpk CreditAttribution: gpk commentedIs this a dupe of related issue #550254: Menu links are sometimes not properly re-parented?
Comment #17
hefox CreditAttribution: hefox commentedThe situation occurs also when just moving around the menu links purposefully, so nope.
Comment #18
sunConfirming 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:
_node_add_access()
, the menu access callback for node/add performs this check: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.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.
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)
Comment #19
klaasvw CreditAttribution: klaasvw commentedThanks very much for the review sun!
The attached patch adds the following changes:
node_hook($type->type, 'form')
access check.$type->type
is now being used.node_add_page()
now returns a render array.Comment #20
klaasvw CreditAttribution: klaasvw commentedComment #21
sunPassing 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.
Comment #22
Itangalo CreditAttribution: Itangalo commentedYay!
Comment #23
catchThis 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.
Comment #24
andypostThis 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
Comment #25
cweagansA 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.
Comment #26
hefox CreditAttribution: hefox commentedAs 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.
Comment #27
sun1) 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.)
Comment #28
cweagansHmm. 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).
Comment #29
andypostThis 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
Comment #30
andypostSuppose 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
Comment #31
anrikun CreditAttribution: anrikun commentedRelated issue: #550254: Menu links are sometimes not properly re-parented
Patches for D8 and D7 are provided there. Please review them.
Comment #32
catchMarked #1844342: Links on node/add page generated from menu?! as duplicate.
Comment #33
jenlamptonHi 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?
Comment #34
jenlamptonreroll D7 version, patch didn't apply cleanly to 7.18.
Comment #35
mkadin CreditAttribution: mkadin commentedI'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.
Comment #36
paul_constantine CreditAttribution: paul_constantine commentedI 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
Comment #37
anrikun CreditAttribution: anrikun commentedDid someone try patch at #550254: Menu links are sometimes not properly re-parented?
Comment #38
Bob123 CreditAttribution: Bob123 commentedSame issue
after moving "add content" to a different menu, with Drupal 7.19 (16 January 2013).
The problem persists...
Comment #39
bjobra CreditAttribution: bjobra commentedI 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
Comment #40
klonosI 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.
Comment #41
klonos@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.
Comment #42
amateescu CreditAttribution: amateescu commentedThis needs to be done in 8.x first.
Comment #43
klonosWell, 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):
When I went into edit mode, it turned that they didn't have a path either:
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.
Comment #43.0
klonos...updated issue summary.
Comment #44
xjm(Merging "node system" and "node.module" components for 8.x; disregard.)
Comment #45
jenlamptonpatch in #34 still applies cleantly to 7.32
Comment #46
calbasiI agree with Klonos... I think it's unbelievable this issue can not be considered a bug !
Comment #47
jenlamptonpatch in #34 still applies cleantly to 7.34
Comment #48
jenlamptonpatch in #34 still applies cleantly to 7.43
Comment #49
ajalan065 CreditAttribution: ajalan065 as a volunteer and at Innoraft commentedtest for the bug in Drupal 8
Comment #53
jenlamptontwo 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
Comment #54
aerozeppelin CreditAttribution: aerozeppelin at California State University San Bernardino commentedAdded tests to #34.
Comment #58
jenlamptonPatch in #54 applies cleanly, and still fixes the issue. Thanks @aerozeppelin!
Comment #61
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedThere 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.
Comment #62
jenlamptonI 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 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.
Comment #63
jenlamptonPatch in #54 still applies cleanly to Drupal 7.58.
Comment #64
jenlamptonPatch in #54 still applies cleanly to Drupal 7.59.
Comment #65
hey-pingu CreditAttribution: hey-pingu commentedI`ve been having a similar issue as described here: https://www.drupal.org/project/admin_menu/issues/2950890
Comment #66
jenlamptonPatch in #54 still applies cleanly to Drupal 7.63.
Comment #67
As If CreditAttribution: As If commentedPatch in #54 still applies cleanly to Drupal 7.64.
Note: The admin_menu module misses it.
Comment #69
joseph.olstadThanks for the patch, I also need this patch
Comment #70
joseph.olstadRationale:
1) Same fix exists in D8 (already committed)
2) Backport has tests
3) Backport works on latest D7 core
Comment #71
mcdruidRemoving 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.
Comment #72
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedMy opinion to #61 and:
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.
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 oftheme_node_add_list()
. It needs to be preserved like in D8 patch. Ideally the new code innode_add_page()
should prepare the same structure of$content
variable, so thattheme_node_add_list()
does not have to be changed at all (otherwise we will risk that we will break existing themes).2.
The else block is unrelated change, as this is not currently in D7, nor in D9 code.
3.
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.
Comment #73
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedI 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
Comment #75
mlncn CreditAttribution: mlncn at Agaric commentedThere 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!)