taxonomy_get_term() bug when adding terms

works for me, 5.0 beta 1

Sorry for being not clear. Here is what I did, on a 5.0 beta 1 install:
Administer > Content Management > Categories
Add a new Category with no hierarchy and multi select, and all nodes.
Add a new term to that category.

No errors or warnings. Check logs, nothing their either.

I think we are using different versions. You are using the cvs, and I am using the beta, so that might be why there are different results. The cvs changes on a regular basis, so that bug may be there because someone was in the middle of some code they were working on, or something. My original post was to inform that the bug was not in the beta release.
I don't really know though. This is my guess. I'm gona have to leave it up to you to figure out the version.

I am going to set the version as 5.0-beta1 (it is asking me to set the version), and then I will set the issue as closed. Please reopen the issue under your version. Sorry for the confusion.

Illegal offset type in isset Drupal 5.0 beta

I get the same error on the latest D.5 beta + D.5 modules

After posting a story, with or without taxonomy items selected, I get the error below. The story posts and if I did apply taxonomy selections the appear on the story.

Adding a new story without taxonomy selections produces this:

warning: Illegal offset type in isset or empty in /var/www/5zebra/modules/taxonomy/taxonomy.module on line 1087.
warning: Illegal offset type in /var/www/5zebra/modules/taxonomy/taxonomy.module on line 1088.
warning: Illegal offset type in /var/www/5zebra/modules/taxonomy/taxonomy.module on line 1091.

(This my localhost test site)
I did a clean install from the 5 beta installation, enabeld modules, added one user other than admin, created roles, set PHP.ini memory limit to 128Mb, set default input type=Full HTML, created a taxonomy category with the name "zebra research", "admin/content/taxonomy/edit/vocabulary/1" settings: Set Type=story | Hierarchy=Multiple | Multiple Select=On | all other options = blank, added 11 terms, got error on very first addition of story.

Environment: Clean URL's, Apache 2.0, PHP 5.1.6, MySQL 5.0.24, Memory Limit 128Mb

List of enabled 5.0 modules:

Book, Color, Comment, Help, Menu, Search, Statistics, Taxonomy, Tracker, Upload, Block, Filter, Node, System, User, Watchdog, Texy, BBCode, Clean Module, Focus, Greybox, Panels, PathAuto, Slideshow, Views, Views Bonus Pack, Views Theme Wizard, Views UI

Editing an existing story and reposting it produces more error messages, dependent on the number of taxonomy selections:

Enabling four new selections on an existing story produces this:
warning: Illegal offset type in isset or empty in /var/www/5zebra/modules/taxonomy/taxonomy.module on line 1087.
warning: Illegal offset type in /var/www/5zebra/modules/taxonomy/taxonomy.module on line 1088.
warning: Illegal offset type in /var/www/5zebra/modules/taxonomy/taxonomy.module on line 1091.
warning: Illegal offset type in isset or empty in /var/www/5zebra/modules/taxonomy/taxonomy.module on line 1087.
warning: Illegal offset type in /var/www/5zebra/modules/taxonomy/taxonomy.module on line 1088.
warning: Illegal offset type in /var/www/5zebra/modules/taxonomy/taxonomy.module on line 1091.

Running CRON.PHP has no effect on these errors.

I am going to set the version as 5.0-beta1 (it is asking me to set the version), and then I will set the issue as closed.

No, maybe not so fast... This issue has been set to closed and I don't know if I am supposed to change this back to an active issue or whether to start a new thread, and in any case these issues are BUGS! in anyone else's language, but I sure as hell experience this bug on the latest Drupal 5 beta downloaded on 12/11/2006!

You might as well try the dev release to check if this has been fixed.
At this point development is only bug fixes for the next beta and nothing else.

I believe this is actually a pathauto problem...

I've noticed it for a while now as well, but didn't take the time to investigate. Now that I know the source I will put more effort into fixing it.

Can the other people who have confirmed this bug also confirm that they are using pathauto? Further, can you confirm that the problem goes away if/when you disable pathauto?

And if someone else can confirm it to pathauto, then please change the project/version/component appropriately.

this is now 80% to be not core...

It may not be core, but that doesn't justify changing the priority just so it stays out of the "critical issues" list.

I have reported the same issue

against pathauto: http://drupal.org/node/98510
against core: http://drupal.org/node/98443

I apologize for not seeing this was already filed.

Testing confirmed:

This still exists in D5.0 Development as off 27/11/2006
This is a path-auto issue that only appears with pathauto turned on

I ran into the same problem with a CVS HEAD instance of Drupal w/ pathauto running and free tagging on in taxonomy.

It looks like the problem is in the function node_get_placeholders (the taxonomy part of the function) in pathauto_node.inc. $firsttermid is sometimes an array.

A provisional patch that at least removed the errors for me is attached.

The taxonomy bulk update needs to be patched as well, as it doesn't considers the term as an array.
The attached patch includes both fixes in pathauto_node.inc and pathauto_taxonomy.inc.

just confirming the same problem with 5.0-beta2 and the problem goes away if pathauto is disabled.

I can confirm this issue using the latest 5.x-1.x-dev and the dev build of Pathauto. Can someone confirm that the above patch fixes the issue or does it simply eliminate the error message (but not fix the bug)? Thanks!

I just updated my site to have this version of the pathauto module, and it fixes the issues I saw. It was the error message and the side effects of throwing the error that was the bug. I just tested posting two blog entries, one with new category terms, and one with existing category terms, and both worked fine.

My vote is that it's fixed.

To make it clear, I installed the 5.x-1.x-dev version of pathauto. Otherwise my site is 5beta2

Whoops, I need to be more careful. I thought I had the standard taxonomy.module.

With 5.x-1.x-dev the taxonomy_get_term function is being called with this as $tid:

a:1:{i:2;s:16:"Testing, stealth";}

The "testing, stealth" is the text I entered into the categories field on my posting. This is a "Free Tagging" category, if that makes any difference.

So anyway, earlier I voted "Fixed" but now I have to say "Still a problem in 5beta2".

I've attached a patch which I believe fixes these problems when creating a node.

It doesn't (yet) address the error when creating a new term. As you can see, this is considerably more complex than the suggestions in #15 and #16.

We have a couple of problems here all in the same area, so I wanted to address them all. Basically, this is a possible array for $node->taxonomy:

Array
(
    [3] => 3
    [2] => Array
        (
            [1] => 1
            [2] => 2
        )

    [tags] => Array
        (
            [4] => freeheavy, freeheavy2, freeheavy3, "freetag, with a comma in it"
            [1] => freesuperheavystillontop
        )

)

In that above array, the first element ([3]) is a simple single select taxonomy that is not nested. The possible values for this are a number (tid) or a 0 if no value is selected.

[2] is a multiple select vocabulary which is an array and can have elements where the key=value=tid or it can have a [0]=>0 value

The [tags] is made of two freetagging vocabularies. [4] is a lower weight freetagging vocabulary than 1. Also note the complexity of possible "tags" in the freetagging where they can have commas inside of quotes which is part of the tag.

Heierarchies, at least in terms of the structure of $node->taxonomy, do not get represented in any different manner. So the term represented by [2][2] could actually be a child of a different term.

So, given all that, I would appreciate it if people could test this patch.

How to Test:

1. duplicate the problem of adding a node and seeing the error messages about illegal offset type
2. Apply the patch to your pathauto_node.inc (see http://drupal.org/node/60108 for details)
3. See if the error messages go away AND if the [cat] pattern is substituted properly when adding nodes

This patch is not an attempt to fix the error messages NOR the lack of aliases for adding terms to vocabularies. Those will come shortly :)

Thanks to everyone who has confirmed this error. Now if we can get some good tests on this patch we'll be on our way to a solid Drupal5 release of Pathauto.

heh. with patch.

I can confirm that the patch has fixed the error issue for me when adding a new node. I tested an image node and a blog node. Both of which did not have an error. I then attempted to change the settings on the Pathauto settings page and received the following errors:

    * The configuration options have been saved.
    * Bulk update of nodes completed, 10 aliases generated.
    * Bulk update of terms completed, 35 aliases generated.
    * Bulk update of index aliases completed, 0 aliases generated.

    * warning: Invalid argument supplied for foreach() in /home/themacge/public_html/welcome/sites/all/modules/pathauto/pathauto_node.inc on line 168.
    * warning: Invalid argument supplied for foreach() in /home/themacge/public_html/welcome/sites/all/modules/pathauto/pathauto_node.inc on line 168.
    * warning: Invalid argument supplied for foreach() in /home/themacge/public_html/welcome/sites/all/modules/pathauto/pathauto_node.inc on line 168.
    * warning: Invalid argument supplied for foreach() in /home/themacge/public_html/welcome/sites/all/modules/pathauto/pathauto_node.inc on line 168.
    * warning: Invalid argument supplied for foreach() in /home/themacge/public_html/welcome/sites/all/modules/pathauto/pathauto_node.inc on line 168.
    * warning: Invalid argument supplied for foreach() in /home/themacge/public_html/welcome/sites/all/modules/pathauto/pathauto_node.inc on line 168.
    * warning: Invalid argument supplied for foreach() in /home/themacge/public_html/welcome/sites/all/modules/pathauto/pathauto_node.inc on line 168.
    * warning: Invalid argument supplied for foreach() in /home/themacge/public_html/welcome/sites/all/modules/pathauto/pathauto_node.inc on line 168.

Addtionally, it does not appear as though [cat] or [catpath] are working in the path generation.

I am using the HEAD version of Drupal and the 5.x-1.x-dev version of pathauto.

Forgive me if I have addressed something that is not part of this patch. I am still getting my bug testing feet wet. Let me know if I can provide more helpful info. I would also be will willing to open up my site config to a dev to check out my configuration.

I tried the previous patch, but I got several syntax errors. The attached patch works for me, I also cleaned up some code.

Reverted back to the Head installed and applied the pathauto.patch_0.txt but still experiencing several different errors .. going to back up and try a clean install with pathauto as the only addon module to see what happens .. will report back here my findings.

@themacgeek - the problem you described in #24 is only when doing a bulkupdate at the same time as saving the settings. The code I just added assumes that the tags are in the form I showed in #22 which may not always be the case.

@stefano73 - thanks for your modified patch. I see you also found the problem during the addition of terms. Can you explain why you used the $category->parent's first element instead of just the $category->tid? What kind of testing did you do (e.g. did you test with multiple selection terms, single selection terms, hierarchies, freetagging)? I didn't do much testing myself, so I'm just asking.

$parents = taxonomy_get_parents_all(array_shift($category->parent));

I made this change to avoid errors when adding new forums. In the forum form the parent is set as array:

$form['parent']['#tree'] = TRUE;
$form['parent'][0] = _forum_parent_select($edit['tid'], t('Parent'), 'container');

so $category->parent is an array having the tid as first element.

A new patch might include the evaluation of $category->parent: if it's an array you pick the first element as tid, otherwise you use $category->parent.

@stefano - thanks for the information. I believe it always is an array, but my question was about the use of \

array_shift($category->parent) vs. $category->tid

If you have any feeling on that or if you did any testing of $category->parent beyond forums let me know. Otherwise I'll assume it "just worked" for forums and that was good enough.

Thanks again.

If you use $category->tid when $category->parent is set, you get a wrong alias for the forum.

When I do a node_save(), I'm not getting an alias per the node_settings. I'm only getting a [title]. The node setting is [vocab]/[catpath]/[title]. This is with the latest patch as posted here.

Byte

It looks like on a node_save, its only passing the selected values from the node form.

taxonomy = Array [2]
1 = (string:1) 0
2 = (string:1) 7

Instead of an array of term objects, each one having $term->vid (vocabulary id) $term->tid (term id) $term->name (name of term)

Byte

subscribing

The attached patch creates the correct alias as in #31.

I can confirm that the patch allows for creating content with the given taxonomy. But - creating new items in the taxonomies still gives the error - and - I also see it in creating forums and containers (since they are really taxonomies too). This running on drupal 5.0-rc1.

So - with pathauto enabled you (well I) still see it for anything that changes the taxonomies in the system - although content creation is OK.

Confirming this bug. After applying latest patch, i still get:

* warning: Illegal offset type in /home/xx/www/modules/taxonomy/taxonomy.module on line 1088.
* warning: Illegal offset type in /home/xx/www/modules/taxonomy/taxonomy.module on line 1089.
* warning: Illegal offset type in /home/xx/www/modules/taxonomy/taxonomy.module on line 1092.

(Which is about 2x less errors)

Btw. this bug should be blocker of releasing Drupal 5.0, because taxonomy + pathauto is so common setup...

I'd also like to confirm that creating a new forum node (i.e., creating a new forum container) causes this error:

* warning: Illegal offset type in isset or empty in .../public_html/modules/taxonomy/taxonomy.module on line 1088.
* warning: Illegal offset type in .../public_html/modules/taxonomy/taxonomy.module on line 1089.
* warning: Illegal offset type in .../public_html/modules/taxonomy/taxonomy.module on line 1092.

I am running the Drupal 5 RC1 version with pathauto activated.

I just tried a fresh installation of current CVS version and made a new patch for this bug. The attached patch works good for me: it creates correct url aliases for taxonomy terms (term lists and free tags), forum topics and nodes.

Should i add this patch to the first one or is this one combined from both?

My last patch is against the latest CVS version, without previous patches.

I've tested the patch on comment #38 and I think that we've finally got something which works pretty well.

I noticed that when creating a new forum you will get an alias for taxonomy/term/tid to be aliased to the correct path, but you don't get one for the forum/tid alias. This seems to be a slight regression from the 4.7 version of the module, though I'm not sure where those were/are being created.

I'm not sure the regression is related to this patch or outside, so perhaps we should commit this and move on.

Can anyone else please test this latest patch and see how it works for them?

Thanks.

Hi, I got the same bug issued here to date, i had to spend many hours to find out its to do with pathaouto.module (because the errors indicates the taxonomy.module raher than the pathauto) eventually i found this issue.

system Drupal 5 RC1
pathauto.module: 5.x-1.x-dev

just let you know that the errors still exist

-difficult to follow the latest changes below and did not applied any patch

after turning off pathauto.module the errors gone, also i noticed the site got a lot faster that indicates the module slows down the site extremely

With a clean install of RC-1 I applied the "pathauto.patch_2.txt" and the error messages after posting a page have been resolved.

Thanks,
kenc

Great, thanks for the review kcolwell.

Can you also confirm that the functionality of your site & pathauto are as you expect?

If nobody has any problems I'll probably apply this today. There are a couple of other issues I'd like to get resolved and then we can have a Pathauto5.x-beta tag/release for folks to really test.

#38 has quite a few code style issues.

Just a few things that I noticed:
- Comments should be in the form "// This is a comment.", on their own lines most of the time
- Need to rename $firsttermid to $first_term_id (even though the original was name that)
- Tabs in there and other spacing issues.

Thanks for the review, RobRoy.

Here's an updated version. If you see any more problems please either re-roll it or point out line numbers.

I am having the same problem with 4.7.4 using the Nov 20th install of getting only the [title] for nodes instead of [vocab]/([cat]or[catpath]or[catalias])/[title]. When I do a bulk update it works fine but not on node creation.

Has anyone seen this on 4.7 or have a patch for this? This is a big hold up for me so anyone that has any suggestion would be great!

Thanks!

I can confirm this patch does fix the issue!

I can confirm the patch works, too.

Confirmed that this applies cleanly and fixes the problem.

I also confirm that this patch does the trick :D

thanks

Great, applied. Thanks everyone for helping with the writing, reviewing, and testing of this patch.

I think this is fixed the issue of creating a path when first submitting an article. So, it does pull the [cat] in the path and uses the lowest weighted term when submitting an article. However, when I do a bulk update to pathauto it changes the paths. Seems to only use 'free-tagging' terms and ignores other vocab types. So now paths are [freetag]/title and if no free tag associated but other vocab it just uses /[title]. Any ideas???

@pshadow are you sure that this is a regression related to this patch or do you think the problem you describe is just a new problem?

I installed pathauto 3 days ago after upgrading to 5. At which time if I enter an article it would ignore the [cat] in the path when creating the url. so example.com/[title], but when I did a bulk pathauto update the urls would be corrected to use [cat] so example.com/[cat]/[title].

I downloaded this new version today and the opposite is now happening. upon adding an article it gives me example.com/[cat]/[title] but when I do bulk update it gives me example.com/[title]. And if after a bulk update I edit a post, it reverts back to the intended url string, added the [cat] back in.

So basically if I want my configuations to take on the bulk update I have to use the pre 17th file, then switch back to yesterday's updated files to for it work correctly upon inserting new articles today.

Sorry for another post but some clarification on how it is working since patch. Worked fine before patch on bulk update.

I have two vocabs - topic (fixed list) and tags (free tagging). On adding post it correclty assigns [cat] from the topic list (weighted lower -1). On bulk it seems to do the following now.

If free tag available it will assign [cat] the first free tag. example.com/free-tag/title
If no free tag and one topic it will assign NO [cat]. example.com/title
If no free-tag and 2 topic vocabs it will assign [cat] the second in alphabetical order. example.com/topic2/title

Perhaps this is a new problem but it didn't exist before yesterday's updates and seems directly related. Should this be a new bug? And where can I get a copy of the files prior to yesterday's update. Would like to reinstall older version but accidently copied over them.

I traced this back to a string comparison issue, patched, and tested.
Let me know if this works for you all, too.
cross-posted with http://drupal.org/node/110621

thanks, this looks to have fixed the issue for me.

I tried applying this patch, but got the following. (Note: tried a dry-run first just to test)

azavia@ebers [~/public_html/spiritmagick/modules/pathauto]# patch --dry-run --verbose < ../pathauto_15.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|Index: pathauto_node.inc
|===================================================================
|RCS file: /cvs/drupal-contrib/contributions/modules/pathauto/pathauto_node.inc,v
|retrieving revision 1.29.2.2
|diff -u -p -r1.29.2.2 pathauto_node.inc
|--- pathauto_node.inc 17 Jan 2007 16:53:41 -0000 1.29.2.2
|+++ pathauto_node.inc 19 Jan 2007 23:20:52 -0000
--------------------------
Patching file pathauto_node.inc using Plan A...
Hunk #1 FAILED at 159.
1 out of 1 hunk FAILED -- saving rejects to file pathauto_node.inc.rej
done
azavia@ebers [~/public_html/spiritmagick/modules/pathauto]#

@devbanana - this patch is so short, just apply it by hand.

@pshadow and @csevb10 @devbanana - I get the same behavior regardless of whether I apply this patch or not, which is to say that bulk updates and individual updates all work fine. So...I'm more than a little confused about what makes it work on my system (recent XAMPP installation) as compared to your systems. Any ideas?

Can anyone else who has been testing this patch confirm/deny the behavior?

Actualy, I think the reason it's failing is that the code it is looking for to change isn't there. I have the snapshot from january 18, so maybe that's why?

My problem from the originally reported has changed. it used to be that bulk update didn't work, but it turns out that was an oddity that happened when it came across a node moved by comment_mover. I deleted that and now bulk update works. But now editing a node cuts out the catpath from the URL, as reported by someone in a comment in this issue I believe.

devbanana, yes, please update to the latest versions of pathauto prior to testing/applying patches. that's almost always a good first step when you find a problem (though I know January 18th isn't exactly a long time ago)

A fun puzzle. Testing the behavior of the non-patched comparison in both php4 and php5 I found that:

- $key is numeric. It runs 0,1,2,3.... etc
- In ($key == 'tags'), the 'tags' string becomes numeric (==0).
- So, ($key == 'tags') returns true only (and always) for the first array element (the one with $key==0), whichever it is. If it happens to be the one with the 'tags' key... so much the better.

No... ignore the above. I had oversimplified my test case.

Not sure why this is an issue for me and not others. A little scary... I tried again installing the last build from the 20th (today) and bulk update doesn't pull in the tags properly. But applying the patch again and it works.

Does your content have two vocabs assigned to the content type? One single hierachy, multiselect, and required. And one free-tagging optional?

Hi,

I have the latest snapshot, and the patch cannot be applied. The code the patch says it is replacing is nothing like the actual code in the pathauto_node.inc file.

pshadow, for testing purposes I use the following:

one freetagging with low weight, one freetagging with heavy weight
one single select
one multiselect

All of them are optional. The single select is lower weight than the multiselect.

I tried several combinations of values when editing the node and then I changed the pattern for my aliases and bulkupdate and change the pattern again and bulkupdate again.

One thing I'm realizing I need to do is create a list of tests that should be run for an "official" release of pathauto. Ideally I'd like to automate them with something like selenium and make it possible for others to quickly perform the tests (since this seems to be an intermittent bug).

CogRusty - your investigation got me thinking. Perhaps another solution would just be to use === ?

What I tested was not real.

I just ripped off that chunk of code and used a mockup $node->taxonomy array which didn't have explicit keys, so it got the numeric ones. When I added explicit keys to my mockup $node->taxonomy array then == did the string comparison ok.

I pulled the latest 5.0 snapshot for testing.
I ran each of the test as pshadow described, testing each case individually and deleting the generated path out of the url_alias between tests.
I was running a PHP 5 installation of XAMPP. (PHP 5.1.6)
I experienced the exact behavior that CogRusty detailed in #63.
Upon my testing, I found that, at least for my version of PHP, the tag comparison translated both values to integers for comparison.
'test' containing no leading integers was translated to 0, and therefore that case was always triggered first even if no free tags were present.

Oh, and just for the record, I tested using real data.
& I believe that you are right greggles.
Using === should have the same basic effect because it will compare the type first and fail.

@greggles (post #60): I can confirm that it did NOT make a difference (with or without csveb10's patch), as long as you make sure you are using revision 1.19.2.2 of pathauto_node.inc (link). Perhaps csveb10's patch is necessary for a very specific bug in a certain PHP version?

IMO Pathauto should get a new release ASAP, I've been having this issue for weeks!

@wim - you said 1.19 and linked to 1.29 - which are you saying is right? I assume you mean 1.29.2.2 and right now that same file is in both the 5.x-1.0 and the 5.x-1.x-DEV tarballs, so I'm not sure how a new release would help in some way.

@pshadow - can you confirm if the === idea would work on your system? It's hard for me to test/debug this problem since it's not consistent.

Thanks all.

@greggles: of course I meant 1.29.2.2, stupid typo. I had the 5.x-1.x-dev tarball installed and I did NOT have version 1.29.2.2 installed, but version 1.29.2.1:

// $Id: pathauto_node.inc,v 1.29.2.1 2006/12/11 15:44:46 greggles Exp $

the contents of -dev tarballs change. The current -dev tarball has 1.29.2.2 in it - I just confirmed that.

@greggles: ok, my bad, sorry for the confusion! I'm still new to the extensive patching and versioning system, but learning every day. Thanks.

Ok - I committed the === to the DRUPAL-5 branch. In a few hours the tar.gz for 5.x-1.x-dev.

Thanks csevb10.

pathauto was causing seemingly taxonomy to report warnings but when trying to translate (using localizer)

well the dev version of pathauto cleared all the warnings of this issue http://drupal.org/node/119079

thought I'd report it

Ooops I spoke too soon, the bug on previous comment is still on, (http://drupal.org/node/119079)

it involves taxonomy_get_term from taxonomy module (patched by localizer), pathauto and localizer,

sorry for spamming this issue but it sounds very similar, if anyone can give any help it would be greatly appreciated.

warning messages only appear when pathauto is enabled so theoretically could be a pathauto issue

Getting the same error when localizer and pathauto are enabled. The message goes away when I disable pathauto. The error appears when clicking to translate a node...this is when the a new node is created with a url alias.

Thnx.

Mojah - Please open a new issue for your problem.

I added a follow up here which seems to point to a simillar bug http://drupal.org/node/124701.
Thank you.

I am still getting this error when PUBLISHING a new node.

I can create the node - using WORKFLOW - no problems. on creation it is not published. When I try to publish it, I get this error:

warning: Illegal offset type in isset or empty in /htdocs/modules/taxonomy/taxonomy.module on line 1150.
warning: Illegal offset type in /htdocs/modules/taxonomy/taxonomy.module on line 1151.
warning: Illegal offset type in /htdocs/modules/taxonomy/taxonomy.module on line 1154.
: Object of class stdClass could not be converted to string in /htdocs/sites/all/modules/pathauto/pathauto_node.inc on line 223.

It looks like something is happening to the path when approving/publishing the node. The real path to the node is supposed to be:
www.xxx.com/vocab/cat/node-title BUT when approving it, it reverts to www.xxx.com/node-title

Every other time, it still takes you to the correct path.

I have installed the 5.X-1.2 verion and using 5.1 with php 5.2.1

Any suggestions?

I suggest you try out the issue and patch that are specific to your situation: http://drupal.org/node/123001

This issue (92900) is about the problem affecting every node creation. Your issue is with the case of using another module (e.g. workflow or leech or...) which has a slightly different format for the node data.

I have experienced this issue at my Drupal 5.2 using the following modules: Image 5.x-1.4 including Image_import and Pathauto 5.x-1.2 (which includes the patch given above, doesn't it?).

I was trying to import some images and assigning them to a taxonomy term which worked just fine for a while (mass import of images was successful, nodes were added, images uploaded, terms assigned to the nodes etc.). Then I added a new (5th) term to the vocabulary which I use to categorize images and (after using the term as a filter in views) experienced several errors (also after deleting this term again):

1) Image import does not work anymore. Every time I try to use it I'll get a blank page. Drupal creates a node for the first image in the row but does neither copy any images to files/images (my image folder) nor create thumbnails or anything.

2) Sometimes I experience the issue described here. My log gets filled with hundreds of entries: ...Illegal Offset Type...

Well I'm not really sure if my problem is really related to this issue but I couldn't find it described anywhere else and some symptoms seem to be similar.

Can anyone give advice what the source of my problem could be?
Thanks a lot!

@Morgenstern - while the symptom is the same your problem is 99% sure not the same problem.

Please open a new issue for your problem and we can debug it specifically.

I have opened a new issue at http://drupal.org/node/164591