Geeklog Forums

Hi,

if I activate the hook "Story Management", the layout of the story switches to archivestorytext.thtml although the story has not been archived yet. Is that normal? The Archive date is in the future, so it should show with the normal layout until the story reaches its due-date, right?

thanks

Correct, it should not use the archived template until it is actually past the archive date.

---

Geeklog components by PortalParts -- www.portalparts.com

So does anybody have the same problem?
If so, I will post it as a bug

Hi Tokyoahead,

I have the same issue, but I don't see it creating any problem other than having a different look. I am thinking about changing the template to match the regular ones.

Are you encountering any problems other than the template?

Sam

not really. However I hate customizing.
Of course I can take the standard layout and copy it into the archive layout.
Not mentioning the trouble I went through to find out why this one article suddenly did not have a "read more" link all of a sudden, I think its still a bug.
further, I like the feature that the archived articles have a different look.
as a matter of fact, I would like a function that changes the "Show on Front Page" to "Show only in Topic" once the article is archived.

as I Geeklog (luckily) has a quite high frequency of meaningfull updates and new releases, it becomes a quite high load of work to update once you start cusomtizing. all template and core changes and hacks should be avoided as much as possible therefore. from my point of view the config.pbp could have 30 more settings to save stuff in one place instead of modyfying the code or the templates.

That exactly what I'd like to have!

Sam

I missed that in my testing. It works fine if the story is a featured story and has the archive option. If it's not and it's set to archive at a future date/time, then I see it is using the archive template when rendering the article.

The issue is the logic is missing the comparison of the expire date when not a featured story. It's not a one liner as there is code needed to convert the date format to a timestamp for comparison. I have just been testing a fix and will be submitting it to CVS in a few days. I want to think about adding the date conversion function as a common library first.

---

Geeklog components by PortalParts -- www.portalparts.com

hi, does archiving only mean that the story is using another template? I thought the archived stories were saved in a seperate 'archived' topic.. but that is not true?

No. it means that archiving works as intended. Only if you set an automatic archiving date in the future, the article will immediately use the archive template, even though the archive date has not come yet.

I found a quick and dirty hack that fixes the layout problem with auto archived articles.

If you modify /geeklog/system/lib-story.php on line 323 to read:

elseif ($A['statuscode'] == 10 && $A['expire']
the story will only use the arive template if the article expiration date has passed!

ok, it botched the post 'cause I didn't use the right formatting

If you modify /geeklog/system/lib-story.php on line 323 to read:



the story will only use the arive template if the article expiration date has passed!

I don't believe we want to compare dates this way. It should be converted to a timestamp and then compared and was what I was referring to in my earlier post.

How would this work for different Timezones, locality settings etc ?
As soon as the date format changes then I wonder if this would not break.

---

Geeklog components by PortalParts -- www.portalparts.com

It may not be the most optimum way to compare dates, and this problem should be addressed for the next release.

As far as different timezones go, the time stored in the DB is the server time and not the client time. regardless of the client's TZ, the article would expire according to the server's TZ. It would take some fancy client-server interaction to get the client's TZ and show custom expired articles based on their locale. The date format stored in the DB is the standard MySQL date format. This comparison is based on that. If you changed the expire field in the stories table to a timestamp, this would break.

This is certainly not a rock-hard solution, just a dirty hack. I won't pretend to know all the ins and outs of Geeklog.

as intended? but I don't see any difference except the template change..