I have had this problem before, but I had thought it was my mistake.

If I initially enable the taxonomy based modules such as simplenews and image_gallery (both of which immediately create vocabs) and *then* enable category's wrapper modules, the vocabs already created do not get converted into containers, as they should. They do not even show up on the category_legacy page to do an import (that's the critical part about this).

On the other hand, if I enable the category's taxonomy wrapper modules first and then enable taxo based modules such as simplenews and image_gallery, they are automatically shown as containers on the category administration page and all is fine from thereon.

The interesting thing is that, manually created vocabs and terms show up on the category_legacy page for doing the import even under Scenario I (enabling taxo_wrapper *after* enabling taxo_based modules). The problem, therefore, seems to be only with taxonomy based modules that automatically create vocabs and terms.

Would this qualify as a bug or is it more of a configuration issue?

CommentFileSizeAuthor
#10 document-wrappers.patch4.32 KBJirkaRybka
#6 taxo_wrapper_works.gif8.12 KBvenkat-rk
#4 simplenews-term_after_taxonomy_revert.gif2.07 KBvenkat-rk
#3 newsletter_page_available.gif3.94 KBvenkat-rk
#1 taxonomy_available.gif7.06 KBvenkat-rk
cat_legacy_manual_term_only.gif5.01 KBvenkat-rk

Comments

venkat-rk’s picture

venkat-rk commented
StatusFileSize
new taxonomy_available.gif7.06 KB

I disabled category after renaming taxonomy.module.old to get the usual taxonomy interface.

As can be seen in the attached screenshot, all the three vocabs are available in the taxonomy table, but they are not getting converted into containers when the taxonomy wrapper module is enabled.

venkat-rk’s picture

venkat-rk commented

Simplenews is failing too, if taxo_wrapper is enabled *after* enabling the taxonomy based modules. I can see the newsletters link under the admin nav menu, but clicking on it gives a 'page not found'.

I checked the db and the simplenews tables are very much there. And, as the previous screenshot showed, I can see both the newsletter vocab and the newsletter term when I revert to taxonomy.

Going to trash this site now and try enabling taxonomy wrapper module *before* enabling taxonomy based modules to test my other hypothesis.

venkat-rk’s picture

venkat-rk commented
StatusFileSize
new newsletter_page_available.gif3.94 KB

Reverting to taxonomy after deleting the wrapper module created taxonomy.module and disabling all category modules solved the simplenews problem. I can see the newsletter settings page again instead of getting a 'page not found'.

venkat-rk’s picture

venkat-rk commented
StatusFileSize
new simplenews-term_after_taxonomy_revert.gif2.07 KB

The newsletter term is also very much there. It seems to get lost in the conversion through wrapper, though.

venkat-rk’s picture

venkat-rk commented

On to test the other scenario through a new site...

venkat-rk’s picture

venkat-rk commented
StatusFileSize
new taxo_wrapper_works.gif8.12 KB

Yes, I confirmed this on a new site.

Enabling the taxonomy wrapper module *first* and then enabling the simplenews, img_gallery or any other taxonomy based modules correctly creates the vocabs as containers. Screenshot attached.

The question remains- is this a bug or a configuration issue?

bdragon’s picture

bdragon commented

Touching this bug because it is something that should be fixed or documented properly.

Ramdak, thanks again for your hours and hours of testing.

venkat-rk’s picture

venkat-rk commented

Ramdak, thanks again for your hours and hours of testing.

Thanks, Bdragon. It's the least I can do to help when I can't code:-)

JirkaRybka’s picture

JirkaRybka commented
Title: Order of enabling taxonomy wrapper affects taxonomy based modules » Order of enabling taxonomy wrapper affects taxonomy based modules (Simplenews, image_gallery)
Version: 4.7.x-1.x-dev » 6.x-2.0-rc1
Component: Category_legacy » Documentation

I suspect this problem to be still present in 6.x, and since we can't do much if the modules were enabled in wrong order, I believe we should fix the documentation first of all.

As for the category_legacy part, that's hard to judge given that it's not ported to 6.x yet, but I've seen in image_gallery code that the vocabulary is created with a "module" flag set to "image_gallery" (instead of "taxonomy"), so that might be the problem.

Let's make this issue central to the problem. Duplicates closed so far:
#133638: Duplicate key when creating first container, and possibly #206369: Image Gallery Conflict with Categories (not sure whether it's related).

JirkaRybka’s picture

JirkaRybka commented
Priority: Critical » Normal
Status: Active » Needs review
StatusFileSize
new document-wrappers.patch4.32 KB

Ok, now I have a patch:

- Added a new paragraph to the INSTALL.txt file, explaining that any new taxonomy/book dependent modules should be installed AFTER the wrappers, if possible. Also mentioning three modules having the problem - i.e. modules that create vocabularies straight away, when installed. I tested, and confirmed that this happens with above mentioned Simplenews and Image Gallery, and also core Forum (!).

Note that these modules create the vocabularies with their own module name in the 'module' field of {vocabulary} table, and usually they create further dependencies to the IDs (vid, tid...) - such as variables keeping track of the "special" vocabulary, and additional database tables joining to taxonomy (both happen with Forum at least), making category_legacy import fragile to say the least. This is where the last sentence of my new paragraph aims. (For core Forum module, this got partially [one-way] fixed in category_legacy, by special-casing the Forum data at #158683: Import from Taxonomy - Forums - this is IMO important to keep, well... because Forum is core.)

- Added some drupal_set_message() explanations to the install hook of Category. When Category is first enabled, it recommends (and links) to install the wrappers. It also checks for existence of any old data in {book} and {vocabulary} tables, and issues a warning about the need of category_legacy import if appropriate.

This patch aims to improve usability, by informing the user properly, how to avoid some pitfalls.

When this part is fixed, we may want to move this issue to the category_legacy component, to ensure that #370631: Port category_legacy to D6 is done properly, keeping the ability to import Forums, and ensuring that all third-party-modules-owned vocabularies are available for at least an attempt of legacy import (might be a good idea to give a warning on these, though, as there may be unhandled dependencies to further data in contrib, similar to what Forum does).

Jaza’s picture

Jaza commented
Status: Needs review » Fixed

Thanks, JirkaRybka! Committed to HEAD.

JirkaRybka’s picture

JirkaRybka commented
Component: Documentation » Category_legacy
Status: Fixed » Active

Thanks.

Moving to category_legacy component for now, so that we don't forget about the rest of the discussion (i.e. legacy imports on third-party-owned vocabulariers). Please revert the status once the category_legacy part is completed, or the information is inherited somewhere (i.e. other issue open).