I would still be happy to help @eelkeblok maintain this module. That said, I am thankful for the D11 release.
One other possibility would be to make more general-purpose version of this theme, and then make this project a more opinionated subtheme of that. I don't really have the bandwidth to take that on at the moment, however.
Maybe it would be more appropriate to discuss getting Same Page Preview into Drupal CMS?
The benefit of Same Page Preview is that it allows Drupal to incorporate a feature of competing CMS solutions that user testing has identified gives content authors a higher degree of confidence that they are using the system properly. Being able to see the rendered version of a piece of content as they are filling out a structured form does provide value to the user.
If XB is planned to offer live preview while filling out a content form (e.g. not working with components etc) then Same Page Preview is not needed, but I think we should validate that before we close this issue.
Another +1 from me.
The scope of changes in the MR may be wider than the maintainers are looking for, and if so I would be happy to tweak as needed. The changes in there do meet my need for creating a condition that works for moderated taxonomy terms, however.
This may need a dedicated project, similar to Scheduler for ECK →
+1 for this idea. Particularly with ECA I could see this being extremely useful.
It turns out this didn't need a lot of code, but it does require some changes to the Event Platform to work as expected. I'll get an issue created there and merge in those changes before merging in the updates here.
Thanks for fixing this @bernardm28!
The code in the MR adds the inputs for a site builder to upload the graphic they want to use, but for some reason the submit handler never fires, and without it the theme settings form will always throw an error.
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.