Problem/Motivation
I have a site that has several SmartDate Recur rules that are supposed to create new instances when needed on cron runs. I noticed recently that while the list of instances was correct in a rule's instances field and in the UI, the new instances were not being created as rows in my content type's node__field_xxx. (In my case this is node__field_date.) Because of this, a view that looks for a current date instance was not working.
After some digging, I tracked this down to an issue with a few of the rules that had field_name set to a field that no longer existed. When the getParentEntity() method ran during cron, and $field_name was used in the entity query with a deleted field, cron stopped the process and never got to the process of making new instances. The code was checking the entity_type was defined but was not checking bundle or field name.
Steps to reproduce
Create a SmartDate Recur rule on a field. Delete the field and run cron
Proposed resolution
I added a method "validateRule" to SmartDateRule. This returns TRUE if entity type, bundle and field name are all defined and field name is defined in the type/bundle and FALSE if any of the checks fail.
I then added a call to this new method before getParentEntity is called.
In addition, I created a drush command, "smart_date_recur:prune-invalid-rules" that checks the rules and removes invalid ones from the database.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | smart_date-recur_prune_old_events.patch | 9.48 KB | foodslover |
Issue fork smart_date-3444258
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
esomething commentedComment #4
esomething commentedComment #6
mandclu commentedThanks for identifying this, and for providing a fix. I updated the code to resolve the issues identified by the CI, and I refactored the new validateRule() method to make the logic easier to follow.
Please validate that the result still works for your use case.
Comment #7
esomething commentedThank you for doing the code cleanup. I've created patches but this was my first MR.
It all looks good to me. I just made a couple of minor changes to the comments in the code to reflect the refactoring.
Comment #9
mandclu commentedGreat. Merged in, and should have a new release out shortly.
Comment #11
mandclu commented@esomething please don't open a new MR on an issue that's already merged. Your changes seem worthwhile so please open a new issue for them.
Comment #12
esomething commentedSorry for that. Would you prefer a new MR or a new issue ticket?
Comment #13
mandclu commentedIf you could file a new issue that would be great. Thanks!
Comment #15
foodslover commentedBased on a client request, I developed a patch to facilitate the bulk deletion of events older than 365 days. This patch includes configurable parameters to streamline the cleanup process, making it a valuable tool for anyone needing to manage outdated events efficiently.
Key Features:
Usage:
To execute the cleanup, run the following Drush command:
drush smart_date_recur:prune-old-events days field_name node_type email_address
Note: Please remember to run `drush cr` after executing this command to ensure that the changes are reflected on the node editing page.