This one surprised me a bit.
To reproduce:
- go to "Structure>Menus>Navigation>List Links"
- rearrange the article and basic page so that the basic page is first, and save that configuration
- delete the article content type from "Structure>Content Types"
Now when you go to the "Add Content" modal, you find that "Article" and its description remain. And if you go to "Structure>Menus>Navigation>List Links" you find that the link also remains.
What's more, if you are tempted that resetting that link with the "reset" option might solve the problem, it instead turns into an extra "Add Content" link which can't be edited or deleted, but only disabled.
Trying cache clearing has no effect.
I'm marking as critical because this is simply too easy to fall into and could easily confuse new users. I'm also unsure if this should go against dev since I haven't tested but I have the issue currently with 7.10.
Comments
Comment #1
AQ808 CreditAttribution: AQ808 commentedProbably belongs in dev
Comment #1.0
AQ808 CreditAttribution: AQ808 commentedClarity
Comment #2
joachim CreditAttribution: joachim commentedConfirming this on D8.
Marking as needing backport all the way to D6, as I remember seeing it there too.
Comment #3
webchickUh, no sorry. :) This is definitely not critical. Sounds like a bug worth fixing, though. Should add tests to ensure it doesn't crop up again.
Comment #4
joachim CreditAttribution: joachim commentedOops, I hadn't noticed it was filed as critical.
Fixing tags.
Comment #5
AQ808 CreditAttribution: AQ808 commentedDon't be too critical. :) Keep in mind that I wasn't marking it critical in terms of D8... I imagine that whole ball of D8 wax is critical at this point.
This is just completely broken UX for the current D7 stable. However, I have no clue how you guys rate priority for bugs in the current stable.
Would this be better served as a 7.x-dev issue, since as a 8.x-dev it has a ton of competition against new emerging features which are bound to come in largely broken?
Comment #6
webchickYou can read about the severity levels here: http://drupal.org/node/45111
And nope. We always fix things in D8 first, then backport. This avoids any regressions when the new version comes out.
Comment #7
monteith CreditAttribution: monteith commentedIssue is only partially reproduced in 8.x
1. Install the latest Drupal 8.x using the standard profile.
2. In "Structure > Menus > Navigation > List Links" rearrange "Article" and "Basic Page" so that "Basic Page" is listed first.
3. Delete the "Article" Content Type from "Structure > Content Types."
Now the "Add Content" modal defaults to adding "Basic Page" content (there is no Article or description listed.)
However, if you go back to "Structure > Menus > Navigation > List Links" the "Article" link still remains.
Resetting the link removes the "Article" link, and adds an "Add Content" link that CAN be edited but not deleted.
Comment #8
monteith CreditAttribution: monteith commentedComment #9
monteith CreditAttribution: monteith commentedComment #10
cweagansFixing tags per http://drupal.org/node/1517250
Comment #10.0
cweagansForgot to mention cache clearing ineffective.
Comment #11
xjmComment #20
quietone CreditAttribution: quietone as a volunteer commentedI tested this on Drupal 7 and the list on "Add Content" modal is indeed incorrect after the deletion of a content type but after clearing the cache it is correct.
For Drupal 9, the node/add page is built in \Drupal\node\Controller\NodeController::addPage where the content type names always sorted. I still tested on Drupal 9.3.x, it works just fine and there was no need to manually clear the cache.
Since this is tagged for backport, changing version.
Comment #21
poker10 CreditAttribution: poker10 at ActivIT s.r.o. commentedThis issue should be solved by #1009982: node/add page misses content types when menu links are moved or disabled, once commited.