Thanks for identifying this, and for providing a fix. Merged in, and I will roll a new release shortly.
mandclu → made their first commit to this issue’s fork.
jdleonard → credited mandclu → .
"Year" does a better job of communicating the difference, but some sites (e.g. events.drupal.org) include multiple events per year, so I think calling it "year" is too opinionated. Maybe something more generic like "Instance identifier"?
Also, it sounds like this is really more a question of admin UX, so we should think about moving this to the Event Platform queue.
I'm not sure all events would want all accepted sessions to be automatically declined, so I've decided to defer that until I can get more input.
The code in question is not using the random value for any kind of cryptographic encoding, or anything else security related.
Without any real explanation as to why this is perceived as a bug, I am closing the issue.
Does anyone know if both anonymous and authenticated users are impacted?
@benstallings should this be moved back to Needs Review? Or is further work still needed?
If possible, more explicit steps to reproduce would be appreciated. Also, MRs are appreciated. Thanks for the work to date on this!
I ended up putting in the title and description from the format form verbatim, to ensure consistency. This change has been merged into the 4.2.x branch.
This module doesn't define the calendar widget for choosing dates. The widget is inherited from Drupal core, and to the point made by @tyapchyc, this is really provided by the browser. As such, it isn't clear what this module could do to address the issue.
Thanks for the work to date on this. I assume this is ready for review?
Someone linked to this thread recently, so I thought it would be worth revisiting. Did we establish that adding an optional "suffix" property to Smart Date Formats would solve this issue? It would be some work to implement but not especially complex, I would think.
I think you could actually tell from the "datetime" value in the "#attributes" array. If it wasn't all day, the string would include the time. So, you can tell this is all day based on the length of this value.
Could I get some steps to reproduce?
I documented the steps to reproduce what you are looking for using an existing formatter. You haven't responded to the steps I took the time to document, so I can only assume you don't dispute that they work without the need for additional code.
If you prefer to user your own, custom formatter then that is also a completely valid approach, but as of now I see no reason to add it to the Smart Date codebase.
I suspect that if you try indexing field_sd_date_range you will find that this is actually the starting timestamp.
@jasa it sounds like you're having the opposite problem to the one initially reported. @marco van bemmel I suspect your issue has more to do with the way you have your product variations configured, but I confess it has been a while since I worked on a commerce setup.
As for the originally reported issue, I confess I am struggling to understand what value is being added by the paragraph that you have the Smart Date field within. You need to have sets of sets of dates for each node?
It does seem like a Javascript issue. Are there errors being reported in the console?
Both proposed solutions (created as child issues) have now been implemented, so closing this as fixed.
The 2.0.x branch has ended up being focused on content architecture and workflow changes. Also, there have been some recent revelations about the speed of the recipe runner that call into question whether or not all of the event_platform can feasibly be moved to recipes, at least until it can operate closer to the Drupal core module installer.
So, deferring these items to a later phase, although it's possible we could address some sooner. In particular, it would be good to have GSMI implemented sooner.
This could probably use a little more formatting finesse. In particular, the program items have different spacing when they aren't links (because the schedule isn't published yet). But it makes sense to merge the functional aspects for now.
With a field added to configure this in ✨ Make "Program" Information configurable Active we can now dynamically populate this information, as well as fix the links to the schedule tabs.
mandclu → created an issue.
mandclu → created an issue.
Thanks for the work here. Merged in.
mandclu → created an issue. See original summary → .
Reduced the scope by pushing the bigger tasks to child issues, and pushed the simpler changes.
Move more complex pieces to child issues, to help prevent circular blockers.
Yeah the existing JS in this module leverages those properties already for the feature that double-clicking on a time slot or date opens a form to create a new event, and I can verify that it's very convenient. The challenge is that passing it into FullCalendar is not as straightforward. The class is no problem but data attributes aren't as well documented. I think adding it within extendedProps might work.
The event popover seems designed to handle the use case of there being too many events to be shown within the calendar cell. While very useful, that seems different from what is being discussed here. I do agree that ✨ Allow opening of events in a modal dialog Active is a duplicate, so thank you for closing that.
One thing from that issue to bring here is the potential approach of just using Drupal's AJAX API. I'm not 100% sure that simply adding the markup work, but it's definitely worth a try. A big advantage of that approach would be not having to worry about additional rendering or markup in the page.
That said, there are potential advantages to something more customizable that design specifically to show an embedded view of the event information within the calendar. But if it works, the AJAX API version could be a good first step with low overhead.
Thanks Jim. I can confirm that when applied on a dev version of Drupal 11.2 the extra blocks do not appear.
Here's a new MR with a tweaked approach. In my testing it eliminates the duplicate display for datetime fields, but preserves the multivalue display for ranges.
Thanks for the additional work here. I see now (having done a little testing) that my earlier optimism that we could skip processing by generating the $uniqueKey before calling the prepareEvent method was unfounded, since the logic for generating it depends on start and end keys that will not be available until after the method has been called.
@erutan thanks to your steps to reproduce, I was able to see the problem, and validate that the proposed code resolves it.
I do see a bigger problem, however. The patch also prevents multivalue date range fields from displaying as expected. That also means that recurring Smart Date fields only display the first value.
I suspect we need a deeper refactoring, to use different logic for date fields that are ranges (where it's reasonable to expect multiple events per entity) from entities that need multiple fields for a single value (and where multiple events per entity are less likely). We currently have some of this logic within the getEventStartEndDates() method, but some different logic might be needed at a different level.
Thanks for the work on this. Merged in.
There is no code implemented here yet, so it be set to Active
Since we recently merged ✨ Allow custom fields as title Active , maybe you could try adding the markup you require in a custom field?
Since the API hasn't been functional in a supported version in quite some time, just removing it from the API documentation for now. We can explore re-implementing it if there is an expressed need for it.