sitecrafting / greg Goto Github PK

We're currently setting 'posts_per_page' => -1 in Greg\EventQuery::params() to ensure that all applicable events are returned based on the current query. Without this, the query would be limited based on the WP posts_per_page setting. But there are probably better and more flexible approaches for this.

See #14 for more context on why this change was implemented in the first place and some potential suggestions for future improvements.

Currently we only support UNTIL-style recurrences being passed to RRule. For more flexibility, we should aim to support as much of the RRULE spec as possible, including COUNT and BYDAY, BYWEEKNO, etc.

More info: https://github.com/rlanvin/php-rrule/wiki/RRule#creation

Given a query like:

[
   'event_month' => '2020-10',
   'truncate_current_month' => true,
   'event_category' => 41,
];

Greg\get_events() will return Events outside the month of 2020-10 if it finds events that recur beyond that month. The Calendar class should instead limit by the start/end date params, which need to be passed from outside.

Also, sorting is messed up somehow. Given an array like:

$events = [[
  'start' => 'October 31, 2020 12:00 am',
  'end' => 'October 31, 2020 12:01 am',
  'title' => 'Event Test Two',
  'recurrence' => [],
  'recurrence_description' => '',
], [
  'start' => 'October 29, 2020 11:00 am',
  'end' => 'October 29, 2020 12:00 pm',
  'title' => 'Event Test',
  'recurrence' => [],
  'recurrence_description' => '',
], [
  'start' => 'October 28, 2020 12:00 pm',
  'end' => 'October 28, 2020 12:31 pm',
  'title' => 'Repeating Event',
  'recurrence' =>
  array (
    'until' => '2020-11-20 12:30:00',
    'frequency' => 'daily',
    'exceptions' => [],
  ),
  'recurrence_description' => '',
]];

$calendar->recurrences($events) is returning all recurrences for Repeating Event through 11/20 before recurrences for the others.

Hi! Please help us help you by providing as much detail as you can about your issue. The more info you give us, the more likely it is that we can help solve your problem!

Expected behavior

$event = [
  'start' => '2020-01-01 12:00:00',
  'exceptions' => ['2020-01-01 12:34:56'],
  'frequency' => 'DAILY',
  // ...
];

Expanding recurrences for this event should take DAILY granularity into account, and therefore not consider the time component.

Actual behavior

Currently Greg will throw away the exception because the exception's time, 12:34:56, does not start's time.

One of the trickier things about setting up Greg is his lack of a UI out of the box. The Events Calendar offers a pretty nice admin UI, although it's arguably a little too complex. An MVP UI would support:

• specifying whether an event recurs or not
• specifying COUNT and UNTIL-style recurrences
• specifying exceptions
• specifying recurrence_description override text

Based on the UI you're using to populate Greg event data, it's possible to get into a state where Greg where it throws an exception while trying to calculate recurrences. Addressing things on the UI side is something that should happen, but as a last line of defense Greg shouldn't throw fatal errors when presented with malformed data.

Example: If you set up events with a "Once" frequency which indicates that no recurrence should happen, it can be possible to get an event into a state when Greg still thinks it should calculate recurrences.

STR:

1. Set up recurring event, including a "recur until" date
2. Switch this event to a frequency of "Once" (i.e. no recurrence)
3. If Greg attempts to calculate recurrences for this event, the combination of the non-valid "Once" frequency and a previously-set "recur until" date results in Greg throwing a fatal error

See post_to_calendar_series in greg/src/Event.php for a potential place to address this issue.

Expected behavior

Greg shouldn't throw a fatal error in this case

Actual behavior

Fatal error: Uncaught InvalidArgumentException: The FREQ rule part must be one of the following: SECONDLY, MINUTELY, HOURLY, DAILY, WEEKLY, MONTHLY, YEARLY in /code/wp-content/plugins/greg/vendor/rlanvin/php-rrule/src/RRule.php:244

Steps to reproduce behavior

1. Set up recurring event, including a "recur until" date
2. Switch this event to a frequency of "Once" (i.e. no recurrence)
3. If Greg attempts to calculate recurrences for this event, the combination of the non-valid "Once" frequency and a previously-set "recur until" date results in Greg throwing a fatal error

What version of WordPress/PHP/Timber/Greg are you using?

How did you install Greg? (for example, via git clone, GitHub zip download, Composer/Packagist?)

When recurrences are calculated for an event, exceptions aren't honored for days where there is also an override in place. This is because when Greg\Calendar::align_time is called while normalizing exception dates, the default event start datetime is always passed in regardless of any overrides. This results in the exception datetime using the wrong time and RRULE not recognizing that it should skip the exception date.

Assuming it's not an option to have RRULE base exceptions on date only and disregard time (which doesn't appear to be an option and might have unintended side effects anyways), our best bet is to make sure align_time gets the correctly-overridden time in the first place.

It'd be nice to be able to call {{ event.recurrence_range() }} to get start - until rather than start - end for recurring events. If the event is not recurring, return false so we can do:

{{ event.recurrence_range('g:ia M j', 'M j') | default(event.range('M j g:ia', 'g:ia')) }}

This will output something like 12:00pm Nov 1 - Nov 3 if the event is recurring, otherwise something like Nov 1 12:00pm - 2:00pm.

Instead of having to write:

<a href="?event_month={{ greg_next_month() }}&event_category={{ greg_event_category() }}">...</a>

It'd be nice if there were a concise greg_next_month_url() helper:

<a href="{{ greg_next_month_url() }}">...</a>

...and a corresponding one for prev. This would require gathering all currently applied filters (via greg/params) and merging them with next/prev month.

A greg_event_category_url() helper taking an optional slug/term_id would also be nice.

This is revolutionary 🚀
https://github.com/Automattic/wordbless

You don't need a database and the WordPress test suite for running tests.
No need for bin/setup-wordpress.sh

Expected behavior

Say I have a repeater field called my_exceptions:

add_filter('greg/meta_keys', function() {
  return [
    'exceptions' => 'my_exceptions',
    // other standard Greg meta_keys
  ];
});

This should be all Greg, and the internal Calendar class, needs.

Actual behavior

Instead we get a Fatal Error: Uncaught InvalidArgumentException: Failed to parse EXDATE - it must be a valid date, timestamp or│2.4.20' id='gform_gravityforms-js'></script>
\DateTime object in /app/wp-content/plugins/greg/vendor/rlanvin/php-rrule/src/RSet.php:290

This is because each element in a repeater is actually an array representing a row of one or more sub-fields. We need to drill down into my_exceptions and flatten it into an array of date strings and pass the strings themselves.

Steps to reproduce behavior

Specify one ore more exceptions as an ACF repeater as above.

What version of WordPress/PHP/Timber/Greg are you using?

N/A

How did you install Greg? (for example, via git clone, GitHub zip download, Composer/Packagist?)

N/A