Let nodes override global setting variable_get('event_nodeapi_'. $node->type, 'never')
robertDouglass - May 28, 2005 - 10:12
| Project: | Event |
| Version: | 5.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Jump to:
Description
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.
| Attachment | Size |
|---|---|
| node_is_event.patch.txt | 3.46 KB |
#1
This 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.
#2
I 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.