smd_calendar: complete schedule / event / calendar / diary

Bloke · 2009-01-24 10:09:30

rsilletti wrote:

The link mode from the txp:popup section navigation uses messy urls when the rest of the site uses clean.

I didn’t know that. Humbug, that will cause problems because the plugin only looks at permlink_mode and assumes all your URLs are fashioned thusly. I wonder why txp:popup doesn’t take the permlink mode into account? Must be a reason. Anyone?

If you navigate to the “events” section and you have a section attribute set, shouldn’t you remain in that section with the navigation of the calender?

Yes. Thats what’s supposed to happen. In fact, even if you’re not in the ‘events’ section, if you show a calendar and you have explicitly specified a section attribute in it, the calendar navs should force you to the named section. That’s what it’s (supposed to be) for!

Hmmmmm. I’ll do some testing with txp:popup and check the plugin logic later, because I did mess around with the URL rewriting bit — and the way sections are handled — in v0.4. It could be because I take $pretext['s'] into account when I build the internal section list and, in this case, it’s erroneously reading what’s coming back from txp:popup instead of from the URL’s section, or the one you specified in the attributes.

Edit: also – ver. 0.33 doesn’t do this.

It won’t: it was stupid. But perhaps that was a good thing after all… d’oh :-(

Thanks for the report. BTW, I’m assuming you’re on TXP 4.0.8?

woof · 2009-01-24 21:48:57

Hi Stef – I just noticed that after an upgrade to 4.0 the Plugin Help content now seems to be abruptly cut off somewhere just before Example 6 and the Changelog. Have you run out of space? No big deal as I can refer to the docs on your site, just thought I’d let you know.

Last edited by woof (2009-01-24 21:49:31)

rsilletti · 2009-01-24 22:42:01

Stef – Yes, I was testing the 4.0.8 release when I noticed this – if its any help this behavior looks quite different on localhost. I’ve seen some odd urls that look like this:

http://localhost/?s=events&m=2&y=2009&calid=event_cal&s=events, so I’m guessing url rewriting is probably indicated as suspect. ver 0.33, ver 0.4 behaves consistently on both my server and localhost.

Last edited by rsilletti (2009-01-25 01:25:48)

stopsatgreen · 2009-01-25 01:01:25

I’m using TXP 4.08, and when I try to install this plugin I get the error: Badly formed or empty plugin code.

Bloke · 2009-01-25 01:11:00

stopsatgreen wrote:

I’m using TXP 4.08, and when I try to install this plugin I get the error: Badly formed or empty plugin code.

Try the compressed version,

woof

D’oh, yes I forgot that my beautifully crafted prose gets turned into HTML which is somewhat bigger than Textile. I’ll refactor the docs: just the facts :-)

rsilletti

Thanks for the extra info. Bug hunting in progress…

Last edited by Bloke (2009-01-25 01:11:28)

stopsatgreen · 2009-01-25 01:28:06

Try the compressed version,

Worked, thanks.

rsilletti · 2009-01-27 01:33:54

Event Calendar , event posted by internal settings to my current time zone is showing in the next day? It was displayed properly for an extended length of time and then shifted a day. I’m tempted to blame my own code, but I’ve noticed some other odd stuff as well (posting times changing without my input), I’m wondering how this plugin handles time offsets.

Posted by: Rick · 05 Feb 2009 · 20:30:00 (actual posting time of “Open Mic 2” event )

Preferences setting for time zone is GMT – 8.00

Last edited by rsilletti (2009-01-27 02:54:50)

Bloke · 2009-01-27 09:37:45

Rick

For general info, see rant #1 and #2, the plugin help and if you feel brave, look at the great time debate

posting times changing without my input

Hmmm, not supposed to! From memory, the plugin reads the true database timestamps and applies the server offset. It uses built-in TXP and PHP functions to work out the dates.

I think — but don’t quote me on this — when you (re)save articles, the time is adjusted based on DST/time zone in effect at the time of Save. I can’t remember if that’s the case; it might leave it alone. Whatever, one thing that does happen is that when you alter the time zone/DST in Admin->Prefs, the database timestamps remain the same but all calculated offsets are shifted by TXP on the admin side.

Thus, any change in time zone/DST after an article is posted makes it appear on the admin side like the time’s wrong. If you notice this and “correct” it, your events will drift on the calendar because it uses the database timestamps instead.

Bottom line: time handling in TXP is a mess. And if you think it’s bad using the plugin, try writing and testing one with all this time stuff moving round you! I nearly melted :-P

But if you find that the plugin is actually altering dates when nothing has changed on the admin side or the server, I’d love to see a test case so I can track it down and squash the bug. Similarly, if you have any notions or ideas on how to handle all this, I’d love to hear them/see some code fragments. I’m fresh out of ideas.

FYI, mrdale’s on GMT-08 so you might want to pick his brain on how he handles it.

rsilletti · 2009-01-27 10:00:50

Yes, I’d forgotten about the shift from the database stamps – and that explains a lot. Think I’ll just keep it simple until my headache goes away. Haven’t been able to pin down anything specific with this and all else seems to work very nicely. Thanks for this, I’m having a great time with the possibilities.

Last edited by rsilletti (2009-01-27 10:09:03)

rsilletti · 2009-01-27 20:38:37

if you think it’s bad using the plugin, try writing and testing one with all this time stuff moving round

ras_if_dates, I can feel your pain.

I’m still trying to use the gmt attribute to move the calender itself into local time, it doesn’t seem to have any effect whether it be left at default or explicitly set to “0”. Am I correct in assuming that it should do so?

Bloke · 2009-01-28 19:53:49

rsilletti wrote:

I’m still trying to use the gmt attribute to move the calender itself into local time

*ahem* Right. About that.

A long time ago in a conversation far far away I discussed having issues with date generation. Throughout the entire Beta phase of the plugin I was using safe_strftime() — as mdp_calendar did before me — to generate the dates, which takes the gmt and lang attributes. Trouble was, I found as soon as the timezone in prefs was varied from GMT, using safe_strftime() to generate calendar events — having already been applied at article creation time — caused:

a double offset if you were ahead of GMT
a cancellation of some of the built-in offset if you were behind GMT

(or the other way round, I forget which)

The “fix” (if you can call it that) was to use PHPs native strftime() instead. So I swapped out almost all the calls and thus gmt became practically unused. I say “practically” because it is still used to generate the days of the week, though my guess is you’d probably not see any major problems if I took it out of there too.

I was hoping that by introducing gmt and lang you could do (probably) what you are trying to do now: “set” dates to a reference point and then all this timezone crap would go away. Sadly, TXP’s method of applying timezone on article display scuppered my plans for date domination. This could be for a number of reasons:

TXP’s date mechanism is warped
The world’s date system is convoluted
I just plain don’t understand it all
Some/all of the above

The bottom line is that the gmt and lang attributes remain, even though they’re not exactly used in any great capacity any more. I’ve been contemplating taking them out entirely but I wanted to keep them lurking in case I found that I should really be using safe_strftime(). I ran out of space in the plugin help to talk about it and kept meaning to mention it here before anyone noticed. Guess that backfired too, sorry :-(

If anyone has the definitive answer about how I can treat dates neutrally so they always appear at the date you set, I would ~~like~~ love to know.

May I ask how you approached the whole date conundrum with ras_if_dates? Perhaps I should be doing the same so that gmt actually becomes a useful attribute again? This can drive a man insane.

Last edited by Bloke (2009-01-28 19:54:41)

rsilletti · 2009-01-29 01:53:45

tz_offset() returns a value calculated this way:

Server_Offset = GMT – Current server time.
CMS offset = time zone setting – Server_Offset + DST

if I put a tag that goes like this in a page template <txp:tz_offset /> it
returns 0 which I assume means that my server is on Greenwich Mean Time.

When TXP writes to the database, the timestamp is set using “NOW” as defined by mysql : expressed in the current time zone, so logically the timestamp is serverset.

I went around safe_strftime() and used $thisarticle[‘posted’] + tz_offset() directly as a time base for comparisons; much simpler than full scale date handling in its context. I’m not sure why safe_strftime isn’t working for you as advertised, but the worst tendency that I had with this was inverting a value in the process without realizing it – nothing like that to make even the best work look wrong. Unless I have a fly on the back of my head that no one is telling about, this works in displayed time and moves with the settings.

function ras_dates_today($atts,$thing)
	{
  		global $thisarticle;
		assert_article();
		extract(lAtts(array(
			'type' => 'apos',
			'setdate' => '',
			'offset' => ''
		),$atts));

	switch($type) {
		case 'apos' : $tz_date = strtotime(date('Y-m-d', $thisarticle['posted'] + tz_offset()));
		break;
		case 'axpr' : $tz_date = strtotime(date('Y-m-d', $thisarticle['expires'] + tz_offset()));
		break;
		case 'amdf' : $tz_date = strtotime(date('Y-m-d', $thisarticle['modified'] + tz_offset()));
		break;
	}

	$thedate = ($setdate) ? $setdate : date('Y-m-d' , mktime() + tz_offset() - ($offset * 86400));
		 return parse(Evalelse($thing, strtotime($thedate) == $tz_date ));
	}

Textpattern CMS

Textpattern CMS support forum

#49 2009-01-24 10:09:30

Re: smd_calendar: complete schedule / event / calendar / diary

#50 2009-01-24 21:48:57

Re: smd_calendar: complete schedule / event / calendar / diary

#51 2009-01-24 22:42:01

Re: smd_calendar: complete schedule / event / calendar / diary

#52 2009-01-25 01:01:25

Re: smd_calendar: complete schedule / event / calendar / diary

#53 2009-01-25 01:11:00

Re: smd_calendar: complete schedule / event / calendar / diary

#54 2009-01-25 01:28:06

Re: smd_calendar: complete schedule / event / calendar / diary

#55 2009-01-27 01:33:54

Re: smd_calendar: complete schedule / event / calendar / diary

#56 2009-01-27 09:37:45

Re: smd_calendar: complete schedule / event / calendar / diary

#57 2009-01-27 10:00:50

Re: smd_calendar: complete schedule / event / calendar / diary

#58 2009-01-27 20:38:37

Re: smd_calendar: complete schedule / event / calendar / diary

#59 2009-01-28 19:53:49

Re: smd_calendar: complete schedule / event / calendar / diary

#60 2009-01-29 01:53:45

Re: smd_calendar: complete schedule / event / calendar / diary

Board footer