Problem/Motivation

As documented in the user guide:

In the display settings for a recurring date field, there is the option to display the next instance separately. When determining which is the next instance, the module will check for an exposed filter with the name of the field (for example, ?field_date=2022-08-22), and if it finds one, will display the next value greater than that value. If no such filter is found, it will display the next value greater than the current time.

Using the machine name of the field as a exposed filter could potentially present a security risk. It's also entirely unnecessary for site visitors to see the field name like this, and makes the URL path uglier (less elegant) than it needs to be.

Proposed resolution

Firstly, allow the filtering to additionally work when the leading 'field_' part of the machine name of the field is omitted from the URL parameter key. So a smart date field with the machine name 'field_smart_date' can be filtered by either URL parameters 'field_smart_date=2026-12-25' or 'smart_date=2026-12-25'.

Secondly, allow the key of the URL parameter for the exposed filter to be freely defined through the admin UI, using a text field in the field Field Formatter, giving the site builder full control of what needs to be exposed in the URL parameters.

The filtering would first check the custom text field for a URL parameter key match. If this fails, it would check if the machine name of the field without the leading 'field_' was used as a URL parameter key. If that fails, it would check for the full machine name used as a URL parameter key, so that these changes don't break anything for existing sites using recurring smart date fields and exposed filters on them.

User interface changes

Addition of a 'filter parameter key' text input in the Field Formatter form.

Data model changes

Addition of a filter_parameter_key variable in the smart_date_recur.schema.yml config.

Issue branch to come shortly...

Issue fork smart_date-3581810

Command icon 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:

About issue forks

Comments

natts created an issue. See original summary.

natts opened merge request !200

natts’s picture

natts
He/they
Primary language English
Location London
commented
Status: Active » Needs review

mandclu made their first commit to this issue’s fork.

  • mandclu committed d6a035e4 on 4.3.x authored by natts 
    feat: #3581810 Improve exposed filter for recurring date

By: natts
By:...
mandclu’s picture

mandclu commented
Version: 4.2.4 » 4.3.x-dev
Status: Needs review » Fixed

I got the CI checks clean and added tests, because I do think this is solid improvement over the way the filter works today. That said, I do have one nit over the current description for the new setting:

Leaving this empty will disable this custom filtering.

I don't see any evidence in the code that the above is true. I understand that for legacy reasons we default back to the field name (also allowing for "field_" to be omitted — nice!) but it doesn't seem as though leaving the setting blank will disable the filtering. If anything it seems more like using an unguessable filter_parameter_key value like "dfjghdkfjhgdjkfhgkdjfhgdkj" will effectively disable the filtering because only someone who know the exact name can trigger the filter.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

natts’s picture

natts
He/they
Primary language English
Location London
commented

What I wrote in that field description didn't mean that it will disable all filtering, just that specific custom filtering.

Thanks for accepting this and adding tests though!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.