Closed (duplicate)
Project:
Fullcalendar View
Version:
8.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Sep 2018 at 14:25 UTC
Updated:
18 Sep 2024 at 12:13 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
dylan donkersgoed commentedI noticed that fullcalendar_view doesn't work with date_recur. I believe it has the same root cause as this issue.
I did some digging and it seems like this is happening because template_preprocess_views_view_fullcalendar() - which actually populates the variables sent through to the calendar - is loading the entity and retrieving the fields from there. So the fields don't go through the actual views rendering process. I'm not really sure why this is?
I'm attaching a patch that renders the fields via the views field handler so that preprocessing etc. will run. This also has the benefit that fields besides the ones hardcoded in template_preprocess_views_view_fullcalendar() should work.
I've left an option (checked by default, at least for now) to use the entity fields to prevent old views from breaking.
Comment #3
dylan donkersgoed commentedReroll for latest dev version.
Comment #4
mingsongHi Dylan,
Thank you so much for the idea and your patch.
I will have a close look at it when I have a chance.
Comment #5
mingsongHi Dylan,
I tested your patch above #3, the problem with the patch is that we can't allow user to rewrite the start date and end date field which must be a valid date format which is accepted by FullCalendar Js. Otherwise, the calendar won't work.
But we still can allow user to rewrite other fields, for example pop-up description field.
So I amended your patch and upload here.
Thanks for you work and the great ideal.
Comment #7
mingsongI commit the patch to Dev version.
You can get it by downloading the latest Dev version.
Comment #8
dylan donkersgoed commentedI see where you're coming from there, I can definitely see that causing a lot of confusion. But not having the option at all hurts the module's interoperability with views and other modules. It also breaks my usecase, though that could possibly be handled by adding another exception for date_recur in a separate issue.
Would it be acceptable if the settings form included a message warning about that or perhaps even validated the date format somehow? E.g. I know the charts module will print a warning instead of displaying the view if values the view is passing into the charts JS are invalid.
I'm attaching a new patch rerolled against the latest dev. It's more or less the same as the old one so shouldn't be merged in yet.
Comment #9
fls-pcate commentedI've run into an issue with the latest dev version with this feature. When I turn on field rewriting w/ HTML content, the month view renders the HTML correctly, but switching to the week, day, list views show the HTML as plain text.
Comment #10
dylan donkersgoed commentedI'm adding a temporary patch to fix a warning related to $view->row_index when using patch #3 with 8.x-2.0-rc10. It looks like this fix is already in the latest dev version.
Comment #11
dylan donkersgoed commentedHere's a re-roll of my path from #8 for the latest dev version. As before, this shouldn't actually be merged in yet.
Comment #12
mingsongDuplicated with #3091643: Rewriting with replacements patterns doesn't work