$entry.body not always available

[Don Chambers]

I have observed an intermittent problem, revealed by my template Kinetic. I have verified this problem in 1.4, 1.4.1, and 1.5 alpha 2. Problem seems related to the extended properties for entries plugin.

Here is the problem: I have been informed by 2 sites that content normally displayed on the frontpage as {$entry.body} was not working. These sites had 2 things in common: They had a fresh install of s9y, and my template, and had never set the option to cache entries using this plugin to "yes/true".

On those sites, when I look at the contents of the $entry array, I see missing fields:

Code: Select all

properties => Array (5)
  ep_cache_body => "whatever.."
body => "whatever ..."
is_cached => true

Please note that I have suppressed the true content above with "whatever", the point is that these values exist in my sandbox.... but NOT in these other sites.

Now, if I DISABLE caching in the plugin on my sandbox, $entry.body (and everything else listed above) no longer exists.. and I encounter the same problem as these other sites. If I re-enable caching, the problem disappears.

HOWEVER, on these other sites, I cannot get $entry.body regardless of whether or not caching is enabled... all I know for sure is that caching has never been enabled on those sites.

The entries.tpl used for this is not radically different from anything else, and exists in nested loops as follows:

Code: Select all

{foreach from=$entries item="dategroup" name="dategroup_loop"}
    {foreach from=$dategroup.entries item="entry" name="entry_loop"}

The code used to fetch this template uses something like this:

Code: Select all

{serendipity_fetchPrintEntries limit="0,5" noCache="false" fetchDrafts=false full="false" use_footer="false" template="myentries.tpl"}

Deleting the plugin, and reinstalling it with its default values (which includes cache=true) solves the problem. Disabling caching will reveal the problem again, but enabling caching eliminates the problem AS LONG AS the plugin was FIRST configured to enable caching.

Any clues? I know caching entries via this plugin had led to numerous problems, but I really need a solution to this!

[garvinhicking]

Hi!

Do you use {serendipity_fetchPrintEntries} to load that template where {$entry.body} is not set? If yes, which exact options do you use for it? This might be due to noCache... or whatever command line options.

I'd love to help, but I need an installation where this happens to toy/debug with. I can't seem to be able to reproduce this on my sandbox. Any chance to get my fingers on such an install?

Regards,
Garvin

[Don Chambers]

Thanks Garvin. I replied via PM.

[Don Chambers]

The code was something like:

Code: Select all

{serendipity_fetchPrintEntries limit="0,5" noCache="false" fetchDrafts=false full="false" use_footer="false" template="myentries.tpl"}

Through trial and error, the problem initially seemed to be full="false".. without it, no problem, with it - failure.

Upon further investigation though, its the quotes causing the problem. Quite frankly, I don't even need all those parameters=false at all, because that appears to be the default for each of them if unspecified.

[garvinhicking]

Hi!

LOL. Of course. "full" actuall means "fetch the entry body". So its more of a bug, that it worked when caching was enabled.

Best regards,
Garvin

[Don Chambers]

Garvin - I thought full=false only fetches entry body, while full=true fetches both body and extended body.... at least according to the docs:

full
(boolean)
Indicates if the full entry will be fetched (body+extended: TRUE),
or only the body (FALSE).

[garvinhicking]

Hi!

Which URL documents this exactly? It needs to be changed, because "full=true" means "fetch the full article" whereas "full=false" means "only fetch required metadata of an entry".

full=false is usually only used for places like in the admin entry overview, where you DON't need any body information about an article.

Regards,
Garvin

[Don Chambers]

Hi!

Which URL documents this exactly? It needs to be changed, because "full=true" means "fetch the full article" whereas "full=false" means "only fetch required metadata of an entry".

full=false is usually only used for places like in the admin entry overview, where you DON't need any body information about an article.

Regards,
Garvin

URL to doc is here: http://www.s9y.org/78.html#A2

However, it DOES seem to work that way - body IS available with full=false.. what was not working, with caching disabled, was full="false" (quoted).