I tried making that change within /components/site-hero/site-hero.[s]css but it doesn't seem to take.
I've uploaded two patch files generated by eslint, one before and one after the changes in the MR!621. It's worth noting that among the places eslint suggests removing the 'use strict' and the surrounding newlines, not all of them are within the modules. I have updated the issue title to reflect the fact that eslint suggests removal of 'use strict' more broadly.
This new MR focuses instead on the patterns identified by eslint for removal. The second patch file shows that all cited uses of 'use strict' are resolved by the new MR.
I would be OK with reverting this change and opening a new MR with a more targeted implementation.
Given that the intended UI to apply recipes is the Project Browser, we should consider whether it would make more sense to move this issue there.
A fork of the most recent FLDC theme has been created as the new Event Horizon → project. More work needs to be done in order to make it configurable, and to make its components dynamically populated through configuration available in the Event Platform.
Detailed feedback would be helpful in the Event Horizon issue queue.
To clarify, the issue is that in some environments a site will default to a UTC timezone, which can cause unexpected behavior, for example with add to calendar links. I spoke to @rfay about this and DDEV has been updated to inherit the timezone of the client computers which should help when Drupal CMS is installed using DDEV.
New installs will always have a timezone set, but I would suggest that if after install the timezone is set to UTC, we add dashboard notice to verify that the timezone is set properly.
This recipe is not designed to work with Drupal CMS. It is designed to work with the contrib Events recipe → . There was an issue 📌 Suggest Event add-ons Active that would have brought this calendar recipe and some others into Drupal CMS, but there was a decision to deviate the events implementation architecture enough from this recipe. This recipe is also compatible with the hundreds of sites that are running the Smart Date Starter Kit → , so the Drupal CMS decision means that we effectively have a schism, and it is no longer possible to have a single recipe that will work with both architectures. If someone wants to create and maintain a new recipe that would implement an implementation of Fullcalendar specifically for Drupal CMS, they are free to do so.
FWIW a fresh install of Fullcalendar on Drupal CMS should work pretty well out of the box, though I haven't personally tested this.
Did you use composer to add the recipe to your site?
Thanks for identifying this, and for providing a fix. Merged in and I will roll a new release.
Good point. I have created a child issue for this.
Right, $form at that point is really a jQuery object. There would need to be a much more significant rewrite to remove the dependency here on jQuery.
Moving this back to RTBC on the previous MR.
Merged in.
Moving this to a new 2.0.x branch.
The schedule tabs still aren't working as intended, but that could be worked on in a separate issue.
Personally I tend to think think this should be rolled into a new major version, because it will have no backwards compatibility with the current 1.x branches. Open to other perspectives, though.
As detailed in the relevant documentation, the #dropbutton is not a label, but references the element to which it should be attached. As such, I don't believe that "action" in this context should be capitalized or translated.
Good catch on the change record. I have updated it, so moving this back to NR.
I had no issue using composer to pull this module into a site running on PHP 8.3, so I don't understand the need for the proposed changes. Perhaps some steps to reproduce on a clean install of Drupal would help.
I'm not against dropping support for Drupal 8 and 9, but considering no actual code changes are needed to support Drupal 11, I don't see a reason to drop support for older versions at this point.
Thank you!
Thanks @liam-morland. I also now have an MR up at
📌
Remove "use strict" statements from JS files
Active
. I was thinking once that is merged, it would be good to start trying to start chipping away at the no-jquery where direct replacements exist. Open to other suggestions, however.
I made a new MR that uses the native Javascript method instead. Here is some documentation on the method I am suggesting.
Wouldn't it make more sense to use the vanilla JS checkValidity() check and do away with the jQuery valid()?
I could not reproduce the issue reported here. I had the module installed and used it successfully in a view's contextual filter. I removed the contextual filter then uninstalled the module. The rest of the site continued to work as expected, including things like pathauto patterns that rely on tokens. Visiting the status page did not indicate any problems either.
It's also worth pointing out that the svg icons are hardcoded to use CSS variables if available (e.g. --color1) that are likely to have collisions because they are so generic. It would be better if these could be prefixed to avoid unintended collisions.
Theoretically we could make this less daunting by having smaller child issues that each address specific issues. For example, one issue could remove .eslintrc.json, another could remove all the "use strict" statements, and so on. It would create a sizeable list of child issues, and each one would probably impact nearly the same number of files, but each issue would be much easier to review because it would be the same pattern everywhere.
I'd be happy to get started with this if there's agreement on the approach.
It's possible this could be refactored to make value comparisons more reliable in general for Likert elements, but the changes here get the table display working again.
What kind of field is it?
mandclu → created an issue. See original summary → .
Updating issue status
This was addressed in ✨ Provide a fieldable way to score sessions Active .
Merged this into a new 1.1.x branch. Additional refinements are likely needed, but we can deal with those in other issues.
Ultimately these are pretty safe changes, so merging them in for now and we can add refinements as needed.
The MR uses a webform to rate sessions, with only an entity reference field and a Likert field for the actual scoring. The latter captures the actual ratings, and can be quickly customized for whatever evaluation rubric a particular camp may want. Note that proper aggregation of the Likert field (for the sake of ordering based on average score) requires applying the patch from ✨ Add an "average" formatter for Likert elements Active .
+1 for the changes in !MR3. I can verify that with these changes the module works as intended in Drupal 11.