Posted by iva2k on June 29, 2009 at 1:13am
| Project: | Feed Element Mapper |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
When using feedapi_mapper to map feed fields to one date field, and there could be missing some of "TO" dates, warnings are reported:
warning: date_offset_get() expects parameter 1 to be DateTime, boolean given in /sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 405.
warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in /sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 407.
warning: date_format() expects parameter 1 to be DateTime, boolean given in /sites/all/modules/feedapi_mapper/mappers/feedapi_mapper_date.inc on line 409.
The resulting mapped nodes are OK.
Comments
#1
The following patch removes these warnings. In this patch I added verification if date part is present.
Please review for committing to 6.x-1.x-dev.
#2
The patch seems to be fine, however I rerolled as a standard drupal patch format and added isset().
#3
nag nag
#4
Committed to 1.x and 2.x branches. Thank you and thanks for the reminder ;)
#5
@alex_b,
Thanks for taking care of this. Sorry for reopening, but latest code with patch in #2 does not remove the warnings, which I received a bunch after updating. I should've tested it, but my code was still using patch in #1 until the recent update. It turns out that adding isset() in #2 passes on empty variables, but enclosed code still generates warnings on specific From-To dates in feeds.
Either remove isset(), or use patch in #1, which is equivalent. That fixed the warnings for good.
#6
However, I assume replacing isset() to empty() should be also fine.
The patch should apply to both branches (likely with some offset)
#7
I edited by hand, and can confirm that !empty() in place of isset() removes the warnings.
#8
should be in FeedAPI mapper 2.0 beta 1
#9
committed, thank you iva2k
#10
Automatically closed -- issue fixed for 2 weeks with no activity.