I'm not sure we should limit it to 3, since a camp with more than three days may want more values. I agree that using storage entities probably makes sense, and perhaps once those are defined we could even use them to make the tabs in the schedule display a little nicer.
I've added an update hook which fixed an existing block in my test environment. Please review.
This is definitely something we're looking at. I don't think that commerce integration will be core to the Event Platform since some events / camps may still want to use Eventbrite etc. but I would love to provide an easy to use Commerce setup as a drop-in alternative
hestenet → credited mandclu → .
hestenet → credited mandclu → .
Circling back on this, @nickdjm any chance you've had a chance to review this yet? I would really like to use this module in the Drupal Event Platform → but I need something that supports taxonomy terms.
I encountered this same bug, using Leaflet on a fresh install of Drupal 11. Here are steps to reproduce the problem on a newly installed site:
- Require and apply the Locations recipe →
- Go to add a location node
- On save, you will encounter the error
Here is the full error output:
TypeError thrown with message "Drupal\Component\Utility\Html::decodeEntities(): Argument #1 ($text) must be of type string, Drupal\Core\Render\Markup given, called in /var/www/html/web/modules/contrib/leaflet/modules/leaflet_views/src/Plugin/views/style/LeafletMap.php on line 1461"
Stacktrace:
#39 TypeError in /var/www/html/web/core/lib/Drupal/Component/Utility/Html.php:393
#38 Drupal\Component\Utility\Html:decodeEntities in /var/www/html/web/modules/contrib/leaflet/modules/leaflet_views/src/Plugin/views/style/LeafletMap.php:1461
#37 Drupal\leaflet_views\Plugin\views\style\LeafletMap:processFeatureTooltips in /var/www/html/web/modules/contrib/leaflet/modules/leaflet_views/src/Plugin/views/style/LeafletMap.php:1368
#36 Drupal\leaflet_views\Plugin\views\style\LeafletMap:processFeature in /var/www/html/web/modules/contrib/leaflet/modules/leaflet_views/src/Plugin/views/style/LeafletMap.php:1116
#35 Drupal\leaflet_views\Plugin\views\style\LeafletMap:processEntityFeatures in /var/www/html/web/modules/contrib/leaflet/modules/leaflet_views/src/Plugin/views/style/LeafletMap.php:999
#34 Drupal\leaflet_views\Plugin\views\style\LeafletMap:processGeofield in /var/www/html/web/modules/contrib/leaflet/modules/leaflet_views/src/Plugin/views/style/LeafletMap.php:940
#33 Drupal\leaflet_views\Plugin\views\style\LeafletMap:processResultsGroups in /var/www/html/web/modules/contrib/leaflet/modules/leaflet_views/src/Plugin/views/style/LeafletMap.php:897
#32 Drupal\leaflet_views\Plugin\views\style\LeafletMap:render in /var/www/html/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php:2203
#31 Drupal\views\Plugin\views\display\DisplayPluginBase:render in /var/www/html/web/core/modules/views/src/ViewExecutable.php:1593
#30 Drupal\views\ViewExecutable:render in /var/www/html/web/core/modules/views/src/Plugin/views/display/Page.php:201
#29 Drupal\views\Plugin\views\display\Page:execute in /var/www/html/web/core/modules/views/src/ViewExecutable.php:1690
#28 Drupal\views\ViewExecutable:executeDisplay in /var/www/html/web/core/modules/views/src/Element/View.php:81
#27 Drupal\views\Element\View:preRenderViewElement in /var/www/html/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php:107
#26 call_user_func_array in /var/www/html/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php:107
#25 Drupal\Core\Render\Renderer:doTrustedCallback in /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php:830
#24 Drupal\Core\Render\Renderer:doCallback in /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php:387
#23 Drupal\Core\Render\Renderer:doRender in /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php:203
#22 Drupal\Core\Render\Renderer:render in /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php:238
#21 Drupal\Core\Render\MainContent\HtmlRenderer:Drupal\Core\Render\MainContent\{closure} in /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php:593
#20 Drupal\Core\Render\Renderer:executeInRenderContext in /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php:231
#19 Drupal\Core\Render\MainContent\HtmlRenderer:prepare in /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php:128
#18 Drupal\Core\Render\MainContent\HtmlRenderer:renderResponse in /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php:90
#17 Drupal\Core\EventSubscriber\MainContentViewSubscriber:onViewRenderArray in /var/www/html/vendor/symfony/event-dispatcher/EventDispatcher.php:246
#16 Symfony\Component\EventDispatcher\EventDispatcher:Symfony\Component\EventDispatcher\{closure} in /var/www/html/vendor/symfony/event-dispatcher/EventDispatcher.php:206
#15 Symfony\Component\EventDispatcher\EventDispatcher:callListeners in /var/www/html/vendor/symfony/event-dispatcher/EventDispatcher.php:56
#14 Symfony\Component\EventDispatcher\EventDispatcher:dispatch in /var/www/html/vendor/symfony/http-kernel/HttpKernel.php:188
#13 Symfony\Component\HttpKernel\HttpKernel:handleRaw in /var/www/html/vendor/symfony/http-kernel/HttpKernel.php:76
#12 Symfony\Component\HttpKernel\HttpKernel:handle in /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php:53
#11 Drupal\Core\StackMiddleware\Session:handle in /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php:48
#10 Drupal\Core\StackMiddleware\KernelPreHandle:handle in /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php:28
#9 Drupal\Core\StackMiddleware\ContentLength:handle in /var/www/html/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php:32
#8 Drupal\big_pipe\StackMiddleware\ContentLength:handle in /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:116
#7 Drupal\page_cache\StackMiddleware\PageCache:pass in /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php:90
#6 Drupal\page_cache\StackMiddleware\PageCache:handle in /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php:48
#5 Drupal\Core\StackMiddleware\ReverseProxyMiddleware:handle in /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php:51
#4 Drupal\Core\StackMiddleware\NegotiationMiddleware:handle in /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php:36
#3 Drupal\Core\StackMiddleware\AjaxPageState:handle in /var/www/html/web/modules/contrib/whoops/src/StackMiddleware/WhoopsMiddleware.php:49
#2 Drupal\whoops\StackMiddleware\WhoopsMiddleware:handle in /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php:51
#1 Drupal\Core\StackMiddleware\StackedHttpKernel:handle in /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php:709
#0 Drupal\Core\DrupalKernel:handle in /var/www/html/web/index.php:19
I also found that reverting back to the previous release resolved the issue, but the patch gets things working as expected too.
teknorah → credited mandclu → .
borisson_ → credited mandclu → .
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.