taxonomy wrapper: undefined function category_cache_op

Hm, the listed backtrace looks like taxonomy_get_vocabularies() gets called at the end of update.php operations, as a part of one of the rebuilds issued there. This is obviously dependent on category.inc, which is not loaded here - we're in update.php, so hook_init() didn't run. This is IMO a bug in the way how update.php handles the rebuilds in relation to hook_init(), that didn't show such symptoms in core only due to taxonomy module being so simple and self-contained. (Although this is core stuff, I'm afraid that we won't be able to fix the bug in there, as many people have tendency to dismiss anything to do with category module immediately :-/)

One of possible solutions might be to revoke #338750: Fatal errors - category.inc sometimes not loaded?, putting require() to the top of category.module file. That would fix all similar problems, but also remove any benefit from not loading the include where not necessary (i.e. cached pages).

Other solution is to uninstall the wrapper prior to update, and instal afterwards. I always considered this a good practice myself, so that core Taxonomy updates can run, but I'm unsure whether it's documented anywhere. May not hurt, anyway, and is probably the easiest fix, and safer way in general.

As a sidenote, I think that the described use case have a problem: The wrapper should have been running all the time, so that the Taxonomy tables are maintained and up-to-date. If the wrapper was installed after a long period of time, the taxonomy tables are outdated, and you're probably going to have problems with taxonomy-dependent modules (when it comes to older contents on your site). You might need to do some sort of a refresh - either a data-replication from category tables (doable, but some columns in database tables have slightly different names and there's a lot of manual work involved), or perhaps through category_resave module (with wrapper installed - this might be time-consuming). Always keep backups!

The taxonomy wrapper maintains taxonomy tables all the time, so that they mirror Category data (more or less). This is the only reliable way to provide compatibility with taxonomy-dependent modules, because (as I understand this) such modules often have direct queries against Taxonomy tables. (The one example I remember is: On 5.x the tables were not always synchronized correctly [due to bugs], which caused major problems with core Forum module.) In fact, the Category 6.x version actually have full Taxonomy code in the wrapper for read operations, only writes are synchronized [differs from 5.x]. The goal is compatibility here, quite obviously.

With wrapper disabled, in the other hand, Category system doesn't touch Taxonomy tables - making it possible to preserve legacy Taxonomy data (for migration, to revert Category evaluation later, dunno, maybe even to run two categorization modules [category+taxonomy] alongside, which is weird but works AFAIK). With wrapper disabled, the compatibility layer doesn't work, so Taxonomy tables are empty.

Unfortunately, there's not much effort on fixing problems now: Category module is going to be discontinued on 7.x, per maintainer's statement some months ago. That also reduced my fixing efforts (as these were targetting flawless future transition of my site to 7.x, which won't happen this way), and apart of the work done by the maintainer, there's nearly nothing more to be seen. Any help is welcome, obviously, but I don't see the future of Category in bright colors... (This is how it looks like, when core developers send a major contribution to "mature in contrib", eh? Um.. Sorry, better ignore my rant.)

I didn't fully test for regular nodes, but I believe that "call this function for every existing node" boils down to the category_resave module provided in the 6.x package. With the wrapper enabled, just enable category_resave module temporarily, and execute the re-save operation on everything (it loads and saves again each node, so that all modules do their stuff). As I said, it's definitely worth a little test in advance and backups, but if I'm right, it should rebuild the Taxonomy data - most probably making it even possible to switch to Taxonomy module later (although there'll be still category nodes/menu items/variables/etc. hanging around, which will need to be cleaned manually if migrating away from Category; this is in fact the purpose of category_legacy module [not ported to 6.x yet]).

So... if I disable the taxonomy wrapper, I will end up destroying entire menus. Great.

Plus, disabling the taxonomy wrapper means I have to disable the resave module, because it's a dependency.

I've been waiting for nine months on a fix.

I stopped working with Drupal 6, and work with Drupal 7 exclusively.

Category module was never a "hop-on hop-off" switchable module, it was more of a permanent replacement for Taxonomy all the time. Issues with migration from Category back to Taxonomy are known, but the plain fact is that there's no-one to work on this. Category module is not supported or maintained anymore, AFAIK.

The problem arose in duplicate folders "Taxonomy" (in some subjects). How I solved the problem - copy the folder "Taxonomy" from the root "../modules" in the directory "... / sites / all / modules / category / wrappers /". After copying, delete "Taxonomy" of "../modules". Warning! In the catalog "... / sites / all / modules / category / wrappers /" folder "Taxonomy" must be removed before it is poured from a different directory. (Drupal 6.34)

Thanks, agypten. I no longer use Drupal for any site, however.