vinjoy707

@dshaykewich,

I’m happy that I was able to help and can only sympathize with your plight. The extensive logging of deprecation notices etc. after moving to PHP8 was a frustration for me too. I wouldn’t feel too bad about getting your hands dirty with plugin edits if it means your site operates more smoothly and your host is not overwhelmed with enormous log files.

The biggest challenge we face is deciding how to move forward. I doubt very much whether the developers at Time.ly have any incentive or motivation to upgrade the legacy plugin to support PHP8. It’s not just their own code, but the other open source projects they have leveraged to build their product (e.g. iCalcreator, Twig). Updating the core code to support PHP8 plus the newest versions of these other tools is likely quite a chore.

Good luck to you (and all the long-term users out there struggling with this issue).

@janzeman, I’m happy to have helped. If your use case involves managing less than 100 events then I would expect that the new hosted platform mode would still be worth a look. The free level of the plugin does require you to have an account and limits the number of events to 100.

I still like the way their calendar presents to site visitors and the modal event detail overlay is a pleasant UX. YMMV, but I would suggest taking some time (45-60+/- minutes) to export your old events and upload them to your new account. A test drive of the hosted platform is worth the effort.

While it didn’t work out for our scenario it does work well. Good luck!

@janzeman, I totally agree that the support is failing long-time users.

Now that Timely has morphed into a full-blown Event Promotion, Management, and Ticketing company they have no interest in maintaining the plugin as a way to create/edit/manage events in your WordPress environment. In their minds the plugins works flawlessly for the intended usage scenario (i.e. a WP frontend to their hosted platform). If you do a completely fresh install of v3.0.01 no CPTs are added and no new tables are added to your WP database. The plugin dynamically embeds IFRAME’s of the Timely hosted platform for admin such as adding/editing events and on the front end to display the calendars. All data is stored on their servers. The code generating the errors is not used in this scenario so server logs are mostly clear.

Unfortunately, for long-time users, when we upgrade we end up using the old code that is borking with deprecation notices on any modern hosting platform using PHP 8.x. This old code is both their own source code plus in the open source libraries they have failed to update such as twig, iCalcreator etc.

I’m not hopeful that anything meaningful will be done – I’m sure they would be much happier if all users migrated to their hosted platform. I don’t blame them for wanting to get ROI on their investment in servers and other infrastructure for their platform. It’s a shame this plugin was good but the value proposition of the new hosted platform does not add up for our usage because to import a single feed requires an upgrade to the $650/yr plan.

More updates regarding 8.x support. I have found there are a number of patches that need to be made in upstream libraries included in the ai1ec plugin. The included versions of libraries for the ics/ical parsing as well as twig are older and integration of the newer PHP 8.x stable versions is likely quite an endeavor. It may be a while before they are updated in this plugin.

In addition to the changes originally outlined, the creation of Dynamic Properties has been deprecated in PHP 8.2. See this link for details.
https://php.watch/versions/8.2/dynamic-properties-deprecated

To resolve the extensive logging of these notices add #[AllowDynamicProperties] attribute to the class definition, for example:

#[AllowDynamicProperties]
class User {
  private int $uid;
}

Make the change to include the #[AllowDynamicProperties] the following files:
lib/http/request.php
lib/iCal/helper/SG_iCal_Recurrence.php
lib/scheduling/utility.php
vendor/lessphp/lessc.inc.php

More updates regarding 8.x support. I have found there are a number of patches that need to be made in upstream libraries included in the ai1ec plugin. The included versions of libraries for the ics/ical parsing as well as twig are older and integration of the newer PHP 8.x stable versions is likely quite an endeavor. It may be a while before they are updated in this plugin.

In addition to the changes originally outlined, the creation of Dynamic Properties has been deprecated in PHP 8.2. See this link for details.
https://php.watch/versions/8.2/dynamic-properties-deprecated

To resolve the extensive logging of these notices add #[AllowDynamicProperties] attribute to the class definition, for example:

#[AllowDynamicProperties]
class User {
  private int $uid;
}

Make the change to include the #[AllowDynamicProperties] the following files:
lib/http/request.php
lib/iCal/helper/SG_iCal_Recurrence.php
lib/scheduling/utility.php
vendor/lessphp/lessc.inc.php

More updates regarding 8.x support. I have found there are a number of patches that need to be made in upstream libraries included in the ai1ec plugin. The included versions of libraries for the ics/ical parsing as well as twig are older and integration of the newer PHP 8.x stable versions is likely quite an endeavor. It may be a while before they are updated in this plugin.

In addition to the changes originally outlined, the creation of Dynamic Properties has been deprecated in PHP 8.2. See this link for details.
https://php.watch/versions/8.2/dynamic-properties-deprecated

To resolve the extensive logging of these notices add #[AllowDynamicProperties] attribute to the class definition, for example:

#[AllowDynamicProperties]
class User {
  private int $uid;
}

Make the change to include the #[AllowDynamicProperties] the following files:
lib/http/request.php
lib/iCal/helper/SG_iCal_Recurrence.php
lib/scheduling/utility.php
vendor/lessphp/lessc.inc.php

@ramon-fincken, I received the same message from the Time.ly support team and also noticed they directed me download the 3.0.1 version of the plugin. As you noted, it is same installed version as reported by folks on this forum.

I am continuing my testing with the patches identified by @leroyrosale in his 3.0.0 fork and I look forward to an update form the plugin developer..

For any others experiencing this issue here are some suggestions…

Offered with no warranty, please test in your own environment before implementation in production sites… YMMV (-:

With much gratitude to @leroyrosales and his forked 3.0.0 version at https://github.com/leroyrosales/all-in-one-event-calendar

To mitigate many of the Deprecation notices being generated in the version 3.0.1 of the plugin you will need to update a number of functions in two library scripts to include the #[\ReturnTypeWillChange] attribute.

See: https://www.php.net/manual/en/class.returntypewillchange.php

Also see this very detailed StackOverflow answer for more info and potentially more suggestions about resolving this issue permanently rather than simply supressing the deprecation notices:
https://stackoverflow.com/questions/71133749/reference-return-type-of-should-either-be-compatible-with-or-the-re

For example,

/**
 * @overload ArrayAccess::offsetGet()
 */
#[\ReturnTypeWillChange]
public function offsetGet( $offset ) {
    return $this->get_scalar( $offset );
}

Change \lib\http\request\abstract.php to update these functions
public function offsetGet
public function offsetSet
public function offsetUnset

Change lib\iCal\helper\SG_iCal_Line.php to update these functions
public function offsetExists
public function offsetGet
public function offsetSet
public function offsetUnset
public function count
public function getIterator

For any others experiencing this issue here are some suggestions…

Offered with no warranty, please test in your own environment before implementation in production sites… YMMV (-:

With much gratitude to @leroyrosales and his forked 3.0.0 version at https://github.com/leroyrosales/all-in-one-event-calendar

To mitigate many of the Deprecation notices being generated in the version 3.0.1 of the plugin you will need to update a number of functions in two library scripts to include the #[\ReturnTypeWillChange] attribute.

See: https://www.php.net/manual/en/class.returntypewillchange.php

Also see this very detailed StackOverflow answer for more info and potentially more suggestions about resolving this issue permanently rather than simply supressing the deprecation notices:
https://stackoverflow.com/questions/71133749/reference-return-type-of-should-either-be-compatible-with-or-the-re

For example,

/**
 * @overload ArrayAccess::offsetGet()
 */
#[\ReturnTypeWillChange]
public function offsetGet( $offset ) {
    return $this->get_scalar( $offset );
}

Change \lib\http\request\abstract.php to update these functions
public function offsetGet
public function offsetSet
public function offsetUnset

Change lib\iCal\helper\SG_iCal_Line.php to update these functions
public function offsetExists
public function offsetGet
public function offsetSet
public function offsetUnset
public function count
public function getIterator

For any others experiencing this issue here are some suggestions…

Offered with no warranty, please test in your own environment before implementation in production sites… YMMV (-:

With much gratitude to @leroyrosales and his forked 3.0.0 version at https://github.com/leroyrosales/all-in-one-event-calendar

To mitigate many of the Deprecation notices being generated in the version 3.0.1 of the plugin you will need to update a number of functions in two library scripts to include the #[\ReturnTypeWillChange] attribute.

See: https://www.php.net/manual/en/class.returntypewillchange.php

Also see this very detailed StackOverflow answer for more info and potentially more suggestions about resolving this issue permanently rather than simply supressing the deprecation notices:
https://stackoverflow.com/questions/71133749/reference-return-type-of-should-either-be-compatible-with-or-the-re

For example,

/**
 * @overload ArrayAccess::offsetGet()
 */
#[\ReturnTypeWillChange]
public function offsetGet( $offset ) {
    return $this->get_scalar( $offset );
}

Change \lib\http\request\abstract.php to update these functions
public function offsetGet
public function offsetSet
public function offsetUnset

Change lib\iCal\helper\SG_iCal_Line.php to update these functions
public function offsetExists
public function offsetGet
public function offsetSet
public function offsetUnset
public function count
public function getIterator

I am also experiencing the same issue, for example:

[05-Apr-2024 19:44:50 UTC] All-in-One Event Calendar: Return type of Ai1ec_Abstract_Query::offsetSet($offset, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice @ /home/n985c25/wp-content/plugins/all-in-one-event-calendar/lib/http/request/abstract.php:215 #8192
[05-Apr-2024 19:44:50 UTC] All-in-One Event Calendar: Return type of Ai1ec_Abstract_Query::offsetUnset($offset) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice @ /home/n985c25/wp-content/plugins/all-in-one-event-calendar/lib/http/request/abstract.php:222 #8192
[05-Apr-2024 19:44:50 UTC] All-in-One Event Calendar: preg_split(): Passing null to parameter #3 ($limit) of type int is deprecated @ /home/n985c25/wp-content/plugins/all-in-one-event-calendar/lib/query/helper.php:156 #8192
[05-Apr-2024 19:44:50 UTC] All-in-One Event Calendar: Return type of Ai1ec_Abstract_Query::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice @ /home/n985c25/wp-content/plugins/all-in-one-event-calendar/lib/http/request/abstract.php:198 #8192
[05-Apr-2024 19:44:50 UTC] All-in-One Event Calendar: Return type of Ai1ec_Abstract_Query::offsetGet($offset) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice @ /home/n985c25/wp-content/plugins/all-in-one-event-calendar/lib/http/request/abstract.php:208 #8192
[05-Apr-2024 19:44:50 UTC] All-in-One Event Calendar: Return type of Ai1ec_Abstract_Query::offsetSet($offset, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice @ /home/n985c25/wp-content/plugins/all-in-one-event-calendar/lib/http/request/abstract.php:215 #8192
[05-Apr-2024 19:44:50 UTC] All-in-One Event Calendar: Return type of Ai1ec_Abstract_Query::offsetUnset($offset) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice @ /home/n985c25/wp-content/plugins/all-in-one-event-calendar/lib/http/request/abstract.php:222 #8192

After a few hours the PHP error log will get to over 1GB in size.

I have also submitted information using the form linked above.

It seems an a tag will mess up the code block so just imagine there is an opening a tag between the first noscript tags with an href attribute similar to {{ event.permalink | e(‘html_attr’) }}.

The closing a tag is between another noscript tag

The conversion of the tag above rendered the code incorrect so here it is again.

									<span class="ai1ec-event-title">
  <noscript>
    
  </noscript>
  {{ event.filtered_title | raw }}
  {% if show_location_in_title and event.venue is not empty %}
  <span class="ai1ec-event-location">
    {{ text_venue_separator | format( event.venue ) }}
  </span>
{% endif %}

  <noscript>
    
  </noscript>
</span>

Further testing has shown that relegating the ai1ec_render_js script to the footer rather than the header when added with wp_enqueue_script seems to provide a consistent fix. Refer to the code in \all-in-one-event-calendar\app\controller\javascript.php at around line 763 and update false to true to force the script to the footer.

Further testing has shown that relegating the ai1ec_render_js script to the footer rather than the header when added with wp_enqueue_script seems to provide a consistent fix. Refer to the code in \all-in-one-event-calendar\app\controller\javascript.php at around line 763 and update false to true to force the script to the footer.