Conflict with exported views via Features

Having this same problem with my own custom module as well.

Yep, this is a known issue, and one that is pretty tricky to resolve. You can fix this conflict in your custom module but adding a 'file' element in your hook_menu implementation for now.

My admin/content page does not load, because of a 403 error. I think it it's the same problem (isn't it?).
It worked till the this commit d53d1bf1a1006df1c2ca14ef8a648dd772e7be27 and stopped working with e01ef6e008a01ff8bfdd1b270b8fcd157245ed65. Maybe it's important for somebody...

Hmm, I don't think so. This issue is related to #1673820: Fatal error when there's a views page with admin/content/xxx path whereas the commits you have above I think are more related to #1780004: Trying to get property of non-object in user_access() with 2 admin views on the same path.

@webcultist i had the same error!

My admin/content page wont load with "Administration views enabled".
I opened an issue here: http://drupal.org/node/1817600
Using older version like "admin_views 7.x-1.0-alpha1" fixes the problem.

The same issue occures with Views UI: Edit Basic Settings.
Disabling Administration views solves the issue.

Versions:
Drupal: 7.17
Administration views: 7.x-1.0
Views UI: Edit Basic Settings: 7.x-1.1

This is a duplicate of #1817600: admin/content Broken. Can't manage content after enabing this module, I'm pretty sure.

Here is an updated patch, based on my original patches over there.

Testing welcome!

Ok, I committed this to 7.x-1.x. http://drupalcode.org/project/admin_views.git/commit/e7abc71

@sun: Sorry, I know you didn't get a chance to see this fully. If you have any quibbles. let me know! :)

I think the fix works.

An alternative would have been to additionally specify 'file path', either derived from the parent, or dynamically composed through 'module'. However, quite potentially, that would needlessly load the include file of the parent for the child in cases where it is actually not needed.

So I actually think this fix is correct. :)

I'm reopening this issue since it doesn't appear to be fixed yet. I have attached a patch proposal. Make sure you clear the menu cache after applying the patch. If git apply doesn't work, use patch -p1 < admin_views-conflict-with-other-modules-1786522.patch. Testing and feedback welcome.

The patch in #11 works for me, tested against conflict in the Media module page (admin/content/media). As the patch creator notes, I needed to clear the cache for the fix to take.

Unfortunately the patch in #11 still does not work 100% of the time. We are still getting reports of sites that are returning page not found on the /admin/content page.

Hey Joel,
It's possible that another module is implementing hook_menu with the same path. Search your codebase for any other menu hooks that define this path. If you do locate something, you could adjust the weight of the admin_views module to be "heavier" than the other module. You would adjust like the following:

$ drush sqlq "select weight from system where name = 'admin_views'"
$ drush sqlq "select weight from system where name = 'insert module with menu hook here'"
$ drush sqlq "update system set weight = [value above +1] where name = 'admin_views'"

Also, as stated above, it's important that you rebuild the menu cache afterwards.

I looked up the menu router while a site was having this issue and there were no other entries for admin/content. file_entity has some entries beneath admin/content but nothing was conflicting with the path as far as I coudl tell. Where would I go to see what is conflicting?

I dont know if this is the same issue or not. We found that when the issue is occurring, both the admin content user and node views disappear from the view listing page.

Hey Joel,
I'm guessing there is something wrong with the menu router entry for that path. What is the output of the following?

mysql> select * from menu_router where path='admin/content';

Do you have the correct page_callback and page_argument values? You should see views_page for page_callback. Also, you should NOT see a value in the include_file field. If any of these issues exist, there is something overriding the patch's hook menu implementation. From terminal in the sites/all folder, try the following:

$ cd /path/to/drupal/root
$ cd sites/all
$ grep -rn "'admin/content'" *

After the patch is applied, you should only notice one $item['admin/content'] = array( result. If you notice more than one, that could be what's overriding the patch's hook menu implementation. Also, did you remember to clear the cache so the menu router is refreshed?

Thanks,

Every time I've tried to snag this issue when it was happening, the menu router has only had 1 (correct) entry for /admin/content.

We took a DB backup of a site while it was experienceing this issue, this is teh entry in menu_router

('admin/content','','','user_access','a:1:{i:0;s:23:\"access content overview\";}','views_page','a:2:{i:0;s:16:\"admin_views_node\";i:1;s:8:\"system_1\";}','',3,2,0,'','admin/content','Content','t','','','a:0:{}',6,'Find and manage content.','',-10,''),

So it does not look like there were any bad entries in there. We do use memcache for caching so some of the cache stuff may not have gotten written in a DB dump.

My install profile has the following when doing the grep you recommended. On teh sites in question the default content module isn't enabled so I dont think the menu_uuid_links is the problem... It looks to me like there is no conflict in the code for this.

modules/contrib/pathauto/pathauto.test:468:    $this->drupalPost('admin/content', $edit, t('Update'));
modules/contrib/admin_menu/tests/admin_menu.test:152:    $this->assertElementByXPath('//div[@id="admin-menu"]//a[contains(@href, :path)]', array(':path' => 'admin/content'), 'Content link found.');
modules/contrib/admin_menu/tests/admin_menu.test:167:    $this->assertNoElementByXPath('//div[@id="admin-menu"]//a[contains(@href, :path)]', array(':path' => 'admin/content'), 'Content link not found.');
modules/contrib/admin_menu/admin_menu.module:590:    if (isset($content['menu']['admin/content'])) {
modules/contrib/admin_menu/admin_menu.module:591:      $content['menu']['admin/content'] += $links;
modules/contrib/admin_views/admin_views_default/node.admin-content.inc:359:$handler->display->display_options['path'] = 'admin/content';
modules/contrib/admin_views/admin_views.module:22:  $items['admin/content'] = array(
modules/contrib/iconizer/admin_icons.css:38:.content .admin-list a[href $='admin/content'] {
modules/folder/oursite_default_content/coursite_default_content.features.menu_uuid_links.inc:490:    'link_path' => 'admin/content',
modules/folder/oursite_default_content/oursite_default_content.features.menu_uuid_links.inc:491:    'router_path' => 'admin/content',

I know i'm piggybacking on another issue that is probalby not related, but we keep having this issue. I was able ot track down the state of menu router when the site is broken, and for admin/content, page_callback is system_admin_menu_block_page instead of views_page 9and there are no arguments or include_file. Simply clearing cache fixes the issue.

the only contrib modules we have enabled with higher weight than admin_views are:

admin menu toolbar, admin menu, page_manager, devel, rules, features, caption_filter

(edit, i'm using the patch in #11)

I made some progress debugging this in #2452161: bug in ctools_plugin_api_info version check logic, results in plugins not being loaded in certain conditions (also, race condition). I think it's a ctools/memcache issue.

Hey Joel,
Sorry, I've been busy on a project over the last few weeks but I think based on your output that maybe admin_menu and admin_views modules are conflicting. Both modules implement the 'admin/content' menu item. Can you please expand your $items array so we can see what it contains? I'm not sure which versions of each contrib module you have installed so I cannot tell what is potentially causing the problem.
Thanks

@Uberhacker, i went down the rabbit hole debugging this last weekend, basically spent 2 days on it. Long story short, race condition between features and ctools. Nothing to do with admin views or admin menu at all.

https://www.drupal.org/node/2452161
https://www.drupal.org/node/2453115

I monkey patched ctools to get around the issue but the underlying issue is still there. I think our sites/servers are so slow that unusual race conditions like this are becoming more and more common.

2452161 has just been committed!

Does this problem persist with the latest -dev release of CTools?

This is a problem with the Features system when default views are exported.

The solution is to clone the bundled views, disable the Admin Views ones, customize the new ones however needed and export them using Features.