I had to debug our TLC website this morning, as it was pointed out to me that parts were misbehaving, and that some content hadn’t survived the upgrade from Drupal 4.7 to Drupal 5.2. The missing content was easy, for the most part. It’s just a matter of renaming the tables to use the content_TABLE format expected by the current CCK module. The exact table names that are expected are listed in the node_type table, under the “orig_type” field – just prepend “content_” to the “orig_type” value for the table name, and CCK should find everything just fine.
One of the CCK content types used the weburl field type under Drupal 4.7, but this has apparently been replaced by “link” in Drupal 5’s version of CCK. That’s fine, I’ll just swap out the data. Shouldn’t be too bad.
What got puzzling, though, was that after switching to link, I was getting segmentation faults on the webserver every time I tried to view, save, or template a CCK content type containing a link. WTF? At first, I didn’t make the connection that it was link that was causing problems. Eventually, I created a “test” CCK content type, containing the same fields as the offending content type (every time I tried to view anything in our “Simple Resource” content type, hell was unleashed). I reproduced the same set of fields, and BOOM, Simple Resource was also bringing down the server. So, I started removing fields. Didn’t take long, since the content type had a total of 2 fields. I started with the Link field. And the content saved, viewed, and templated just fine.
AHAH! It’s something wrong with Link! Maybe it’s trying to validate the URL? Maybe it’s trying to download the content at the other end of the URL to do some processing?
Nope. Turns out, Link may use the token.module to parse out bits of the URL. But token.module was getting caught in a recursive loop. I had to install token.module to support the current version of pathauto.module – I need that, so I can’t disable token.module. Turns out, there’s an easy way to avoid this recursion-killing-the-webserver segmentation fault problem. In the CCK definition for the link field, just uncheck the “Allow Tokens” option. Yeah. It’s that easy. But it took me all frigging morning to figure out what the problem was, and about 5 seconds to fix it once it was identified.
Links that were useful in diagnosing and solving this:
- Infinite Loop with Link + Token
- content_view() not recursive safe
- Token module causes segmentation fault (this was the solution – see comment #4 on that page)
Had a very similar experience with the image module — infinite recursion. I actually debugged it to the source looking at the stack and wrote a patch. Hopefully they’ll commit it. It is seeming as things get more complicated, there is a lot more code floating around that has not been tested all that well.
and it’s complete and utter hell to debug. somewhere, in the mix of modules and core code, something is going wrong. somehow. now, fix it. oy…
The current stable version of Pathauto is actually 5.x-1.2 and it does not require the Tokens module. I know that the beta of 5.x-2.0 is marked as rekommended, but it’s more buggy and less stable. There’s really no big need to switch to 2.0 yet for most people, afaik.
patches welcome.
i’ve actually been a bit irritated with the token/pathauto switch. i did it on a site or two, but have been using the current stable on everything else. at least i didn’t get segfaults…
@justin – that’s why it’s the beta version. you don’t have to update just because update status tells you to.
@dnorman – it appears that the problem was in that unimplemented recursive check. I’ve now applied that patch to the dev release. pending another patch I need to get in there I’ll be releasing that as the stable version of token today.
Gawd I can’t tell you how many irritating encounters I’ve had with this bug – I was about to commit a patch to token.module but I’m too irritated with it to do that right now 🙁 thanks for your assistance though! 🙂