Every time I click the save button on Settings>OG Galleries, 4 new phantom menu items are added to my menu. I call them phantoms because you can see the little bullet markers all scrunched up to the left but there is no text, so it looks like a phantom menu item. Here is an example of the view source from a page. Everything between "create content" and "galleries" was added, 4 lines at a time.


<li class="collapsed"><a href="/drupal/node/add">create content</a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/24"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/23"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/22"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/25"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/26"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/32"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/31"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/21"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/20"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/27"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/18"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/28"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/29"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/19"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/30"></a></li>
<li class="leaf"><a href="/drupal/taxonomy_menu/17"></a></li>
<li class="leaf"><a href="/drupal/galleries">galleries</a></li>

I can see the entries in the admin>menu list, but when I try to edit one of the items, it is not found. When I try to disable them, it says they are disabled, but they stay on the list. They have addresses that looks like

http://www.example.com/drupal/admin/menu/item/edit/-476

I can't figure out how to get them out of my menu structure.

Thanks for your help.

Jim

Comments

jarea’s picture

jarea commented

Update: I went to settings>taxonomy_menu and saw a bunch of null entries there, which I was able to uncheck to get them off the menu. But it still does not explain why they are showing up in the first place.

Jim

jarea’s picture

jarea commented

Update #2

I followed this back to the category menu and saw that it had created a series of spurious page, image and some undefined node type entries in the category section.

Hope this helps.

Jim

karens’s picture

karens commented

I need more info to debug this since I can't replicate it yet. The only thing that og_galleries is doing with taxonomy in settings is creating a vocabulary and term for group to use as a gallery for that group. It isn't creating menu entries, so I'm guessing something else is doing that, like taxonomy menu.

What other modules do you have installed that have anything to do with either organic groups or taxonomy?

Do you currently have any groups defined, and do you have the same number of phantom entries as you have groups?

What vocabularies are defined (did the program create a vocab for an image gallery for each group?

If the vocabularies are defined, do they have any terms associated with them? There should be one og galleries vocab with one og galleries term for each of your groups, plus one public og galleries vocab with one term for the public galleries.

karens’s picture

karens commented

Og galleries does not create any node types, so I'm guessing you are using the category module which is creating a node for your new tax terms? I have no idea if this program will work with the category module. It's not tested. Category does lots of different things with vocabularies and taxonomy terms, and it may well be doing something that just won't work here.

jarea’s picture

jarea commented

Karen,

Thanks for your replies. After working with it a bit more, I am better understanding its modus-operandi.

First, I am using both the taxonomy and taxonomy menu modules. I am not using the category module.

Whenever I update admin>settings>OG Galleries, it creates a new vocabulary in the taxonomy (categories) section for each node type that was selected which explains why sometimes I would get one new menu item and other times I would get three or four. Each vocabulary has a node type assigned to it, but the name is null.

Taxonony menu then automatically adds a menu record for each of the new vocabularies and with a null name, they turn out looking like "phantom" menu items.

So for damage control at this point, I can use admin>categories and admin>settings>taxonomy_menu to clean up any undesired results and make a note not to use admin>settings>OG Galleries except when absolutely necessary.

So at this point I don't know whether this is a bug, because it appears to be operating as you describe. However, you may have a problem with creating new vocabularies when one already exists. It does seem more like an unexpected interaction with other modules.

Now I am seeing another interaction that does not seem correct (and I haven't checked yet to see if this is already reported). When another user (with administer galleries permission) adds a gallery under OG Gallery, it is not being added as a term in the OG Gallery vocabulary.

Hope his clears things up a bit.

Regards - Jim

karens’s picture

karens commented

I'm going to try working with the code to make it behave better. It should not be creating a vocabulary unless none exists, but the check seems to not be working correctly. I also see I need to add some checks to keep it from adding terms if previous steps failed. I will post here when I get fixes made.

karens’s picture

karens commented

I have an idea about what happened here and have committed a change to both HEAD and 4.7. I think it is a combination of a mistake in the way it handled multiple image types, and not adding in checks to keep it from trying to create terms if the vocabulary did not get created correctly.

FYI - here's what should be happening. When you go to settings and select image types to add to galleries, it should be updating all image gallery vocabularies to include all those types. It should *not* create a vocab for each type, just one vocab for each group that uses all types, plus one vocab for the public gallery. If no vocab exists for a group, it will try to create one, along with a default term (gallery) to start off with (that term can be changed and others can be added).

In your database, the vocabulary table should have og_galleries as the module name for all og_galleries vocabs. That may have gotten messed up earlier but hopefully will be right going forward. You can fix that manually, if necessary. (Maybe I need to add something to the code to fix this? I haven't yet).

If you look at admin/categories you should see a image galleries vocab for each group with at least one term in each one. Each of those vocabs should be matched by an entry in the og_galleries table that links a group id to a vocab id. If that got goofed up earlier, you can fix it manually, and again, hopefully, going forward it will work correctly.

Sorry for the problems!

karens’s picture

karens commented

I think many problems were related to trying to use the module before things were setup correctly, so I have committed changes to the setup process, put in preventions to keep things that are not setup right from being used, added warnings to help clarify what needs to be done, and added a remove button in the settings section to make it easy to remove all traces and start over if the setup went wrong. You'll find the update in the cvs repository, the download file won't get updated until later.

Try this new version, go to admin/settings and use the remove button to remove the old install, re-install the module and get everything set up again, and see if there are still problems.

jarea’s picture

jarea commented

Karen,

Things are looking clearer now. Uploaded the new files from the CVS repository and reactived OG Galleries. Still got the same four phantom categories (no name, assigned to image type, which is what I specified in admin>settings>og_galleries).

I speculated that I got one phantom category for each group and forum that was existing at the time that I hit admin>settings>og_galleries.

I then went back and assigned an image type to two of the pre-existing groups and left one group and one forum with no image type and hit admin>settings>og_galleries again. Still got 4 phantoms.

For the next part of my test, I deleted the two test groups that created while OG Gallery was activated (got error messages from OG Gallery, reported on separate issue), inactivated OG Gallery, and created two new groups with OG Gallery turned off. Then I reactived OG Gallery and resubmitted admin>settings>og_galleries. Sure enough, I got six phantoms. Theory confirmed.

Then I submitted admin>settings>og_galleries again and was up to twelve phantoms.

I am submitting two other separate issues that I uncovered during my testing. The first was the previously mentioned error message. The second relates to where the images are showing up when they are uploaded into an OG Gallery.

Hope this clarifies matters for you.

Jim

karens’s picture

karens commented

Hmm, not looking clearer to me :-( I've installed this on a couple sites now and never got this behavior. I'll keep trying to find a way to replicate it...

jarea’s picture

jarea commented

I created a sandbox containing only core, OG modules and other modules required by those and all works fine. I'll see if I can isolate which module causes the problems in the other installation.

jarea’s picture

jarea commented

Case closed

After a somewhat harrowing experience (http://drupal.org/node/86506) I could not get OG to operate properly so I did a complete installation and the problem resolved itself. All appears to be working properly. Images are also displaying properly. I updated that issue as resolved as well.

Thanks for your help Karen.

jarea’s picture

jarea commented

It's Baaack!

This is the damdest thing to run to ground. After I reported this thing closed and everthing was running fine, I started reactivating all of the modules that I had deactivated during my tests. I fired up actions, article, janode, urlfilter, tinymce and imce (checking them all on in one page load) and the problem returned. To make matters more confusing, I turned them all back off and the problem continued.

Next I went back to my sandbox installation and loaded up the six modules. No problem. Everything works fine. It gets even stranger.

I went back to the original installation, dropped all of the OG tables and reinstalled using Devel and thankfully, everything worked fine. Now I reactivated the six modules one at a time, each time testing to see if the problem recurred. The problem never came back. At this point I am bringing up modules one at a time and testing after each one. So far it is all good but it seems like there is a ghost in the machine. I'll keep you posted on new developments as they arise.

karens’s picture

karens commented
Status: Active » Fixed

At very long last I found the source of this bizarre problem. It turned out to be one place where I needed to convert an object to an array. It should now be working in latest commit.

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)