Deprecated Function Warning and Slow Import Performance with Feeds iCal Module

@rockmachine Are you able to provide some details on the following?

1. How many events are in the ICS feed? How large is the file?
2. What is the data structure for one of your events? Can you share an example, as I'm interested to know how many properties are in each event.
3. What version of PHP are you running?
4. What are the system resources (RAM, CPU)?
5. Can you share code snippets of what you changed? How did you make these changes, manually or did you use a custom sub class?

This certainly seems like it could be a result from adding the "additionalFields" properties in https://www.drupal.org/project/feeds_ical/issues/3358713 ✨ Add additional fields Fixed

We did address a similar report in https://www.drupal.org/project/feeds_ical/issues/3445551 🐛 PHP 8.2: Creation of dynamic property is deprecated Fixed

However, I'm also wondering how this might be working if each event has a large number of properties, and if there are many events, if we are simply seeing the performance issues in writing watchdog logs during the import. Assuming a high number of deprecation errors per event across a high volume of events would potentially result in a large volume of writes.

As a quick test, could you disable watchdog (Database Logging module) and PHP error logging? Then try the import again to see if there are improvements?

As a potential solution for this I am thinking we make the "additionalFields" handling optional for each feed via config. That would allow users to opt in to additionalFields only if needed.

Additionally the approach you have taken to extend the IcalItem class should allow you to define all expected fields, and hence remove the deprecation warnings.

Please take some time to provide feedback here and let me know if disabling the logging improves the performance at all.

Dear Ben, thank you for your reply. I will now work on it and get all details here. You already told me a direction, the watchdog one. We just deleted 20 GBs of logfiles there, and didn't know where so many logs were coming from. We will now look into it and get back to you. This is very helpful.
Thank you very much and speak soon, your's gratefully, Flo

Hi @rockmachine - Just wanted to check in and see how things are working for you. Were any of these suggestions helpful?

Hi Ben, sorry for late reply.

All this was very helpful, thank you very much. The problem was 2 things:

1. because of cancelled imports, there was a really long queue of 250.000 elements, actually there are only 7000 elements in that calendar. i deleted the content of the "queue" in the database, and got that fixed.

2. i added some code to the "icalitem.php":

New Protected Properties Added:

In the modified file, the following protected properties were added:
$exrule
$contact
$url
$x_instant_event

and a new method was added:

A new method set was added in the modified file. This method allows setting the value of a property dynamically:

php
Code kopieren
/**
* Sets the value of a property.
*
* @param string $name
* The name of the property.
* @param mixed $value
* The value of the property.
*/
public function set($name, $value) {
if (property_exists($this, $name)) {
$this->$name = $value;
}
}
These changes introduce additional properties to the class and provide a new method for setting property values dynamically, enhancing the flexibility and functionality of the class. ​​

Right now, it is importing perfectly, and it takes like 5 mins for the 7000 calendar entries (most of them only get checked for changes).

hope this could help you fixing the module, in case my case is not too "special". i am quite new to Drupal, so i hope what i did is safe...

thank you very very much for caring, this is amazing. i think your module is one of the essential ingredients of my whole process setup. and it works perfectly now.

alll the best,

flo

@rockmachine Thanks for the follow up. Glad things are working for you now!

To future proof your code changes you should introduce a custom module: https://www.drupal.org/docs/develop/creating-modules →

The goal here would be to create a sub class of the IcalItem class that contains the properties you need to override. This will keep your code intact in your new custom module, and allow the Feeds iCal module to continue to receive updates as they are released. Otherwise you will need to refrain from updating the module which is not best practice.