You are not logged in.
Pages: 1
I'm trying to build a calendar plugin for a website and trying to get the data from the BTXEvents extension to the template now.
Stumbled upon something maybe someone can clarify?
I've succesfully entered a recurring event in the module, but didn't include an end date. If I see correctly in events.php the query is caching the event date for - 1 year and + 2 years. However when I use the getUpcomingEvents feature the recurring event only is shown once with the initial setup date. The btx_events_date_cache table contains only 1 rule with the initial data.
Is it meant to be only one entry in the db? Or should the query write a row for each recurring event. If not i'd have to calculate the future events in the frontend, doesn't seem the appropriate way right?
Offline
There should be a single event in btx_events_events but there should be multiple instances in btx_events_date_cache.
I just installed on a fresh 4.2 environment and it looks like there's a bug with the form -- it's missing its publish hook so the date cache is never being filled out.
To fix this, edit the events form and click the Manage Hooks button. Added "BTXEvents::publishHook" as the publishing hook. After that, re-save the event and it should populate the date cache.
Offline
Hey tim,
cheers for the clarification. Seems that adding "BTXEvents::publishHook" as Publishing hook it screws up the form date input etc.
Doesn't seem the right fix for 4.2.1?
thanks.
Thomas
Last edited by visconti (June 26, 2015 4:23am)
Offline
That's the proper hook setup, it looks like the Date Chooser field has switched to "text". It's possible that the field type didn't import properly? I don't remember a 4.2.1 bug related to that but it's possible. Do you see "Events — Date Chooser" as a field option? If not at it was previously working I'm guessing the database entry is just missing:
INSERT INTO `bigtree_field_types` (`id`, `name`, `use_cases`, `self_draw`, `extension`) VALUES ('com.fastspot.events*date-chooser', 'Events — Date Chooser', '{\"modules\":\"on\"}', 'on', 'com.fastspot.events');
That call should fix the missing field type.
Offline
Found the issue, i scrambled the d/m/y which caused the issue.
For now i'm holding onto your format and will change it only at output.
Cheers for the help.
Offline
Issue wasn't completely fixed. Indeed it had something to do with the fieldtype, after fixing the publishing hook.
However recurring events still weren't cached like they are supposed to. Fount the bug now, i wasn't setting an end date (relying on the script to automaticly calculate 2 years in advance) however it doesnt do so.
So manually setting the end date of the recurring event fixed the issue for me. For now i'll make the field a required field.
Cheers,
Thomas
Offline
Strange, I can't replicate this issue. I've tried a weekly recurring event without start or end dates, with a start and without an end, with both start and end dates, and with a start and a "until" date. All of them cached the right dates for me.
Are you using an alternate date format in $bigtree["config"]["date_format"]? I'm wondering if that could be an issue.
Offline
Hey Tim,
sorry for the late reply. I'm indeed using another date format:
$bigtree["config"]["date_format"] = "d-m-Y";
and for the enviornment:
date_default_timezone_set("Europe/Amsterdam");
Offline
Thanks! I'll look into this more and hopefully get a fix in place.
Offline
Hi Tim,
noticed you updated the events plugin, tried it immediatly, but now i'm getting the following msg:
Fatal error: Call to undefined method BigTree::dateFormat() in /home/extensions/com.fastspot.events/field-types/date-chooser/process.php on line 3
Offline
The update requires BigTree 4.2.4 (released yesterday) to function properly -- I tried to get that in the release notes, but it's sadly not all that clear
Offline
Pages: 1