It’s an intermittent, but repeatable, error. It seems to alternate between (at least) two pages, both of which fetch the same data from the same relationship field of the same weblog entry. Clearing the relationship cache seems to fix it temporarily, but the problem will crop up again a couple of pageviews later.

I just upgraded EE from 1.6.3 to 1.6.4.

Stumped.

Hi, KKCJ - are you running any extensions?

Yes’m. How would you like me to list the extensions - alphabetical, random, or over easy? Would you like a side helping of plugins and modules with that?

Extensions:
Advanced Captcha (v.1.0.2)
Tag Submit (v.2.5.0)
LG TinyMCE (v.1.3.1)

EDIT: I have confirmed a way to recreate this problem (on my site, at least). The related_entry code is displayed on two separate templates / pages. After I clear the cached relationship entries, whichever page I access first is fine, while the second page accessed will display the {REL[###]....REL} error.

EDIT 2: I have disabled all extensions and the problem still occurs. Further testing has revealed that it seems to allow the first fetch of the related entries’ fields successfully, but every attempt to fetch those same fields on any other template page afterwards results in the REL error.

In case it makes any difference, this problem is on a live site, so…

What types of caching do you have employed on the site? And did you repair/optimize the tables after the update?

I did optimize the tables during the upgrade script.

Where would I check on the different types of caching?

Did you repair as well? Now would be a good time to do that, which you can do in the SQL Manager.

The different types of caching are described here, with locations:

http://expressionengine.com/docs/general/caching.html

Repair’s complete - all was and is “OK”.

Caching:

- SQL Query Caching: On
- Tag Caching: Not on any involved tags
- Template Caching: Not on any involved templates
- Dynamic Weblog Query Caching: No
- Query Disabling: On one of the exp:weblog:entries tag that contains the related entries tag, I have ‘disable=“categories|member_data|pagination|trackbacks”’. But on another template where the problem also shows up (depending on which is viewed first after clearing the cache, as stated above), I am not disabling anything at all.

And the first to load after clearing cache keeps working fine?  All the others don’t.  And that’s if they’re identical tags, correct?

Hm- are you saving templates as text files?  Blast- this is making no sense.  Do me a favor- paste a tag that borks.  I want to see if I can duplicate on my site.  To duplicate- I put the exact same tag on two templates, clear cached data, load one up- and I’d expect the other template to bork?

First to load after clearing the cache loads fine, the next doesn’t. And they remain that way, even in different browsers - until the cache is reset (by a weblog entry being posted or manual cache clearing).

I’m not saving templates as text files, no.

The funny thing is, each of those two pages pulls the latest entry from a specified weblog. When I view the multi-entry page for that weblog, the first (latest) entry’s related_entry title is corrupted, while the rest of the listing is fine. It’s as if somehow, the cache for that most recent entry’s related_entries title is getting corrupted on the other pages… somehow…

Would it be simpler to PM you CP access?

We generally save login for a last result.  Let me see if I can replicate the issue on my install.  Seems very odd.  I just don’t get why it’s borking this way.

OK- this one was very odd and very hard to trigger, but we tracked down the problem to the Tag module- specifically the _db_charset_switch function.  It was interfering with the related data serialized array and causing an unserialize error in mod.weblog.php around line 440:

Remember when you asked if it could be due to odd characters in the text and I said ‘no’?  I was wrong.  So- when you make a bug report to the Solspace forum, that’s an important element in what goes wrong.

What I’ve done for a short term fix is comment out most of the calls to _db_charset_switch in system/modules/tag/mod.tag.php.  Now you’re not getting the funky markers showing instead of the code- so ‘yay’!

However, for a long term fix, you’ll want to report this to the Solspace crew and likely link back to this thread.  It really is an odd quirk, and hard to replicate.

But it boils down to that function interfering with the serialized array when it contains high ascii characters.

Make sense?

Oy! What a headache.

Ironically, I’ve been dealing with another (unrelated?) issue with SolSpace regarding the tag module - specifically, the lack of support for tags with quotation marks or apostrophes in them. I kept on getting a “Disallowed Key Characters” error when I’d try to view a tag like “Eagle’s Wings”. They eventually tracked it down to a “problem” with the listed characters in system/core/core.input.php - adding in a “\`” to the “if ( ! ereg(”^[A-Za-z0-9\:\_\/\-]+$”, $str))” line allowed me to have tags named “Eagle`s Wings”.

So, you found a problem with their code, and meanwhile they found a problem (?) with yours. It’s almost poetic justice…

EDIT: Bug report filed.

Thanks for letting us know. You’re all good now? Any other unresolved issues?

Nothing that should find a warm and loving home in this thread. I like keeping thread content relevant to the titles just as much as y’all do.

That’s the spirit Well, you know where to find us in case you should need more help…