Re-add Create content

doesn't seem to work that way any more you use the create content link in the navigation menu. I've rolled back from 3.x-dev as there are some bugs being worked on that were affecting other things.

You can move the Create Content tree from the Navigation menu into the Administration Menu though. Need to flush the menu cache to get it to appear though.

Items in the Administration Menu seem to have a path dependency, eg. I couldn't get custom help items to show up until I set a custom path for them under 'admin/instructions'. I'd guess this is why the Create Content tree went awol, the path is 'node/add%' so didn't come under the 'admin/content/%path'

FYI: No, the "Create content" sub-menu tree was left out in the rewrite to focus on the main administration menu first. You should be able to simply move the existing items from the Navigation menu into the Administration menu, just like you can move any other items around now. However, I'm not yet sure how to - properly - deal with such customizations in 3.x-dev.

Applies to 6.x-3.x only.

Interested in this issue

I do think this belongs in the admin menu. One of the usability studies they did for Drupal 7 shows that people intuitively expect to find it in the admin area anyway. Also, on our sites, we completely hide the navigation menu, relying exclusively on admin_menu for all the site administration stuff including posting content.

i'd welcome the return of this also, thanks.

I'm just jumping in Drupal, and have installed 6.13. When you say I can copy or pull the Create Content function to the Admin's menu, where do I find the Navigation Menu? I'm a newbie and hope you guys can help. Thanks.

administe -> menus

You can actually add this submenu using hook_admin_menu_output_alter().

/**
 * Implementation of hook_admin_menu_output_alter().
 *
 * Add "Create content" as a top level submenu in the admin menu.
 */
function mymodule_admin_menu_output_alter(&$content) {
  // Add a top level item for the Create content menu itself.
  $content['mymodule'] = array(
    '#theme' => 'admin_menu_links',
    '#weight' => -99,
    '#sorted' => TRUE,
  );

  // Copy the create content submenu to our backend menu.
  $content['mymodule']['create-content'] = array(
    '#title' => t('Create content'),
    '#href' => 'node/add',
    '#weight' => -10,
  );
  $i18nstrings_exists = module_exists('i18nstrings');
  foreach (node_get_types() as $type) {
    if (node_access('create', $type->type)) {
      $type_url_str = str_replace('_', '-', $type->type);
      $content['mymodule']['create-content'][$type_url_str] = array(
        '#title' => drupal_ucfirst(!$i18nstrings_exists ? $type->name : tt("nodetype:type:$type->type:name", $type->name)),
        '#href' => 'node/add/'. $type_url_str,
      );
      if (!empty($type->description)) {
        $description = (!$i18nstrings_exists ? $type->description : tt("nodetype:type:$type->type:description", $type->description));
        $content['mymodule']['create-content'][$type_url_str]['#options'] = array('attributes' => array('title' => $description));
      }
    }
  }
  if (!empty($content['mymodule']['create-content'])) {
    uasort($content['mymodule']['create-content'], '_mymodule_element_sort');
  }
}
function _mymodule_element_sort($a, $b) {
  $a_title = (is_array($a) && isset($a['#title'])) ? $a['#title'] : '';
  $b_title = (is_array($b) && isset($b['#title'])) ? $b['#title'] : '';
  return strcasecmp($a_title, $b_title);
}

Thanks for reporting, reviewing, and testing! Committed attached patch to 3.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

Just downloaded the 6.x-3.x-dev 2009-Aug-17, it's working great, no bugs so far... Loving it!
Thanx for bringing it back!

Sorry to spoil the cake... there are several modules who check arg(0) to see if they are on the node add form, the most prominent one being

pathauto_form_alter(&$form, $form_state, $form_id) {
  // Only do this for node forms
  if (isset($form['#id']) && ($form['#id'] == 'node-form') && arg(0) == 'node') {
  ...

It's surely not a grave issue - but it is a problem.

The actual path for adding new content is /admin/node/add/contenttype instead of /node/add/contenttype. A bug or did i miss something? Using 3.0-alpha3.

cheers, Ronald

Why should pathauto need to use arg(0)? Shouldn't the form_id be sufficient?

@rkr: The actual normal drupal path for adding a node is node/add/x. See http://api.drupal.org/api/function/node_menu/6
@seanr: Patch for pathauto in #369840-54: If a user changes the automatic path, try to remember that in the future removes the need for arg and uses $form_id comparison.

What i wanted to say: the actual path admin menu provides for adding new content: /admin/node/add/content-type which *should* be without the leading "admin" path.

cheers, Ronald

@19: well unfortunately, pathauto isn't the only module doing that kinda stuff... i found others but no time regexping them right now..

OG also depens on 'node/add/*' and not 'admin/node/add/*'. See og_determine_context().

I think admin_menu would have to create additional menu links rather than changing existing menu paths.

In the meantime, we're using a variation of the code I posted in #13 to append the "Create content" submenu using 'node/add' instead of 'admin/node/add', and because we need this rendered on a different location of the admin_menu.

And here's how we can get rid of the 'admin/node/add' entries:

/**
 * Implementation of hook_menu_alter().
 *
 * Needs to be executed after admin_menu, so mymodule weight
 * needs to be adjusted accordingly at hook_enable() time. :P
 * Note that admin_menu's weight is 100.
 */
function mymodule_menu_alter(&$items) {
  foreach ($items as $path => $item) {
    // See http ://drupal.org/node/502500 Re-add Create content.
    if (strpos($path, 'admin/node/add') === 0) {
      unset($items[$path]);
    }
  }
}

Hope that helps someone. :P

Subscribing

Subscribing

this issue is resolved in the latest 6.x-3.x-dev, no?

(well, it's back for me anyway :)

Same thing here. Create Content is gone for me in 6.x-3.x-dev. Just reinstalled alpha 3 and it's back.

Subscribing

agreed. 'create content' belongs in admin_menu, on a practical level for development purposes. i went a bit crazy yesterday trying to figure it out, but i'm back in alpha

I know in the strictest sense, "content management" does not imply "create content"... but perhaps it could be a flag/option in the admin menu menu in which it could be toggled back on.

I know there are other options out there (simplemenu), but I liked how admin menu had an all-in-one approach.

The patch in #13 looks promising... and it looks like the arg(0) issue is a non-issue based on #19.

Rolling back to 6.15 in the meantime...

PS, I did add the code in #13 and it does seem to give me the correct feature back... I'll ping/reply if I run into any problems later.

Thank you markus_petrux!

I've noticed that the patch code has now been commented out from alpha4, so "Create Content" no longer appears. I've uncommented the code in the module on my site, and it appears to be functioning correctly. Was there a particular reason why this code was omitted?

Thanks!!

David

Thanks for mentioning it was commented out. I was wondering where it had gone as well. Uncommented and it works on mine now too.

I could not find any mention of why it was commented out in the CHANGELOG.txt file; but according to the alpha-4 new features list, it was a test-case that was commented out so that it could be removed. I wasn't aware that there was anything functionally wrong with this test-case — is it possible to keep it or to make it optional with a control in the administration UI?

I don't know about other people, but I personally find this feature incredibly useful (and my clients do too!).

Also, bug #743760: Missing Create Content Option appears to be a duplicate of this one.

I found out, not sure if this is what we should do, that you can add that link back by editing node/add (Create content under Navitation) in the administer menu section, and choosing a new parent Administration menu -> Administer. That worked for me.

im new to drupal and just noticed 'create content' was missing from my menu, and it was there not long ago. i am not sure what occurred for that to go missing. it is also no longer visible in administration>menu>navigation either. I not sure what steps to take to add the code from #13, or if there is a path i can just re-add, and recreate the 'create content'. menu option

any help is appreciated.

Subscribing

Confirming what Dubs says, line 124-132 in admin_menu.module is commented out, works as it should when uncommented.

Subscribing. As with other users, the 'create content' menu is the primary method for site administrators to add content on my sites as navigation menu is disabled. I'm going to manually patch this back in for now, but a definite +1 on re-including the feature as it breaks all my sites otherwise!

I'm also confirming that uncommenting lines reported in #32 and #38 does the trick to bring the Create Content menu back. At this point I'm seeing the Create Content menu in both the Admin menu and the Navigation menu too.

One caveat to readding the code (which may be why it was commented out)... The two submenus in both Admin and Navigation don't stay in sync. Reordering or disabling menu items would have to be done in both places. (And if someone were to manually add a menu item to the Create Content submenu, it would have to be added to both menus... though I can't imagine a scenario where anyone would manually add a navigation item into the Create Content submenu.) Also, I also just tested that new node types added by a module are successfully added to both menus.

If the code is readded, then I can suggest one thing which should be fixed before it's rereleased. There may be a case where someone has create a page with a path like "/node/additional-info". All nodes that have a path beginning with "/node/add" will be caught by this code, so here's a fix:
The code on line 124 is:
elseif (strpos($path, 'node/add') === 0) {
This should be changed to:
elseif ($path == 'node/add' || strpos($path, 'node/add/') === 0) {

I'm using drupal 6.16 and admin menu 6.x-3.0-alpha4. i follow #38 but there is line #123 to #133 see attached pic...just uncomment the code and enjoy.

@linksor

Thanks for the info on the node/add -node/additional [..] issue. I could imagine myself getting lost for years before suspecting that one! Really appreciate that info!

Subscribe.

when is the uncommented code going to be in -dev?

Subscribing...

Subscribing

Same issue

Drupal 6.16
Admin-menu 3.0-alpha4
Safari, Firefox

The picture shows the difference between admin-menu 3.0-alpha3 (Create content was there) and 3.0-alpha4 (Create content is not there)

Also the small arrow on the left has a drop down menu that falls out of the internet browser window (the only way to see its content is to click the arrow on the menu, then use the keyboard right arrow)

Subscribing

Add my vote in favor of putting admin/node/add/* back in.

I've successfully undone the commenting out on my sites.

Very happy to find out what happened: thnx for the thread and options. +1 to moving this into a config option under Admin Menu

Subscribing

Add my vote for adding back the Create Content menu.

Awaiting the return.

I lean towards what suggested in #35 being the best way so solve this, and have just done it myself on a site I build. Another benefit of this solusion is that you may like to position it as a sub item of 'Content Management' to save space in the top level menu bar.

I am not sure of what possible user complications it can have to move it from Navigation, I mean to what degree the 'Create Content' or Navigation as a whole are made available to ordinary users, authenticated or not. Personally I choose to never use it for users as I find it more intuitive to give that option in its relavent context but it also comes down to what kind of site you're building.

I am also thinking in the direction that if you have a need for 'Create Content' to be a available in both Admin Menu and Navigation (which I belive is rare) then you probably have the skills to find and uncomment the relevant code w/o problem. So what really is needed, as so many times, is not more code but more and/or better documentation.

Also this is deffinately not a critical issue as it doesn't affect the modules usability in a seruious way (a Major or Needed Priority is really needed) and it's in fact already available as shown in #35 and with further details above. But ok lets do it again:

1. In AM select 'Site Building->Menus->List menus'
2. On next screen click the 'Navigation' url.
3. For the 'Create Content' item, click 'edit'.
4. On the next page find the DropList with label 'Parent item:' and in the list find but now pay attention, select the item 'Administer' just beneeth it.
5. This will change the page to list the Adnim Menu items and further down after the list you will find the button 'Save configuration' - click it and you are done!

In step 4. if you don't want it to be in the top menu bar row, you could select e.g. 'Content Management' instead and it will show up as first sub menu item inder it.

Would it be possible for someone to post what exactly the uncommented code looks like? I found the block. Removed the comment tags, but I think there may be something going awry with closing brackets and such. Or maybe you also need to adjust comments/brackets somewhere else too? Any suggestions? Thanks very much.

@erikao:

As Distributed:

/*
    // Copy 'Add new content' into admin_menu menu.
    elseif (strpos($path, 'node/add') === 0) {
      $newpath = 'admin/' . $path;
      $items[$newpath] = admin_menu_copy_item($item, $path, $newpath);
      $items[$newpath]['menu_name'] = 'admin_menu';
      if ($newpath == 'admin/node/add') {
        $items[$newpath]['weight'] = -15;
      }
    }
*/

As Modified:

    // Copy 'Add new content' into admin_menu menu.
    elseif (strpos($path, 'node/add') === 0) {
      $newpath = 'admin/' . $path;
      $items[$newpath] = admin_menu_copy_item($item, $path, $newpath);
      $items[$newpath]['menu_name'] = 'admin_menu';
      if ($newpath == 'admin/node/add') {
        $items[$newpath]['weight'] = -15;
      }
    }
/**/

Note that I just moved the comment marks down to bracket each other. Saves typing!

Subscribing.

Like the poster above said ... A very much used feature and its simply uncommented. Adding to the 1000 people line with "uncomment and it worked".

My 5 cents: I also think it should be out of the box

Those who do not want it (for whatever reason) could comment it out. But I think they would be a striking minority.

Some people want it in the admin menu bar, some want it out.
Easiest solution would be a setting as there is already an admin module settings form.

I would be happy to cook up a patch to make it a setting but I might be missing something as to why it was exactly commented out.
I've tried to figure it out from this thread but it's a bit confusing.

Info is welcomed!

Cheers

My vote is having it in there or having an option in settings.

Agree that it should be out of box.

I would be happy to cook up a patch to make it a setting but I might be missing something as to why it was exactly commented out.

The exact reason to comment it out was that the path for the 'node/add' page was forcefully changed, which may break modules or themes relying on (read: testing for) the exact path. I suggest to create a redirector instead:

1. register a new menu callback admin_menu (or something like that)
2. add visible menu items using the redirector URL for all paths that start with 'node/add'
3. the callback strips its path prefix and issues a drupal_goto()

That way we don't have to move the 'node/add' menu item anymore.

4. Create an update function to fix existing installations.

In #13 there's a code snippet that generates node/add links under a separate submenu of the admin menu. tt() is now deprecated, but maybe that code could be used as a possible method to get this feature back to admin_menu.

PS: Not sure why the issue status was changed in #57.

Yeah, why not actually make use of admin menu's features ;)

Just not sure about $type->description, we have code somewhere that normally avoids displaying the title attribute altogether for admin menu links (see admin_menu_links_menu()). In this case on the other hand it doesn't seem to hurt.

Subscribing. People have cone to expect it to be in the admin menu, so I think it should remain there. Plus, it makes sense for it to be up there with all the other admin stuff.

Subscribing as well, I would like to see it up there too.

Do we need to rebuild those links from scratch? The menu link tree structure for node/add should already exist in {menu_links} -- technically, we just want to retrieve and render that menu links sub-tree just like we render the entire administrative menu.

admin/node/add has the distinctive property of using the admin theme (and possibly allowing a different editor). I'm not currently relying on either of these features, but they're potentially useful.

OTOH, breaking modules that rely on node/add can make admin_menu impossible to use. Seems we need an option...

subscribing

It's part of the 1.5 version since more than a year and we have here a discussion since more than a year if and how this functionality sould be added. Kinda strange....

For my customers, creating content using the admin menu is an essential part of an easy administration of the website.

Subscribing.

I'd really appreciate getting the Create Content menu back into Admin Menu...

subscribing

Subscribing
If I can manualy create an add content item (node/add )to the menu why isn't it included in Admin Menu?

If I remember correctly, the "create" capability has fallen out with updates several times in the past year. It sure would be great to have some stability in this. I write and post 90 percent or more of my site's content, but the inner workings of Drupal remain a mystery to me. Our volunteer webmaster, in his spare time from a real job, handles the upgrades. He's been gracious about troubleshooting whenever "create" becomes disabled, but I am always pulled between the timeliness of what I need to post and my reluctance to impose on the webmaster's time.

Are upgrades getting an adequate shakedown before they're released, or is it the nature of this enterprise that the bugs are found only post-release?

I have 3 sites. All running admin_menu. Two of which are for sure using 1.5. One of the 1.5s has the create content link and the other does not.

Any suggestions on beginning trouble-shooting

For those people new to this thread, comment #2 tells you how to add the Create Content back into the Administration menu without modifying the code; that is:

1. Go to Site Building -> Menus -> List
2. Click on Navigation
3. Edit the Create Content menu item
4. Change the Parent menu from to and click Save.
5. Flush the menu cache.

This should persist through admin_menu updates, as admin_menu merely renders the Administration menu.

We need admin_menu mod then...

@amorfati: The Create Content menu item in the Navigation menu should remain for non-admins (who can't use admin_menu).

+1 for create content should be enabled out of box.
+1 for having an option in settings.

Patch via CVS DRUPAL-6--3, which:

• Add an additional option within admin/settings/admin_menu which control the enable (by default) or disable of copy 'Add new content' into administration menu.
• Replace original commented code snippet with conditional check.

Fully tested with Drupal 6.17 + admin_menu 6.x-3.x-dev.

Shouldn't "node/add" menu items appear even though my user doesn't have the "access administration pages" permission? I have moved the entire "create content" tree out of the Navigation menu and to the top level of Administration menu. It only appears after I have granted the user the "access administration pages" permission.

Subscribing

My typical use case:
- When I start creating a site, the first thing is usually to disable system navigation, and enable admin_menu instead.
- While building the site, I will use the admin menu to create content. It's the only way during this phase of development.
- For the client I create a custom menu "admin links", where I put everything this client is allowed and supposed to do. I don't see a point in using system navigation menu for that. This happens when the site is almost finished. Before this happens, admin_menu is the only way to add content.
- The client will never see the admin menu (it looks quite boring anyway, with so few items).
- As an administrator I will still use the "create content" link in admin_menu, instead of the custom admin links menu, even when the site is finished and online. For some content types there are no links in "admin links", but admin_menu does have them.

If I have a client who wants to do more things himself, I will give him access to admin_menu, and not add a custom "admin links" menu. So in this case the client will use admin menu to create content.

Even if I would give system nav to the client for adding content, I would still appreciate to have the create content link in the admin menu for myself. Especially, if I have the system nav disabled during site building.

Conclusion:
admin menu and system nav is for different users during different stages of site building, and each of them needs a way to create content. There is no reason for an exclusive "or".

Excellent writeup donquixote. There is absolut no reason not to include it.

Setting to TBTC, because 80% of the users are running admin menu with this patch anyway and no one complained so far.

The patch just uncomments the old, known to be buggy code.

We need to retrieve the menu link tree of and below node/add instead, and add the result, if non-empty, to the renderable array containing the admin_menu links. Ideally, as hook_admin_menu_output_alter() implementation of Node module, i.e., node_admin_menu_output_alter().

Hi- I've spent 4 hours trying to get the create page and create story back in the admin menu module but no joy. I've read all of the above but none seem to work. Please could someone let me know exactly what to do? When I look at line 123 is see this:

/**
* Implementation of hook_footer().
*
* Admin menu was previously output via hook_block(), but suffered from
* theme-specific stylesheets that may be applied to layout blocks. We now
* output Admin menu in the footer to circumvent this.
*
* @todo Since admin_menu is rebuilt in the same request, we should be able
* to use a helper function instead of a variable to remind us to rebuild
* (variable_set() is slow).
*/

subscribe. This is the most confusing issue I've ever read. Would be good if people who don't know what they're talking about and haven't read the whole thread would STFU.

Perhaps it would be a good idea for one of the maintainers, or someone who knows what's going on to create a new issue, with:
- a succinct summary of the current state of things
- the problem
- stumbling blocks with proposed solutions
and then close this issue?

i believe my site has become corrupted. Im missing certain menu items such as all User settings/ site/building/modules, ect. I cant even edit panel panel pages I get page is not avail.
although i see all of my porper mods/ect on the server.

is there a way to re-add this content, or should i back up the db, and re-import on a new drupal install..

this is afetr months of work.

any help is greatly appreciated.

It would also be good if people would convey a calm manor when posting to the issue queue, avoiding unnecessary inciteful remarks. Your comment would be useful if you could explain how you see the topic has deviated from the issue and then politely request coherent discussion to remain on that topic.

@ice5nake: That issue with 1.5 doesn't really belong in this thread about a different bug, but I have a suggestion for you... check your PHP versions: with PHP 5.3 those links are bugged. More info here #673058: missing links (e.g. create content) in admin_menu - I found that from here #806056: Missing Menu Items - Content Types & Dropdown from the Favicon

#14: admin_menu-DRUPAL-6--3.create-content.patch queued for re-testing.

i have same problem on the drupal 6.17 , 6.x-1.5 and 6.x-3.0-alpha4 not have create content link.

@sun (#86):

We need to retrieve the menu link tree of and below node/add instead, and add the result, if non-empty, to the renderable array containing the admin_menu links. Ideally, as hook_admin_menu_output_alter() implementation of Node module, i.e., node_admin_menu_output_alter().

Makes sense.
The only problem could be if other modules want to alter the create content stuff, using the same hook.
Can we be sure that contrib and custom modules always get a higher module weight than node module does?

Here is a "patch" for 6.x-3.x, following the idea in #86.
Well, it is not really in a patch format. You can choose to either use it as a custom module (you need to add a .info file), or insert the code anywhere in admin_menu to patch it.

Btw, I think the new hook is a bit unpleasant to work with, if one has to iterate all items only to find a specific path.

EDIT:
A different idea can be found here:
#821128-7: Ensure reliable link structure and contents for alter hooks (to not break on customizations)

@patch #97 (myself):
One can get the idea that it would be better to fetch only the part of navigation that contains the create content links, instead of menu_tree_all_data().

I don't know of any such function in D6. I had a look in menu_block, and found that it uses either menu_tree_all_data() or menu_tree_page_data(), none of which fetch only a part of a tree for a given argument. I might soon publish a module that does exactly this. Until then, I think menu_tree_page_data is fine. In most cases the navigation menu is very small, and the admin menu has to be built only every once in a while.

I'm quite sure that menu_block contains more advanced menu link tree retrieval functions than menu_tree_all_data(), unless they got removed somehow.

Also, there's not really a patch here.

Latest D6 and D7 versions look like this (menu_block.module, function menu_tree_build):

  if ($config['expanded'] || $config['parent_mlid']) {
    // Get the full, un-pruned tree.
    $tree = menu_tree_all_data($config['menu_name']);
    // And add the active trail data back to the full tree.
    menu_tree_add_active_path($tree);
  }
  else {
    // Get the tree pruned for just the active trail.
    $tree = menu_tree_page_data($config['menu_name']);
  }

The relevant code for us is the above section, because we don't care about the "active trail".
Later menu_block will "prune" the tree to remove the overhead.

unless they got removed somehow

Could be, I dunno. But then there is probably a reason for that.

Also, there's not really a patch here.

You can simply copy the code and put it anywhere in admin_menu. This is about the same as a patch, except that it does not depend on a specific version's line numbers, and that you can choose where to put it.

I can turn it into a real patch if we can agree on the other questions. Until then, I will simply use it as a custom module.

@donquixote: thanks man! your code works. still i cant be believe there is more than 100 responses and discussion just to get a single menu item back!

Hello, When you say "copy the code and put it anywhere in admin_menu" what exactly do you mean? I have a folder called admin_menu in modules put don't know what file to save it in there. Any help greatly appreciated.
Thanks
Mark

Any file that is loaded when the admin menu is built will fit.
If you are not sure, put it in admin_menu.module, then it will work in any case.

great - thanks

#38 worked like a charm for me. Easy fix once I found this. Just uncommented and flushed cache. thanks.

+1 for re-adding "Create content" out of the box.

What will final version of 6.x-3.x-dev look like?

I'd also like to see "create content" come back.

One problem related to this is that if you attempt to move the Create content links to the admin menu on 3x and then you uninstall the admin menu then the menu items are permanently deleted. I couldn't figure out a way to get them back after that. Recreating them manually isn't the same since new content types are not automatically added.

#109: no, don't move them, copy them!

Normal users should not have access to the admin menu, but they may still be allowed to create content, so core's links need to remain where they are.

#54 did the trick but I really really shouldn't need to do this. There is no good reason why this should be commented out by default. Either make it a setting or leave it uncommented, but this solution is just lazy and annoying.

I think it would be good to make all of the "additions" to the administration menu optional in the settings UI. I can't be modifying code (#54) to uncomment features every time I deploy or upgrade this module.

If/when you use the button to rebuild the admin menu, you lose your manually added items anyway, so centralizing them and making them flexible/resettable is a big plus. The various node manager modules/views are an example.

Here is my solution (using a custom module):

Create new menu entries for creating each content type using node_get_types(). The entries will be paths that redirect to the actual node/add/* page.

function proto_menu(){
  $items['admin/workflow'] = array(
    'title' => 'Workflow',
    'description' => 'Content Workflow',
    'page callback' => 'proto_dashboard',
    'access arguments' => array('administer site configuration'),
    'weight' => -100,
  );
  
  $items['admin/workflow/node_add'] = array(
    'title' => 'Create Content',
    'description' => 'Content Workflow',
    'page callback' => 'proto_goto',
    'page arguments' => array(2),
    'access arguments' => array('administer site configuration'),
  );
  foreach(node_get_types() as $machine => $object){
    $items['admin/workflow/node_add/node_add_'.$machine] = array(
      'title' => $object->name,
      'description' => 'Settings for the proto module.',
      'page callback' => 'proto_goto',
      'page arguments' => array(3),
      'access arguments' => array('administer site configuration'),
    );
  }
  return $items;
}

function proto_goto($path){
  $path = str_replace('-','_',str_replace('_','/',$path));
  dpm($path);
  drupal_goto($path);
}

This approach makes sense to me, but other people's thoughts would be appreciated.

I thought I'd read that the d.o. redesign was going to give us the ability to subscribe to issues without making the useless comment "+1 subscribe", but I must have been mistaken. So here's my pointless comment made only so it will add this to my issues. Apologies.

I just thought I'd mention this: the 6.x-3.0-alpha4 version now has an extra module you can enable, called "Administration menu Toolbar style", which places the "add content" item on the right of the toolbar, next to the logout button. It's buggy in the sense that the menu falls off the screen, but it's a start...

If create content is coming back, we need to be careful with the default task links.

Possibly related to:
#946736: Do not output default local tasks

subscribe

subscribing

subscribe

The problem with the new hook_admin_menu_output_alter() is that you need to deal with numeric keys, and this on multiple levels.
See #97 and #98 and #821128-7: Ensure reliable link structure and contents for alter hooks (to not break on customizations)
The kind-of-a-solution in #97 has additional functions to search through the numeric keys of a submenu, and find specific items by their link path. Having to do this does not make me very happy.

This why I decided to craft a new module, DQX AdminMenu, which drops the by-mlid approach. It fetches directly from menu_router table, and ignores menu_links entirely.
There is no public api yet, all the modifications are hardcoded. But when this module will get an API, this api will be based on string keys.
A downside is that you can't use the menu edit form to manually edit the menu structure, add new items etc. That's the price.
I don't think the technical approach of dqx_adminmenu can ever deliver a feature-complete replacement of admin_menu, this is why I thought a separate module was the way to go.

subscribing

In case #1025582: Custom db_select 'conditions' parameter for menu_build_tree() still lands for D7, I have a super-simple fix ready.

subscribe

subscribe

Subscribing. I rely on Admin Menu for several self-administered sites. Workaround #2 got me going again. Hope to see Create Content worked back into 6.x and 7.x, thanks!

Guess I was late to the party. Seems to be working in 6.x-1.6 :)

@Kevin,
This problem applies to the 6.x-3.x branch, but not to 6.x-1.x (unless something has changed since I started following).
The main reason (imo) why you would want 6.x-3.x is the client-side caching, which makes the module much less of a performance drain for admins. And you get admin_views, which is great.

As mentioned in #120, there is a separate solution that works for me.

subscribing

Glad there was an option like #120 ! Thanks for re-pointing this out.

@ #129 did you have any compelling reason to change the version?

Not really, my apologies. I changed it back. I changed it because I was dealing with the issue in version 6... of the module didn't know I was making overall changes, just thought I was recording what version I was using.

Yeah, I'm kind of dependent on that "create content" path in admin_menu. It just would be nice to have.

subscribe

subscribe

I never thought about this before for Drupal 7. This was a great idea. Thank You muhleder.

I'm really hoping to see it added back into 6.3 dev. I have it in the 7.3 dev but still nothing in Drupal 6 version of it.

@sun -

In case #1025582: Custom db_select 'conditions' parameter for menu_build_tree() still lands for D7, I have a super-simple fix ready.

Can you share this patch? I'd be keen to try out your core patch with admin_menu. Is there someone with an in depth knowledge of the menu system that can review that patch?

Sorry for the noise; now for real.

patch?

subscribe. really need this to be added back in, and automated based on new content type creation.

+1 for bringing back the menu.

i took what entrigan (thanks for this!!) did in #113 and mode these changes:

- moved under Content where it used to be
- simplified code
- changed for D7

function liquid_menu() {
  $items = array();
  
  //======== replace missing Add Content to admin_menu
  $items['admin/content/workflow/node_add'] = array(
    'title' => 'Create Content',
    'description' => 'Content Workflow',
    'page callback' => '_liquid_add_content',
    'page arguments' => array(2),
    'access arguments' => array('administer site configuration'),
  );
  foreach(node_type_get_types() as $type => $object){
    $items['admin/content/workflow/node_add/' . $type] = array(
      'title' => $object->name,
      'description' => 'Settings for the proto module.',
      'page callback' => '_liquid_add_content',
      'page arguments' => array(4),
      'access arguments' => array('administer site configuration'),
    );
  }

  return $items;
}

function _liquid_add_content($path){
  drupal_goto("node/add/$path");
}

Here is a patch using the code in #144 (thanks for that liquidcms) against the current dev release.

Forgot to change the status.

Sweet... The patch in #145 works perfectly, cheers!

oops did I mess up the status? :/

For what it's worth, here's something I did for Drupal 7. I wrote it back in January and have been using it on my D7 sites ever since. Today, I adapted it using some code from #144 above.

My module adds a top-level "Create" tab and adds node types (adjusted for permission) underneath in a drop-down. Attached is a screenshot of what it looks like.

Also, it removes the "Tasks" and "Index" items from the Admin Menu.

Here is the code:

/**
* Implementation of hook_admin_menu_output_alter().
*
* Add "Create content" as a top level submenu in the admin menu.
*/
function create_content_links_admin_menu_output_alter(&$content) {
  // Add a top level item for the Create content menu itself.
  $content['create_content_links'] = array(
    '#theme' => 'admin_menu_links',
    '#weight' => -99,
    '#sorted' => TRUE,
  );

  // Copy the create content submenu to our backend menu.
  $content['create_content_links']['create-content'] = array(
    '#title' => t('Create'),
    '#href' => 'node/add',
    '#weight' => -10,
  );
  
  foreach(node_type_get_types() as $type => $object){
    if (node_access('create', $type)) {
      $node_type_url = str_replace('_', '-', $type);
      $content['create_content_links']['create-content'][$node_type_url] = array(
        '#title' => $object->name,
        '#href' => 'node/add/'. $node_type_url,
      );
    } 
  }
	
  // Remove "Tasks" and "Index" from Admin Menu output
  $admin_menu_exclusions = array(
    t('Tasks'),
    t('Index'),
  );
  
  foreach($content['menu'] as $menu_key => $menu_tree) {
    if (in_array($menu_tree['#title'], $admin_menu_exclusions))
      unset($content['menu'][$menu_key]);
  }

} // end hook_admin_menu_output_alter

Is there a working solution for 6.x?

@Nitebreed. read thru this issue, many solutions have been posted for 6.x
I'm currently just changing the menu's as mentioned in #3... workaround that works for now...

Cheers

@Bartezz, those workarounds don't honor the permissions for the content-types right. Let say that if a user has the right to create content Type A and not content type B, both the types appear in the menu.

+1 million for adding the patch in #145 to next release

Please do not post "+1" comments. They are annoying to people working on the issue, and do not contribute anything. If you want to follow the discussion, click the "follow" link at the top of the issue, or feel free to contribute meaningful discussion points.

Here's the #145 patch but it also works with node types with underscores in the machine name.

Edit: Sorry about the +1 comment. I haven't gotten used to the follow feature yet! Will use it in the future.

The foreach access check for the individual content types needs to check user permissions for each content type, not just administer site configuration.

This patch adds the same access checking as the regular node/add and node/add/[node type] pages.

While creating this patch I realised that since this adds menu items starting with /admin, to be able to access these menu items the user has to be granted the 'access administration pages' permission which you don't neccessarily need to have to be able to create nodes..

This probably isn't a big problem since usually you'll be granted both permissions, but I think it's something we should be aware of..

actually, you would rarely be granted both.. :)

@liquidcms; depends on you setup I think but do agree we can't assume one has both permissions!

+ $items['admin/content/workflow/node_add'] = array(
Huh? This path does not exist on a default install. Is that something to do with a contrib module? The standard path is just node/add and node/add/$content_type

bah, never mind me. Not paying attention.

Works for me.

Re liquidcms #158, it appears that if you don't have the access administration pages permission then none of the pages that you'd be able to use if you had that permission are available in the admin menu, so this behaviour is consitent (eg. admin/content for "administer content"). I may be wrong, it's happened before ;)

Is this not something that should be done with an API, instead of being hardcoded into the menu building function? Is this not possible or not practical with the current APIs?

Ok to hardcode this stuff and commit rather sooner than later, but should this not make us think?

This is my first post on the forum. I was having trouble with the add content link not showing for a user for ages. Thanks to naught101, I started playing around with permissions. When I give permission for 'View the Administration Theme' the add content link is shown. Not sure if that is of any help.

Menu title should be sentence case, 'Create content'.

Other than that, works perfectly for me.

I think maybe the more pertinent question would be how often does a user have access to admin_menu but still not administer site configuration. That said, could we not just make the paths /node_add/type, and redirect from there sop they don't have to get into /admin? Or does that prevent the menu from being placed correctly?

Here's the patch from #157 rerolled for UI strings and coding style.

> I think maybe the more pertinent question would be how often does a user have access to admin_menu but still not administer site configuration

Quite often actually. If users have access to site reports, or just one or two admin pages, it's nice to be able to give them access to the admin menu so they can get around the admin area easily.

Patch in #166 works for me.

Hope this gets soon in dev version at least, I am also missing content creation part.

+++ b/admin_menu.moduleundefined
@@ -99,6 +99,25 @@ function admin_menu_menu() {
+  $items['admin/content/workflow/node_add'] = array(

This is a URL, it should be node-add not node_add.

I may have missed something in the 168 previous comments, but why is this being placed at admin/content/workflow? Why the word 'workflow'? If there is a good reason, it should be placed in the issue summary.

@tim.plunkett I originally named the link workflow because it was placed in the top level of admin menu and the idea was to hold common workflow tasks (often in duplicate of menu items elsewhere).

However now that in D7 "content management" has been more or less split into "content" and "structure" I think the proper place for this is in "content" and to remove the "workflow" item all together.

So it would be
content (admin/content) > create content (admin/content/create) > node type (admin/content/create/node-type)

#1025582: Custom db_select 'conditions' parameter for menu_build_tree() landed for both D8 and D7 just recently and will be part of the next minor release of D7. So here is the plan:

We will require that next minor D7 release (or higher) by adding a dependencies[] = system (>=7.12) in admin_menu.info, and thus retrieve the partial menu link tree for node/add (and everything below) to inject "Create content" as the first top-level link in the menu.

Ok, here's something along the lines of what sun suggests. I'm pretty sure this is not the best way of going about it, but I'm a bit pressed for time, and wanted a work-around. Definitely needs work. See code comments for stumbling points.

Thanks!

Attached patch implements it fully.

+  $tree = menu_build_tree($link['menu_name'], array(
+    'conditions' => $conditions,
+    'min_depth' => $link['depth'],
+  ));

This ain't working for me. This is the same problem I was getting in my patch - and the reason for the reset. $tree contains something like this (Krumo output):

tree =>
    ... (Array, 3 elements)
        50000 Add content 6 (Array, 2 elements)
        50000 Compose tips 4 (Array, 2 elements)
        50000 Search 157 (Array, 2 elements)

No idea why, because they don't match the conditions. Perhaps there is a problem with #1025582: Custom db_select 'conditions' parameter for menu_build_tree()?

+    $content['menu'] += $links;

Also, this doesn't work, because $content['menu'] is keyed numerically, and key 6 ("People" for me) already exists. Something like

+    $content['menu'][3] += $links;

would work, except for the previous problem, so

+    $content['menu'][3][$key] = $links[$key];

is a quick workaround.
Here, 3 is the index of the "Content" top level menu. I don't know how to get this, except by looping over them, as I do at the start of my previous patch. Perhaps there is a better way. #821128: Ensure reliable link structure and contents for alter hooks (to not break on customizations) contains a code that has a helper function for doing just this, perhaps it'd make sense to include that, as otherwise hook_admin_menu_output_alter() is pretty difficult to use...

Very odd. #173 works nicely for me. Are you really really sure that

1) you have the latest 7.x-dev core, and
2) the latest admin_menu 7.x-3.x ?

Because, especially before the latest 7.x-dev core, I'm totally aware that $tree looked/looks as you sample-dumped - menu_build_tree() produces the menu link tree from the root up to and including the "Add content" link, which is obviously not what we want, and in the end being the reason for pushing that core patch in after the fact.

+++ b/admin_menu.infoundefined
@@ -3,4 +3,7 @@ description = "Provides a dropdown menu to most administrative tasks and other c
+dependencies[] = system (>=7.12)

Why isn't this >=7.11?

Why isn't this >=7.11?

I'm assuming sun is predicting 7.11 to be a security update only.

Alright, plenty of debugging madness revealed the actual bug: array_merge() re-indexes integer keys.

Test bot has a bug, so this won't be tested. Looks good to me though, code seems good, works fine. Let's get this in!

The testbot does not yet know how to do versioned dependencies in its dependency generation.

Thanks for reporting, reviewing, and testing! Committed and pushed to 7.x-3.x and 8.x-3.x.

A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.

I think this has caused a regression. I'm seeing all items from my Navigation menu being placed into the admin_menu even though they've been disabled. Running Drupal 7.x-dev.

Definitely confirmed it's this issue which caused the regression.

@Dave Reid, this requires Drupal >7.10 ... (or a git pull on 7.x). At least that's my understanding. And I think you get exactly the described behavior otherwise. Same complaint as #1406858: Examples Conflict with Admin Menu (Examples menu items in Admin Menu).

It was an x-post that caused this to set it back to fixed, but please make sure this isn't your problem.

I've updated to the latest D7 core from Git and this behavior is still occurring.

Grr, this required a menu cache clear and then an admin_menu cache clear. I was only clearing the admin_menu. Sorry for the noise.

Confirmed that it worked for drupal 7.12 / admin_menu 7.x-3.x-dev
the patch rejected the changes to the .info file but everything else worked.
thanks!

Do you need to do anything on the configuration for the add content to be on the menu? Such as moving it from navigation, or it should be there on its own?

sorry, though rc1 included this, my bad!

Yes it works but it's not under the Content parent item, it's in a separate root level menu called Add content all the way to the left (for me)

Here's a simple patch that, applied after #178, will move the add content menu and put it inside the main "Content" menu.

Not sure if it's the best way to do it, but it works for me with a freshly installed drupal.

Comments are welcome!.

cheers.

edit: double posting...

here's a patch with both patches #178 and #192 applied in one.
Please post back reviews!

Latest follow-up work and patches belong into #1428584: Users expect "Add content" below "Content" instead of here

Thanks markus_petrux (#13). Works perfectly.

For Drupal 7: change

foreach (node_get_types() as $type) {

to

foreach (node_type_get_types() as $type) {

Edit: See nateeanes in #149 for full solution.

#13 (D6, admin_menu 3.x) is a great solution to avoid all the issues listed here with different updates.
Thanks!

#35 worked for me Thank you :)