Problem

1. After changing the name of the article content type from "article" to "nyhed", the following error occurs on the following path: #overlay=admin/structure/types/manage/nyhed/fields.
Error: Notice: Undefined index: nyhed in _field_ui_bundle_admin_path() (line 314 of /home/www/xxx/modules/field_ui/field_ui.module).

2. When the affected machine name is saved in the $_SESSION['node_overview_filter'] used at path /admin/content

Proposed solution

This is cache issue. We should change function node_type_form_submit() in modules/node/content_types.inc. We need to add

field_cache_clear();
$_SESSION['node_overview_filter'] = array();

after node_types_rebuild();

CommentFileSizeAuthor
#19 drupal-fix_content_list_page_error_after_changing_machine_name-876366-19.patch736 byteshgoto
#12 876366-index-error-12.patch763 bytessivaji_ganesh_jojodae
#4 876366-index-error.patch534 bytesmarcingy
e20100807.jpg90.06 KBAnonymous (not verified)

Comments

Anonymous’s picture

Anonymous (not verified) commented

The error isn't persistent, when I go to the mentioned path now, no error occurs.

I'm thinking it could be a cache issue, as the error occured directly after the change. If this is correct I would class the error as minor, however I still think an error like this shouldn't occur, even if it goes away by itself.

furamag’s picture

furamag commented

I'm able to recreate this issue. This is cache issue. We should change function node_type_form_submit in modules/node/content_types.inc. We need to add 

field_cache_clear();

after

node_types_rebuild();

This fix works for me.

callison’s picture

callison commented

@furamag: Can you submit a patch?

marcingy’s picture

marcingy commented
Version: 7.0-alpha6 » 7.x-dev
Status: Active » Needs review
StatusFileSize
new 876366-index-error.patch534 bytes

We don't need to clear the data cache only the info cache. Patch attached.

callison’s picture

callison commented
Title: Changing content type name breaks index » Changing content type machine name breaks index
Status: Needs review » Reviewed & tested by the community

Looks good to me. Just a note for anyone else trying this - It's the machine name of the content type that causes the issue, not the human readable one.

dawehner’s picture

dawehner
Primary language German
commented
Version: 7.x-dev » 8.x-dev
Issue tags: +Needs backport to D7
dries’s picture

dries commented
Status: Reviewed & tested by the community » Needs review

While this looks like it would fix the problem, I wonder if it is a complete solution. For example, don't we need to clear the field info cache when we delete a node type?

Kjartan’s picture

Kjartan commented
Version: 8.x-dev » 7.x-dev
Status: Needs review » Needs work

I can not reproduce this for 8.x, but its still there in 7.x. The earlier patch fixes the issue so should be good to commit.

To Dries' point there is no error on delete, but I agree that we should probably clear relevant caches even if there isn't an obvious way to trigger php notices.

enrico200165’s picture

enrico200165 commented

After changing the machine name of a content type it is impossible to create new content of that type, if I try I land on the general Add Content page.
Besides code fixes, is there any (manual) way to fix this issue now so my site returns usable?

Should I post this as a separate issue? (I do not see any error messages about index)

bobbyaldol’s picture

bobbyaldol commented

@furamag
Can you tell us how you recreated the issue...That would help a lot

jaredcampbell’s picture

jaredcampbell commented

I had this same (or at least very similar) problem. When I changed the machine name of a content type and navigated to /admin/content I received the following error message:

"Notice: Undefined index: venue in node_filter_form() (line 177 of /home/district/public_html/district-trivia.com/modules/node/node.admin.inc)."

I believe I got this error message because my filter in /admin/content was currently set to the content type's old machine name. I fixed this by doing the following:

1. Changed the content type back to the original machine name
2. Went to /admin/content and clicked "Reset"
3. Changed the content type back to the new, desired machine name
4. Went to /admin/content and the error message was gone

Then I realized I had to manually update all of my views to point to the new content type. Voila! Everything appears to be working.

sivaji_ganesh_jojodae’s picture

sivaji_ganesh_jojodae commented
Issue summary: View changes
Status: Needs work » Needs review
Issue tags: +Novice
StatusFileSize
new 876366-index-error-12.patch763 bytes

I don't see any issues with renaming the machine name of content types. I'm still able to create new contents after changing its machine name.

Anyway I have added call to field_cache_clear() in node_type_form_submit() as it is believed to fix the issue for those who are able to reproduce it.

Besides I have added line to clear filter in page /admin/content for the case mention in comment #11.

Patch addressing the same has been attached. Rolled against branch 7.x.

sivaji_ganesh_jojodae’s picture

sivaji_ganesh_jojodae commented
Issue summary: View changes

Updated issue summary

parthipanramesh’s picture

parthipanramesh commented
Status: Needs review » Reviewed & tested by the community

I tested the latest patch and I am not getting any errors when I change name of the article content type. So it seems to work fine! Thank you!

David_Rothstein’s picture

David_Rothstein commented
Status: Reviewed & tested by the community » Needs work

Like #12 I can't reproduce the original issue (the one that's supposed to require the field_cache_clear()); is it still reproducible? And if we do need a field_cache_clear() there, do we need something equivalent in Drupal 8?

The second issue (with the admin/content filters) I can reproduce, and it would be Drupal 7 only. But if we clear the filters every single time a content type is saved, that's going to be extremely annoying for site administrators; they'll lose their filters completely even though 99% of the time the selected filters weren't even such to have triggered this bug. We should only clear the content type filter, and only when necessary (or alternatively, never clear it but add code on admin/content to handle the possibility of the filters in the session no longer existing; that would likely be a more robust fix).

balagan’s picture

balagan commented
Component: node.module » ajax system

I had a drupal 7.23 installed, where this problem occured. I wanted to try the patch and installed the current (7.34) core, where I cannot reproduce the error. I guess it is fixed.

balagan’s picture

balagan commented
Component: ajax system » node system

Sorry, I did not mean to change the component.

sowmiya.S’s picture

sowmiya.S commented

Hi,
I have tested, this issue with patch in my local drupal, itz working fine.

hgoto’s picture

hgoto commented
Status: Needs work » Needs review
StatusFileSize
new drupal-fix_content_list_page_error_after_changing_machine_name-876366-19.patch736 bytes

I tested this.

- The issue 1 cannot be reproduced.
- On the other hand, issue 2 can be reproduced.

So my recognition is the same as David_Rothstein's.

The patch #12 works well but I agree with #15.

We should only clear the content type filter, and only when necessary (or alternatively, never clear it but add code on admin/content to handle the possibility of the filters in the session no longer existing; that would likely be a more robust fix).

The error only occurs in admin/content page and should be handled there rather than the content type edit form. I tried creating a patch to handle the issue in the admin/content page and would like someone to review this. Thank you.

Steps to test the patch:

1. Open admin/content page and filter content type to article.
2. Open admin/structure/types/manage/article page and change the machine name, e.g, "nyhed".
3. Revisit the admin/content page. You can see an error message like "Notice: Undefined index: type in node_filter_form()". (You can reproduce the issue.)
4. Apply the patch.
5. Redo the steps 1 to 3. You'll find the error disappears.

stefan.r’s picture

stefan.r commented
Issue tags: +Needs manual testing, +Needs issue summary update, +Dublin2016

Marking Novice for the manual testing, confirmation that #15 has been addressed, and issue summary update

skt-001’s picture

skt-001 commented

there is no issue persist in any updated version of 7.x and for 7.x #19 fixes the issues. RTBC+1

poker10’s picture

poker10 commented
Status: Needs review » Needs work
Issue tags: -Needs backport to D7, -Novice, -Needs manual testing +Needs tests

This was not committed to D8+, therefore removing the backport tag. If I read that correctly, the issue 2 is only a D7 problem.

As this is a bug, we should probably add a simple test to demonstrate the problem (and no manual testing will be needed afterwards). Moving to NW.

Status: Needs work » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.