🇺🇸United States @foodslover

Based 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:

1. - Bulk deletion of outdated events while preserving recent ones.
2. - Automatic removal of expired recurrence rules that are no longer in use.
3. - Updates to recurring events to ensure accurate start and end dates.
4. - Email summary reports generated upon completion for tracking and verification.

Usage:

To execute the cleanup, run the following Drush command:
```sh
drush smart_date_recur:prune-old-events 365 field_name event 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.

After upgrading the module from v2.1 to v2.2, we encountered issues where the bulk editing pages became non-functional.

Error: Call to undefined method Drupal\views_bulk_operations\Form\ConfigureAction::getEntity() in simplify_hide_widget() (line 588 of /var/www/html/docroot/modules/contrib/simplify/simplify.module).

#0 /var/www/html/docroot/modules/contrib/simplify/simplify.module(335): simplify_hide_widget('comment', Array, Object(Drupal\Core\Form\FormState))
#1 /var/www/html/docroot/core/lib/Drupal/Core/Extension/ModuleHandler.php(552): simplify_field_widget_complete_comment_default_form_alter(Array, Object(Drupal\Core\Form\FormState), Array)
#2 /var/www/html/docroot/core/lib/Drupal/Core/Field/WidgetBase.php(156): Drupal\Core\Extension\ModuleHandler->alter('field_widget_co...', Array, Object(Drupal\Core\Form\FormState), Array)
#3 /var/www/html/docroot/core/lib/Drupal/Core/Entity/Entity/EntityFormDisplay.php(190): Drupal\Core\Field\WidgetBase->form(Object(Drupal\comment\CommentFieldItemList), Array, Object(Drupal\Core\Form\FormState))
#4 /var/www/html/docroot/modules/contrib/views_bulk_edit/src/Form/BulkEditFormTrait.php(144): Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm(Object(Drupal\node\Entity\Node), Array, Object(Drupal\Core\Form\FormState))
#5 /var/www/html/docroot/modules/contrib/views_bulk_edit/src/Form/BulkEditFormTrait.php(93): Drupal\views_bulk_edit\Plugin\Action\ModifyEntityValues->getBundleForm('node', 'blog', 'Blog entry', Array, Object(Drupal\Core\Form\FormState), 1)
#6 /var/www/html/docroot/modules/contrib/views_bulk_edit/src/Plugin/Action/ModifyEntityValues.php(156): Drupal\views_bulk_edit\Plugin\Action\ModifyEntityValues->buildBundleForms(Array, Object(Drupal\Core\Form\FormState), Array)
#7 /var/www/html/docroot/modules/contrib/views_bulk_operations/src/Form/ConfigureAction.php(92): Drupal\views_bulk_edit\Plugin\Action\ModifyEntityValues->buildConfigurationForm(Array, Object(Drupal\Core\Form\FormState))

....

Rolling back to v2.1 resolved the problem, restoring functionality as expected.

Upon comparing the code between v2.1 and v2.2, I identified several issues in the original implementation of the simplify_hide_widget() function in v2.2. These issues made the function error-prone, particularly in scenarios involving bulk operations or interactions with the comment widget.

To address these problems, I modified the `simplify_hide_widget()` function to resolve specific issues I identified. If the main maintainer believes any of these changes are unnecessary or can be improved, please feel free to adjust the code as needed.

1. Missing Validation: Assumed `$form_state` always had a valid form object and entity, causing errors in unsupported contexts.
- Fix: Added checks to ensure validity before proceeding.

2. Bundle Type Handling Relied on `$entity->type` without ensuring its presence.
- Fix: Used `hasField` and null-safe checks to handle entities without a `type` field.

3. Form Structure Assumptions: Assumed `$form['widget'][0]['#attributes']` always existed.
- Fix: Added checks and created structure if missing.

4. Undefined Config Values: `_simplify_get_config_value` calls lacked default values.
- Fix: Added default values (`[]`) to prevent undefined errors.

5. Loose Type Checks: `in_array` checks were not type-safe.
- Fix: Enabled strict type checking.

This adjustment ensures a slight delay before initiating the download, improving the user experience and preventing potential browser restrictions on automatic downloads in Drupal 10.3.10.

Here’s the solution I used—I hope it helps!

1. **Update the Component Version**:
First, I updated the component to version `1.0.0-rc5`. Then, to resolve the issue in my custom module, `module_abc`, I applied the approach from [this patch]( https://www.drupal.org/files/issues/2024-07-10/3460633-02-unable-to-find... → ). Following the file structure in this patch, I mirrored the setup used for `component_example`.

2. **Add the `components.yml` Configuration File**:
I created a `components.yml` configuration file for the custom component within `module_abc`. According to the example in the patch, the path should look like this:

```plaintext
/docroot/modules/custom/custom_module_abc/modules/module_abc/components//.component.yml
```

Inside this file, I used content similar to the patch:

```yaml
name: module abc
description: '......'
props:
type: object
properties: {}
```

3. **Create the Required `.twig` Template File**:
In Drupal 10.3 and above, each component also requires a corresponding `.twig` template file. I added this `.twig` file in the same directory as the `.component.yml` file and named it according to the component:

```plaintext
/docroot/modules/custom/custom_module_abc/modules/module_abc/components//.twig
```

Inside the `.twig` file, I included the following basic structure:

```twig
{#
/**
* @file
* Required Twig template for components as of Drupal 10.3.
*/
#}
```

After creating this empty `.twig` file, the error was resolved, and no further code changes were needed. The module is now functioning as expected.

This patch is compatible with both v2.0.2 and v2.0.3.

Upon updating to Drupal 10.2.5, it became evident that the current patch ( https://www.drupal.org/project/drupal/issues/2325899#comment-14900128 🐛 UI fatal caused by views argument handlers no longer can provide their own default argument handling Needs work ) was no longer compatible. In response, I have refined the patch code to ensure its compatibility with the latest Drupal version, 10.2.5. My objective is to make this revised code advantageous for individuals utilizing Drupal 10.2.5 and in need of this particular functionality.

Drupal : 10.2.5
php: 8.2.15

The changes made in Patch #18 & #20 caused an issue where the system attempted to find an entity type called "view_id," which doesn't actually exist in Drupal. This led to an error message: `Drupal\Component\Plugin\Exception\PluginNotFoundException: The "view_id" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition()` when a user accessed the URL `/admin/config/search/redirect`.

The latest patch has fixed these bugs, ensuring that when using the current version of Drupal 9.5 & 10.1.6, this error no longer occurs when accessing the specified URL.

This revised code attempts to utilize entity titles for internal URLs. It checks if the provided entity type exists in Drupal before attempting to load an entity. If an entity is loaded successfully, it checks for translations and retrieves the title or name field. For cases where route parameters are absent, it loads links by route and sets the root menu item's title.

Key modifications:

1. Check Entity Type Definition: Before attempting to load an entity, hasDefinition() checks if the provided entity type exists in Drupal. This prevents attempting to load non-existent entity types.
2. Entity Loading and Field Handling: After confirming the existence of the entity type, getStorage() is used to retrieve the entity storage handler.