Add hook_taxonomy_vocabulary_info()

It looks a bit odd to me doing this in taxonomy_get_vocabularies() - why not a hook_modules_installed() or hook_modules_enabled()?

Drupal 8, sadly.

It's totally insane that this wonderful patch is moved to D8, just because #347959: modules_installed is broken during testing, resp. the initial Field API patch, totally broke SimpleTest.

That last patch looks just nice + correct and was ready months ago.

Let's see if we can fix #347959: modules_installed is broken during testing quickly, so we can get this one in before January 15th.

Postponing, pending #836748: Improve documentation about install/enable/etc. hook invocation order

If 836748 does not get in, this will have to be done with an ugly workaround.

Otherwise, this is a reroll of #5 with a fix to field_name in forum_enable that was causing forum.install to always try to create a field regardless of whether it already existed.

Unfortunately it looks like forum.module is not the best example for hook_taxonomy_vocabulary_info. hook_taxonomy_vocabulary_info() is a great idea and a good* implementation, but it seems like it's not going to work for any module that needs the vocabularies during install / enable.

In the case of forum.module, the problem boils down to a circular dependency: forum_enable() expects to find a vocabulary exposed by forum_taxonomy_vocabulary_info(), but the vocabulary isn't registered in the system until taxonomy_modules_installed() is run. taxonomy_modules_installed() won't find the vocabulary unless forum_enable() has already been run.

Short of major changes to the install/enable process, there's simply no way that the vocabulary defined in forum_taxonomy_vocabulary_info() will be available during forum_enable().

So, the attached patch is another reroll of #5 with the change:

• fix to field_name in forum_enable() that was causing forum.install to always try to create a field regardless of whether it already existed
• during forum_enable(), call forum_taxonomy_vocabulary_info() directly and save the vocabulary with taxonomy_vocabulary_save().

*An ideal solution for hook_taxonomy_vocabulary_info would be to treat vocabularies defined in implementations of the hook as first-class citizens, a la ctools exportables. In other words, eliminate the requirement that vocabularies be stored in the database. Abstract this idea up to entities, and we're talking about some major rethinking of some Drupal fundamentals.

Move the code from forum_enable() into forum_modules_installed() or forum_modules_enabled(), check whether 'forum' is in the installed/enabled modules, and if it is, you can rely on the vocabulary being installed.

Brilliant, sun. That is why you make the big bucks.

one more instance of field_name needed to be updated.

wrong name for field_name

... and another.

Installed forum, vocabulary created, field attached with correct vocabulary, etc.

Re: module; As module isn't doing much anymore as far as I can tell (no hook_term_path, forum is doing enetity alter to change the path I think?), and it involves a bit of messy code to do module_implements, then foreach over each result to add in module, might as well say screw it imo.

As far as I can tell, there's are the only two referencing using module (excluding schema):

taxonomy.admin.inc forum (appear to use it cept for saving)
$form['module'] = array('#type' => 'value', '#value' => $vocabulary->module);
taxonomy.module vocabulary save
  if (!isset($vocabulary->module)) {
    $vocabulary->module = 'taxonomy';
  }
taxonomy.install's scehma
      'module' => array(
        'type' => 'varchar',
        'length' => 255,
        'not null' => TRUE,
        'default' => '',
        'description' => 'The module which created the vocabulary.',
      ),

(Twitter 'discussion', asked bangpound why no alter hook; can't really change much, and as there's no revert, ie this is just on install, wouldn't be too useful, would need the module to be enabled before the one defining the vocabulary to alter it!)

(Hm, users can delete vocabularies despite what module created it. :O; though in the case of forums can do variable_set('forum_nav_vocabulary', new vid) to recover from that).

Rerolled patch:

• changes 'module' attribute of hook from required to optional. Iterating over module_implements() is not much different than iterating over the result of module_invoke_all(), so this seemed like a decent compromise.
• defines a constant for forum's vocabulary machine name, FORUM_VOCAB_MACHINE_NAME.
• removes vid variable forum_nav_vocabulary - there's no reason for it since we can more reliably use taxonomy_vocabulary_machine_name_load(FORUM_VOCAB_MACHINE_NAME).
• fixes some trailing whitespace.
• updates forum tests.

um, didn't read the issue, but introducing a constant for a machine readable taxonomy vocabulary name sounds a bit odd to me.

If I'm not mistaken, then the hook_modules_enabled() code can stay in the .install file.

+++ modules/forum/forum.module	28 Jun 2010 15:35:17 -0000
@@ -229,7 +317,9 @@ function forum_init() {
+  $forum_vocabulary =
+    taxonomy_vocabulary_machine_name_load(FORUM_VOCAB_MACHINE_NAME);

+++ modules/forum/forum.test	28 Jun 2010 15:35:17 -0000
@@ -100,8 +100,9 @@ class ForumTestCase extends DrupalWebTes
+    $vocabulary =
+      taxonomy_vocabulary_machine_name_load(FORUM_VOCAB_MACHINE_NAME);

@@ -181,8 +182,8 @@ class ForumTestCase extends DrupalWebTes
-    $original_settings = taxonomy_vocabulary_load($vid);
+    $original_settings =
+      taxonomy_vocabulary_machine_name_load(FORUM_VOCAB_MACHINE_NAME);

@@ -201,7 +202,8 @@ class ForumTestCase extends DrupalWebTes
-    $current_settings = taxonomy_vocabulary_load($vid);
+    $current_settings =
+      taxonomy_vocabulary_machine_name_load(FORUM_VOCAB_MACHINE_NAME);

@@ -210,7 +212,8 @@ class ForumTestCase extends DrupalWebTes
+    $current_settings =
+      taxonomy_vocabulary_machine_name_load(FORUM_VOCAB_MACHINE_NAME);

@@ -244,7 +247,9 @@ class ForumTestCase extends DrupalWebTes
+    $vocabulary =
+      taxonomy_vocabulary_machine_name_load(FORUM_VOCAB_MACHINE_NAME);

Strange wrapping here. Only comments should wrap at 80 chars.

+++ modules/taxonomy/taxonomy.api.php	28 Jun 2010 15:35:17 -0000
@@ -86,6 +86,48 @@ function hook_taxonomy_vocabulary_delete
+ * @return
+ *   An associative array of information defining the vocabularies. The array
...
+ *   - "name": the human-readable name of the vocabulary. Required.

No quotes for array keys, just the key, followed by a colon. http://drupal.org/node/1354

+++ modules/taxonomy/taxonomy.api.php	28 Jun 2010 15:35:17 -0000
@@ -86,6 +86,48 @@ function hook_taxonomy_vocabulary_delete
+ *
+ */
+function hook_taxonomy_vocabulary_info(){

Stale trailing blank docblock line.

+++ modules/taxonomy/taxonomy.module	28 Jun 2010 15:35:17 -0000
@@ -673,6 +678,31 @@ function taxonomy_terms_static_reset() {
+function taxonomy_modules_installed($modules) {

Missing function docblock.

+++ modules/taxonomy/taxonomy.module	28 Jun 2010 15:35:17 -0000
@@ -673,6 +678,31 @@ function taxonomy_terms_static_reset() {
+  $defaults = array('hierarchy' => 0, 'relations' => 0, 'module' => FALSE, 'weight' => 0);
...
+    foreach ($info as $machine_name => $vocab_info) {
+      $vocab_info = array_merge($defaults, $vocab_info);

Usually, we do

$vocab_info += array(...);

to merge in any defaults.

Powered by Dreditor.

OK, thanks for the feedback sun.

I have rerolled with the suggested changes and a couple others:

• Since the variable forum_nav_vocabulary is going away, implemented forum_update_7002() to update forum vocabulary's machine_name when upgrading from D6.
• Updated documentation for forum_modules_enabled to explain why it lives in forum.install
• Removed some trailing whitespace.

forum_form_alter() was calling taxonomy_vocabulary_machine_name_load for all forms, which broke update.php. changed multiple if statements therein to switch-case.
updated documentation for forum_update_7002().

replaced a few straggling variable_get('forum_nav_vocabulary', '')'s in forum.admin.inc

#34: 569326-hook_taxonomy_vocabulary_info_8.patch queued for re-testing.

Almost a year later, moving to D8 again, should try to get it in early there.

I don't think it is valid anymore see taxonomy.vocabulary.forums.yml.

> I don't think it is valid anymore see taxonomy.vocabulary.forums.yml.

Agreed.