smd_calendar: complete schedule / event / calendar / diary

Bloke · 2009-02-23 15:14:05

robhert wrote:

There is a way to handle ‘tru_tags’ with future events?

No idea! I thought tru_tags just stored its information in the keywords field, which is available (as a list) from the individual article event in the calendar? But if the tru_tags tags are limited to current articles (i.e. no time="future" option then I think you are ‘stuck in the past’ so-to-speak, sorry :-(

progre55 · 2009-02-23 15:19:46

Bloke:

I agree with the fundamental problem, but because the plug in allows me to filter by section, I thought that when looking at site.com/properties/23-acacia-drive if in the form I had the calendar set for “section=“23 Acacia Drive” I would be in good shape.

Now I know that the property would also fall in the event calendar (since it would be in the same section, but I will just bury it in the past.

The date range in the extrafield, which was my original approach, is not feasable (the more I thought about it) because it would be almost unmanageable from the end users point of view even if the plug in could accomidate it.

progre55

robhert · 2009-02-23 15:53:32

Thanks for your answer. Still I’m waiting for some solution… by the way, do you know about some plugins for TAGs? Maybe you developed some one.

I’m trying the search of my site… and I can’t see , in the results, FUTURE events… what’s wrong? Please help!

Thanks!

Bloke · 2009-02-23 15:55:26

progre55 wrote:

when looking at site.com/properties/23-acacia-drive if in the form I had the calendar set for “section=“23 Acacia Drive” I would be in good shape.

Yeah that should work as long as you don’t have clickable links from the already-booked events themselves; otherwise they’ll point to site.com/23-acacia-drive/url-title instead of site.com/properties/23-acacia-drive, unless you do some clever rewriting or a bit of jiggery pokery when creating the calendar cells.

The date range in the extrafield… would be almost unmanageable from the end users point of view even if the plug in could accomidate it.

OK, no probs. It needs doing so I’m going to try and get it working anyway.

Just a random thought, how about:

setting up the properties as normal in their own properties section
setting up a rentals section
whenever a property is rented, create a new article in the rentals section with the name of the property in the url-title. The start and end dates of the article are the start and end of the rental period
on your calendar, fix it to look at the rentals section and just write a conditional that says “if the url-title of the event in the current cell is the same as the url-title of the current property then display the event”

The downside is that TXP will complain that you have several articles with the same name when you save them (it allows this; it just warns you).

Alternatively, tell the end user to create a new article with some other unique info in the url-title (it could be anything, property code, dates, what they had for breakfast, whatever: you’ll never see it) and have them enter the property name in custom1. You can then do the same “if” logic but compare custom1 in the event with the individual article url-title.

If the end user has to type in (or select) the property name whether they are picking from a dropdown category list, a dropdown select list or typing it in a url-title / custom field you might as well use the custom field to “tie” the two records in the two sections together.

Even better (and less prone to error perhaps) than using the property name would be to use a property code utilising some naming convention that you devise, e.g. 23 acacia drive is 0023-aca-dri. As long as the person creating the Property in the first place ensures that the url-title of the article uses the property code and then every time it is referenced from the rental articles you use the same code, everything gels nicely.

Like I say, just a thought. It may or may not have legs.

Last edited by Bloke (2009-02-23 15:58:33)

Bloke · 2009-02-23 16:00:08

robhert wrote:

do you know about some plugins for TAGs?

Apart from tru_tags there’s smd_tags but that’s in a bit of a mess at the moment. It’s being repaired.

I’m trying the search of my site… and I can’t see , in the results, FUTURE events… what’s wrong?

Does TXP allow you to see future articles in search results? I don’t know if it does.

robhert · 2009-02-23 16:03:34

Thanks again Bloke!. But wait a minute, how could I find an event using the search? Or I can’t :( ??

els · 2009-02-23 17:51:17

robhert wrote:

But wait a minute, how could I find an event using the search? Or I can’t :( ??

Are you talking about the Txp search or the tru_tags search? In both cases you need time="any" or time="future" to be able to search future articles. Either in the txp:article tag or in the txp:tru_tags_handler tag.

Bloke wrote:

If there was a Textpattern Innovations award I’d nominate Els :-)

Too much honour, really. It’s easy being innovative with a plugin like this :) Oh, I have great plans for my availability calendar, much more than where I left it a month ago. Just don’t have time at all to work on it now. But I’ll show you when it’s finished. If I can translate my ideas into tags of course… ;)

merz1 · 2009-02-23 20:06:35

Re. tru_tags & search: tru_tags uses the core search features AND tru_tags_handler can’t handle future articles. My conclusion is that both is not possible at the moment.

Btw (re. announcement of future events): This strengthens my argument that the real (aka: begin, future) event date should be in a custom field! And that the publishing date should be used for the date/time when the article is published to the TXP database to be consistent with the standard TXP core. This way announcements of upcoming events in the normal publishing flow/timeline are possible.

els · 2009-02-23 20:36:59

merz1 wrote:

AND tru_tags_handler can’t handle future articles.

Hmm.. I was almost certain that I once used it for future articles… But that was a while ago so I must be mistaken. Sorry for the incorrect advice!

merz1 · 2009-02-23 21:38:34

Re. tru_tags and future articles: Maybe there is hope via Nathan:

I need to look at the code to be sure, but I’m pretty sure it does intentionally filter our future-dated articles. I’m pretty sure that TXP originally hid future-dated articles, so I just mimicked that behavior. I’ll look into as soon as I have a chance. It will probably require a code fix.

progre55 · 2009-02-24 02:12:20

Bloke:

Question: Would it/is it possible in anyway to set to two custom fields so that Custom Field A would be the start of the event and Custom Field B would be the end of the event?

This would be similar to the articles time stamp (without the actual time info) and also without it automatically self filling in. I also would not want the info in one field for ease of use for the end user and a couple of additional reasons.

Just curious …

progre55

Bloke · 2009-02-24 09:57:33

progre55 wrote:

is it possible in anyway to set to two custom fields so that Custom Field A would be the start of the event and Custom Field B would be the end of the event?

Well it would make merz1 happy for sure :-p And it might pave the way for the TV schedule app mentioned earlier in the thread too.

I was actually thinking about this last night and wondering if it was possible. My nagging doubt is whether I could easily make the plugin ignore the timestamp/expiry of the article and use the “override” timestamps instead. A few points:

The date you specify would have to optionally take the time as well. But if you don’t specify a time, what time do I use as “default”? Can I set the start as 00:00:00 and end as 23:59:59? What happens when DST kicks in? Does the event ‘move’ an hour into the previous (or next) day? Or does this — in fact — completely bypass the so-called ‘date issue’ in TXP whereby everything shifts when DST changes? Can this be a neat fix for wandering dates? Interesting…
Should you only be able to specify one start and end time per article, and use the existing fields if you want this event repeated? For example, manually overriding the start and end date/time gives you a ‘width’ for the event as it does now. If that width is >1 day then it’s a spanned event. If you use an extrafield or a stepfield then the event is duplicated as it is now, using your set dates as the starting point. If you could specify multiple start and end timestamps, does it get confusing trying to keep the lists in sync, or is it a useful feature? (not even sure it’s possible actually, just thinking out loud)
What happens if a date is missing or mangled? Currently it is not possible to mangle a date because TXP does checks that a) the Posted and Expiry dates are valid and b) the Expiry is later than the Posted date. If you (or a client) are putting your own dates in, all bets are off. What should I do when discovering a mangled date? Ignore the entire event? Default to the Posted/Expires of the article?

What I’m wondering — programmatically — is if I can offer, say, a datefield attribute that takes one or two options:

datefield="Posted:Expires" is the default, which would work in exactly the way it does now
datefield="custom3:custom8" would assume that all articles have their timestamps in these two fields (subject to some kind of behaviour if the dates are missing or mangled, as described above — which is your preference? Can you see a need for both types of behaviour?)
datefield="custom3" is equivalent to datefield="custom3:Expires"
datefield=":custom3" is equivalent to datefield="Posted:custom3"

I’ve not thought this through any further, it’s just speculation at present. Can anyone see any major pitfalls? What should happen in the event of mashed or missing custom dates? Any better ideas?

Last edited by Bloke (2009-02-24 10:00:09)

Textpattern CMS

Textpattern CMS support forum

#157 2009-02-23 15:14:05

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

#158 2009-02-23 15:19:46

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

#159 2009-02-23 15:53:32

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

#160 2009-02-23 15:55:26

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

#161 2009-02-23 16:00:08

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

#162 2009-02-23 16:03:34

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

#163 2009-02-23 17:51:17

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

#164 2009-02-23 20:06:35

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

#165 2009-02-23 20:36:59

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

#166 2009-02-23 21:38:34

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

#167 2009-02-24 02:12:20

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

#168 2009-02-24 09:57:33

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

Board footer