Serendipity Forums

Playing with the aggregator plugin, I've noticed a number of differences in the $entries array for locally created entries, and those created as a result of aggregating. Please note that my test was performed on 2 sandbox (localhost) installations, but both are running the identical 1.3branch release and my own personal template.

I'll try not to complicate things for now as I have a 2-dimension comparison. The first is what the $entries array looks like when on a detailed page view vs. a fetchprintentries view, and the second dimension is comparing the original entry against its aggregated "copy".

Here are the observations:

The most critcal is that $entry.body and $entry.extended do not exist in the aggregated entry when viewing via fetchprintentries. These fields DO exist in the detailed entry view, as well as the source entry (ie, the site I am aggregating FROM) when using fetchprintentries.

Additional fields that do not exist for an aggregated entry regardless of view (fetchprintentries, or normal overview/detailed):

• is_cached => true
  has_extended => true
  has_comments => true
  label_comments => "Comments"
  has_trackbacks => true
  label_trackbacks => "Trackbacks"

I should point out that when I aggregated the entries, I disallowed comments to the aggregated entry, should that matter.

Less troublesome for me, but something I noticed, is that the original source entry has the following fields, but they do not exist in the aggregated entry in detailed entry view:

• add_footer => null
  is_extended => true

The solution for most of this is to edit the aggregated entry and save it... but that is not an optimal solution.

So..... what do we need to do to resolve this?

Hi!

That's normal because aggregated entries never have extended bodies. The comment/tb labels are missing because those entries do not have comments, as per your config.

HTH,
Garvin

I can understand the lack of comment and trackback labels, but what about $entry.body?

Hi!

I can't reproduce that, would need access to such an installation. Which fetchentries call do you refer to? A custom one, or the one being used for entries.tpl in the default overview?

If custom one: Have you checked the $full option? With $full=false, no body/extended fields will be fetched.

Regards,
Garvin

Garvin - this is on my localhost sandbox, so I cannot easily show it to you live.... I would have to update and reconfigure my main site to emulate this, which is something I would like to avoid.

It is not full="true"... I tried that one.

Again, fetchprintentries has $entry.body even using full="false" for entries that were not aggregated.... $entry.body does not exist for entries that have been aggregated. As previously mentioned, if the entry is opened then saved, it then works, but that defeats a lot of what is desireable with aggregation.

Hi!

Maybe you can setup a sandbox on your live site or another one with HTTP access?

The aggregator uses serendipity_updertEntry() to save an article. This is the same funtion that s9y uses internally to save an entry. I don't see why it should not save the article like the others, but of course there must be something that saves differently then. But I need an installation to reproduce it with and run some FTP debugging.

Regards,
Garvin

To follow-up, Garvin (aka "s9y Miracle Worker") was able to identify the problem as being a combination of both the entry properties and aggregator plugins when caching entries. Both of these have been updated.