Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
In FullCalendar, there is a need to select on of the added fields as "THE DATE FIELD". Similarly, you can specify one as the Title and the URL to override the entity title and URL.
I've reused this mechanism on several client sites, and I'm tired of doing that without abstracting it :)
Comment | File | Size | Author |
---|---|---|---|
#20 | views-1765824-20.patch | 576 bytes | tim.plunkett |
#19 | views-1765824-18-D7-do-not-test.patch | 576 bytes | dawehner |
#18 | views-1765824-18-D8.patch | 635 bytes | tim.plunkett |
#18 | views-1765824-18-D7-do-not-test.patch | 576 bytes | tim.plunkett |
#16 | views-1765824-16.patch | 17.11 KB | tim.plunkett |
Comments
Comment #1
tim.plunkettSince this would require extremely custom theming in the style plugin, it's declared as a 'no ui' and needs to be extended. Here's a screenshot of 4 fields, the first of which has a description and is optional.
Comment #2
tim.plunkettHere's the example class (D7) used to generate the screenshot:
Comment #3
aspilicious CreditAttribution: aspilicious commentedDon't we need ta mechanism to add some kind of filtering on the fields?
For example I know we only use real date fields in fullcalendar when we search for a date field.
Comment #4
tim.plunkettRolling a D7 patch for now as a proof of concept to show how it could work with fullcalendar.
If it makes sense I can forward port it.
Comment #5
dawehnerYeah i have seen a lot of similar plugins, like many slideshow/image related ones, so i would vote to introduce such a feature.
Can you explain how to use that without an actual subclass? So it seems to make sense to remove the @Plugin() and make the class abstract
It seems to be that you want to have the default as optional, so what about using a 'required' here instead?
What about removing the views_ prefix here, this seems kind of redundant.
Comment #6
tim.plunkettOkay, I forward ported this, and took into account #5.
Here's an interdiff against #1.
Comment #7
tim.plunkett@aspilicious asked for tests, which I wrote, but I did it on top of #1771944: Replace exported views in tests with config files
So this will break for now, but a retest as soon as that's committed should pass.
Comment #11
tim.plunkett#7: views-1765824-7.patch queued for re-testing.
Comment #12
aspilicious CreditAttribution: aspilicious commentedLooks good but the indentation for yaml file changed. 2 spaces it is now :)
Comment #13
dawehnerThe 2 spaces aren't really a big issue, but yeah it should be better corrected but hey if you don't want to do it, this is a good novice issue.
Let's clean up things like that later.
Good redunction of the code.
Maybe filterNumericFields could be better name
Comment #14
tim.plunkettFunny, I had filterNumericFields the first time. I'll change that before committing.
The spaces can be fixed in #1774290: Change YAML file indentations to 2 spaces
Comment #15
tim.plunketthttp://drupalcode.org/project/views.git/commit/4ab57b6
Will backport today.
Comment #16
tim.plunkettWow, D7 is already soooo painful to use
Comment #17
dawehnerI'm wondering whether it would make sense to mark this as abstract so it is required to implement.
Committed to 7.x-3.x
Comment #18
tim.plunkettGood idea!
Comment #19
dawehnerPerfect! Let's see what the tests tells us on d7.
Comment #20
tim.plunkettWithout the "do-not-patch"
Comment #21
dawehnerhehe, it's green and go!