I get a long wait, high CPU usage and an eventual "white screen of death" after generating aliases for taxonomy terms. This did not happen until Taxonomy Manager module caused some problems with a few terms that were assigned to themselves as children numerous times. Taxonomy.module UI was listing many terms as children of themselves recursively. I was able to make the term list in taxonomy.module's UI appear correctly by removing the parent assignments for those terms, but pathauto is still not completing the generation. It generates 12 terms before it stops. I tried setting the limit of aliases generated per execution to 10, but that did not solve the problem. Any idea how I might clean this up?

Comments

webavant’s picture

I repaired/optimized tables and tried again. This time, it generated 10 aliases just fine on the first run, but timed out on the second run:

[04-Jun-2009 12:55:38] PHP Fatal error: Maximum execution time of 30 seconds exceeded in /Users/tony/Sites/tricountyfarm/modules/taxonomy/taxonomy.module on line 777

So, it looks like this is a problem with taxonomy.module and/or Taxonomy Manager, but I am desperate if anyone knows how to clean this up.

Strangely, I woke up to find that somehow, all 222 terms had aliases mysteriously. I deleted them before trying to reproduce the above issue. Does anyone know what might cause this? It seems like one of my terms somewhere between tid 10 and 20 has some sort of problem. I cannot tell by looking. Any helpful hints?

webavant’s picture

I am almost positive that this issue is caused by having two terms of the same name. I'll test it some more in a couple of days. This is probably a known or documented issue. I did use the 'search' function to see if I could find a duplicate issue, but maybe I missed this problem. It seems like pathauto should stop generating aliases when it encounters duplicate terms and show a warning in order to prevent this timeout error.

greggles’s picture

Title: WSOD » WSOD when bulk generating circularly hierarchical taxonomy

First, try 6.x-1.x-dev.

Second, perhaps deleting your taxonomy will be necessary.

webel’s picture

I have same problem. Am using a complex taxonomy with terms with multiple parents. Some term names may repeat.

webel’s picture

When I delete all of the taxonomy aliases it still happens. It seems to be triggered by an attempt to generate an alias for one node (I've done about 200 of 300, and pathauto is stuck somewhere). It also happens when I execute a view of all content nodes. I have no idea how this could implicate the taxonomy. Sorry for such vague diagnostics (it's nearly midnight and I've run out of energy), hope it helps. Webel

webel’s picture

I removed all multiple parents from my taxonomy. I used direct SQL to check that there are no terms with multiple parents, and no terms with repeat names. It still happens. I've tried deleting all path auto aliases for vocabs. The first few batches of 50 go through fine, then it stalls, even if I turn the batch size down to 1.

@greggles who wrote:

First, try 6.x-1.x-dev.

Will do and will report back here.

Second, perhaps deleting your taxonomy will be necessary.

I hope not.

webel’s picture

I tried 6.x-1.x-dev. Same problem. And like webavant I had previously had problems with Taxonomy Manager (in my case during a merge). However I am quite sure now that my taxonomy tables are clean because of direct SQL checks.

Could having an ampersand in the term name cause trouble ? Yes, desperate guessing now.

webel’s picture

Devel module's dpr to the rescue:

/**
 * Find all ancestors of a given term ID.
 */
function taxonomy_get_parents_all($tid) {
  $parents = array();
  dpr($tid,FALSE,"taxonomy_get_parents_all.tid"); //DEBUG
  if ($tid) {
    $parents[] = taxonomy_get_term($tid);
	dpr($tid,FALSE,"taxonomy_get_parents_all.parents"); //DEBUG
	$n = 0;
    while ($parent = taxonomy_get_parents($parents[$n]->tid)) {
	  dpr($tid,FALSE,"taxonomy_get_parents.parent"); //DEBUG
      $parents = array_merge($parents, $parent);
      $n++;
    }
  }
  return $parents;
}

Infinite recursion found:

taxonomy_get_parents_all.tid => 155

taxonomy_get_parents_all.parents => 155

taxonomy_get_parents.parent => 155

taxonomy_get_parents.parent => 155

..

Sneaky. Direct SQL on term_hierarchy shows the parent of 155 is 255. And the parent of 255 is .. tada .. 255. Taxonomy Manager did not catch this. Deleted offending row with 255 255 from term_hierarchy, reran ..

taxonomy_get_parents_all.tid => 19

taxonomy_get_parents_all.parents => 19

taxonomy_get_parents.parent => 19

taxonomy_get_parents_all.tid => 203

taxonomy_get_parents_all.parents => 203

taxonomy_get_parents.parent => 203

taxonomy_get_parents.parent => 203
..

Another one. This time 203 has 203 as parent. Delete offending circular row .. now it runs through fine.

Ahh... what better way to spend a Sunday evening than to solve problems with a computer that you would never have had without a computer. Now that's what I call achievement, really productive work. And I can also use all my views again. Case solved.

It might be a good idea to code some catches for such circular taxonomy refs in, especially given that Taxonomy Manager can create them it seems

webel’s picture

@webavant I am happy for this to be marked closed, it's up to you.

greggles’s picture

I don't think Pathauto should include code that catches an inconsistent data model created by other modules. If we did that where would it stop?

Can anyone else confirm they had this circular reference problem as a result of using Taxonomy Manager? If so we can move this issue to that queue.

webel’s picture

I am for moving it to Taxonomy Manager.

greggles’s picture

Title: WSOD when bulk generating circularly hierarchical taxonomy » Circular hierarchical taxonomies are bad
Project: Pathauto » Taxonomy Manager
Version: 6.x-1.1 » 6.x-1.x-dev

Great.

mh86’s picture

Status: Active » Fixed

I added validations to the Taxonomy Manager to ensure a consistent hierarchy, this should prevent adding of cycles during hierarchy changes or merging.

webel’s picture

thanks !

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.