admin/content Broken. Can't manage content after enabing this module

The issue you have referred to above is not the same issue. You are saying your view at admin/content doesn't work. That is issue is regarding children of that view page. Have you tried this on a vanilla drupal installation? I have a feeling it may be something to do with your site/config.

That looks like it is almost certainly your module setup. I guess start enabling modules one by one and see when it breaks.... :)

Hi,

We're encountering the same/similar issue as reported above after having run a module upgrade to admin_views.

Admin views is removing the admin/content/* menu items from the admin menu. If I disable admin_menu, the admin/content/* menu items reappear, and vice versa.

If I view the list of links that are part of the management menu via the Drupal UI (eg. at admin/structure/menu/manage/management), I also see that admin/content/* menu links are missing. However, if I look directly at the {menu_links} table, I can see the all admin/content/* entries are present.

Happy to help debug further — just point me where to go.

FYI, the version we've just upgraded to is:

; Information added by drupal.org packaging script on 2012-09-09
version = "7.x-1.0"
core = "7.x"
project = "admin_views"
datestamp = "1347174752"

same issue ...

Administration Views module is not usable anymore and a warning should be put on the module homepage till the point it can be made to work again!!

This issue does not occur on a clean drupal 7 installation, so this must be a conflict with other modules on the sites.

@standingtall and others, A bit more information would be helpful, as there are only a handful of people having this issue, so it obviously isn't happening all the time. Just "It doesn't work" doesn't really help a great deal I'm afraid.

Further to @torrance123 comment, I have the elFinder module installed. When admin views is disabled I can see all the files at admin/content/files. When admin views is enabled I get a 500 error:

PHP Fatal error: require_once(): Failed opening required '/***/sites/all/modules/contrib/elfinder/custom_pub.admin.inc' (include_path='.:/usr/share/php5:/usr/share/php5/PEAR') in /***/includes/menu.inc on line 514

I haven't had a chance to look into it further but thought I would post it on here in case it helps narrow in on the problem.

After some further based on the error, for some reason the menu module is trying to load custom_pub.admin.inc which is part of the custom publishing options module. This only happens when the admin views module is enabled. So I disabled the custom_pub module and I still get the 500 error only this time it's:

[Tue Dec 11 06:42:07 2012] [error] [client 10.242.2.10] PHP Fatal error: require_once(): Failed opening required '/***/sites/all/modules/contrib/elfinder/node.admin.inc' (include_path='.:/usr/share/php5:/usr/share/php5/PEAR') in /***/includes/menu.inc on line 514

My thought is that there is something in the admin views module that is conflicting with either the elfinder module or the admin/content/files path. Could be something like the path along with admin views is trying to load up the admin include files for all modules...failing on the first one it loads. So when custom_pub is enabled it fails on that. If disabled then it fails on the next module which seems to be the node module.

Worth noting that I also have the media module installed and going to admin/content/media works fine. This is why I think the elfinder module might be partially to blame for this issue.

I don't have time now to debug further so I had to go against the drupal bible and added an empty custom_pub.admin.inc file into the elfinder module.

This is not specifically an elfinder issue, this is an issue for any module that provides a callback at admin/content/XX That ISN'T a view page. This is a tricky issue to solve due to router item inheritance. So people can fix this temporarily if they really need to by adding their own 'file' entry to their menu items.

ok, I wrote a few tests first to expose the actual bug/issue.

I have also got a fix too. I'm happy to commit this, as it works for me, and in the tests but would be good to get feedback from people that are having these issues.

Here's a patch showing failing tests, then hopefully all passing.

Anyone testing; Use the second patch, apply to the latest git checkout of the 7.x-1.x branch and flush caches.

Good, that doesn't totally work properly though but I think this might. Same applies as above to testers.

I committed a fix for this over in #1786522: Conflict with exported views via Features. This should fix this too. Closing for now. Reviews welcome.... Please pull the latest dev version of the module or wait a few hours to download the snapshot.

#18 doesn't solve it for me.

After reverting your views?

yes .. reverted all views but still won't work.

@standingtall - Do you have any more info than that? Generally "won't work" is a bit of an unhelpful diagnosis ;)

Modules, does this work for you on a clean install for instance?

#18 solves it for me.
I disabled the module, then uninstalled it (modules -> uninstall), then deleted the "admin_content_node" view, then re-enabled the module.
Thanks!

@landor, good to hear! :)

#18 Does NOT fix the issue for me either. Under every circumstance the Content menu item is missing and going directly to "/admin/content" produces "You have reached a page that you do not have the proper permissions to view."

OK. I've got it working but it was very strange.

I followed the process in #18 (even un-installed the module and re-installed).
Initial visit to /admin/content yielded permission denied error.
After examining the "Administration: Nodes" View, there was a Page display (to go along with the System display) that BOTH had Paths that pointed to "admin/content" (obvious conflict).
After deleting the Page display (which seemed to be an unnecessary duplicate display and I'm not sure where it came from), everything started to work fine, including the appearance of "Content" menu item.

Is creating a duplicate Page display (at the same path) the default behavior of the Admin Views module? Should I be using a this Page display instead (so that I can maintain the default settings in the System display for reference?) I guess that kind of makes sense, but creating the Page display with the same Path as the System display sounds like a mistake.

Is creating a duplicate Page display (at the same path) the default behavior of the Admin Views module?

Is that sarcastic? No, that's not the default behaviour. These problems only occur generally when people have SAVED THESE ADMINS VIEWS (So they are overridden in the database) then upgrade. This is a characteristic of how the CTools export system works in general with in code and overridden items in the database. It will always use the overridden one if it has it there. I also don't think it's a good idea we just delete peoples admin views during a module upgrade.

Seems like that additional display has been added by a user, as we have always used the system display.

I am going to add a note to the project page to warn people that overridden views aren't really supported.

@damiankloip, I'm glad you've determined that at the present time, overridden views aren't supposed. However, this isn't satisfactory to me as the only reason I install admin_views is I can customize the admin content and user pages. The default pages that admin_views provides are definitely an improvement over the core pages, but each Drupal site is different, and I need the ability to customize these pages to what each site needs.

The bigger issue at work here is that loosing the ability to have overridden views is a regression from 7.x-1.0-alpha1. I'm not sure how it can be okay to have something fundamental be in an alpha, but be missing from two production releases.

Its not missing. You are free to do whatever you like with your views, but how do we feasibly support any updates to views if they are overridden? You can't. So I'm afraid calling this a regression is not to true at all.

The best fix we could do is to always remove the old view. As this changed name after the alpha release. But then this would also delete peoples old views if they were upgrading from that version.

The regression aspect I'm referring to is that it was possible in 7.x-1.0-alpha1 to update this module without breaking when the admin views were overridden the database.

Is there a way to decouple the overriding functionality from the actual view export? Perhaps provide a default view that is used, but allow the site admin to select a different one? This way, a site admin could maintain their own views, whether in database, exported to code, or exported through a feature. And updates to the core functionality, that is, this module, wouldn't interfere with the maintenance of the views.

Hm, I'm not sure exactly what you mean. Are you familiar with the CTools export system? This is just default views which implicitly relies on CTools for this. You are welcome to override your views but if any views change between releases, you will not get these changes.

The ONLY reason we are having issues here is that the views changed name from from the alpha release.

So again, I'm not sure how this is a regression in the functionality. This works much the same as it did before and this module is pretty much default views. If you have upgraded you really just need to remove the old view that was in the database and use the new overriden view with the correct machine name.

This is a fixed issue and 'won't fix' for anything else as far as I'm concerned.. Sorry :/

Sorry damian, re-opening.

We've not overridden the views, I've tried doing as suggested (disabling, removing any views which stick around, re-enabling). Tried going back to alpha1, tried latest dev, all of which don't work and I've got the issue that:

Go to content view, click "Reset", "The page isn't redirecting properly".

Let me know if there's any other info I can give.

This is not related to this issue. You need to upgrade views. See #1844510: Views "Reset" button causes infinite redirect loop

I had this problem too.

Turned out that I had Commerce Backoffice view that override admin/content URL

So.. if you have this problem go to /admin/structure/views and search for "admin/content" or any other url you having trouble with and see if some other view is already using that.

Maybe check "Path" too..