[request] Bounty: Update MDP Calendar

renobird · 2008-12-22 13:54:55

Well here it is the 22nd and it sure feels like x-mas!

To quote Jakob “just seen this and feeling faint”.

I’ll throw some cash at this for sure – not quite sure what I can afford at the moment – but I’m in.

—
T

Bloke · 2008-12-22 15:23:44

renobird wrote:

I’ll throw some cash at this for sure – not quite sure what I can afford at the moment – but I’m in.

Many thanks, Tom. When I’ve ironed out a few more of the wrinkles (most of which are in my post above yours…) I’ll send you a pre-release copy to mess with. Hopefully in time for Christmas proper :-)

Bloke · 2008-12-22 17:09:24

An update while I’m in monologue mode.

In my — thus far limited — testing, it seems if I force safe_strftime() to use gmt="1" by default, then the plugin behaves itself ‘internally’ and calculates the correct offsets and things, exactly like the PHP strftime() does. While that is a relief and alleviates complex timezone calculations on my behalf, it smells ever so slightly of old varnish and I can’t help thinking I’m missing something (probably the fact I’m actually in a GMT time zone and it’ll collapse elsewhere in the world)
Nevertheless, if I do that, it also appears the plugin — internally and publicly — is immune to changes in the DST prefs setting, which is tip top in my book
If I alter the time zone in prefs, the plugin still continues to behave internally but of course the <txp:posted /> and <txp:expires /> tags render the offset times. The ‘fix’ for older events is to specify gmt="1" in your posted/expiry tags. This isn’t much of a hassle (I don’t think) because you don’t tend to change time zone very often, if at all
Conversely if you enter a new article while under the influence of a time zone, any new events using posted/expires tags with gmt=“1” will render the incorrect time, but if they are set to gmt="0" the desired time (as set in the article) is displayed. Dilemma
Of course, either way the TXP articles on the admin side “change time” as stuff is adjusted, which is a pain. The key thing to remember, I guess, is that if you see a time in an ‘event’ article that’s already posted leave it the heck alone no matter how tempting it is to correct it. And if you do have to re-save the article, make sure you take the current time zone and method in which you display times to visitors into account or it’ll fall apart upon saving

All this hair-pulling leads to a conclusion: The only way an event/calendar system can possibly work in TXP today (4.0.7) is if the administrators and people entering articles are completely consistent and the time zone/DST never changes and no articles are ever edited and resaved under a new time zone/DST. Vary any of those conditions and it gets messy very quickly. Unfortunately, I don’t think that is a reasonable assertion because a web site will evolve over time and should be able to cope with such fluctuations.

I can go someway with this plugin because I intend to enhance the conditional tag to be able to detect and react to timestamps. Thus if you changed timezone today (for whatever reason: server move, maybe), you could run a test as you rendered your calendar to see if the date was > a particular date and output posted tags with gmt=“0” from that date forward. Else use gmt=“1”. It’s not ideal but it helps; the onus is still on the site owner to understand all this time lark, and frankly it’s Einstein territory at best, but when things don’t go to plan at least there’s an avenue to wander down with some lights on.

Thus I’m with saccade on this issue: each timestamp should be stored as an epoch in the database that’s immutable and absolute (well, until 2038, but that’s another problem entirely!). Its ‘context’ — the conditions at the time of posting — should be recorded as ancilliary information in another column or two. For specialist apps like calendars it’s up to us site admins and plugin authors to use the extra columns to fit our intended use models and factor any adjustments into the design so timestamps can appear to remain constant where they need to — both client and admin side.

Going forward, if that means adding a couple of optional args to safe_strftime() and the posted/expires tags, or some better prefs in the database to allow adjustments to be made automatically, I don’t know and I’m not qualified to make those decisions. I’m rapidly approaching the opinion that there is no ‘best fit’ solution but there could probably be some kind of automatic ‘best guess’ solution that works logically for most people and can be overridden should the need arise. This will take some brain power and I don’t have the capacity, cap’n ;-)

If anyone has anything else on this I’d love to thrash it out to something workable.

P.S. the plugin still of course works, it’s just a pain in the admin side when things like DST kick in.

EDIT: aww crap, if you save an article with DST on it applies DST to the timestamp it stores in the DB so when it switches back it shows up an hour earlier, and the setting of gmt has no effect either way until you resave the article in ‘winter’. Can anyone spell m i n e f i e l BOOM…?

Last edited by Bloke (2008-12-22 20:26:32)

net-carver · 2008-12-23 13:49:40

StefBloke

Interesting PHP timestamp article.

Bloke · 2008-12-23 14:13:42

Ahaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa! There may be some light at the end of the time tunnel.

Right, that’s my afternoon taken care of. Thanks Steve :-)

net-carver · 2008-12-23 14:31:48

StefBloke

NP, hehehe. BTW, the link to php.net at the end of the article I quoted is wrong. Should go here (at least for UK clicks.)

Bloke · 2008-12-30 14:11:14

Update on smd_calendar: I’ve not got much further with DST, but the timezone thing I think I’ve cracked by simply not using safe_strftime(). I’m using PHP’s native strftime() instead which seems to stop TXP calculating the timezone offset twice and getting in a pickle. It’s holding up ok with all timezone tests I’ve run so far, and mrdale has concurred it’s working across the pond in GMT-8 land. Fingers crossed…

The plugin is up to v0.3 as of this morning but it’s not published because I’ve not finished the latest round of “can it just do…” from mrdale, which I’m trying to roll into 0.3 as well. Anyone who has an older copy and wants to try it out, get in touch because some of the v0.2x releases were brain damaged in the date department and may cause head scratching.

I’ve managed to squeeze in a cellform attribute, among other stuff, so you have the option to pretty much design your own cells on the calendar from scratch; thus if you don’t like the way the date number is displayed, you can do it yo’self.

If I can crack mrdale’s latest request it’ll be even more useful, but it’s pretty involved and is too early to say whether it’ll work the way I want it to. I was hoping to get it ready before New Year but it’s touch and go right now. Perhaps with an Easterly wind and a sprinkling of fairy dust. Sorry to keep promising it’ll be released and then not releasing it, but kind benefactors get first stab at this one.

Even if I do say so myself, this plugin is a major step forward for event management that would not be possible were it not for the brilliant stuff behind the scenes in the 4.0.7+ codebase. All hail TXP, for it is mighty.

mrdale · 2008-12-30 16:17:37

BTW: I should say that Stef’s Calendar wildly exceeds my expectations. It’s awesome. Stef always delivers far more elegance, function and flexibility that one initially asks for.

The “can it just do” that Stef mentions turns this plugin into a full-fledged events package. It’s outside the original scope (and I’ll end up sponsoring this further to the tune of a beloved ancestral cabbage)…

so I would encourage anyone who can swing it to donate something and sponsor this really useful piece of work.

Last edited by mrdale (2008-12-30 16:18:34)

joebaich · 2008-12-30 16:51:18

Bloke wrote:

EDIT: USD?! Might as well offer magic beans ;-)

Stef go for the USDs spurning any offers of beans. Though the USD is ailing, the GBP (Gordy Broon’s Pund) is ailing even more. Several months ago you would have received around 50 pence for each dollar, today you will receive around 68 pence.

I’ll add some GBP in due course.

Last edited by joebaich (2008-12-30 16:53:08)

Bloke · 2008-12-30 17:12:09

joebaich wrote:

Though the USD is ailing, the GBP (Gordy Broon’s Pund) is ailing even more.

Hehe, and don’t we know it…! Many thanks for the offer of some cash for this. Something from the wishlist is equally cool if you’d prefer.

OT, I have a suspicion the central bankers are *cough* ‘helping’ this economic downfall with massive fiat currency injections, stock market manipulation and media rumour-mongering like they did in the 1900s. When GBP falls to 1:1 (or below, which is, ummm, about now) against the Euro the top brass will say “tut tut tut, well the pound’s worthless now. No point having a referendum that we know will result in rejection… might as well take the Euro, eh?”

From there, it’s not a huge step to: “oh look, all world currencies have collapsed. Best swap them all out for the Universal MegaDollar, which we’ll print and back with more fresh air. By the way, a loaf of bread is now 10 MegaDollars because we’ve carved all the food land up to grow biofuel for our huge government SUVs. Sorry an’ all that.”

/end party political broadcast by the So Long And Thanks For Nothing Party :-)

P.S. I hope I’m wrong.

Last edited by Bloke (2008-12-30 20:11:07)

mrdale · 2008-12-30 17:53:42

word.

Bloke · 2009-01-01 21:00:18

mwuahahahahaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

I think mrdale’s “can it just do this…” is ready to rock n roll along with countless other new features. Across the six tags that make up this plugin there are no fewer than… deep breath… 86 90 attributes so you can tweak the plugin to the nth degree. But it’ll all hang together with virtually no attributes if you prefer, and deliver what I hope is complete calendar and event management under one roof. No hacks, no extensions, just plain TXP + one plugin.

The code is on its way to my willing volunteers/kind benefactors for their perusal. Based on their feedback and testing I’ll know if it does what I claim. Sit tight.

Last edited by Bloke (2009-01-04 21:54:04)

Bloke · 2009-01-02 18:55:47

I’ve just had an email from woof regarding this plugin and iCal which brings about an interesting use of the plugin. This is going in as Example 5 in the documentation but I thought I’d share it here as a great example of how one of the tags in the plugin can be used.

If you want to output your events in iCal format so other people can sync their calendars to yours, put something like this in a new Page template in its own Section:

BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:Gigs Calendar
PRODID:-//Apple Computer, Inc//iCal 1.5//EN
X-WR-TIMEZONE:Europe/London
<txp:smd_article_event form="icsitem" time="any"
section="gigs" limit="1000">
 BEGIN:VEVENT
 DTSTART:<txp:posted format="%Y%m%dT%H%i%s" />
 DTEND:<txp:expires format="%Y%m%dT%H%i%s" />
 SUMMARY:<txp:title />
 END:VEVENT
</txp:smd_article_event>
END:VCALENDAR

That will output an iCal-formatted gig list (repeated or otherwise). Thus, standard events show up and any recurring events (up to 10 per event using the defaults + attributes above) will be displayed as well. If you had a monthly gig at the Hound & Hare pub, your mates need never miss your eclectic mix of Rock and Bhangra again!

If you got freaky with it and added some conditional logic inside the template you could even read in URL variables and plug them in. Thus you could link to that section directly off the calendar itself, pass in the current section, category or event info that the visitor was browsing and have a customised iCal stream pumped out of Textpattern allowing your visitors to stay abreast of events that interest them when they take their laptop offline.

It’s calendarific.

Many thanks to woof for bringing the original David Emery article to my attention. Rock on.

Last edited by Bloke (2009-01-02 18:58:31)

mrdale · 2009-01-04 04:33:53

Brilliant, gentlemen! Orders of magnitude more utility without asking. If you use this plugin think about contributing.

Bloke · 2009-01-06 14:44:59

Release the hounds :-p

Textpattern CMS

Textpattern CMS support forum

#16 2008-12-22 13:54:55

Re: [request] Bounty: Update MDP Calendar

#17 2008-12-22 15:23:44

Re: [request] Bounty: Update MDP Calendar

#18 2008-12-22 17:09:24

Re: [request] Bounty: Update MDP Calendar

#19 2008-12-23 13:49:40

Re: [request] Bounty: Update MDP Calendar

#20 2008-12-23 14:13:42

Re: [request] Bounty: Update MDP Calendar

#21 2008-12-23 14:31:48

Re: [request] Bounty: Update MDP Calendar

#22 2008-12-30 14:11:14

Re: [request] Bounty: Update MDP Calendar

#23 2008-12-30 16:17:37

Re: [request] Bounty: Update MDP Calendar

#24 2008-12-30 16:51:18

Re: [request] Bounty: Update MDP Calendar

#25 2008-12-30 17:12:09

Re: [request] Bounty: Update MDP Calendar

#26 2008-12-30 17:53:42

Re: [request] Bounty: Update MDP Calendar

#27 2009-01-01 21:00:18

Re: [request] Bounty: Update MDP Calendar

#28 2009-01-02 18:55:47

Re: [request] Bounty: Update MDP Calendar

#29 2009-01-04 04:33:53

Re: [request] Bounty: Update MDP Calendar

#30 2009-01-06 14:44:59

Re: [request] Bounty: Update MDP Calendar

Board footer