FieldtypeRecurringDates

[elabx]

https://github.com/elabx/FieldtypeRecurringDates

Well a few summers later, finally got like a sort of working version. For info please take a look at the repo's readme. 

It's still super alpha but going to deploy into a couple websites to replace Recurme so wish me luck. 

This module is only a Fieldtype and Inputfield, there are no "markup" modules as there used to be in Recurme.

I'd appreciate any testing or any kind of comments. 

[bernhard]

Great to see someone tackling this ? I wish you all the best for the challenge ? 

Do you have some screenshots? And maybe a short description how the module works from a technical point of view? Why did you split the finding part in a separate module?

[elabx]

4 hours ago, bernhard said:

Why did you split the finding part in a separate module?

To be honest this wasn't a very conscious decision it just felt kinda odd to define it within the Fieldtype module? I also though of it to be able to combine with other Date module fields through a hook in the finder, I'll set an example as soon as I can too, since this definitely needs documentation. 

4 hours ago, bernhard said:

Do you have some screenshots? And maybe a short description how the module works from a technical point of view?

Yes I will upload a GIF as soon as I can!

I'm not sure there is a lot to say?? In general I feel it's overall regular Fieldtype/Inputfield development. Which took me some time to grasp lol. (Thanks @MarkE for your fieldtype breakdown!). Also de UI is built with Alpine.js. And the heavy lifting (calculating the occurrences) is done by php-rrule. 

Ok after writing this I'm thinking it might be worth to explain myself a bit more haha.

4 hours ago, bernhard said:

Great to see someone tackling this ? I wish you all the best for the challenge ? 

Thanks mate! 

[bernhard]

6 minutes ago, elabx said:

Ok after writing this I'm thinking it might be worth to explain myself a bit more haha.

The most important question would be how you save dates in the DB. How do you handle endless recurring dates? Do you set a hard limit on numer of recurrences? Or do you set a limit on the year in the future? etc etc.

[elabx]

1 hour ago, bernhard said:

The most important question would be how you save dates in the DB.

This is done as a regular Fieldtype under a `data` column, it basically looks like a Datetime field db table, and there is a secondary table that saves the field settings in terms of UI state. I might need to still to a bit of cleanup in this because I was going to include an "exclude" boolean column, to skip specific dates in an occurrence rule, but I am thinking of changing that approach. 

1 hour ago, bernhard said:

The most important question would be how you save dates in the DB. How do you handle endless recurring dates? Do you set a hard limit on numer of recurrences? Or do you set a limit on the year in the future? etc etc.

I set a hard limit through either count limit, or a date. This is basically a limitation of the php-rrule library itself, as you WILL end with an infinite loop if either COUNT or UNTIL parts of the rule are not set. So if I remember correctly now, the module should even throw an error if you try to save something without one or the other value. 

I want to implement a "Never" option, but the only way I can think of it is to depend on a hidden hard limit, and a async task that "recalculates the rule" in the database. In the previous module it didn't recalculate, it just assumed you'd never reach the 50k iteration of the occurrence lol, I'm surprised it has actually worked pretty well until now. 

[gornycreative]

This looks interesting, I was a Recurme user back in the day and haven't really touched it since support stopped but this looks interesting. I'll definitely pull it and play with it.

[elabx]

17 minutes ago, gornycreative said:

This looks interesting, I was a Recurme user back in the day and haven't really touched it since support stopped but this looks interesting.

The main ideas behind this update are

• Migrating the frontend to a "reactive js framework" which I think simplified the frontend code A LOT. So the UI is powered by Alpine.js.
• Migrating the database schema to use Date column to store event occurrences as data, not as text within one row. Not sure if warn people that this could get out of control easily in the sense that you could store whatever thousands of pages the computer can handle lol. The data can now be queried by the date column and it uses the regular date selectors we are used to, you can also paginate the results of each occurrence definition and it will paginate them form the dabase, making it more efficient in general than how it was built previously. So you can to something like:
   

  $page->recurring_dates_field('start=20, limit=100')

   

[elabx]

I just noticed that the field doesn't really work within selectors as I expected, but working on it! ?

Here's the problem laid out a bit:

 

[pideluxe]

Thank you very much for taking on this topic, as it is often needed and a reasonable and simple implementation is important.

What do you think about including a duration in the field? If you were to use the data from this field for a calendar, it would be good if the duration was also stored immediately. I found out that php-rrule doesn't directly take duration into account, but there is a issue for this. I've already made some changes to include the duration in your fieldtype, but this is more project-specific and one would have to think about how to implement this in general.

[elabx]

9 hours ago, pideluxe said:

I've already made some changes to include the duration in your fieldtype, but this is more project-specific and one would have to think about how to implement this in general.

I also sort of have this scenario and decided to use separate Time fields to indicate start and end time of each occurrence. I just have to assume that the occurrences have the same time.