Jump to content

FieldtypeRecurringDates


elabx
 Share

Recommended Posts

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. 

  • Like 9
  • Thanks 5
Link to comment
Share on other sites

  • elabx changed the title to FieldtypeRecurringDates

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?

  • Like 3
Link to comment
Share on other sites

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! 

  • Like 3
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. 

  • Like 2
Link to comment
Share on other sites

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')

     

  • Like 3
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...