I set the formatter settings for a repeating date as follows
date:event_listing:full:field_event_when_fromto "both";
date:event_listing:full:field_event_when_multiple_from "now";
date:event_listing:full:field_event_when_multiple_number "5";
date:event_listing:full:field_event_when_multiple_to "now +1 months";
date:event_listing:full:field_event_when_show_repeat_rule "show";
But it still displays all the results not just those for the next month.
After some digging I tracked it to the fact that and empty string is being passed to date_formatter_get_settings() in the context argument instead of of 'full'.
I added a gross hack to date.module thus
function date_formatter_get_settings($field_name, $type_name, $context) {
if (empty($context)) { $context = 'full'; } //Gross hack
$options = array();
Which makes it work but I'm not familiar enough with the code to figure out why the correct value wasn't being passed in the first place.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | date_module_cache.patch | 1.05 KB | jcmarco |
| #2 | date_module.patch | 1.3 KB | jcmarco |
Comments
Comment #1
philsward commented+1 -> I have noticed the same issue.
I am also getting errors when using date repeats on saving a node, something about the date expecting a 1 or something... don't have the error off hand...
Comment #2
jcmarco commentedI found the same problem when trying to show just a fixed number of events in a CCK with a repeating event and other date field with no repetitions. But it is the same if you only have a repeating date field.
Digging into the problem I found that the problem was in date_prepare_node() ["Helper function to adapt node date fields to formatter settings"]
called by the theme functions when displaying any date field.
This function avoid multiple db access when displaying the fields with multiple dates, it has a kind of "cache" variable ($prepared_node) that returns its value if there is a query with the same field name, already read before but the problem is with this cache and the contexts.
There is a context issue, when that $prepared_node is filled in a context (in my case when displaying a node is token-teaser-full, always the three for a full node), then it reads the variable name for this context, but in the case of token the field display is configured with empty values and when the function is called in other contexts (for teaser and full) the variable is already there with the wrong values, and its returned always with no control about limiting the number of repeating events. The same with teaser configuration that affects to the full node configuration.
So that problem happens if you have different configurations for token, teaser or full node because the first loaded value force to ignore the configuration for next context.
I have added a context variable into this cache variable, that adds a "field_name"_context field with the running context and then a checking that control the data stored in there and the running context if other case it discard the cache and execute the rest of code and if the case of a cache recording add the context for that cache variable values.
It is fun because date_prepare_node() already has the $context loaded but not used in the cache context so probably this issue was an omission in the code.
A different question not related with the original one is that if it is really needed to pass the $node to the function, probably a referencing &$node is enough and it avoids moving up and down a variable so huge as $node.
Comment #3
jcmarco commentedPlease forget last patch, I shouldn't have mixed two different issues in the same one.
Probably my second assumption about $node referencing is wrong.
Anyway the issue with the cache was there and the patch fixed the issue.
Sorry for the mistake.
Comment #4
karens commentedThere are several issues here. One is that the context should never be empty, which happens because the default value is getting set to NULL instead of 'full', so I just committed a fix for that.
The second is as noted in #2 that date_prepared_node's stored values are ignoring context, which they should not. I don't think the supplied patch is going to work correctly, plus we may also need to be sure that the node is handled differently if a field is shared across content types, so I just got rid of the caching altogether, which should fix that problem.