Taxonomy throwing odd errors when previewing node

Im still having this problem with preview in Taxonomy 6.4

I'm getting this in 6.4
Last time this happened it seems another module was messing up the array a bit.
http://drupal.org/node/269205

I've just installed ubercart and its 25 associated modules, so it may be any one of them. Tracing... It's an adjustment made to the node object or form somewhere previously, so it's not directly in the callstack...

I'd suggest that drupals APIs get a little more robust to rogue input anyway, so i feel an is_numeric() check in taxonomy_get_term would be in order. I know other folk disagree philosophically, but I think APIs should fail gracefully, even if a module was ported badly.

.dan.

So far it seems that the $node->taxonomy array contains a term object, not an array as expected. I wonder how that got there and who forgot to cast it...
Actually I like objects for terms more, but the system doesn't ...

As far as I can tell, taxonomy_preview_terms gets called too many times, casting it from array to object once, then attempts to again, but dies because it already is.
Here's how I catch it.

--- modules/taxonomy/taxonomy.module	2008-09-18 00:55:37.000000000 +1200
+++ modules/taxonomy/taxonomy.module	2008-10-03 16:16:15.000000000 +1300
@@ -588,9 +588,10 @@ function taxonomy_preview_terms($node) {
         }
       }
       // A 'Single select' field returns the term id.
-      elseif ($term) {
+      elseif (is_numeric($term)) {
         $taxonomy[$term] = taxonomy_get_term($term);
       }
+      // Else probably an object already. Leave it alone.
     }
   }
   return $taxonomy;

Hm. I see what you are thinking, but not quite.

The error that was being addressed is a nasty php indexing exception triggered by addressing $taxonomy[$term] where $term is an object.
Where $term is zero, that's not an error, just invalid data.

taxonomy_get_term(0) returns NULL (I'm pretty sure) which doesn't error. But could conceivably later I guess.
It's wrong, so yes it should be fixed if detected.

But will need to be fixed by unset(), not by ignoring it.

Outputting an untouched zero in the term list where an object is required may cause trouble later when

...
  foreach($node->taxonomy as $term) {
    $tid = $term->tid;
    # where $term=0;
  }

so I guess

      elseif (is_numeric($term)) {
        if ($term) {
          $taxonomy[$term] = taxonomy_get_term($term);
        }
        else {
          unset($taxonomy[$term]);
        }
      }

however that extra code fixes an issue which has never yet arisen. This OP one has.
(BTW, the error can only be replicated when a vocab is set to single select, required AFAIK)

I'm personally in favor of paranoia ... but if we were to worry about it, that check for zero should be much higher in the chain of events.

Suggestions?

That's a "we don't babysit broken code" type of issue. You should stop trying to fix the symptom and fix the root cause instead.

Marked as won't fix.

The root cause is in one of the non-core modules messing up with the taxonomy.

The error that appear here is a *symptom*. You should fix the cause. The patch in #4 should not even be considered.

Anyway, I'm reassigning that as a support request and set it back to active, so that we can investigate which module is performing wrong and assign the blame on it =)

I spent over an hour tracing the entire active codebase watching anything that was attempting to change $node->taxonomy
All I could see was that in the course of a submitted node preview, taxonomy_preview() was invoked 3 times, each by which appeared to core callstacks. form_alter (or drupal_alter?) ran twice on the form. NODE_BUILD_PREVIEW was not being set on the $node object.

I couldn't track it down to any contrib, although I'd certainly, and still do suspect one as what triggered this as a side effect. If it were possible to understand the chain of events that leads up to this point, that would be cool. I failed.

You call it babysitting,
I call it not trusting external inputs.
Blindly assuming all data from all sources is valid all the time is not what I would expect from a robust API.

My code style is to fix things in a way that stops the problem from happening again (where practical), rather than just hoping it doesn't. Other folk can differ.
But yes, I'd like to find the cause in the contrib. Because knowledge is good also.

Any solution to this yet? I still having this warnings on taxonomy 6.5.
* warning: Illegal offset type in isset or empty in taxonomy.module on line 1015.
* warning: Illegal offset type in taxonomy.module on line 1016.
* warning: Illegal offset type in taxonomy.module on line 1019.
* warning: Illegal offset type in taxonomy.module on line 592.

@earnie, dman: taxonomy_preview_terms() should only be called once. That's the problem we need to identify and fix in that issue ticket. Changing "taxonomy_preview_terms()" to hide the error there and think it solved the issue is just burying your head in the sand.

Any solution to this yet? I still having this warnings on taxonomy 6.5.

* warning: Illegal offset type in isset or empty in taxonomy.module on line 1015.
* warning: Illegal offset type in taxonomy.module on line 1016.
* warning: Illegal offset type in taxonomy.module on line 1019.
* warning: Illegal offset type in taxonomy.module on line 592.

or should i burying ny head in the sand?

thanks

My enabled modules are :

1. Administration Menu 6.x-1.1
2. Views UI 6.x-2.1
3. Advanced help 6.x-1.1
4. Advanced help example 6.x-1.1
5. FCKeditor 6.x-1.3-rc3
6. IMCE 6.x-1.1
7. Taxonomy Access Control 6.x-1.x-dev

Do you want the core modules also ? I would like to help...

thanks for the reply

OMG. I had absolutely zero of those modules present when I got the error. That's a worry. :-{

I have this same problem; the only modules I have enabled that are also on your list are:

Views 6.x-2.1, Views exporter 6.x-2.1, Views UI 6.x-2.1 and Advanced Help 6.x-1.1.

I can also say that I didn't have the error messages showing up until 26/10/2008, after I upgraded to Views 6.x-2.1 (on 21/10), installed Advanced Help (also 21/10) and then upgraded to drupal core 6.6 on 23/10.

Simplistically, this looks to me like an interaction between Views 6.x-2.1 and Drupal 6.6. Although others have been seeing it in earlier versions of Drupal core... so maybe an interaction between Views 2 and Drupal.

Hi again,

I noticed that when i changed the them ftom nitobe to pixture-reloaded the warninngs were gone!!!

I have wabi installed and active. No nitobe.

Full list of modules below. As I said above, this only started appearing after I upgraded first to Views 6.x-2.1 and then Drupal 6.6. It may be relevant that after the upgrade to Drupal 6.6, some of my taxonomy vocabularies (Image Galleries and Web Links) lost their association with any node types. Since I manually re-instated these, I haven't seen the error reported again (yet).

Image 6.x-1.0-alpha3
Image assist 6.x-2.x-dev
Image Gallery 6.x-1.0-alpha3
Image Import 6.x-1.0-alpha3
insertFrame 6.x-1.2
Pathologic 6.x-1.1-beta13
GMap 6.x-1.0-rc2
GMap Macro Builder 6.x-1.0-rc2
GMap Taxonomy Markers 6.x-1.0-rc2
Advanced help 6.x-1.1
Menu breadcrumb 6.x-1.1
Nodeaccess 6.x-1.2
Pathauto 6.x-2.x-dev
Site Documentation 6.x-1.2
Term Display 6.x-1.0
Token 6.x-1.11
Token actions 6.x-1.11
Web Links 6.x-1.0
Web Links Filter 6.x-1.0
Views 6.x-2.1
Views exporter 6.x-2.1
Views UI 6.x-2.1

No nitobe for me. the only bits I didn't trust - the only bits on a fresh installation - were a full installation of ubercart. I couldn't see any justification for them messing with taxonomy, but OTOH, I couldn't speak for them either.

Hello,

Has this issue been resolved in the meantime? I also get the same warning message when I want to preview a comment or a node. I am using D6.6.

A stupid question: how can I use the patch? Do I have to copy/paste the content into the taxonomy module file?

Cheers,
Roger

  if (module_exists('taxonomy')) {
    $terms = taxonomy_link('taxonomy terms', $node);
  }
  else {
    $terms = array();
  }

So it's the theme that calls taxonomy_link() the second time. Interesting :)

Ok, let's keep that issue in D6 only for now, the taxonomy module is being heavily refactored in D7.

As a stop-gap solution for D6, I suggest we simply add a $node->built_preview_terms flag at the bottom of taxonomy_preview_terms() and check for it in the enclosing if (isset($node->taxonomy)) of that function.

Hi Damien,

Wow, that was fast! :-) Would you mind to tell me step by step what I have to do? I am a new Drupal user and don't know where to put the code you provided.

Although I assume I have to add it to the taxonomy.module file? Am I right? Does it matter where I put it (I mean in the beginning or end of the file?).

Cheers,
Roger

Hello,

Anybody willing to help? Any assistance is highly appreciated!

Cheers,
Roger

Subscribing

If I understand Damien correctly, he suggests the attached patch. (Right? Damien, I hope you don't mind me jumping in. Thanks for suggesting a way to fix this!)

For those not familiar with patching files, you can manually replace lines 572-597 (all of the function taxonomy_preview_terms) in the Drupal 6.8 taxonomy.module with the below lines. Hope this helps.

function taxonomy_preview_terms($node) {
  $taxonomy = array();
  if (isset($node->taxonomy) && (!$node->built_preview_terms)) {
    foreach ($node->taxonomy as $key => $term) {
      unset($node->taxonomy[$key]);
      // A 'Multiple select' and a 'Free tagging' field returns an array.
      if (is_array($term)) {
        foreach ($term as $tid) {
          if ($key == 'tags') {
            // Free tagging; the values will be saved for later as strings
            // instead of objects to fill the form again.
            $taxonomy['tags'] = $term;
          }
          else {
            $taxonomy[$tid] = taxonomy_get_term($tid);
          }
        }
      }
      // A 'Single select' field returns the term id.
      elseif ($term) {
        $taxonomy[$term] = taxonomy_get_term($term);
      }
    }
  }
  $node->built_preview_terms = true;
  return $taxonomy;
}

Hi smh67,

It worked perfectly! THANKS a lot!! A big issue that prevented me from going online is now resolved.

Cheers,
Roger

Needs review.

Hi there,

I'm using Drupal 6.9 and just came across this bug. Considering that it seems to be mostly harmless, it sure is ugly.

Here are the errors on preview after choosing a tag in the add/edit story page (not choosing a tag means no errors):

* warning: Illegal offset type in isset or empty in /html/modules/taxonomy/taxonomy.module on line 1015.
* warning: Illegal offset type in /html/modules/taxonomy/taxonomy.module on line 1016.
* warning: Illegal offset type in /html/modules/taxonomy/taxonomy.module on line 1019.
* warning: Illegal offset type in /html/modules/taxonomy/taxonomy.module on line 592.
* warning: Illegal offset type in isset or empty in /html/modules/taxonomy/taxonomy.module on line 1015.
* warning: Illegal offset type in /html/modules/taxonomy/taxonomy.module on line 1016.
* warning: Illegal offset type in /html/modules/taxonomy/taxonomy.module on line 1019.
* warning: Illegal offset type in /html/modules/taxonomy/taxonomy.module on line 592.

My installation only has core modules installed (no contributed modules) and I am indeed using the nitobe theme. I haven't checked against other themes but given that nitobe seems to be a common thread in this bug report, I suspect it's specific to nitobe.

I am seeing it on Drupal 6.10, previewing a user profile.
I am using Garland (and content_profile for profile nodes).

I am also receiving this issue on D 6.10 for any preview that included taxonomy terms. From what I understand this is a significant issue in relation to the display of content, especially to the unsuspecting user who is attempting to harmlessly add content and then may think they've done something wrong... or worse, that the website is dysfunctional. I'm somewhat surprised that an error related to taxonomy module would linger so long, but I'm keeping my eyes out for solutions and just reporting that I am receiving the same error on the most current version of Drupal. if anyone discovers a solution please post..

To be fair, the error, as far as we know, is not a problem with taxonomy module.
It's a problems with the way some other modules are interacting with core taxonomy. We are not sure how or why, but some contrib things expect $node->taxonomy to be turned into an array of ids not an array of objects (or something like that) at a certain point in the process.

However taxonomy.module breaks because it didn't expect that to happen. Therefore it's inconceivable. There is opposition to adding any proper error checking because it's something that should never happen.
Yet it does.

As a coder, I think that adding error handling and assertions where there is an identified need is sometimes necessary. The condition should not happen, but it did, so lets deal with it, and try to warn about the root cause when we can. "error handling"

Others just want the thing that causes the problem to stop doing so. Which is also a great way forward. But so far has failed.
We are often unable to replicate the issue, so haven't even boiled it down to one common module. Maybe there are several modules making the same mistake.

To get towards a solution, please post the contrib modules and theme you are using. And describe the taxonomy (select, freetag, required) etc
Maybe we will see a cause.

I am using Taxonomy Manager & Taxonomy Menu, but something I noticed is that before I upgraded to Drupal 6.10 (from 6.4) this error was not occurring, or at least it wasn't being displayed during preview..

Nothing changed about my contrib modules, the Drupal version changed, and this occured.. I understand its how the contrib modules are interacting with taxonomy- not taxonomy itself, but I wonder what has changed with core taxonomy to create this 'error'.

Any help would be greatly appreciated, as I am looking for a solution for this.. Its not a site-breaking problem, but its certainly a problem that can scare users and make them less confident about your site.. I hope this is dealt with soon.

Thank you.

I have 6.10 and I'm seeing the same issues which I track down to taxonomy_preview_terms then found this. I have cck, veiws, cck taxomony widget, token. Everything that needs taxomony that I don't use is turn off, some uninstalled too. I tried the patch above but that doesn't work for me. I've looked in page and node tpl files and no reference to taxomony. Changing theme to bluemarine has no effect so I don't think it is theme related. I do use cck to select the taxomony and some are multiple select. The problem is the same as above in that it is the line:

// A 'Single select' field returns the term id.
elseif ($term) {
//$taxonomy[$term] = taxonomy_get_term($term);
}

that gives the error. Comment that out and all is well. The $node->built_preview_terms does not seem to stay set. It starts off as {} then is set to {1} but next time round it is {} again

(I've stuck print "{";print_r($node->built_preview_terms);print "}"; at the start and end of the function).

UPDATE

The problem I think is line 578 "if (is_array($term))" $term is an object so fails this test and falls through to line 590

// A 'Single select' field returns the term id.
elseif ($term) {
$taxonomy[$term] = taxonomy_get_term($term);
}

"elseif ($term)" returns true as $term is not null, it's an object. Hence the next line throws a fit. I've patched 578 to be:

if (is_array($term) || is_object($term)) {

so it processes both now and this seems to fix the error.

malc_b,

Your fix does indeed hide the errors, unfortunately I get erroneous behaviour.

If I make changes to an items taxonomy, then hit preview, my changes are reset.

------------Added After More Testing-------------

For me it appears to be the module "Node Form Rearrange" that is triggering the error. When I disable it things work properly.

Additionally, in the preview page with errors, any re-arranging I have done is ignored, and the category fields are displayed under the title where they default.

When adding the is_object as suggested above, the errors are no longer displayed, but this movement of fields to their default location does happen.

Drupal 6.10, Node Form Rearrange 6.x-1.0

I'm not using module "Node Form Rearrange" so that can't be my error.

I tried this patch in 6.10 version, but it didn't get rid of the warnings. Is there a similar patch for taxonomy 6.10?

(edit: by "this patch" i mean the one from comment #33. )

Here are my installed modules:

Colorpicker
Colorpicker Widget
Content
Content Copy
Filefield
Filefield Meta
Imagefield
Option Widgets
Text
ImageAPI
ImageAPI GD2
Imagecache
Imagecache UI
getID3
Global Redirect
MetaTags
Pathauto
PNGFix
Taxonomy Breadcrumb
Taxonomy Defaults
Thickbox
Token
JQuery Update
Dynamic Rendering
Wysiwyg
Views
Views UI

It looks like Nitobe was causing the issues for me.

Below is the body of a post I made in the post installation forum last night.

After reading this thread I disabled Nitobe theme and this solved the issue for me. No more errors when previewing posts.

I still have the site running on a local mamp server, with the taxonomy errors, if I can be of any help please let me know. I know nothing about coding, but am willing to help out how I can.

** original post from post install forum **

________________________________

Moved my local drupal site to remote server today. Everything was running fine - until I decided to turn on forums.

Now, anytime I try to preview a new story, or any content type with a taxonomy field I get the following error:

    * warning: Illegal offset type in isset or empty in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 1011.
    * warning: Illegal offset type in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 1012.
    * warning: Illegal offset type in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 1015.
    * warning: Illegal offset type in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 591.
    * warning: Illegal offset type in isset or empty in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 1011.
    * warning: Illegal offset type in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 1012.
    * warning: Illegal offset type in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 1015.
    * warning: Illegal offset type in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 591.
    * warning: Illegal offset type in isset or empty in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 1011.
    * warning: Illegal offset type in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 1012.
    * warning: Illegal offset type in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 1015.
    * warning: Illegal offset type in /home/baltimor/public_html/modules/taxonomy/taxonomy.module on line 591.

The content will still post and the taxonomy will update (I have a taxonomy list appearing in a side bar menu to categorize stories) - but this error message is driving me completely insane.

In addition to the vocabulary automatically created by enabling forums, I am only using 1 taxonomy vocabulary with a total of about 20 terms.

I am new to drupal and am teaching myself, but I have tested this site extensively before uploading. As I mentioned everything was running fine, on both the remote site as well as the local site on my computer, until I enabled the forums module.

Also, to test this I enabled forums on the local machine and am getting the same problem.

This is why I really believe that whatever broke started when I turned on forums.

But who knows.

Further more, on the remote site I disabled forums and deleted the automatically created taxonomy list but "forum topic" still shows up as a content type in my create content menu. It does not show up when I go to admin/content types.

I am running drupal 6.1.2 along with the following contributed modules:
calendar, captcha, cck, date, fckeditor, imce, poor mans cron, taxonomy menu, views, getid3, audio and token

All modules are up to date....

Any help with this would be greatly appreciated. I've worked so hard to get this thing up and I have no idea how to fix this, other than wiping the slate clean and building the site again from the ground up. (not as bad as it sounds, and if it comes down to it that is what I will do - - - but I would like to avoid it if at all possible)

:(

Patch http://drupal.org/node/275352#comment-1165929 did NOT solve the issue for me.

This patch does solve the issue,
http://drupal.org/files/issues/taxonomy-preview_terms_object_error-20081...

Modules:
Content 6.x-2.2
Content Taxonomy 6.x-1.0-beta6
Content Taxonomy Options 6.x-1.0-beta6
Views 6.x-2.5
Views UI 6.x-2.5
Taxonomy 6.10

I've attached a patch which fixes the issue. When previewing, it checks if the term is already an object. If it is, we can safely assume it has already been converted and we'll bypass taxonomy_get_term().

Here's a patch against HEAD

Here's a patch against HEAD that should work with the test bot!

This bug seems to be related for those who have Content Taxonomy installed, http://drupal.org/node/391906

Same error, using Nitobe and disabling it (or switching to another theme) works.

Unfortunately, I really like and need to use Nitobe-- I'm not familiar with patching core, like taxonomy, but heard it's not good to patch core if we can help it?

As a temp work-around, is there a way to disable previewing of new content? I found preview settings at admin/content/node-settings but didn't see an option for disabling previews altogether. I did apply the replacement code Shannon put up here (thx!), but unfortunately it broke my site/block formatting so I can't really use it.

thx KV

Although I was concerned about patching core (not being that experienced), this 2nd patch above did solve it for me as well when using the Nitobe theme. thx KV

That patch is a bit of a hack. It sounds more logical to fix the caller. If we insist on proceeding with this patch (which I don't encourage we do), we should update the documentation to reflex this change.

A quick grep through my drupal's source code shows that both taxonomy_link and taxonomy_preview_terms are not called in any external modules, so identifying the caller is harder than it seems.

To get this bug fixed properly, we need to be able to replicate it. Everyone that has an interest in getting this bug fixed (Nitobe users excepted, as you already have your fix) should try and replicate this with a fresh install of Drupal in the minimum number of steps possible.

Post your findings, anyone who can replicate the bug (in any number of steps) gets massive karma!

I spent hours trying to track it - but wherever it happened was behind way to many magically-named, nested and layered hook callbacks for me to trace. I did not have Nitobe.
As I said above, I don't think it's unreasonable for a robust API to do a few assertions to to validate that the input it's been given won't cause pain just because it got a zero instead of a number > 1.

I know that all input from third-party modules is assumed to be perfect all the time in Drupal ... but as we can see ... mysterious things can go wrong. And as much as I'd also eliminate the cause this time - I'm also in favour of something that will stop it happening again.
If I had the chance I'd sprinkle a few more judicious assertions in other places too, specifically to trigger a warning - not death - when FAPI gets a value where it assumed an array would be. But that's dreaming, I know.

Also having this problem. When I create a node then select 'preview' it throws out: -

* warning: Illegal offset type in isset or empty in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1015.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1016.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1019.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 592.
* warning: Illegal offset type in isset or empty in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1015.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1016.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1019.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 592.
* warning: Illegal offset type in isset or empty in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1015.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1016.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1019.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 592.
* warning: Illegal offset type in isset or empty in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1015.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1016.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 1019.
* warning: Illegal offset type in /home/mainwebpr1/public_html/proto/modules/taxonomy/taxonomy.module on line 592.

This first needs steps to reproduce (other than with a buggy theme), then the patch should come with a test.

I have reproduced this bug with a single module!

Taxonomy 6.12

Combined with the core modules:

Block 6.12
Filter 6.12
Node 6.12
System 6.12
User 6.12

I think what is happening is not an error in the code or module interaction, it is database ghosts that are being picked up and not handled properly by the Taxonomy module.

There was error: warnings: «Illegal offset type...»
This have been solved by this patch: http://drupal.org/files/issues/taxonomy-preview_terms_object_error-20081...
----------------------------
Tested on:
Drupal 6.13
CCK 2.4
Views 2.6
----------------------------
Subscribing…

Regarding the patch, how do i apply it to my copy of Drupal?

Update: While i'm still not sure how to apply a patch, i took the code in the patch and made the relevant changes myself in the module. The error message is now gone.

you may want to check the Applying patches page

:) @TomSherlock #66
Going off topic a bit but..

Patching it by hand a few times is a great learning experience, and will give you more confidence about learning the tools that automate the process.
I think it's great that anyone should learn what a patch is, what it looks like and what it does - in real terms - before learning the tools and commands that you can use to use them. I think that will overcome a heap of the resistance or learning curve for many coders.

Thanks for the fix.

Some users are running into this on a complex site with several taxonomy related modules installed, and I'm having trouble reproducing it. The following errors are triggered when new forum nodes are being previewed by a small number of users under as yet unknown circumstances:

• warning: Illegal offset type in isset or empty in /var/www/drupal/modules/taxonomy/taxonomy.module on line 1039.
• warning: Illegal offset type in /var/www/drupal/modules/taxonomy/taxonomy.module on line 1040.
• warning: Illegal offset type in /var/www/drupal/modules/taxonomy/taxonomy.module on line 1043.
• warning: Illegal offset type in /var/www/drupal/modules/taxonomy/taxonomy.module on line 607.

I realise that this is probably caused by one of the taxonomy related modules, but tracking down exactly which one seems impossible if I can't actually reproduce it myself.