Jump to content

Recurme – Processwire Recurring Dates Field & Custom Calendar Module.


joshuag

Recommended Posts

34 minutes ago, GhostRider said:

I'll post the fix that worked for us a bit later this evening.

Remember that version you are using not only has this fix, but lots of other changes for other bugs as well. Maybe it's time to post that version in its entirety somewhere - obviously with no support or warranty, but perhaps a repo that others could issue PRs against?

Then again, I honestly think the entire storage and retrieval side of this module needs to be rebuilt from scratch. the inputfield is really pretty nice, but the rest is unfortunately very cumbersome and buggy. Of course, this is not an easy thing to get right, so I am not meaning to be too critical 🙂

  • Like 1
Link to comment
Share on other sites

Below is what we had changed in the MarkupRecurme.module file. As @adrian posted, our version has had a number of tweaks. So perhaps have a closer look before implementing these changes. Hopefully this helps.

Line 271
$m = date('m', strtotime($date[3]));

To
$m = date('m', strtotime("1st " . $date[3]));

AND

Line 864
$m = date('m', strtotime($date[3]));
$y = $date[4];

To
$m = date('m', strtotime("1st " . $exclude[3]));
$y = $exclude[4];

 

 

  • Like 3
Link to comment
Share on other sites

For those who are interested, here is an explanation of why: https://www.php.net/manual/en/function.strtotime.php#92600

You need to add either the day or the year to the month to get it to work correctly. There are also some alternative fixes listed in this thread: https://stackoverflow.com/questions/3283550/convert-month-from-name-to-number

  • Like 2
Link to comment
Share on other sites

  • 4 months later...

Has anyone using the Recurme module had any issues after updating to the latest PW core 3.0.165?
Our tweaked version is no longer returning results.
Just curious if the core update has affected an out of the box version of Recurme.
All of the $recurme-> methods are returning null.

Link to comment
Share on other sites

  • 2 weeks later...

R.E. 3.0.165 - The issue seems to be with the selectors Recurme uses to find matching events.

Currently, all selectors string-match dates using ~= selector. If this is replaced with the %= selector in the recurme module, then I start getting results again.

Example - in the ___find method in MarkupRecurme, change ~= with %=

When I read about selectors: https://processwire.com/docs/selectors/operators/#contains-words it seems that ~= should be the selector to use - but I'm not sure why it's not working. Not sure if anyone can shed light on that at all.

Edit: here's an example of a failing and working selector:
doesn't work (no results found - should return results, was returning results prior to 3.0.165)

event_dates~=Sep/2020|Sep/2020|Oct/2020,template=event


works (get results):  

event_dates%=Sep/2020|Sep/2020|Oct/2020,template=event

 

 

Link to comment
Share on other sites

OK - pretty sure this is broken since processwire 3.0.160 when a "Major refactor/rewrite of ProcessWire's Database classes" was implemented: https://github.com/processwire/processwire/commit/06acbe57a32e18625248382499bb31527484c315#diff-83091c78a3273da557616affcb670296, specifically, the use of $sanitizer->wordsArray was used to clean the BOOLEAN query value (https://github.com/processwire/processwire/commit/1f293cc4f4092883b4eaf915950ba3c7c5430a7a#diff-83091c78a3273da557616affcb670296R633). 

The use of this words array function means that "Jul/2021" in the underlying DB query changes to: 

MATCH(field_event_dates.data) AGAINST('+Jul/2021' IN BOOLEAN MODE)) ) ))

(which previously return results) to:

MATCH(field_event_dates.data) AGAINST('+Jul* +2021' IN BOOLEAN MODE)) ) ))

(which does not find any matches).

 

  1. I'm not sure if the issue of stripping out "\" from ~= searches (and other sanitization via the wordsArray) is a cause for concern generally - or a good thing from a security standpoint?
  2. Looking at the use of "~=" in the recurrme module, I'm somewhat convinced that this can be switched to %= without loss of functionality or unwanted side effects (also, performance?) but need to do more testing to tell if this is the case or not.
  • Like 4
Link to comment
Share on other sites

I can confirm that replacing all instances of  ~= with %= in the MarkupRecurme.module brings back expected results.
Is anyone else experiencing issues with the Recurme module and PW core 3.0.165 or later?

I thought I noticed another reference in the PW forum re: sanitization possibly being the cause of another recent bug.

Will post if I find remember / find it.

Link to comment
Share on other sites

  • 3 months later...
  • 1 year later...

This seems to be a pretty useful module. I am looking for a solution just like that. 

Is anybody using this module with the latest Version of processwire and does it still work with the modifications mentioned a few posts above?

Link to comment
Share on other sites

  • 1 month later...

Currently coding out booking functionality with week calendar view that is taking a while, so would love to here more about possible solutions people have used, the revival of this, or similar modules

Link to comment
Share on other sites

On 4/29/2022 at 6:47 PM, benbyf said:

Currently coding out booking functionality with week calendar view that is taking a while, so would love to here more about possible solutions people have used, the revival of this, or similar modules

A couple months ago I reached out to the original author of Recurme and asked about the possibility of open sourcing the module and taking a role as maintainer. I've used this module previously and think a good calendar module is critical for the PW ecosystem. Had a great exchange with him and he was open and willing to turn over any assets needed and allow the code to be open sourced with no restrictions. As far as I know the module is still largely usable with the tweaks people have mentioned in this thread but I can't speak to more than that.

I started working on refactoring the code and have a few ideas on how to improve/revamp it. I'm still enthusiastic about the idea of keeping development alive but unfortunately I just don't have the time right now to take it on with how busy I am with non-programming stuff as well as my commitment to getting the next version of my Fluency module released.

I'd love to see this open sourced and would count myself as a contributor or help out where I can, but being a maintainer/lead is outside of my abilities right now. Hope there is some interest or capacity out there to make this happen.

  • Like 1
Link to comment
Share on other sites

Supposedly this dude is rebuilding it 😛 Ok seriously, trying hard, but my time is also limited right now, I almost have the UI rebuilt in Alpine, just need to wrap my head around the Fieldtype interface. But I'd say it's still at like 20% - 30% I am trying to get a run at it asap to build the bare minimum, without the Markup modules, which I also need anyway lol

 

  • Like 4
Link to comment
Share on other sites

9 minutes ago, elabx said:

Supposedly this dude is rebuilding it 😛 Ok seriously, trying hard, but my time is also limited right now, I almost have the UI rebuilt in Alpine, just need to wrap my head around the Fieldtype interface. But I'd say it's still at like 20% - 30% I am trying to get a run at it asap to build the bare minimum, without the Markup modules, which I also need anyway lol

 

Nice! Very awesome seeing the concept worked on and a great contribution to the ecosystem. Working with time bends my brain, you have my respect and admiration haha.

Looking forward to seeing your work. Haven't used Alpine yet personally but it looks fantastic.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

I ran into the following errors when switching from PHP version 7.3 to 7.4 with this module and ProcessWire 3.0.184

Deprecated: Invalid characters passed for attempted conversion, these have been ignored in /home/build/public_html/site/modules/Recurme/MarkupRecurme.module on line 1082 (x2)

Warning: Cannot modify header information - headers already sent by (output started at /home/build/public_html/site/modules/Recurme/MarkupRecurme.module:1082) in /home/build/public_html/wire/modules/Process/ProcessPageView.module on line 161

While this might be addressing the symptoms rather than the cause, I was able to restore full functionality by changing the first part of line 1082 from:

private function i(){$this->v = false;} ...

to

private function i(){$this->v = true;} ...

as suggested on a previous page, AND by also removing all of my license information (email and key) within the admin settings.

There may be a more proper fix to the issue, but I wasn't willing to deconstruct that line's 1,691 characters of complexity to seek it out.

 

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
×
×
  • Create New...