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.One of node import solutions is great feeds module (http://drupal.org/project/feeds). Unfortunately, scheduler module doesn't support
of importing unpublish_on and publish_on values during feeds import. Feeds module offers mapping api, which could be used to extend other modules to integrate with feeds module.
Attached patch is implementation of feeds mapper for scheduler module. This is my first mapper implementation, so it could be suboptimal.
I'm using date_api module to convert parsed value to timestamp form, and after that converted value is assigned to publish_on or unpublish_on
value. It seems to work, but it wasn't tested very much.
More info:
http://drupal.org/node/622700
Comments
Comment #1
Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commentedCould you please explain what your patch is supposed to do. I have never used the feeds module and I do not understand the patch. Also could you please try to implement it without dependency on the date module? We don't want scheduler to depend on a large contributed module like date. The dependency should always be an options (as with the date popup).
Comment #2
jsobiecki CreditAttribution: jsobiecki commentedOk, i will try to remove this dependency. I will attach modified patch later.
Description of patch:
Feeds module (from end user perspective) is a way of importing data (like users, nodes taxonomy, etc) from different sources into drupal.
It can import data from different sources (like RSS feeds, XML file etc). If you want to import nodes into drupal, you have to define *mappings* set.
It means, that users select what source data (like CSV file column, xml xpath result etc) maps to one of node fields. Out of the box, feeds supports things like title, body, cck fields and some more.
For example you can make such mapping:
results of xpath query: //root/element/@val => $node->title.
Unfortunately, feeds module doesn't support node values used by scheduler module (unpublish_on, publish_on).
From developer perspective feeds module is set of flexible APIs. One of those APIs is Mapping API (you can read about it: http://drupal.org/node/622700).
Mapping API allows developer to write additional mappings, which can be used by end user. You can see list of contrib mappings here: http://drupal.org/node/856780. My patch implements such mapper, using Mapping API. It implements one hook:
scheduler_feeds_node_processor_targets_alter -> this hook alter $target variable. $target is array with list of implemented mappers. Key of this array is target name (target could be node title, body or whatever). In this patch case, i "registered" two targets: publish_on and unpublish_on. I hope that ideas behinds values in this array are clean :)
I implemented for those two targets one callback function: scheduler_set_target. This function takes three arguments:
$node - $node object which is currently composited by feeds module
$target -> name of field in $node object (it's key of $target array at scheduler_feeds_node_processor_targets_alter)
$value -> value which is provider by parser. In general i assume that $value is string describing date, but without specific format.
My callback function converts $value to well defined timestamp form. After that this value is assigned to node object. After all mappers finish their job, node is saved. And thats all ;)
Comment #3
jsobiecki CreditAttribution: jsobiecki commentedOk, this patch doesn't need date_api module.
Comment #4
jsobiecki CreditAttribution: jsobiecki commentedEric,
Do you have additional questions about this patch?
Comment #5
Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commentedI changed your patch a bit (e.g. prior to php5.1 strtotime() would return -1 on error).
Please review and test. It would also be nice if someone could test it with php5.0 or even php4.
Comment #6
Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commentedhttp://drupal.org/cvs?commit=432396
Comment #8
Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commentedWe need to check if this still works for D7 and change it if needed.
Comment #9
sillygwailoI'll take a look at it now.
Comment #10
sillygwailoAttached is the first attempt at a patch for D7.
I removed the return statement, since it alters the $targets array by reference anyway. The hook for feeds seems to have changed, both in the function name and the arguments it sends to the call back. That's reflected in the patch. I also do some very rudimentary checking to see if the value passed to Scheduler is numeric, i.e. something that looks like a timestamp. If not, run
strtotime()on it.Comment #11
sillygwailoComment #12
Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commentedSorry, I did not get around testing your patch. Tomorrow, I promise...
Comment #13
sillygwailoNo worries. Re-rolling for the latest dev and removing a variable that doesn't get used.
Comment #14
Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commentedAnybody have some data file/stream we could use to test this?
The code looks good so far. Is the name of scheduler_set_target() "arbitrary", e.g. not a hook? Looks like the callback name is declared in scheduler_feeds_processor_targets_alter(). Could we rename scheduler_set_target() to something like scheduler_feeds_set_targets() to make it clear what it is used for?
Comment #15
sillygwailoYes, we can change the callback to whatever we like.
Comment #16
Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commentedI can see the scheduler fields in the mapper so scheduler_feeds_processor_targets_alter() seems to work. What do we do about the _set_target() function? One thing seems to be weird: It does not return anything and all parameters are by-value. How does it work its magic? Am I missing anything?
Comment #17
sillygwailoIt's my understanding that objects are passed by reference by default. See http://php.net/manual/en/language.oop5.references.php for nuance on the subject especially the
foo()function in the first example. Thefoo()function acts in the same way the callback works, in that it modifies the properties of the object directly, rather than assigning the object to a variable (in which case areturnstatement would be necessary). See also the paragraph at http://drupal.org/update/modules/6/7#php_versionComment #18
sillygwailoAnother re-roll, this one removing the unused
$targetempty array from the hook.Comment #19
Eric-Alexander Schaefer CreditAttribution: Eric-Alexander Schaefer commentedYou are right. Looks good. (http://drupal.org/cvs?commit=499320)