Just noticed that the three content type items that I added using hook_node_info that had underscores, were added too the admin menu under the icon > Administer menu, as such:

Icon > administer > Edit
Icon > administer > Edit
Icon > administer > Edit
Icon > administer > Manage fields
Icon > administer > Manage fields
Icon > administer > Manage fields
...

rather than the Content management > Content types > XXX location like the ones without underscores.

Comments

Anonymous’s picture

Yes. I'm seeing this as well. However I only have one underscore named content type, and it's a different content type that gets shifted to the icon menu in the manner you describe above. I have:

blog
book
bookmark
feedapi_node
image
log
page
story
tweet

feedapi_node has an underscore, but the whole menu for the bookmark node type gets shifted to the ICON menu.

sun’s picture

Is it possible that this affects only content-types that are defined by other modules via hook_node_info() ?

alan d.’s picture

Hi Sun

I just added a native Drupal content type that had an underscore, and the menu works correctly. I also added a custom module via the hook_node_info that specifies the module as "node", rather than my custom module, and the error still happens.

<?php
/**
 * Implementation of hook_node_info().
 */
function jm_node_info() {
  return array(

    // Fine
    'client' => array(
      'name' => t('Client'),
      'module' => 'jm',
      'description' => t("A client of Caign Webs."),
      'has_title' => TRUE,
      'title_label' => t('Name'),
      'has_body' => TRUE,
      'body_label' => t('Details'),
    ),

    // Broken
    'project_notes' => array(
      'name' => t('Project notes'),
      'module' => 'jm',
      'description' => t("Project notes."),
      'has_title' => TRUE,
      'title_label' => t('Title'),
      'has_body' => TRUE,
      'body_label' => t('Notes'),
    ),

    // Broken
    'project_test' => array(
      'name' => t('Project notes'),
      'module' => 'node',
      'description' => t("Project notes."),
      'has_title' => TRUE,
      'title_label' => t('Title'),
      'has_body' => TRUE,
      'body_label' => t('Notes'),
    ),
);
}
?>
sun’s picture

For all of those content-types, could you lookup the paths the links in the regular "Navigation" menu are pointing to? If the parent menu item is set incorrectly, this sounds like the broken content-types have different paths or are not present in the menu at all.

Anonymous’s picture

Hmm.. I don't quite follow what you're saying. Are you saying this is related to the fact that when we're editing fields in a custom content type, the breadcrumbs skip over the content type's edit form and go straight back to the "content management" admin menu?

alan d.’s picture

The menu parent is set to admin, all of the menu paths work correctly.

I just run a few tests, initially having difficulty mimicking the bug. However, the following can be used to mimic it:

Clean install, drupal-6-dev from August 27, 2008 6:29:59 PM (the only D6 for testing I had. The same bug was seen in D6.4)

Enable a test module, CCK, Text, Admin menu.

Ensure that the cache is flushed/up to date

Add new items to node_info hook, using underscores, flush the cache and the error appears

The test module before the changes was:

; test.info
name = "Administration Menu Test"
description = "For testing."
package = "Other"
core = 6.x
<?php
// test.module

/**
* Implementation of hook_node_info().
*/
function test_node_info() {
  return array(

    // Fine
    'client' => array(
      'name' => t('Client'),
      'module' => 'test',
      'description' => t("A client of Caign Webs."),
      'has_title' => TRUE,
      'title_label' => t('Name'),
      'has_body' => TRUE,
      'body_label' => t('Details'),
    ),

    // Broken
    'project_notes' => array(
      'name' => t('Project notes'),
      'module' => 'test',
      'description' => t("Project notes."),
      'has_title' => TRUE,
      'title_label' => t('Title'),
      'has_body' => TRUE,
      'body_label' => t('Notes'),
    ),
);
}

?>

And after everything was installed/caches flushed, etc

<?php

/**
* Implementation of hook_node_info().
*/
function test_node_info() {
  return array(

    // Fine
    'client' => array(
      'name' => t('Client'),
      'module' => 'test',
      'description' => t("A client of Caign Webs."),
      'has_title' => TRUE,
      'title_label' => t('Name'),
      'has_body' => TRUE,
      'body_label' => t('Details'),
    ),

    // Broken
    'project_notes' => array(
      'name' => t('Project notes'),
      'module' => 'test',
      'description' => t("Project notes."),
      'has_title' => TRUE,
      'title_label' => t('Title'),
      'has_body' => TRUE,
      'body_label' => t('Notes'),
    ),

    // Broken
    'project_notes_3' => array(
      'name' => t('Project notes'),
      'module' => 'test',
      'description' => t("Project notes 3."),
      'has_title' => TRUE,
      'title_label' => t('Title'),
      'has_body' => TRUE,
      'body_label' => t('Notes'),
    ),

    'project_notes_2' => array(
      'name' => t('Project notes 2'),
      'module' => 'test',
      'description' => t("Project notes 2."),
      'has_title' => TRUE,
      'title_label' => t('Title'),
      'has_body' => TRUE,
      'body_label' => t('Notes'),
    ),

    // Broken
    'project_test' => array(
      'name' => t('Project notes'),
      'module' => 'node',
      'description' => t("Project notes."),
      'has_title' => TRUE,
      'title_label' => t('Title'),
      'has_body' => TRUE,
      'body_label' => t('Notes'),
    ),
);
}
?>

The main difference was that CCK displayed errors after adding the extra content types using this procedure. I do not think that these errors appeared on the system when the bug first showed itself, but I can not be 100% sure about this.

    * notice: Undefined index: url_str in C:\bin\web\drupal\cvs-versions\drupal-6-dev\sites\all\modules\cck\content.module on line 123.
    * notice: Undefined index: url_str in C:\bin\web\drupal\cvs-versions\drupal-6-dev\sites\all\modules\cck\content.module on line 123.
    * notice: Undefined index: url_str in C:\bin\web\drupal\cvs-versions\drupal-6-dev\sites\all\modules\cck\content.module on line 123.
alan d.’s picture

Also as a follow up, I've uninstalled and reinstalled everything and the first few items work correctly, all of the new extra content types are still broken.

After dropping the database and starting afresh, the error was mimicked using the full module from above using these steps (done individually, order of the last two steps is not important):

Install clean Drupal 6
Install test module
Install admin menu

yan’s picture

In Drupal 5.10 with Administration Menu 5.x-2.6, all my "Content Types" --> "Edit [content type]" menu items link to the /fields page, not to the standard edit page of the content type.

sun’s picture

Status: Active » Needs review
StatusFileSize
new820 bytes

I've tried to debug this now for a few hours.

However, albeit I'm attaching a patch here, I still do not completely grasp what's actually happening here. Regarding the example module in #6, I'm successfully getting all menu items for content-types that ...

Ow. Just recognized that I'm mixing two issues. #301147: Recently added content type doesn't show in Content Management -> Content -> Add... list is closely related. ;)

So, yes, attached patch should fix THIS issue by implementing the same check that node.module does. 8)

Please test.

alan d.’s picture

The patch by itself has not fixed the issue on the first site that I tried it on.

eg: This is still happening:

[icon] > Administer > Edit
[icon] > Administer > Edit
[icon] > Administer > Manage Fields
[icon] > Administer > Manage Fields
...

I really do not know why the menu system plays with underscores and hyphens, but must be a bit of a nightmare working this stuff out.

I tested the patch on both the 6.x-1.x-dev (2008-Oct-26) and version 1.1 with the same result, but on a live site; not on the code supplied to mimic the bug given above. Did the patch work on the example content above? I've deleted that setup so it would take some time resetting this up.

mgorino’s picture

I am with the same problem and I have new spolight about the issue:
The problem occurs when you have a content type with a name of another content type + any string like:
- feature
- feature_icon
In this case, the Feature Icon links becomes children of the "Administer" menu of this module.

mgorino’s picture

Priority: Minor » Normal
Status: Needs review » Active

The patch didn't work for me.
Try to create a content type with a name like "contenttype1" and then other with the name "contenttype1_item" and you're going to see that the options to edit the content type "contenttype1_item" will be rendered as a submenu of the "Administer" button.

attheshow’s picture

Just marked another issue as a duplicate for this one. #363591: Content types are shown loosely Looks like a few more of us are having this issue.

attheshow’s picture

Version: 6.x-1.1 » 6.x-1.3
design.er’s picture

atheshow, thanks for referencing to this thread - I'm the author of the issue #363591: Content types are shown loosely.
I'm subscribing here and hope that this problem will be fixed. Unfortunately I'm not a coder but I will help out with testing the patches.

attheshow’s picture

StatusFileSize
new144.73 KB

I just tried the patch with 6.x-1.x-dev and didn't see any change.

I've attached an image of what's going on on my screen.

I thought it was happening to any content type that I created that had a hyphen in the name, but I have one content type that I created that does not have the issue. I would note however, that I built the "broken link report" content type a while ago. Perhaps in version 1.1 of the module. I'm not sure how that could make a difference, but I thought I'd make note of it.

sun’s picture

Status: Active » Closed (duplicate)

#384100: Content type menu items can end up in wrong place due to naming clash contains a patch that should fix the "content_type" + "content_type_whatever" issue.

Since most of you were complaining about that, I'm marking this issue as duplicate. Feel free to re-open it though, if this issue is not fixed by the patch in the other issue.