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.
A mapper for Feeds would be nice.
Comment | File | Size | Author |
---|---|---|---|
#27 | oh_import.zip | 1.66 KB | kufeiko |
#23 | office_hours.feeds_.7.x-1.3.patch | 867 bytes | GerZah |
#3 | 1160440_3_office_hours.feeds_.patch | 10.75 KB | johnv |
#2 | 1160440_2_office_hours.feeds_.patch | 9.02 KB | johnv |
#1 | 1160440_office_hours.feeds_.patch | 7.97 KB | johnv |
Comments
Comment #1
johnvAttached a Feeds mapper for Office Hours.
You can use the following columns: day, hours/morehours from-to, hours/morehours from and hours/morehours to.
The day should be named in full English name, or a day number, where sunday = 0, monday=1, etc.
The hours can be used as hh:mm or hh.mm
I suppose Feeds Tamper can help to format the times and/or day to the proper format.
Here's an exampel file:
nid;weekday;Hours_1;Hours_2
2345;monday;11:00 - 18:01;
2345;tuesday;10:00 - 12:00;13:15-17.45
2383;monday;11:00 - 18:01;
2383;tuesday;10:00 - 12:00;13:15-17.45
Comment #2
johnva better version..
Comment #3
johnvyet another better patch..
Comment #4
xmacex CreditAttribution: xmacex commentedTotally sweet mate, let's have this in the package please?
Comment #5
johnvWorkin' on it. Did you check your import thoroughly? In my imports is happens (once and a while) that only 2-3 of 6 days are generated. I cannot figure out what's the cause. It only happens with bigger imports (>30 entities).
Comment #6
johnvCommitted to D7.
Perhaps the following line must be removed after Feeds has been fixed in this issue: #1139676: feeds_alter doesn't support hook_module_implements_alter, hook_hook_info and hook_hook_info_alter
module_load_include('inc', 'office_hours', 'office_hours.feeds');
Comment #8
johnvThe issue as in #6 has been committed to Feeds as of december 2011: #1139676-22: feeds_alter doesn't support hook_module_implements_alter, hook_hook_info and hook_hook_info_alter.
So removed the line with commit 0a7961e.
Comment #10
aditya.captovate CreditAttribution: aditya.captovate commentedHave come across an issue whereby only the last csv entry for an entitity is saved. For example, from the following csv, only the value for Sunday is saved
title,weekday,hours_1
assac,monday,08:30 - 16:30
assac,tuesday,08:30 - 16:30
assac,wednesday,08:30 - 16:30
assac,thursday,08:30 - 16:30
assac,friday,08:30 - 16:30
assac,saturday,
assac,sunday,
Comment #11
Ivo.Radulovski CreditAttribution: Ivo.Radulovski commentedhello, it imports only the last value (overwrites the previous values)
any clue?
nid;weekday;Hours_start;Hours_end
10647;Monday;07:00;19:00
10647;Tuesday;08:00;16:00
Only Tuesday is importedt when i run it like this
using
used Feeds 7.x-2.0-alpha8 and Office Hours 7.x-1.3
Comment #12
Ivo.Radulovski CreditAttribution: Ivo.Radulovski commentedalso this seems to be a bug
Comment #13
vlooivlerke CreditAttribution: vlooivlerke commentedI have tried every possible way to import office hours and are only able to import one day and its times. The rest of the week is ignored. Tried some Feeds Tamper but did not work.
I think the Day feed part has a bug.
Comment #14
pozz CreditAttribution: pozz commentedIt seems not work. In Feeds i set Day for "DAY", Hours for "HOUR_1" and More Hours for "HOUR_2"
is it correct? any help?
DAY;HOUR_1;HOUR_2
monday;09:30-12:00;15:00-18:00
Comment #15
johnvPlease try today's dev-version.
The Feeds importer was broken since the latest structure change of the field, which allowed unlimited blocks per day.
Remember, you need to have the 'day' column/field BEFORE the 'hours' or 'morehours' columns/fields.
From now on, you can feed any number of timeblocks per day. There is no difference anymore between 'hours' and 'morehours'.
Just keeping both for backwards compatibility.
Comment #17
Berliner-dupe CreditAttribution: Berliner-dupe commentedI tested all for one day for testing....
... but nothing works. The office hour day is ever empty ....
In Feedsmapping i map ......
"Office hour: Day" = Day
"Office hour: Hours" = Hours
or
"Office hour: Hours start" = Hours_start
"Office hour: Hours end" = Hours_end
I use the latest office-hours dev-version and the latest Feeds-dev-version but nothing.
What i make wrong?
Comment #18
Berliner-dupe CreditAttribution: Berliner-dupe commentedComment #20
GerZah CreditAttribution: GerZah commentedRe- importing opening times for multiple days:
The problem is that any new CSV line with the same unique field (e.g. NID) will create a new set of opening times during import – which means that even if your feed will update the same node multiple times, ultimately only the last open/close hours will show up (as first reported in #11).
The solution is far from obvious, but simple enough (in my case in good old 7.x-1.3): All opening hours for the different days need to be in one line.
I know that this is a tough precondition; however, as to the nature of Feeds which will update the whole field with every new line of import data, I have no idea how to import multiple open/close constellation for the same node in different lines.
Constructive example: Instead of using something like this
use something like this:
Then create the following mapping:
Yes – that's correct: Create a second rule for each hours:day, hours:start, and hours:end.
Actually, my input data looks something like this:
This turns out a bit bulky:
All I can say is: It works this way.
Comment #21
johnvIt turns out that the Feeds implementation was developed on a tweaked Feeds module.
IMO The best way is to change the code:
- if a new node starts in the Feeds, Just add the new value
- on any subsequent line for the same node, reload the node from database, take the values and append the new one.
Comment #22
GerZah CreditAttribution: GerZah commented@johnv I don't think so. This is how Feeds handles things. It's similar with multi-val strings: AFAIK, you can't simply add new items during another import for the same unique id: Feeds will always discard the previous content and import the new one (e.g. multiple strings via tamper / explode).
Comment #23
GerZah CreditAttribution: GerZah commentedAnyways, another thing regarding my "everything in one line" example in #20:
I'm looking at imports like this:
Meaning: Closed in Sunday.
I tried various things, like replacing "NULL" with an empty value via tamper. But as soon as $sv_day is defined, office_hours.feeds.inc will always carry out intval($feed_element) and thus transforming any non-numeric input to "0" i.e. midnight.
I suggest the following patch
This way we can actually import entire weeks with closed days. – I've attached the patch file.
Comment #24
troybthompson CreditAttribution: troybthompson commented#23 is a lifesaver just when I needed it. Much easier to implement, thank you.
The only issue I seem to be having is if the node had office hours before and the feed changes to all nulls so it's closed every day (because originally it was 00:00-00:00 before the patch), then it's not updating. I don't know if this is a problem of this patch or feeds in general.
Comment #25
GerZah CreditAttribution: GerZah commented@troybthompson It's not? According to my experience, whenever the node with the office hours field is updated, Feeds creates a whole new set of office hours – blank at first, then filled through that (one) CSV line, it will carry only those days that are actually defined.
Mind you, if you are using start / end as single values, both need to be non-numeric. Otherwise, as you have first defined the day field (as instructed in #15), the static variable $sv will be set for that particular day, and either one is_numeric() start or end will define this day.
In other words: Make sure that both start and end will be non-numerical and you should be fine.
Comment #26
troybthompson CreditAttribution: troybthompson commentedYes, just tested again. If I have one day's start and end fields as null, it updates and marks it closed correctly. If I have all days null, it seems to ignore them all. That's why I was wondering if it was a feeds issue.
Feeds 7.x-2.0-alpha8 (the new dev method breaks other modules right now), Office Hours 7.x-1.3+20-dev (2014-Oct-24) with your code replacing that section (not patch since it looks like OH dev's feed is different from what you were patching). So maybe it's just my combination. I'm going to be importing everything from scratch so this won't really affect me but may others.
Comment #27
kufeiko CreditAttribution: kufeiko as a volunteer commentedIn a recent project I developed a small module (attached) to import office hours on one-per-line basis, which seems a lot more better.
The imput is a .csv with the following format:
In Feeds admin interface you will have to map every day to its column.
Comment #28
kufeiko CreditAttribution: kufeiko as a volunteer commentedComment #29
finaukaufusi CreditAttribution: finaukaufusi commentedI'm trying to use the oh_import module with no success
I'm importing my office hours together with other fields in my node content type.
Question: Do I have to provide the node id (nid)? I thought it should be automatically populate like the other fields.
Comment #30
osman@vanko, I found your custom module quite useful, thanks for sharing.
However, my import data includes multiple time spans for each day, and each day are listed in the same row in the CSV file.
i.e.
As you can see days are listed as columns and in each column time-spans are separated by a comma.
I made some changes to your code, to support a file similar to this example. I temporarily excluded the update logic you had in place; I think it is a nice feature, btw.
Here is the updated code for importing a dataset similar to above:
Comment #31
osmanComment #32
kufeiko CreditAttribution: kufeiko as a volunteer commented@osman Yes, there are many different scenarios about those imports, so I guess a little tweaking is inevitable :)
Thanks for sharing your code too, so anyone with such problems can benefit from it.
Comment #33
johnvComment #34
johnvComment #35
johnvGiven the life cycle of D7, this issue is considered closed. However, patches are appreciated.