zem_event and Textpattern 4.20

armando · 2009-10-25 00:10:43

The zem_event is not compatible with Textpattern 4.20. I have to disable to enter in admin area. I discover that using http://forum.textpattern.com/viewtopic.php?id=31654&p=3

#27 & #28.
Fatal error: Call to undefined function include_element() in /home/budismoc/public_html/textpattern/lib/txplib_misc.php(594) : eval()’d code on line 1920

But the problem is how to use zem_event with Textpattern 4.2? If I have an article and put it in the calendar section, is impossible because is disable.

Thanks in advance for some help

armando

rsilletti · 2009-10-25 00:49:36

include_element() is a crockery function (4.1.0) and shouldn’t be called in the plugin if you are running Version 4.2.0 TXP, unless changes in the numbering scheme are letting it by – which it doesn’t by my best shot at the code.

Are you using the current stable download of TXP?

Last edited by rsilletti (2009-10-25 00:55:25)

armando · 2009-10-25 09:46:01

Yes, I’m using the correct stable version … before the version was 4.08 … and when I tried to return to 4.08 the problem happen too (but I gave up this version).
Thanks
Armando

rsilletti · 2009-10-25 16:01:37

zem_event has been idle for some time, and hasn’t been updated with current versions of TXP (last commit was 20 Aug 2008), were you using it with success with any earlier version?

armando · 2009-10-26 10:35:24

We are using in many installations (TXP v4.06 and v4.08, more than 30). And all using zem_event. For example: http://budismocampinas.org.br/index.php?s=calendar
Will be very interesting to have an update of zem_event with v4.20. The new capability of hosting multiple sites from a single installation is very useful.
Thanks

Armando

rsilletti · 2009-10-26 18:00:23

I personally haven’t used the multi-site capability, nor am I prepared to try to code to it at present; judging from the response here otherwise it may be some time before zem_event is brought up to speed for that – IMHO.

armando · 2009-10-26 19:36:32

To be pragmatic, what we need is zem_event running. It’s seemed to me easy to solve this, because it is work! Only doesn’t work with admin is using the TXP. That is good guys: take courage!
Thanks for your attention.
Arm.

kostas45 · 2009-10-27 18:51:12

Have you checked smd_calendar?

zeusdidit · 2009-12-23 22:41:22

The concern with SMD_Calendar is that when I had started using zem_event it made sense. It has it’s own section in the admin along with a simple UI to build events. I’m currently using SMD_Calendar. It’s technologically difficult to use since everything must be coded by hand.

I suggest getting zem_event running properly so at least you can see how events were handled and seeing if SMD_Calendar can incorporate some of the UI principles into it’s setup.

I like the idea that events (articles) are handled separately in it’s own area to set up the calendars. Again, I’m still pretty new to SMD_Calendar and I was only able to use Zem_Event for a little bit before one of my upgrades crashed it but I would be willing to pay a ransom to see zem_event come back to life OR see SMD_Calendar grow to being an integral part of TXP or PAY a ranson to have SMD_Calendar have it’s own area to build events.

FireFusion · 2010-01-18 07:36:08

i’ve got quiet a few sites running Zem event. I would also be interested in a patch if anyone has one.

Bloke · 2010-01-18 10:39:06

zeusdidit wrote:

when I had started using zem_event it made sense. It has it’s own section in the admin along with a simple UI to build events.

Sorry I only just spotted this thread. I’m a little out of touch with zem_event but when I last tried it:

you had to twist down a panel below the article in the Write tab so you could add an event
the event didn’t seem to be tied to the article itself (aside from the fact you had to locate the correct article before you could edit the event info)
the event had its own title and posted dates — separate from the article to which it was associated which either meant a lot of duplication or the article fields themselves were left empty
the information you could enter was limited to the fields that were pre-configured in the plugin — no expansion (or reduction) of fields was possible
you couldn’t initiate a search to find event info

Doesn’t seem that simple to me :-) What dedicated area in the admin side are you referring to? What did it do for you? I must have missed that bit.

I’m currently using SMD_Calendar. It’s technologically difficult to use since everything must be coded by hand.

What do you mean ‘by hand’. Any article can be an event. The recommended way to use the plugin if you want to keep everything separate is to put all event articles in a dedicated section. Being able to use custom fields means you have complete flexibility over what you want to collect in each ‘event’. And with the latest glz_custom_fields (and/or sed_section-fields / ied_hide_in_admin) I believe you can attach date picker widgets to certain custom fields or hide things you don’t want people to fill in, thus creating a better workflow for those entering events.

I would be willing to pay a ransom to see zem_event come back to life OR see SMD_Calendar grow to being an integral part of TXP or PAY a ranson to have SMD_Calendar have it’s own area to build events.

As detailed I’ve begun completely rewriting smd_calendar from the ground up. It still uses articles as the main currency, but one of the key ingredients I originally forgot (event start/end time!) when I altered mdp_calendar was missing from the plugin. Since the plugin has grown from a simple calendar to a more complete event/scheduling system it’s become clear to me that this oversight is not good enough; hence the rewrite.

At the moment an event’s duration is the difference between the time in its Posted field and the time in its Expiry field. This is unacceptable because it is counter-intuitive to create a spanned event such as a Broadway show that runs for 6 weeks (except weekends) with a show that runs three hours a day. Being able to select one or two custom fields to hold an event start/end/duration fills this oversight and gives a lot more flexibility in how you use articles to create events.

Then comes the issue of building event lists and the calendar itself. Yes, it’s tricky to do complex things. Yes, I’ve learned some stuff since writing the plugin first time round. Yes I’m applying what I’ve learned to this new version to try and make it simpler. But even now you can show a completely functional calendar — with clickable events — using a naked <txp:smd_calendar /> tag and work up from there. Same goes for an event list: <txp:smd_article_events /> without any attributes will show you the spanned, recurring or whatever events (articles) from the current section and allow you to page through them — which is something article_custom can’t do. I did try to make the output side of things easy to start with, but if I’ve missed something obvious then please let me know.

The new version will have the capability to create more “event-like” articles, but it will still be based around an article when all is said and done. To me, this is far more intuitive than attaching a separate event to an existing article and having to put a separate event start time, a separate event end time, a separate title and only being able to fill in a fixed set of event information. Most events I created with zem_event had empty Body and Excerpt areas because otherwise I ended up putting the same information in two places. And (iirc) every time I visited the article to edit it in the Write tab I had to twist down the Event panel. That’s still a pretty “manual” operation to me, but maybe I missed the point of the plugin!

The upshot is that neither plugin is optimum for events. This is partly to do with TXP itself, but mostly because they’re both incomplete implementations. If you struggle with smd_calendar, that’s cool (I can’t please everyone!) but if you have any ideas on how to improve its workflow, NOW is the time to raise them while I’m in the early stages of rewriting the plugin. I can’t promise anything and I don’t ransom code, but if you put some great ideas forward and I agree they make sense to be built into the plugin, feel free to donate a few shekels if such features would help you out.

smd_calendar won’t become an integral part of TXP, but since 4.2.0 has given a lot more power to plugin authors, the avenues open to me are more numerous so things that were difficult/impossible in 4.0.8 may now be within sight.

Last edited by Bloke (2010-01-18 10:39:52)

Anton · 2010-02-21 11:28:59

To return to the main topic (and ignoring if zem_event is good or bad), is there any way we could get this working again? Anyone know what might have changed that broke this plugin?

cheers,

/Anton

Textpattern CMS

Textpattern CMS support forum

#1 2009-10-25 00:10:43

zem_event and Textpattern 4.20

#2 2009-10-25 00:49:36

Re: zem_event and Textpattern 4.20

#3 2009-10-25 09:46:01

Re: zem_event and Textpattern 4.20

#4 2009-10-25 16:01:37

Re: zem_event and Textpattern 4.20

#5 2009-10-26 10:35:24

Re: zem_event and Textpattern 4.20

#6 2009-10-26 18:00:23

Re: zem_event and Textpattern 4.20

#7 2009-10-26 19:36:32

Re: zem_event and Textpattern 4.20

#8 2009-10-27 18:51:12

Re: zem_event and Textpattern 4.20

#9 2009-12-23 22:41:22

Re: zem_event and Textpattern 4.20

#10 2010-01-18 07:36:08

Re: zem_event and Textpattern 4.20

#11 2010-01-18 10:39:06

Re: zem_event and Textpattern 4.20

#12 2010-02-21 11:28:59

Re: zem_event and Textpattern 4.20

Board footer