samalander → created an issue.
Sounds like it would take care of the problem.
But maybe all URL parameters should be URL-encoded, so they get passed to the right place; not just destination. In my case, destination was causing issue, but other parameters could cause other kinds of problems.
I moved the required-indicator from markup to styles in the form-element and fieldset components of the issue branch so that the #states core API can modify it.
I used the Claro method as a model because it lets us use a Bootstrap variable for the indicator's color.
I had to add .css files to the components. The existing .scss files are ignored by the single directory components functionality when rendering the component in a starterkit-created theme. They also do not get preprocessed by npm when processing the child theme.
I had a discussion with doxigo → on Slack (in the #radix channel starting 2024-06-26) about that. There are multiple ways to go. I chose to just add the matching .css files as that was the simplest way to get it working for this issue.
Another issue should probably be created to find the best solution for the whole theme and apply it. (For example, the alert component has code in its .scss file that is currently not used.)
samalander → created an issue.
samalander → created an issue.
samalander → created an issue.
The previous patches didn't suppress the error message for me.
I looked at the calling code, and it requires the keyed array to function, so getTokenArgument should always return it. The merge request (9) I just submitted does that.
samalander → made their first commit to this issue’s fork.
PHP7 is EOL, true. According to the same page, it remains the most widely used version with nearly 50% usage and is supported by Ubuntu 20.04 LTS (which is what we use) until April 2025, well after Drupal 9 reaches its EOL.
I wasn't necessarily asking to maintain compatibility until the very end. I don't mind staying behind for a few months. I'm worried about what could happen if a security flaw is discovered since installing the updated version won't be possible.
Anyway, I understand your POV. Thanks for the quick response.
Hi, sorry to be reopening a closed issue.
PHP 7.4 is still supported by Drupal 9 until its end of life.
https://www.drupal.org/docs/getting-started/system-requirements/php-requ... →
Dropping support early means users like me will be unable to receive future updates, especially security updates.
I don't think something like this should be done in a minor release. Especially since issue #3310687 → (Drop PHP7 compatibility) says to only do it for the 3.x branch for now.
Feel free to re-close; I'll just be over here with version 8.x-2.33, crossing my fingers that no security flaw is found in the next 7 months.