This patch lets a node decide that it is eligible for treatment as an event by setting $node->show_as_event to one of the expected strings {'all', 'request', 'never'}. This does not change the behavior of the module with respect to its current uses, but opens the way for a basicevent module which knows that it is an event type out-of-the-box (needs no configuration). I think this will also be important if anyone decides to program an upcoming.org node type where the node is an event that conforms to the upcoming.org specification. The patch also makes it possible for a node to become an event node on-the-fly just by setting the $node->show_as_event flag.
| Comment | File | Size | Author |
|---|---|---|---|
| node_is_event.patch.txt | 3.46 KB | robertdouglass |
Comments
Comment #1
crunchywelch commentedThis looks good, I wonder if there are any thoughts about how we would deal with possible inconsistencies in configuration and behaviour. For example, the content configuration screen appearing 'broken' when a content type is set to 'never' for calendar views and this is overridden by a module directly and nodes show up on the calendar anyway. Do we not care about that, or should we add another option, or only allow overriding the variable if enabled or something? Would like to get killes thoughts on this as well. If no one raises any concerns I dont see another reason to not commit the patch.
Comment #2
boris mann commentedI think in this case the correct behaviour is for the per-node setting to override the "global" settings. There should be a note underneath the event settings that per-node/module settings can override these settings.
Comment #3
urbanlegend commentedGiven that this issue has not been updated in 11 years or more, I am closing this ticket as outdated (no longer needed and/or relevant). However, if anyone feels this represents an issue that is still being encountered in the current version of Drupal, please reopen and/or provide additional comments.