text:
Join as a member. There's a certificate with your name on it.
I want to manually assign taxonomy terms to a feed. So I have created a vocab, lets say one of the terms is news. I have set-up a feed from a news site and set the feed to use the news term. I thought this would then assign that term to all the imported items, but it doesn't. Is there any chance this can be added as a feature?
|David Goode
|David Goode
|David Goode
Comment #1alex_b CreditAttribution: alex_b commented
|Taxonomy Propogation
|» Taxonomy inheritance
This feature is called taxonomy inheritance in FeedAPI, for clarity I'm going to call it Taxonomy inheritance here, too.
This feature can be easily added by extending FeedsNodeProcessor. As for actually making this part of Feeds at this point, I don't have any plans for that. I would accept a solidly reviewed patch with a test though.
Comment #5willmoy CreditAttribution: willmoy commented
No (sorry), yes (please). :)
Comment #6tobedeleted CreditAttribution: tobedeleted commented
Very keen to see this type of feature included. For me it is essential that I can tag new content coming in to the site so that is can then be displayed in the relevant place/s.
Comment #7alex_b CreditAttribution: alex_b commented
|» Needs review
- I see tabs as spaces http://drupal.org/coding-standards
- Let's make this a setting in the FeedsNodeProcessor
- Use
node_load() to retrieve taxonomy of feed node, copying taxonomy from the feed node to the item node should then be very simple (sth. like
$node->taxonomy = $feed_node->taxonomy)
- Before committing, this patch will need a test.
Comment #9alex_b CreditAttribution: alex_b commented
|Needs review
|» Needs work
- There are still some indentation issues. Please also have a look at standards for comments and control structures http://drupal.org/coding-standards
- Always patch against the current branch (right now there is only one branch which is head).
- Feeds ships with 1000+ assertions testing its existing functionality (see feeds/tests). We should also include a test for taxonomy inheritance. Refer to http://drupal.org/project/simpletest for learning how to run tests and how to write them (tests look funky, but they're *really* easy to pick up).
Comment #11alex_b CreditAttribution: alex_b commented
As for the coding standards, this is what I hate, going between different packages and systems and trying to remember which one I am in and the standard to use.
Yeah, you gotta speak the local dialect here ;-)
Comment #15paganwinter CreditAttribution: paganwinter commented
Comment #16robertDouglass CreditAttribution: robertDouglass commented
|Taxonomy inheritance
|» Inherit settings from parent feed node (like taxonomy)
|Needs review
|» Needs work
I think the patch represents the wrong approach. I'd like to be able to register "inheritors" for a lack of a better name, and specify exactly which bits of the parent node get inherited. The current patch is a one-off solution for taxonomy.
Here's a chat I had with alex_b where he shared some pointers for the approach:
[1/26/10 9:48:40 PM] Alex Barth: I would make it a method FeedsNodeProcessor::inherit($feed_node, $node)
[1/26/10 9:49:05 PM] Alex Barth: that I'd invoke from FeedsNodeProcessor::process() just before node_save($node);
[1/26/10 9:49:41 PM] Alex Barth: You can load the feed node in process() with
[1/26/10 9:50:08 PM] Alex Barth: if ($source->feed_nid) {
$feed_node = node_load($source->feed_nid);
[1/26/10 9:50:30 PM] Alex Barth: keep in mind that there may be no feed node in cases of direct imports from the stand alone form
[1/26/10 9:50:32 PM] Robert Douglass: And how to register inheritance rules?
[1/26/10 9:50:46 PM] Robert Douglass: Seems like it needs to be another h tab for CTools
[1/26/10 9:51:18 PM] Alex Barth: that can be a setting of the FeedsNodeProcessor that is exposed in FeedsNodeProcessor::configForm() IF the domain access module is present
(Note I was asking specifically about inheriting domain module settings from the parent node).
Sorry to nickbits for hijacking the issue =) It'll be better this way, though.
Comment #17robertDouglass CreditAttribution: robertDouglass commented
As a temporary stopgap to this issue I wrote a small custom module that implements hook_nodeapi and successfully "inherited" my domain module settings to the imported nodes like this:
function roller_nodeapi(&$node, $op) {
switch ($op) {
case 'insert':
if ($node->type == 'video_external') {
if ($feed_nid = db_result(db_query("SELECT feed_nid FROM {feeds_node_item} WHERE nid=%d", $node->nid))) {
$feed_node = node_load($feed_nid);
$node->domain_site = $feed_node->domain_site;
$node->domains = $feed_node->domains;
$node->subdomains = $feed_node->subdomains;
One could do the same with taxonomy or whatever. I'm not suggesting this is a long term solution... but if anyone else has a similar need and can't wait, I thought the code might be useful.
Comment #18Anonymous (not verified) CreditAttribution: Anonymous commented
So I thought that this thread was going in the direction that I was hoping, but maybe I missed something.
Here's my situation:
I am importing multiple calendars from our association's Google Apps account. I have created a feed for each one, "Symposiums", "Events", "7 Pillars". What I can't seem to do is find a way to sort by the feed. For example, I want to show the first event associated with "Symposiums", the first one association with "Events", and the first one associated with "7 Pillars".
Is there a way to have a particular Taxonomy term, like "Symposiums", attached to the feed that will then be automagically added to all the nodes created from that feed? I could filter each block by the term that way...
I have learned a heck of a lot about using Drupal, but unfortunately, I can't help much with building/developing patches. I welcome testing new developments, lol.
I have the development site at www.thecfaa.com/indev
Comment #19paganwinter CreditAttribution: paganwinter commented
Comment #20Anonymous (not verified) CreditAttribution: Anonymous commented
As a temporary stopgap to this issue I wrote a small custom module that implements hook_nodeapi and successfully "inherited" my domain module settings to the imported nodes like this:
function roller_nodeapi(&$node, $op) { switch ($op) { case 'insert': if ($node->type == 'video_external') { if ($feed_nid = db_result(db_query("SELECT feed_nid FROM {feeds_node_item} WHERE nid=%d", $node->nid))) { $feed_node = node_load($feed_nid); $node->domain_site = $feed_node->domain_site; $node->domains = $feed_node->domains; $node->subdomains = $feed_node->subdomains; } } break; } }
One could do the same with taxonomy or whatever. I'm not suggesting this is a long term solution... but if anyone else has a similar need and can't wait, I thought the code might be useful.
What part of this would you change to inherit the taxonomy? I really want to be able to apply taxonomy terms to the imported nodes so that I can sort the different types of events by the taxonomy. Any help on what you wrote would be appreciated, and I understand it would only be a temporary fix...
Comment #21paganwinter CreditAttribution: paganwinter commented
Create a node-.tpl.php file (by copying your theme's node.tpl.php file and renaming it accordingly) for your Feeds config node as well as your feed item node, and add this at the bottom of those files:
This will cause all data associated with your node for that node type, to be displayed when you view the respective nodes.
This will list out all taxonomy related data for that node.
Feeds Config -> node-feeds_config.tpl.php
Feeds Item -> node-feeds_item.tpl.php
From this you can figure out how the taxonomy terms are stored in your Feeds Config type nodes.
Then accordingly modify the above code:
function roller_nodeapi(&$node, $op) {
switch ($op) {
case 'insert':
if ($node->type == 'feeds_item') {
if ($feed_nid = db_result(db_query("SELECT feed_nid FROM {feeds_node_item} WHERE nid=%d", $node->nid))) {
$feed_node = node_load($feed_nid);
$node->taxonomy = $feed_node->taxonomy;
I think this should do it.
(Boy, am I bad at explaining stuff...)
Comment #22skizzo CreditAttribution: skizzo commented
Is there a way to have a particular Taxonomy term, like "Symposiums", attached to the feed that will then be automagically added to all the nodes created from that feed?
@cfaadev: As I understand it, that's what nickbits's patch Taxonomy Inheritance Patch is supposed to do...
Comment #23skizzo CreditAttribution: skizzo commented
@robertDouglass Re:#17
Indeed I do have a similar need (actually I need to inherith both domain and taxomomy).
- created a custom module mymodule
- in your code: renamed function roller_nodeapi into mymodule_roller_nodeapi
- in your code: renamed 'video_external' into my feed item's content type name
- enabled mymodule
Now, clicking on the feed Import tab the feed item nodes are created, but the they are
all assigned to "current domain" (as per default Domain configuration).
Any other setting I am missing?
What makes MyModule override Domain Access behaviour?
Thank you...
Comment #24drewish CreditAttribution: drewish commented
Comment #25lennart CreditAttribution: lennart commented
A general solution to inheritance is a good idea. Feed items inheriting the node author from the feed node is another example that comes to mind alongside taxonomy inheritance.
Comment #26AntiNSA CreditAttribution: AntiNSA commented
This is not happening in feeds right now? Then how can you say feeds is better than feedapi? Sure I need less server load... but I newad to have basic features.
Comment #27AntiNSA CreditAttribution: AntiNSA commented
Can someone give a status update on this issue? At least the option of inheriting taxonomy?
Comment #28AntiNSA CreditAttribution: AntiNSA commented
When patching withthe latesto option I get this error... here is a copy from the rejected file with cygwin
*** 37,43 ****
$node->nid = $nid;
$node->vid = db_result(db_query('SELECT vid FROM {node} WHERE nid = %d', $nid));
// Save the node.
--- 37,51 ----
$node->nid = $nid;
$node->vid = db_result(db_query('SELECT vid FROM {node} WHERE nid = %d', $nid));
+ if ($this->config['taxonomy_inheritance'] && module_exists('taxonomy')) {
+ // Find out what term(s) the parent node uses
+ // Use node_load to get the parent information (see http://api.drupal.org/api/function/node_load/6).
+ $feed_node = node_load($source->feed_nid);
+ // Set node to use the same taxonomy term(s) as it's parent
+ $node->taxonomy = $feed_node->taxonomy;
+ }
// Save the node.
Comment #29AntiNSA CreditAttribution: AntiNSA commented
|» Critical
Comment #30alex_b CreditAttribution: alex_b commented
|» Normal
#27 - To my knowledge, nobody is actively working on this feature at the moment. robertDouglass posted a good stop gap in #17 and constitutes in IMO a good practice.
Issue is not critical (Feeds uses 'critical' only for issues that need to be solved for upcoming releases).
Comment #31AntiNSA CreditAttribution: AntiNSA commented
ok I applied his patch, however since there ios now a new dev release , will I have to patch it with the old fix , and patch every release?
Comment #32AntiNSA CreditAttribution: AntiNSA commented
|Inherit settings from parent feed node (like taxonomy)
|» Inherit settings from parent feed node (like taxonomy) Organic group Audience inheritance; where do I put this?
Can you please tell me how to alter this information in order to get the audience settings for organic groups to be inherited? And where do I put this information at?
Comment #33jboeger CreditAttribution: jboeger commented
Definitely a feature I need... subscribing....
Comment #34Dmxr100 CreditAttribution: Dmxr100 commented
Inheritance of ImageField CCK would also be of great use, so that a feed could perhaps have the source's logo associated with it, and then displayed alongside all posts from that feed.
Comment #35drupallogic CreditAttribution: drupallogic commented
without mapping terms to feed items, I can't use Feeds and need to stay with FeedAPI...
hope it's added.
Comment #36AntiNSA CreditAttribution: AntiNSA commented
|Inherit settings from parent feed node (like taxonomy) Organic group Audience inheritance; where do I put this?
|» Inherit settings from parent feed node (like taxonomy); This should be a core feeds function Sign petition!
Seems like this is a very important feature, and popular amongst all users. I cant see the logic if you were going to create a method to create new nodes automatically from feeds why would you prevent them from being categorized? PLease accept this ongoing petition from feeds users and feedapi converts. We need this! Power to the people.
Comment #37alex_b CreditAttribution: alex_b commented
|Inherit settings from parent feed node (like taxonomy); This should be a core feeds function Sign petition!
|» Inherit settings from parent feed node (like taxonomy)
PLease accept this ongoing petition from feeds users and feedapi converts.
There is a fundamental misunderstanding: Nobody is here to fulfill other people's feature requests.
Contributing to open source is not petitioning feature requests, it's writing patches, helping out with documentation and filing solid issue reports.
Comment #38alex_b CreditAttribution: alex_b commented
#17 is a good stop gap solution.
#13 is very close.
- The portion of the code in FeedsNodeProcessor::process() needs to be broken out into a method FeedsNodeProcessor::inherit() (for easier overridability)
- there needs to be a check whether $feed_nid is non-zero before attempting to load the node (this is essentially what I said in the IRC excerpt in #16).
Comment #39alex_b CreditAttribution: alex_b commented
#36/#37 - To make this very clear: there is nothing wrong with feature requests, in fact I appreciate them. But we can't petition each other to implement them. If you want to see something happening, you need to step up.
Comment #40AntiNSA CreditAttribution: AntiNSA commented
:) I am trying so hard to step up every way I can and in every way... but I dont have that ability to make the patch. You know what it takes.. you have the skills.. you have the power and my sincere hope that you will grant us nonables your skills in completing this feature request
Comment #41gravelpot CreditAttribution: gravelpot commented
Comment #42squinternata CreditAttribution: squinternata commented
excuse me maybe i didn't understand well..but it means that it s not there feature about inherit taxonomy language and whatever?
thank you
Comment #43AntiNSA CreditAttribution: AntiNSA commented
No, it seems that it is not a priority at all for feeds. I hope it will be though!!!1
Comment #44squinternata CreditAttribution: squinternata commented
ok i ll wait for news about it..in the meanwhile i come back to feedapi..
cause for me this feature is necessary!
thank you
Comment #45AntiNSA CreditAttribution: AntiNSA commented
44 replies and no solution? Come on Drupal!!!!! Go Go Go! Where is the solution? We need this!!!!
Comment #46skizzo CreditAttribution: skizzo commented
uhm... 10 out of 45 come from the same user :-)
Comment #47bflora CreditAttribution: bflora commented
Comment #48pdcarto CreditAttribution: pdcarto commented
On the project page, it says:
* Feeds is the successor module of FeedAPI and Feed Element Mapper.
I appreciate the advances in usability from Feeds, but this is not going to be a successor to FeedAPI and FEM until this feature is implemented. The authors have two choices: 1. Change this issue to a bug report and assign someone to fix it, or 2. Remove the "successor to FeedAPI..." claim from the project page.
Comment #49pdcarto CreditAttribution: pdcarto commented
I'm wondering how hard it would be (for someone who knows what he or she is doing) to adapt the feedapi inherit module to work with Feeds?
Comment #50AntiNSA CreditAttribution: AntiNSA commented
I completely agree with #48, and would love someone to do what 49 says. Right now I am creating tons of content types.... which is a huge timewaster instead of being able to inherit taxonomy....
Comment #51jtr CreditAttribution: jtr commented
For some reason, setting the uid of the feed item did not work for me using the trick in #17 or #21. Here is my code that now works:
function feeds_custom_inherit_nodeapi(&$node, $op) {
switch ($op) {
case 'prepare':
case 'insert':
if ($node->type == 'feed_item') {
if($op == 'prepare') {
$feed_node = node_load((int)$node->feeds_node_item->feed_nid);
} else {
if ($feed_nid = db_result(db_query("SELECT feed_nid FROM {feeds_node_item} WHERE nid=%d", $node->nid))) {
$feed_node = node_load((int)$feed_nid);
} else {break;}
$node->uid = $feed_node->uid;
$node->og_groups = $feed_node->og_groups;
$node->og_groups_both = $feed_node->og_groups_both;
$node->og_public = $feed_node->og_public;
$node->taxonomy = $feed_node->taxonomy;
I also had to comment out the line in FeedsNodeProcessor.inc that does this:
$node->uid = 0;
I can't help but think that my code is pretty inefficient, but it seemed that with just the insert nodeapi hook, somehow i was still getting anonymous authors.
Comment #52pdcarto CreditAttribution: pdcarto commented
W/respect to #49...
The more I think about it, the more I think a separate feeds_inherit module would be the right way to go. It could be bundled with Feeds, or made a separate project, depending primarily upon the ownership/maintainer situation.
Which brings me to my second thought, which is that if each person who chimed in requesting this feature (just on this issue) were to ante up some money, we might be able to get this on the fast track. I count 17 individuals expressing a desire for this feature on this thread; if just half of them were willing to put down some cash, we could do this. I'm thinking alex_b would be the obvious first-choice for such a bounty, since he has been so closely involved in both feeds and feedapi (and feedapi inherit).
So, Alex, what kind of bounty would it take to get you to take this on (porting feedapi_inherit to feeds_inherit)?
Thanks, Pat
Comment #53alex_b CreditAttribution: alex_b commented
Pat - I'd actually like to see this feature in Feeds, my problem is not money but time. I'd love to see a developer step up and go for the whole nine yards: hammer out basic architectural decisions (I can be of help for that), write patches with tests and respond to feedback on issue. #13 was a good start but we need an approach that scales beyond taxonomy inheritance. If somebody's seriously interested in nailing this feature, please contact me on IRC, I'll be really happy to help out.
Comment #54AntiNSA CreditAttribution: AntiNSA commented
I am a poor teacher in China I would help if I could but I cant afford it and have no credit card :(
Comment #55pdcarto CreditAttribution: pdcarto commented
Re #53, Alex is saying that he would prefer embedding inheritance into FeedsNodeProcessor.inc, rather than having a separate "feeds inherit" module. At the same time, he recommends making inheritance scalable, which I take to mean that one could plug in new types of inheritance that are not provided in the basic Feeds module. I have no idea how one would go about doing that.
Re #16, Robert "hijacked" the issue saying it'll be "better this way", but I'm not sure what "way" that is. The conclusion from his IRC chat with Alex appears to be that Alex was recommending that Nick's approach from #13 simply be expanded to cover a larger number of known inheritance cases (taxonomy, author, target groups, etc).
Robert's approach introduced in #17 and followed in a number of subsequent comments, which is to make a separate module that pokes the particular inherited attribute into the $node object can therefore be regarded as simply a workaround for the lack of inheritance in Feeds, and useful as it may be for individual cases, is probably not a step towards closing this issue.
Alex's offer of support in #53 for some developer to step up and go the whole nine yards makes this seem quite daunting (particularly the scalability). With effort, I might be able to hack FeedsNodeProcessor.inc to cover the inheritance cases supported by feedapi_inherit, but I'm a hobbyist-level developer at best and anything I wrote would certainly not come close to clearing the bar for an acceptable patch. Should I even try?
Or would it be better to try to build up a bounty and continue to try to find/cajole another developer?
Comment #56pdcarto CreditAttribution: pdcarto commented
Attached is my attempt to merge the feedapi_inherit module's functionality in FeedsNodeProcessor.inc. The configuration settings and inheritance functions seem to be working for og, taxonomy and author (I'm not using language, so that's not been tested).
I have no clue as to how to set up a SimpleTest case, but would be willing to try given some encouragement and help.
Comment #57AntiNSA CreditAttribution: AntiNSA commented
Super effort! This is in my nodequeue to test. Hopefully I can test in the next 24 hours
Comment #58poloparis CreditAttribution: poloparis commented
Hi, regarding #21 paganwinter's solution, it passes along the correct taxonomy for me but it does not save it to to the feed item node.
I tried a drupal_write_record('feeds_node_item', $node, 'nid'); without success
Could anyone point me in the right direction please ?
Comment #59AntiNSA CreditAttribution: AntiNSA commented
|Inherit settings from parent feed node (like taxonomy)
|» Inherit settings from parent feed node (like taxonomy) WE HAVE PATCH! Help Debug PLease!!!
Thanks for the effort! So Far I get this error :
Warning: Call-time pass-by-reference has been deprecated in /home/cyberfan/htdocs/sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc on line 74
and this error:
warning: Cannot modify header information - headers already sent by (output started at /home/cyberfan/htdocs/sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc:74) in /home/cyberfan/htdocs/includes/common.inc on line 148.
Still testing...
Comment #60AntiNSA CreditAttribution: AntiNSA commented
Ok I cant get past this error... gives a white screen :
Warning: Call-time pass-by-reference has been deprecated in /home/cyberfan/htdocs/sites/all/modules/feeds/plugins/FeedsNodeProcessor.inc on line 74
Comment #61alex_b CreditAttribution: alex_b commented
#55: very nice work.
I should have expanded a little more on what I meant with 'scalability' but you got it right: we're looking for an approach that makes inheritance extensible so that we don't need to patch Feeds for every use case that needs it.
The patch attached (untested) adds such extensibility very closely following the pattern set by Feeds' Mapping API:
FNP::getInheritors() declares a list of available inheritors and callbacks for them. It invokes a
hook_feeds_node_processor_inheritors_alter() that can be implemented to add more inheritors.
FNP::inherit() invokes these callbacks if the inheritor has been selected by a site builder. Please review.
Further I have made these modifications:
* Indentation needs to be 2 spaces instead of 4.
* I renamed feeds_inherit_do_inherit() to inherit() (BTW, use lower camelCase for methods).
* Check whether feed_nid is present before inheriting
if ($source->feed_nid) {
* Not 'parent feed' but 'feed node' in descriptions.
* No need to pass objects by reference as of PHP 5
* Disable inheritance options if importer is not attached to feed content type.
* Currently the inheritors just live in FeedsNodeProcessor.inc. They are very short so I didn't want to create a separate location for them like mappers have. I think that's fine for now.
* Testing (I have only tested the UI, not the actual inheritance).
* Write simpletests
* Documentation in feeds.api.php
* Documentation in Drupal handbooks
* Shouldn't language inheritance depend on locale?
Comment #62alex_b CreditAttribution: alex_b commented
|Inherit settings from parent feed node (like taxonomy) WE HAVE PATCH! Help Debug PLease!!!
|» Inherit settings from parent feed node (like taxonomy)
AntiNSA: please refrain from attaching demands to the issue title. And again: please make sure your issue reports are specific, ie. we need to be able to reproduce them. So: where exactly do errors happen, after what steps, with which configuration?
Comment #63pdcarto CreditAttribution: pdcarto commented
|Needs work
|» Needs review
Re #61: Alex's patch works perfectly in my first testing of a couple rss feeds: UI and og/taxonomy/author inheritance all doing what they're supposed to. Very nice work! Thank you very much!
I'd be happy to try adding the Drupal handbooks: site-builder's documentation but I don't think you'd want me touching the developers documentation. In any case, that should happen after the feature request has been committed, right?
Comment #64AntiNSA CreditAttribution: AntiNSA commented
#62 If you could focus on debugging and developing the patch for feed inheritance as well as you do on criticizing my iupdate of the title, Im sure we can see an increase in efficiency!
I updated the title to reflect teh fact that this thread now has a patch, for those who thought it was lacking, and reflected the current patch development status.
As for the error message, immediatly after installing they appeared. After trying to import a feed I recieved the error / whitescreen. I will try to install the updated version of the patch and see what happens.
Comment #65AntiNSA CreditAttribution: AntiNSA commented
All apologies. I love drupal.. and thanks for the effort. to not mistake determination wwith anything else.
Comment #66Gerhard Killesreiter CreditAttribution: Gerhard Killesreiter commented
@ AntiNSA: I am happy to see that you apparently plan to give up your disruptive behaviour. At drupal.org, we try to provide space for people like Alex to work on improving Drupal. We are not happy if somebody uses this space to disrupt their hard work through unsubstantiated demands. So please restrain yourself, maybe help Alex a bit by documenting Feeds and relax.
However, if you should take up your former behaviour (and since you say you speak German): Wir können auch anders.
Comment #67pdcarto CreditAttribution: pdcarto commented
Alex asked me to try to write some simpletests for #61.
Oh boy - a new learning opportunity! ;-)
Stay tuned (and poke me if I haven't reported anything back in a few days)...
Comment #68klonos CreditAttribution: klonos commented
@Gerhard Killesreiter: We had a private email exchange with AntiNSA (just before his reply in#65) and he is not a mean person at all. He simply is an impatient one perhaps, but he means well. After all we all are friends here.
I am begging everyone (also note to self) to stop this meaningless series of postings that don't have anything to do with the progress of this issue. If you need to say something personal to a person, say it in a private mail and stop polluting the issue queue. Now, I'll shut up because I am doing it too ;)
Comment #69AntiNSA CreditAttribution: AntiNSA commented
The newest patch seems to work great! Thanks. I am hesitant though to allow organic groups the right to create their own feeds.. imagine 800 users with 20 feeds each updating on a chron run... I am sure my server would time out.... how do you manage to allow soo many feeds to update?
Comment #70iaminawe CreditAttribution: iaminawe commented
I can confirm that the lasy patch works nicely to fix the author inherit issue.
It does not seem to be inheriting the authors default input filter so all imported content type still default to the site default which in my case is plain text.
This same issue was also brought up here http://drupal.org/node/652180#comment-2706472
Is there any known way around this?
Comment #71AntiNSA CreditAttribution: AntiNSA commented
yes you can use the module called "Better Formats" do set default content filter formats. Thats what I did
Comment #72skizzo CreditAttribution: skizzo commented
I would like to test the patch. I am running domain and feeds 6.x-1.0-alpha13
but I don't see a checkbox for domain inheritance (mentioned in #16 and #17).
Could it be added to patch #61?
Comment #73slicedsoup CreditAttribution: slicedsoup commented
This is working for me. Great patch.
Comment #74bflora CreditAttribution: bflora commented
patch is working for me. Thanks!
Comment #75idflorin CreditAttribution: idflorin commented
Comment #76miche CreditAttribution: miche commented
patch #61
ONLY tested "inherit feed author" on 6.x-1.0-alpha14. WORKED!
Comment #77Michelle CreditAttribution: Michelle commented
#61 works for me with the latest dev snapshot. I tested taxonomy and author, not OG.
Comment #78srobert72 CreditAttribution: srobert72 commented
Need inheritance for Language and some CCK fields (NodeReference).
I've post another issue #777376: Inherited fields in Feed Items from their Feed parent which I realize now is duplicate of this one.
This one appears to be more generic.
Comment #79alex_b CreditAttribution: alex_b commented
|Needs review
|» Needs work
Setting to NW as patch needs tests (#67) - pdcarto, still on to it? Does somebody else want to step up?
Comment #80srobert72 CreditAttribution: srobert72 commented
Here is my feedback.
I've just tested patch #61 and it works well for me.
Module version : Feeds 6.x-1.x-dev (2010-May-06)
Options from patch : Language + Taxonomy inheritance
Test with 2 Feed in different language which import 25 FeedItem each.
I'd like also to inherit CCK values from Feed to FeedItem children.
Do you think it could be implemented soon ?
Comment #81dixon_ CreditAttribution: dixon_ commented
|Needs work
|» Needs review
Here is a re-roll of the patch from #61. I've added documentation to
feeds.api.php and made the translation inheritor depend on
locale.module instead. I've also fixed three code style (indentation) issues.
I've been able to test the user, taxonomy and language inheritors without any problems! I haven't been able to test the og inheritor yet.
What's left:
- Write simple tests for all inheritors. (This is a commit blocker if I understand things right.)
- Document the inheritor functionality and the new hook in the handbook here on d.o. (I'll gladly do that when this gets committed.)
Even though is still not 100% complete, I'm marking this as "needs review" to get some eyes on it.
//dixon_, NodeOne
Comment #82dixon_ CreditAttribution: dixon_ commented
Comment #83srobert72 CreditAttribution: srobert72 commented
I tested it again but I have this error now while updating :
Fatal error:
Cannot redeclare class FeedsImporter in /home/drupal/sites/all/modules/feeds/includes/FeedsImporter.inc on line 31
EDIT : Sorry my mistake
It's was just right access problem. No problem in your patch.
Comment #84srobert72 CreditAttribution: srobert72 commented
Here is my feedback.
TEST patch #82
Module version : Feeds 6.x-1.x-dev (2010-May-06)
Options from patch : Language + Taxonomy inheritance
Test with 2 Feed in different language which import 25 FeedItem each.
After deleting all old FeedItem, I click on "Import" link of each Feed.
25 FeedItem are imported for each. Great.
But after a while (maybe many cron launches) I have also 25 FeedItem "Language neutral".
It's not due to new patch version. I have noticed also same issue with #61 patch after a while.
Comment #85ehudash CreditAttribution: ehudash commented
I have tested patch from #82 as well and found no problems.
Now I wonder how can I add the Domain Access properties inheritance from the Feed node onto the imported Feed Item nodes.
I'm a bit of a newbie so can someone guide me on how to do this correctly, or maybe post an updated patch?
Comment #86ehudash CreditAttribution: ehudash commented
|Needs review
|» Reviewed & tested by the community
Would love to see Domain Access inheritance as well.
Working on it myself but I'm a bit of a newbie, so it may take a while :)
Comment #87pdcarto CreditAttribution: pdcarto commented
|Reviewed & tested by the community
|» Needs review
My apologies to everyone. I said I'd try to write the simpletests without having any idea what that entailed in terms of know-how. If someone show knows his way around testing would be willing to pick this up, I would be very much obliged.
Changing this back to `needs review` - since the formal testing remains to be done.
Comment #88alex_b CreditAttribution: alex_b commented
#82 looks good. #81 describes next actions. I am not working actively on this, so if someone wants to pick up the test torch, go for it!
Comment #89srobert72 CreditAttribution: srobert72 commented
patch #82 is no more compatible with last DEV release (2010-May-17)
Could you update it ? Thanks a lot
Comment #90ccoppen CreditAttribution: ccoppen commented
In patching using either #61 or #82, I get a reject error for plugins/FeedsNodeProcessor.inc.
I'm using the 6.x-1.x-dev version. I was using alpha15 but switched to make sure everything would patch correctly.
I'm attaching the rej file.
When I attempted to reverse the file, I got Hunk #1 failed at 69 as well in plugins/FeedsNodeProcessor.inc. So, it is neither succeeding in patching the file, nor reversing the file. Though, only 1 out of 4 hunks FAILED.
Comment #91ccoppen CreditAttribution: ccoppen commented
Attaching small patch to fix what's broken in #82. Maybe someone wants to reroll everything back into one?
EDIT: I get the inheritance checkbox on the Feed Settings page, but the inheritance is not happening.
Any thoughts?
Comment #92ccoppen CreditAttribution: ccoppen commented
Sorry to be posting again so soon, but attached is a patch with the changes from #82 rolled with the fixes from 91. I'm still testing to see if it really works. I get the checkboxes, but not sure if the inheritance really works.
Comment #93skizzo CreditAttribution: skizzo commented
Applied patch #92 cleanly to 6.x-1.0-alpha15. I see the 3 checkboxes (language, taxonomy, author) and all 3 attributes are inherited correctly in my setup. As #86, I would really like to see domain inheritance implemented so it can be tested before the patch is committed. @ehudash: any progress?
Comment #94srobert72 CreditAttribution: srobert72 commented
Patch #92 works for me on last DEV release (May 17, 2010).
It repairs correctly broken patch #82.
I've tested inherited language and taxonomy.
Thank you @ccoppen
Comment #96Exploratus CreditAttribution: Exploratus commented
All this needs is Domain Access, and it would be complete.
Comment #97arlind CreditAttribution: arlind commented
Definitely a feature I need... subscribing....
Comment #98deggertsen CreditAttribution: deggertsen commented
Tested #92 and works great. No problems so far. This needs to be put in.
Comment #99ufku CreditAttribution: ufku commented
|Needs work
|» Reviewed & tested by the community
I think this is ready to go.
Please submit other inheritance related feature requests as separate issues.
Comment #100alex_b CreditAttribution: alex_b commented
|Reviewed & tested by the community
|» Needs work
We are very close here, yep, but we need tests!
Comment #101michellezeedru CreditAttribution: michellezeedru commented
Subscribing .. would be happy to help test, but running into problems applying the patch for #92. Maybe because I'm trying to apply against 6.x-1.0-alpha15? I placed the patch in sites/all/modules/feeds, but when I try to run it, I get an error:
patching file feeds.api.php
can't find file to patch at input line 31
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
|diff -urp ./plugins/FeedsNodeProcessor.inc ../NEWfeeds/plugins/FeedsNodeProcessor.inc
|--- ./plugins/FeedsNodeProcessor.inc 2010-05-20 10:46:35.000000000 -0400
|+++ ../NEWfeeds/plugins/FeedsNodeProcessor.inc 2010-05-20 11:11:39.000000000 -0400
Thanks for this module - looking forward to getting this feature rolled in!
Comment #102Mathijs Koenraadt CreditAttribution: Mathijs Koenraadt commented
Just my 2 cents, but do feed nodes also inhert i18n settings from the feed? E.g. the feed has Drupal language set to "French", and then all the nodes derived from it get that "French" setting as well. I'm asking because I'm doing tests with multilingual feeds, and haven't found out how to do it properly. My feed nodes all get the default languages.
Comment #103klonos CreditAttribution: klonos commented
I am not testing atm, but I too am importing single-language feeds and I need to set the language appropriately so that feed items inherit language setting(s).
Comment #104Jerimee CreditAttribution: Jerimee commented
Comment #105NCtiNet CreditAttribution: NCtiNet commented
Comment #106arlind CreditAttribution: arlind commented
Thanks for the great work on the patch - could it be made into a module, then it can be tested by a bigger audience and move it forward a to a alpha release - like me who doesn't know how to patch ;-)
thanks Bo
Comment #107alex_b CreditAttribution: alex_b commented
#106: I'd rather see tests than a separate module. We are very close, it's not hard at all to write tests. Just takes taking a little bump on the learning curve ;-)
Comment #108alex_b CreditAttribution: alex_b commented
Comment #109deggertsen CreditAttribution: deggertsen commented
It doesn't really make sense to make this a separate module as this functionality should really be included in this module, so a patch is appropriate. Go to http://drupal.org/patch/apply in order to learn how to apply patches. You may need to know some basic terminal/linux commands in order to navigate folders etc in the command line so check out something like this site http://www.reallylinux.com/docs/basic.shtml for that info. Once you know the basics applying a patch is a piece of cake.
This patch has been working great by the way. Hope we can have it actually put into the dev version soon at least.
Comment #email@example.com CreditAttribution: firstname.lastname@example.com commented
Patch #92 is working great for me too. Thanks everyone who has worked on this. Had a couple of issues with the patch file itself, but that was likely me not applying it correctly (this is the first patch i've ever tried to apply).
Just incase it wasn't me, here is result from the .rej file. I just applied the "'inherit' => array()," line manually to FeedsNodeProcessor.inc, and everything went smoothly after that.
*** 145,150 ****
'update_existing' => 0,
'expire' => FEEDS_EXPIRE_NEVER,
'mappings' => array(),
--- 152,158 ----
'update_existing' => 0,
'expire' => FEEDS_EXPIRE_NEVER,
'mappings' => array(),
+ 'inherit' => array(),
Comment #111NCtiNet CreditAttribution: NCtiNet commented
Why not add these categories in the taxonomy?
<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:media="http://search.yahoo.com/mrss/">
<pubDate>Mon, 28 Jun 10 13:26:54 -0400</pubDate>
<title>Avril Lavigne - Hot</title>
<description><![CDATA[Music video by Avril Lavigne performing Hot. (C) 2007 RCA/JIVE Label Group, a unit of Sony Music Entertainment]]></description>
<media:player url="http://youtube.com/?v=fzb75m8NuMQ" />
<media:thumbnail url="http://img.youtube.com/vi/fzb75m8NuMQ/default.jpg" width="120" height="90" />
<media:title>Avril Lavigne - Hot</media:title>
<media:category label="Tags">Avril, Lavigne, RCA, Records, Label, Pop</media:category>
<enclosure url="http://youtube.com/v/fzb75m8NuMQ.swf" length="202" type="application/x-shockwave-flash"/>
<title>Inna - Hot (True Love Video Edit) (On Ultra Dance 11 out now)</title>
<description><![CDATA[Inna - Hot (True Love Video Edit) from Ultra Records. Get Ultra T-shirts here: www.ultrarecords.storenvy.com Ultra Dance 11 out now. Buy the US album on iTunes bit.ly UK Release Date March 14]]></description>
<media:player url="http://youtube.com/?v=1rh3_r0nbKs" />
<media:thumbnail url="http://img.youtube.com/vi/1rh3_r0nbKs/default.jpg" width="120" height="90" />
<media:title>Inna - Hot (True Love Video Edit) (On Ultra Dance 11 out now)</media:title>
<media:category label="Tags">Inna, Hot, True, Love, Video, Edit, ultra, records, house, trance, music, progressive, electro</media:category>
<enclosure url="http://youtube.com/v/1rh3_r0nbKs.swf" length="225" type="application/x-shockwave-flash"/>
Comment #112palpatine1976 CreditAttribution: palpatine1976 commented
I'm getting same results as #101 and #110. Patch #92 fails on Hunk #2 - adding the line below:
+ 'inherit' => array(),
line into plugins/FeedsNodeProcessor.inc.
If you do this single line insert manually it seems to work - but should we have an updated patch or is this going to be rolled into a Dev build soon?
Great addition to the plugin tho!
Comment #113klonos CreditAttribution: klonos commented
as Alex said before (#100)... all we now need is tests and we are ready to commit.
Comment #114Equinger CreditAttribution: Equinger commented
I need to put a vote in for inheriting OG from the parent node as well. This is a feature we use heavily from the Feed API. I want to transition to this module for more customized parsing, but this feature is necessary.
Indeed, I can see how having the OG manage feeds would cause performance issues, but really, while our site is structured around organic groups, it does not imply that the OG will have the privileges to willy nilly add or control feeds. The OG is used simply to direct the audience and where on the site the feeds go from a user access/ ui perspective.
Comment #115Donnyboypony CreditAttribution: Donnyboypony commented
You guys really helped me! I was finally able to turn a Group Node into a Feed Node as well. I'm not sure how extensible it is and I'm not sure if this is a complete hack, but I've only been diving into modules for about 6weeks now.
if ($feed_node->type == 'mygroupnode') {
//set the group array just incase
$item_node->og_groups = array();
//take mygroupnode's nid as the group id
$gid = $feed_node->nid;
//inserts the mygroupnode NID as the og_group value
$item_node->og_groups = array( $gid => $gid );
//inserts the mygroupnode title as group name
$item_node->og_groups_both = array( $gid => $feed_node->title);
}else {
if (isset($feed_node->og_public) ) {
if (!isset($item_node->og_public)) {
$item_node->og_public = 1;
$item_node->og_public = $item_node->og_public & $feed_node->og_public;
if (isset($feed_node->og_groups)) {
if (!(isset($item_node->og_groups) && is_array($item_node->og_groups))) {
$item_node->og_groups = array();
$item_node->og_groups = array_merge($feed_node->og_groups, $item_node->og_groups);
foreach ($item_node->og_groups as $gid) {
if ($gid != 0) {
$transformed_groups[$gid] = $gid;
$item_node->og_groups = $transformed_groups;
if (isset($feed_node->og_groups_names)) {
if (!is_array($item_node->og_groups_names)) {
$item_node->og_groups_names = array();
$item_node->og_groups_names = array_merge($feed_node->og_groups_names, $item_node->og_groups_names);
What do you guys think?
Comment #116awakenedvoice CreditAttribution: awakenedvoice commented
Comment #117jkdaza CreditAttribution: jkdaza commented
Patch #92 works for me, tested only on Taxonomy terms, with Feeds 6.x-1.0-beta1.
Nice work ccoppen!!
Now, I wonder, how hard is it going to be adding the Location inheritance?
I haven't got enough PHP skills to do it, but I can support with testing as much as I can.
Anyone up to it?
Comment #118jvieille CreditAttribution: jvieille commented
Impossible to patch the current release, even manually, the code is much too different.
Is this possible to port it the the current Beta 2 release or - better - to commit the change.
Comment #119jvieille CreditAttribution: jvieille commented
smithmilner, what to do with this code? When where to invoke it, what it does exactly?
Comment #120DanielJohnston CreditAttribution: DanielJohnston commented
Subscribing. Specifically interested in allowing organic group admins to import nodes and users that automatically get assigned as appropriate audience / group members.
Comment #121Donnyboypony CreditAttribution: Donnyboypony commented
Ok, Apply Patch from comment #92 and go to plugins/FeedsNodeProcessor.inc
and replace the feeds_inherit_og function with:
* Inherit OG properties.
function feeds_inherit_og($item_node, $feed_node) {
if ($feed_node->type == 'mygroupnode') {
//set the group array just incase
$item_node->og_groups = array();
//take mygroupnode's nid as the group id
$gid = $feed_node->nid;
//inserts the mygroupnode NID as the og_group value
$item_node->og_groups = array( $gid => $gid );
//inserts the mygroupnode title as group name
$item_node->og_groups_both = array( $gid => $feed_node->title);
}else {
if (isset($feed_node->og_public) ) {
if (!isset($item_node->og_public)) {
$item_node->og_public = 1;
$item_node->og_public = $item_node->og_public & $feed_node->og_public;
if (isset($feed_node->og_groups)) {
if (!(isset($item_node->og_groups) && is_array($item_node->og_groups))) {
$item_node->og_groups = array();
$item_node->og_groups = array_merge($feed_node->og_groups, $item_node->og_groups);
foreach ($item_node->og_groups as $gid) {
if ($gid != 0) {
$transformed_groups[$gid] = $gid;
$item_node->og_groups = $transformed_groups;
if (isset($feed_node->og_groups_names)) {
if (!is_array($item_node->og_groups_names)) {
$item_node->og_groups_names = array();
$item_node->og_groups_names = array_merge($feed_node->og_groups_names, $item_node->og_groups_names);
be sure to change the Group Node value to whatever the machine name of your group node type is.
I was trying to attach a feed importer directly on a group. I was having troubles because the items from that feed weren't getting placed into the same group. After a bit of research I could safely say it's because a group isn't in a group... it IS the group. This code here is where you declare if your feed importer is attached to a group (not an item in a group) and then inserts corresponding group info into each feed item's object array.
Comment #122Steven Jones CreditAttribution: Steven Jones commented
Comment #123jvieille CreditAttribution: jvieille commented
But what is the proposed change for this function?
Now waiting for a patch that works with Beta 2...
Comment #124Donnyboypony CreditAttribution: Donnyboypony commented
The first If statement of that function is not part of the original patch. All you need is to write the machine name of your group node type and you're feed items will be placed in the group. An Example would be if I had a content type called League with a machine name of "league" that was a group.
if ($feed_node->type == 'league') {
//set the group array just incase
$item_node->og_groups = array();
//take mygroupnode's nid as the group id
$gid = $feed_node->nid;
//inserts the mygroupnode NID as the og_group value
$item_node->og_groups = array( $gid => $gid );
//inserts the mygroupnode title as group name
$item_node->og_groups_both = array( $gid => $feed_node->title);
}else {
After you write in the content type name, while editing any league you can input a feed and the feed items will be placed into that league.
Comment #125epersonae2 CreditAttribution: epersonae2 commented
NCtiNet (#111) - quick use case that got me here:
I want to build a private feed reader, cause I don't much like Google Reader, the other PHP app I've found is slow and clunky, and I like Drupal.
I'm going to be grouping feeds as Local, Webdev, Music and so on. Those categories don't exist inside the feeds on the sites themselves. They are purely my creation.
Additionally, I have no interest in using the site's categories of "house, trance, music" etc. (In your example)
Comment #126XiaN Vizjereij CreditAttribution: XiaN Vizjereij commented
Can someone please reroll the patch for beta2?
Comment #127DanielJohnston CreditAttribution: DanielJohnston commented
@smithmilner - I applied #92 with manual fixes as in #110 then edited in your code from #121, and my Feeds are now happily importing to inherited organic groups. Obviously before the code can be put into Feeds, it needs either a selector for which content type to look at, or to inherit either the top or all organic groups. Manually editing in the content type is a short term solution, but it's done the job for me. Thank you!
Comment #128jvieille CreditAttribution: jvieille commented
A patch for beta 2 from #92 + #110 + #121 would be much appreciated!
... before beta 3 comes out!
Comment #129Donnyboypony CreditAttribution: Donnyboypony commented
@danieljohnston - Glad it's working for you! Yeah it really is a short term solution but got the job done for me. I'll look into a better solution when I have some free time.
Comment #130jkdaza CreditAttribution: jkdaza commented
I have added few lines to patch #92 in order to support the location inheritance.
It works for me, with Feeds 6.x-1.0-beta1, but please test it.
It's my first tweak to a Drupal module, so any suggestion or comment would be helpful. I do not know how to write a patch so I ll just add the code here, it should be pretty obvious where it goes, after looking at patch #92.
The first bit that add Location to the list of inheritors:
if (module_exists('location')) {
$inheritors['location'] = array(
'name' => t('Inherit location'),
'description' => t('Feed nodes inherit location settings from feed node.'),
'callback' => 'feeds_inherit_location',
And then the function, very straight forward:
* Inherit location properties.
function feeds_inherit_location($item_node, $feed_node) {
$item_node->locations[0] = $feed_node->locations[0];
$item_node->locations[0] = $feed_node->locations[0];
Hope it helps
Comment #131DanielJohnston CreditAttribution: DanielJohnston commented
Having tested this for importing nodes, it's working fine. Is there anything similar for importing users though? What I'm looking for is a way of allowing organic group owners / admins to import users and have those users automatically join the import creator's organic group. May be willing to pay a bounty on this if someone can put together a working patch in the very near future, as I'm meant to be going live shortly!
Comment #132illmatix CreditAttribution: illmatix commented
Comment #133jvieille CreditAttribution: jvieille commented
#92 + #110 + #121+ #130 => patch beta 2
Comment #134alex_b CreditAttribution: alex_b commented
Comment #135jvieille CreditAttribution: jvieille commented
#134: I am not expert enough to create a patch, even less to create a patch for a version based on a patch from another one.
It is still so much a pain to apply a patch (Tortoise merge on Windows, looks like crap) that I generally modify manually my files... But here it is too complex and the beta 2 code is to much different.
Please apologize for the noise.
Comment #136alex_b CreditAttribution: alex_b commented
Comment #137Mathijs Koenraadt CreditAttribution: Mathijs Koenraadt commented
You have the option to use a "stand-alone" form on import. For inheriting language, this stand-alone form should have a language option as well.
Comment #1381st-angel CreditAttribution: 1st-angel commented
This is a patch agains beta2 which patches in all the changes from #92 + #110 + #121 and #130.
Comment #139alex_b CreditAttribution: alex_b commented
|Needs review
|» Needs work
Comment #140jvieille CreditAttribution: jvieille commented
Thank you so much!
I'll test it
Comment #141meatbag CreditAttribution: meatbag commented
Comment #142jvieille CreditAttribution: jvieille commented
That works perfectly.
Node processor can be set to inherit taxonomy, language and author fro Feed node. This is definitely a splendid achievement!
Comment #143vlooivlerke CreditAttribution: vlooivlerke commented
It works!
Thanks, for the great work.
Comment #144Bartezz CreditAttribution: Bartezz commented
#138: I manually added the patch to -beta3 because Tortoise wouldn't apply it.
Nodes do get create upon import yet getting this error:
warning: Invalid argument supplied for foreach() in C:\xampplite\htdocs\drupal\sites\all\modules\feeds\plugins\FeedsNodeProcessor.inc on line 412.
#line 412:
foreach ($this->config['inherit'] as $key => $value) {
Comment #145aaron_michels CreditAttribution: aaron_michels commented
Subscribing... thanks for working on this, guys.
Comment #146domesticat CreditAttribution: domesticat commented
I'm using the patch (hooray and thank you!) but wanted to pose a question to see if this use case has been considered: a site admin can set up taxonomy to inherit if the importer is attached to a node type. However, if the standalone form is used, there's no way to select taxonomy, etc.
I could see this being a design choice, but I wanted to make sure it had been considered.
Comment #147David Stosik CreditAttribution: David Stosik commented
Comment #148Marc Ledergerber CreditAttribution: Marc Ledergerber commented
It would be great if the "inherit" patch (in #138 above) were committed to the next version of Feeds ==> 6.x-1.0-beta4
Currently, the Feed Node processor does not allow taxonomy to pass to Feed nodes. This patch seems to handle this function.
Please confirm that this function also works in standalone form mode too, so taxonomy can be selected, mapped upon import from a local file (e.g. CSV import of taxonomy and Feed source using Feed Node processor).
Comment #149klonos CreditAttribution: klonos commented
Issues are only set to 'patch (to be ported)' once they are fixed in one major version and need to be ported to another (for example fixed in 6.x - need to be ported to 7.x, or the other way 'round). This status is not meant to be used among minor versions (there can never be porting form version 6.x to 6.y).
Also, as repeatedly stated by the module maintainer in several posts (#100, #107, #108, #139) this will only be committed once we have tests for it. I guess he made it pretty clear! I am monitoring all this module's issues and I think it is his 'policy' -so to say- that every new feature needs to have tests before committing. I understand the frustration of people always having to apply patches in order to get things working, but we need to respect the way alex maintains this module and help him get tests. So, setting back to 'needs work'.
Comment #150jkdaza CreditAttribution: jkdaza commented
Can you please confirm the patch #138 works for beta3?
Comment #151klonos CreditAttribution: klonos commented
I myself use latest devs in general. I could set up a test environment and test patch #138 with beta3 ...but so can you or anyone else that currently uses beta3 ;)
Just remember to back up all patched files and you can revert to them if something happens to go wrong.
Comment #152Marc Ledergerber CreditAttribution: Marc Ledergerber commented
See http://drupal.org/node/862874 re Taxonomy support for mapping fields using "Feed Node processor" when importing from local CSV file with standalone form
Comment #153alex_b CreditAttribution: alex_b commented
|Inherit settings from parent feed node (like taxonomy)
|» Inherit properties from parent feed node (taxonomy, author, OG, language)
Make it easier to find this issue.
Comment #154jvieille CreditAttribution: jvieille commented
#149, could you clarify?
1) Do you mean we have to wait this module to be final (not beta) to get this feature in?
2) What does "tested" means, in addition to the several posts telling it works great?
Comment #155aidanlis CreditAttribution: aidanlis commented
I've removed the fieldset from the settings page and used checkboxes for a more consistent look, and I've scaffolded the unit tests. I'll aim to get the tests done tomorrow. New patches attached.
Comment #156klonos CreditAttribution: klonos commented
1) I wasn't trying to make any point. You were just using the 'patch to be ported' status the wrong way (Please check the Status link available right under the drop-down menu that allows you to set it)
2) Also check the same link, but you need to know the following because you seem to be confusing testing done by users (should be called 'trials' or something instead of tests) with the SimpleTest... When we talk about tests here, we mean automated tests that are written and meant to provide quality assurance. They help automate test most common tasks a module should be able to do without errors (pass these tests with green).
Comment #157alex_b CreditAttribution: alex_b commented
#155: this looks very nice.
In the test I saw you use
module_exists().This will bite you as it will check whether the module is installed in the test while you need to install it in setUp().
Just do the same that we do in all other tests: assume that these modules are present, install them in setUp() and add a note into the tests' description that it requires OG and Location (the other modules are core anyway).
We will then add the required modules for tests to the Feeds test profile - which btw I recommend using for tests if you are familiar with drush / drush make.
Comment #158DanielJohnston CreditAttribution: DanielJohnston commented
#155: looks good and have patched successfully with beta 4, BUT it looks like organic groups inheritance still requires manual editing of FeedsNodeProcessor.inc to replace 'mygroupnode' with the name of the content type that you want to check for organic groups membership, as explained in #121 and #124. Is there any way of making this a text box or radio selector in the importer settings?
Comment #159aidanlis CreditAttribution: aidanlis commented
#158: I've used og_get_types, will that do? I initially had a select box, then realised you could have more than one group node so used checkboxes, then realised there's probably a function for this, and voila.
#157: I've fixed up the test to setUp those modules and removed the module_exists checks.
To test inheritance I wrote the function createCustomFeedNode, which allowed me to set arbitrary properties on the node. This could be combined with createFeedNode for simplicity, but I didn't want to poke around too much.
I've added a test for the Author inheritance which passes on my setup, and scaffolded the rest of the tests so that it should be easy for the next person. I haven't used Drupal's SimpleTest before so this was all quite a challenge, I hope it's on the right track.
Comment #160aidanlis CreditAttribution: aidanlis commented
Typo in #159
Comment #161alex_b CreditAttribution: alex_b commented
|Needs work
|» Needs review
160, is this NR now or are you planning on more work?
Comment #162alex_b CreditAttribution: alex_b commented
Cleaning up tags.
Comment #163alex_b CreditAttribution: alex_b commented
|Needs review
|» Needs work
To test inheritance I wrote the function createCustomFeedNode, which allowed me to set arbitrary properties on the node. This could be combined with createFeedNode for simplicity, but I didn't want to poke around too much.
Just go ahead and patch createFeedNode() - that'll be cleaner.
Only user inheritance is tested so far, hence setting back to NW.
Comment #164aidanlis CreditAttribution: aidanlis commented
Yeh, still definitely NW, I ran out of time and thought I'd upload the progress in case anyone else wants to finish it off.
Comment #165aidanlis CreditAttribution: aidanlis commented
Okay I've installed the feeds_test package, checked out Feeds from CVS, and run all of the unit tests, I'm getting:
459 passes, 6 fails, and 12 exceptions for Feeds. Is that normal? I want to make sure everything's working before I start.
Comment #166pdrake CreditAttribution: pdrake commented
I have just completed some work on the ability for imported users to inherit the group from the feed node. That is, there is a setting on the user import processor to allow for inheritance. And I have extended my OG mapper to include the ability to map the new user's groups to the feed node's groups. Attached are the patches to add inheritance to the User processor. I will post the actual mapper in the OG mapper thread.
Comment #168aidanlis CreditAttribution: aidanlis commented
Maybe it would be better if #166 was raised as a new issue, so it doesn't hold up the changes to the FeedsNodeProcessor (unless you have unit tests for your patch?)
Comment #169pdrake CreditAttribution: pdrake commented
Because the patch in #166 does not provide any inheritable fields, it merely patches FeedsUserProcessor to allow other modules to hook in and provide inheritable fields, I'm not sure if there are any unit tests required. I would think the tests would need to be created along with the mapper or module which actually provides an inheritable field. Is that not the case?
If there are unit tests required for this patch, let me know and give me some basic direction and I'll try to get something together in the next day or two.
Comment #170momendo CreditAttribution: momendo commented
+1 to get this patch in ASAP
I was expecting Feeds to be able to do this feature like FeedAPI did. :-(
Comment #171deckfifty CreditAttribution: deckfifty commented
Comment #172unrev.org CreditAttribution: unrev.org commented
Chiming in for subscription and taxo inheritance for feeds. Otherwise the module is quite slick!
Comment #173jenna.tollerson CreditAttribution: jenna.tollerson commented
What would it take to get this committed? Would a bounty help? Any labor I can chip in? I know it's because I'm not used to following dev threads like this, but I am really confused about the progress and it would be great to just have an assignment. :)
Comment #174momendo CreditAttribution: momendo commented
#160 seems to be a good basic fix. #166 added more to that relating to OG module. I think testing is needed.
Comment #175aidanlis CreditAttribution: aidanlis commented
The only thing holding this up now is the unit tests. I don't know how to write them, I've done 80% of the work but I can't get them to pass. I ping alex_b every day, but he's been AFK for the last two weeks.
Comment #176pdrake CreditAttribution: pdrake commented
There were some problems reported with patch not properly applying my patches in #166 so I re-created them. These are patches against beta4 as opposed to #166 which was against beta3.
Comment #177klonos CreditAttribution: klonos commented
... I believe new features are done against latest dev versions in order to avoid such things. This way, you get more chances to be included in the next stable (or an alpha or beta)
Comment #178pdrake CreditAttribution: pdrake commented
Generally, I do create patches using the latest dev version. In this case, it was work-for-hire and the patches being rolled for a particular release was specified in the statement of work.
Comment #179klonos CreditAttribution: klonos commented
Thanx for taking the time to reply Peter. I think the patch still works with the latest dev, though it might need manual patching. Perhaps if you were kind enough you'd roll it against it to spare people from the manual work.
Comment #180jun CreditAttribution: jun commented
Comment #181zacho CreditAttribution: zacho commented
Comment #182rbrownell CreditAttribution: rbrownell commented
Quick question: has this been committed to a release at all? Reading through all of this, I am kind of lost.
Comment #183Michelle CreditAttribution: Michelle commented
@nfd: Nope, still waiting on someone who knows how to make simpletests.
Comment #184boogsbobo CreditAttribution: boogsbobo commented
Comment #185jvieille CreditAttribution: jvieille commented
What is the problem with tests? It looks like a new (or mainly forgotten) policy that only applies to some modules.
Anyway, a patch is always painful to apply, letting very few users doing the field testing.
On the other hand, a dev version is supposed to be unstable, so incomplete formal testing would not hurt.
Why not committing to an updated dev?
Comment #186Michelle CreditAttribution: Michelle commented
There is no policy. It's up to individual module maintainers if they want to use tests or not. Test driven development means less buggy code so I can understand their reasoning. On the other hand, it does make it difficult when you have people wanting to use a feature, willing to test the feature, but that don't know how to make tests.
Comment #187aidanlis CreditAttribution: aidanlis commented
The patch is already field tested - it works perfectly. The module maintainer has made the decision not to commit anything to CVS without tests, which I think is a great idea. The only problem is the maintainer has been MIA for 2 weeks, and I can't finish the tests without him.
I've re-rolled the patches #166 and #160 into a single patch, which is now attached.
If you're not sure how to use patch on command line, download patch_manager which makes patching modules a breeze.
Comment #188alex_b CreditAttribution: alex_b commented
|Needs work
|» Needs review
Back from vacation, I need to get some time to review #187. aidanlis: can you summarize your open issues with the patch?
#185 jvieille: Tests are required to avoid regressions. In fact, I would argue that maintaining an integration-heavy module like Feeds while staying sane is only possible with tests. I require them on a per patch basis, otherwise, they just don't happen.
Comment #189aidanlis CreditAttribution: aidanlis commented
Hi Alex, hope you had a nice vacation.
If you apply the patch in #187, you'll see when running the Feeds test with Inheritance testcase, the following errors:
"Your configuration has been created with default settings." found Other feeds.test.inc 99 FeedsWebTestCase->createFeedConfiguration()
"Your changes have been saved." found Other feeds.test.inc 139 FeedsWebTestCase->setSettings()
Valid content type found: Other feeds.test.inc 162 FeedsWebTestCase->createFeedNode()
Then a bunch of other errors. I don't know what's going on ... when I perform the actions manually, I do see the strings that the TestCase is failing to see. I'm new to simpletesting with Drupal, so I don't know how to see what output I'm actually getting when the test fails.
Comment #190David Goode CreditAttribution: David Goode commented
Hey all; I feel like an easier way to implement this would be entirely on the parser side, exposing new sources, and then just let the existing mappers take care of sticking it wherever it wants to go depending on the storage method. This was it automatically works with any processors that have such mappers. I have attached a patch that has much of the previous functionality; it doesn't work for things where mappers don't exist though, such as OG group settings (to my knowledge). Also doesn't have tests :-( I copied parts of the previous patches for things like the mapper functions.
This has been tested with the syndication parser and the data mappers for taxonomy; other testing would be required. Includes minor parser change to both syndication and SimplePie.
Comment #191David Goode CreditAttribution: David Goode commented
Tweak for better performance.
Comment #192David Goode CreditAttribution: David Goode commented
Support for module-name based features exported vocabs.
Comment #193AntiNSA CreditAttribution: AntiNSA commented
I am getting really close to needing my feeds to inherit taxonomy I define when inporting feeds. is this feature near ready, or has anyone got it to work?
in detetail:
CONTENT TYPE A holds the url for the feed to import
---holds a custom taxonomy vocab
CONTENT TYPE B - nodes created from importing the items from the url provided in content A
--has the same taxonomy vocabulary assigned
--------If I selected cats in content type a, every imported feed/freshly created node of CONTENT B would be assigned that taxonomy , in this case "cats"
Thats what I mean when I say inherit taxonomy... is it possible soon?
Comment #194aidanlis CreditAttribution: aidanlis commented
#193: Yes, just install patch #187.
#190: Can you explain your approaches benefits over what we already have in #187?
Comment #195Will White CreditAttribution: Will White commented
It looks like this patch aims to do what you need.
Comment #196brycesenz CreditAttribution: brycesenz commented
I am interested in the idea of feed items being able to inherit CCK fields from the feed node (an idea brought up earlier in this thread). I would be willing to help test out patches which cover this use case, or possibly trying to extend an existing patch if the author feels that such an extension could be handled by an admittedly novice PHP coder.
I would also be willing to chip in a modest amount of money (especially if others feel the same way) to help make this a priority. Big ups to everyone's who has put forth work on this so far; it's turned out to be an incredibly awesome module.
Comment #197David Goode CreditAttribution: David Goode commented
To #194
Hey, this version can be implemented very easily in basically all parsers--just add a single line. Then, it will work with all processors. It provides a new source, so any processor can then use it as long as it has a compatible target. Taxonomy is already "inheritable" to nodes and data entries with this patch, for instance, without actually changing either processor. It also doesn't require a new UI and involves less code.
On a higher level, it maintains the separation between "sources," associated with parsers, and "targets," which are the realm of processors and their mappers. Inherited content looks the same to the processor as content actually retrieved from the feed or CSV file or whatever, and can be treated by reusing the same storage stack.
Comment #198ufku CreditAttribution: ufku commented
David's method is extending the already available mapping functionality by providing an extra source(feed node). A big +1 from me.
Comment #199realnerd CreditAttribution: realnerd commented
To #197
this version can be implemented very easily in basically all parsers--just add a single line.
How would i go about this if i wanted to do exactly this, but for the xpath parser module?
the code from the module found here http://drupal.org/node/871384
Comment #200alex_b CreditAttribution: alex_b commented
#190 You went there :) I've avoided going through the mapping stack so far as strictly speaking a subscription's feed node is different from the feed item that is being mapped from. However, I see the benefit of the parser level API allowing any processor to use inheritance.
I will need to do a closer review.
In regards to OG support, the approach from #190 would require #857424: Mapper for Organic Groups.
Comment #201AntiNSA CreditAttribution: AntiNSA commented
patch 187 failed to cause feed nodes inherit taxonomy for me.
Comment #202AntiNSA CreditAttribution: AntiNSA commented
I have applied the patch in #192 and after setting the taxonomy, the nodes created and the taxonomy set where you enter the feed address is not inherited by the created nodes. I installed the patch against the latest dev version.
Comment #203AntiNSA CreditAttribution: AntiNSA commented
Ihave tried to assighn vocabulary with content taxonomy and also tried to select taxonomy by assigning taxonomy vocabulary to content types. none of them are being inherited when nodes are being created.
Comment #204alex_b CreditAttribution: alex_b commented
#190 was completely broken, but inspiring. This patch builds on David's argument from #190 that we should be expanding the mapping API in Feeds to implement inheritance rather than creating a similar separate API.
Here's a quick screenshot that should explain most, see how the mapping UI is used to map feed node properties to feed item node properties: http://skitch.com/alexbarth/dikw2/edit-importer-feed-feeds-test-site
Expanding the mapping API has the additional advantage of laying the ground work of mapping feed level import content (e. g. a feed's description or its icon or its link) to feed items. It also is a first step of mapping feed level import content to the feed node itself - this is going to take some serious additional work though.
Expanding the mapping API comes of course at the cost of a rather invasive patch (compare the ~50k to previous ~20k patches). A lot of refactoring had to be done to expand the mapping API from a mapping-target-only API to a source and target API. Now additionally to the existing hooks allowing other modules to expand on available mapping targets (
hook_feeds_node_processor_targets_alter() or
hook_feeds_user_processor_targets_alter()) you will find a new
hook_feeds_parser_sources_alter() that allows for injecting new mapping sources. See feeds.api.php for more details.
The most important change to the existing API is that map() and related functions (existimgItemId(), setSourceElement()) now require to pass in $batch instead of $item. This is necessary as we need to be able to access batch level data:
// Previously:
$this->map($item, $target) {
// Map from $item;
// Now:
$this->map($batch, $target) {
// Map from $batch->currentItem();
// or map from $batch->feedNode();
The availability of $batch->currentItem() also means that in a processor, the batch object should not be consumed with shiftItem() but just iterated over with nextItem():
// Previously:
while ($item = $batch->shiftItem()) {
// Now:
while ($item = $batch->nextItem()) {
All tests passing.
Todo: as we don't consume items with shiftItem() anymore, we may run into issues with batching as we will always store all items between page loads now... This issue would go away with #744660: Expand batch support to fetchers and parsers which I don't think we will be able to commit in Drupal 6.
Comment #205alex_b CreditAttribution: alex_b commented
Switched back to a
shiftItem() based approach. This is close to RTBC now, reviews more than appreciated at this point.
I haven't mentioned that in #204 explicitly, but patch contains tests for taxonomy, og, locale and uid inheritance, all passing.
Comment #206ufku CreditAttribution: ufku commented
Tested #205 successfully with "Common syndication parser" for "Taxonomy mapping".
Used 3 vocabularies and they were successfully mapped from Feed node to Feed item nodes.
Comment #207alex_b CreditAttribution: alex_b commented
To be released w/ 6.x-1.0-beta5.
Comment #208alex_b CreditAttribution: alex_b commented
|Needs review
|» Fixed
Comment #209Michelle CreditAttribution: Michelle commented
Thanks, Alex!
Comment #210DanielJohnston CreditAttribution: DanielJohnston commented
Quick question: the committed patch appears to incorporate #166. Does this still require / work with #857424: Mapper for Organic Groups or does it provide the full functionality itself? Looking forward to beta 5!
Comment #211alex_b CreditAttribution: alex_b commented
Comment #212Michelle CreditAttribution: Michelle commented
I've gotten rather lost in this huge issue... Did this ever cover Domain Access? I've got a hacked up version of Feeds so it works with that as well as passing the author name of the parent node to the feed entry node. Looks like author is covered but what about DA?
I know I'm being lazy... If you don't know this off the top of your head and have to look it up, ignore me and I'll go STFQ :)
Comment #213alex_b CreditAttribution: alex_b commented
Does not cover DA. Has all the API improvements to implement DA real fast though - have a look at mappers/locale.inc.
Comment #214Michelle CreditAttribution: Michelle commented
Alex - Thanks! Will have a look. I'd like to get rid of my custom code.
Comment #215rbrownell CreditAttribution: rbrownell commented
I keep getting this error... I am thinking it is taxonomy inherit related.
user warning: Duplicate entry '13-11738' for key 1 query: INSERT INTO term_node (nid, vid, tid) VALUES (11738, 11738, 13) in /srv/www/html/modules/taxonomy/taxonomy.module on line 716.?
Comment #216rbrownell CreditAttribution: rbrownell commented
When is Beta 5 coming out? I can't seem to find it!
Comment #217alex_b CreditAttribution: alex_b commented
#215: please file a separate issue, *describing which configuration you use and how to reproduce the bug!*
beta 5 will come out some time this or next week.
Comment #218brycesenz CreditAttribution: brycesenz commented
Will this update cover inheritance of CCK fields, or should that be opened as a separate issue?
Comment #219alex_b CreditAttribution: alex_b commented
That's a separate issue.
Comment #220momendo CreditAttribution: momendo commented
I think this is a big enough feature to mention as a bullet point on the Feeds project homepage.
Comment #221aidanlis CreditAttribution: aidanlis commented
Great work alex_b and everyone else who contributed!
Comment #222rbrownell CreditAttribution: rbrownell commented
|» Active
From what I can tell, this was not released in 6.x-1.0-beta5! Can anyone confirm?
If it has been, where are the checkmark boxes that you select to tell it to inherrit the variables from the feed node or is this susposed to be automatic? If it is susposed to be automatic with no checkmark boxes required it is not working.
Comment #223alex_b CreditAttribution: alex_b commented
|» Fixed
This has been released. Please read #204 and see the screenshot linked from it.
Comment #224AntiNSA CreditAttribution: AntiNSA commented
my error/sorry
Comment #225AntiNSA CreditAttribution: AntiNSA commented
that was my error,, sorry/
Comment #226rbrownell CreditAttribution: rbrownell commented
|» Active
alex_b: Thanks for letting me know. I was using one of the other patches that applies the taxonomy to all as opposed to haveing it map at the mapping level. Here is something else for you.
The method used causes a conflict with various parsers that require the individual to type a value as the source. See: xPath Parser #908776: No Source Available For Mapping. Should this be a new issue or the same one?
Comment #227alex_b CreditAttribution: alex_b commented
|» Fixed
nfd - this needs to be fixed in parsers - #908776: No Source Available For Mapping. There is nothing we can fix in Feeds for that.
Comment #228Bartezz CreditAttribution: Bartezz commented
Just installed the latest stable version! Great!!! Author, language and taxonomy from the feed node are perfectly mapped.
Thanx for this great feature!!!!
Comment #229jvieille CreditAttribution: jvieille commented
This is really a neat enhancement. Thanks!
Comment #230Sericlaire CreditAttribution: Sericlaire commented
Hi folks,
When attempting to apply the patch via patch manager apparently "Patching did not go smoothly".
Followed by:
Patching file tests/feeds_mapper_taxonomy.test using Plan A...
Hunk #1 FAILED at 38.
Hunk #2 succeeded at 55 with fuzz 2 (offset -21 lines).
Hunk #3 FAILED at 149.
Hunk #4 succeeded at 390 with fuzz 2 (offset 170 lines).
2 out of 4 hunks FAILED -- saving rejects to file tests/feeds_mapper_taxonomy.test.rej
at the bottom.. Is this an error on my part or?
Comment #231Bartezz CreditAttribution: Bartezz commented
Don't use patch but download latest version...
Comment #232rbrownell CreditAttribution: rbrownell commented
Sorry about that, I wasn't totally sure. Sorry for the inconveience.
Comment #233ehudash CreditAttribution: ehudash commented
Thanks for the fix!
Does anyone have new info regarding the #826964: Inherit settings from parent feed node (Domain Access) ?
Comment #234endiku CreditAttribution: endiku commented
As I understand it, #205 is now part of the latest beta. I have beta7 and can see the patch information from #205 in the files. However I am not seeing the Feed Node choices in the source dropdown list for mapping for node processor. Was there some key element I have missed in this thread?
Comment #235alex_b CreditAttribution: alex_b commented
@234: Please read notes around patch that was committed. Also look at screenshot.
Comment #236endiku CreditAttribution: endiku commented
Sorry to repeat my question, especially if this is a dumb question. However I have already read all the patch notes.
Is there more to do beyond having this patch implemented? I thought that the additional mapped sources were included in the update. I see them in the feeds/mappers directory. Such as og.inc and taxonomy.inc. However I do not see any additional sources in the drop down such as the screenshot shows.
My understanding is that this update automatically adds source node sources to the source dropdown list without the need to add these sources manually. Am I wrong in that assumption? I understand there is a developer's guide to mapping (http://drupal.org/node/622700) but I am still a little unclear to whether that pertains to adding mapping sources for other modules as well as the sources mentioned in this patch, such as og and taxonomy.
Comment #237alex_b CreditAttribution: alex_b commented
#236 - the additional sources only show up if they actually exist on the feed node's content type. Are you sure that there is e. g. a taxonomy configured for the feed node?
Comment #238endiku CreditAttribution: endiku commented
Turns out it is because of iCal feed parser.
Sorry I didn't find that first. Didn't realize the problem until I rebuilt the feed to check what you were saying and saw the sources when it was using the default parser but then not for ical.
Comment #240jnettik CreditAttribution: jnettik commented
Will this feature be added to iCal parsers?
Comment #241Lasac CreditAttribution: Lasac commented
I am aswell not really getting this. Can i set a taxonomy term for a feed that will import nodes. So just like i can set the author, can i also declare the term? My nodetype does have the taxonomy but i can't see nothing of it.
Comment #242Anonymous (not verified) CreditAttribution: Anonymous commented
Has this patch be ported on Drupal 7?
Comment #243skolesnyk CreditAttribution: skolesnyk commented
Yes, it has. Check out Feed settings at admin/structure/feeds/feed/settings/FeedsNodeProcessor
Comment #244m4olivei CreditAttribution: m4olivei commented
I'm having trouble using hook_feeds_parser_sources_alter with a CSV Parser. Is it even possible to make user of hook_feeds_parser_sources_alter when a CSV parser is used? I ask because I can't get it to work and also noticed that the patch committed here includes an override to the getMappingSources() function:
class FeedsCSVParser extends FeedsParser {
* Override parent::getMappingSources().
public function getMappingSources() {
return FALSE;
Comment #245AlfTheCat CreditAttribution: AlfTheCat commented
@m4olivei have you been able to get this working for CSV imports? I'm not able to get it going either... I've opened a seperate issue #1587482: Cannot inherit taxonomy from feed node when using CSV parser.
Would appreciate any help!


text:
I'm a Winnipeg-based print and web designer with 7 years of experience working in the Graphic Design industry and specializing in logo design, illustration, and hand-drawn typography. I am passionate about creating imaginative illustrations and linocut prints with themes inspired by nature, martial arts, science fiction, and mythology.
Graphic Designer
- Full time
- Part time
- One time
- Contract
- Temp
I specialize in logo design, illustration, website design, and design for print materials like brochures, newspaper and magazine ads, and editorial page layout.
Work History
Pattison Outdoor Advertising
From November 2011
Graphic design for many large format advertising products like billboards and transit ads.
Go to the website to learn more about what we do!
Graphic Designer
KIK Associates
July 2009 - March 2011
Graphic Designer
January 2004 - July 2009
Business Card for local Computer Programmer / IT Consultant
All elements designed by Kristen Guy.
Font: Eurostile Demi
CMYK business card, double sided, vertical format.
QR Code on front of card needs to be 1 inch x 1 inch, will be updated for second proof.
Template Design & Layout, Clothing File Prep / Prepress
Set up and prepare files to go to China for production for a local martial arts studio.
Clothing vector artwork created in Adobe Illustrator.
*(Original artwork for Robert Lee Martial Arts Logo and Karate Kid graphic were supplied to me. Client supplied all direction for the look and placement for the graphics on the clothing.
Website Design
Portfolio and resume HTML website for a professional fine artist.
Landscape Nature Paintings Series
Violet Dusk and Always Midnight Somewhere
Paintings may be purchased as a set of 6 (3 of each) glossy postcards, or as a set of 6 (3 of each) blank greeting cards, or individually as high quality giclee prints.
Postcards are standard size and you can request a short personalized message to be printed on the front or back of the postcards. $15.00 per set of 6.
Blank greeting cards are available for $15.00 per set of 6.
Pricing of the giclee prints will vary depending on size of print requested. Sizes and pricing available upon request.
Both original acrylic paintings are for sale. Both are 30"w x 24"h. "Violet Dusk", and "Always Midnight Somewhere". Either original painting can be purchased for $450 CDN, or best offer, and comes with artist's signature stamp in bottom right corner.
Paintings whether giclee print or original canvas artwork may not be photographed, scanned or reproduced for any reason without consent from the artist, Kristen Guy.
For information contact via e-mail: email@example.com
Prepress / Production / File Prep
File prep and layout of vector artwork for a Winnipeg based martial arts instructor for the following items:
• Business Cards
• Duffle Bags
• T-shirts
• Hand wraps
• Water Bottles
• Hand Towels
Website Design
Portfolio and resume HTML website for a professional freelance copywriter.
Qualifications & Certifications
Graphic Design Advanced
Red River College
Graphic Design
Red River College
Pinawa Secondary School
Skillpages has been acquired by Bark.com!
Bark.com is pioneering the way people find local services. Skillpages is the world's premier directory of service providers.Find out more

subset: commoncrawl


text:
"It's been an adventure just getting here."
Kate Spooner of Grand Pre, a goalie on the East Hants Pro Cresting Penguins hockey team, was one of the people trapped on the Marine Atlantic Ferry between Newfoundland and Nova Scotia April 3 after it became stuck in thick ice.
Spooner was travelling to Deer Lake, NL, the site of the Atlantic midget AAA girls' championship, with her teammates, including another Kings County resident, Courtney Foster.
The team left around 3:30 p.m. April 1 for North Sydney to catch the ferry to Newfoundland. The roads "weren't great," but the team made it to the outskirts of North Sydney when their bus got stuck in heavy snow.
"We were turning off the off ramp, about 500 metres from our hotel, when we got stuck in about a metre of snow," Spooner said.
"We already knew the ferry was cancelled. We were stuck for two hours. All sorts of men with shovels, and snowplows, were trying to get the bus unstuck. It's amazing how many people just showed up to help."
Once they got moving again, they spent two hours waiting in line.
"Finally, we got to the checkpoint, but it was two more hours before we got on the ferry because they load the trucks first."
The team finally made it onto the ferry, which had been scheduled to leave at midnight, around 2 p.m. on Wednesday.
"Then we couldn't leave until 5:30 because they were checking the conditions."
Once on the ferry, the team had "rooms with bunks, and a nice cafeteria where we got a hot meal," but the adventures weren't over yet. Less than an hour out of North Sydney, the ferry became stuck in the ice.
"There was probably four feet of ice everywhere," Spooner said.
Three of the five teams in the tournament - Nova Scotia, P.E.I. and New Brunswick - were all on the same ferry.
"We were all wondering if it would be cancelled, or postponed, or the schedule pushed back. Finally, we got notice that the schedule would be pushed back a day."
Despite some tweets from people on the ferry, Spooner said they never ran out of food on the ferry.
"I expect they were getting a bit low on some things, but we were told they had enough to feed everybody for three days," she said.
"The crew was great. They gave us all a complementary meal for all the time we'd had to wait."
Finally freed from the ice, the ferry arrived at Port aux Basques, NL early in the afternoon April 3.
After an uneventful bus ride, Spooner and her teammates were in their hotel when she called, looking forward to a restful night. The tournament will now get underway April 4, with games at 11:30 a.m. and 7 p.m., followed by two games April 5.
"I'm looking forward to it, now that we're here. Once we got here, there was such a relief, but we're all excited now."
She's feeling confident Nova Scotia will do well.
"I have a good feeling we'll be playing in the final."
Even so, their win over Boston Pizza in the league final was "unexpected. B.P. had won every year there's been a league," she said.
"We love playing them. They're our rivals. We were happy just to be in the final. The best game of the series was probably game two, the one we won 1-0. Games three and four were similar. We got all the right bounces...a lot of people said they felt we deserved to win. It's our year, and everybody has really bought into the system."
Results from Atlantics are available here and games can be watched live here.


text:
Oldsmobile Cutlass Supreme for Sale
Selected Filters:Type of Ad: Vehicles for Sale Make: Oldsmobile Model: Cutlass Supreme Remove All
1972 Oldsmobile Cutlass Supreme 2dr HT
Staunton, IL
2dr HT, nice clean 2 owner car, good body and paint, nice orig int, shows 81,xxx mi, believed to be actual, V8, auto, ps,... More
1971 Oldsmobile Cutlass Supreme 350 Four Speed
Stratford, NJ
Just arrived!!! This is and outstanding RARE!! Rocket 350 four speed.... Loaded with Power Steering Power Disc Brakes..... Great Black paint!!! Excellent Black interior,... More
1979 Oldsmobile Cutlass Supreme Brougham
Anderson, CA
Amazing Survivor from Redding California. Purchased new from Trevellyan Oldsmobile in San Diego. This phenomenal find has just 24711 actual miles. Rarely driven and... More
1967 Oldsmobile Cutlass Supreme Supreme
Cedar Rapids, IA
1967 Oldsmobile Cutlass Convertible The '67 Olds Cutlass Series was the most popular nameplate for a U.S. built car. They used top quality... More
1978 Oldsmobile Cutlass Supreme 2dr
Staunton, IL
1978 Olds Cutlass Supreme 2dr, nice black bucket seat and console int, new tires on rally wheels, good paint, great driver, v8, at, 49,xxx... More
1977 Oldsmobile Cutlass Supreme Coupe
Staunton, IL
nice int and new paint, split bucket p seat, V8, at, ps, pb, fact a/c, 55,xxx mi, runs good.... More
1994 Oldsmobile Cutlass Supreme Conv
Staunton, IL
Well kept car, nice top, nice orig leather int, newer tires, V6, auto, full power, cold a/c, hot fun in the summer time, runs/drives... More
1970 Oldsmobile Cutlass Supreme Supreme
Maryville, TN
Most All of Our Auctions End Early Call Us for A Great Price 865 988 8088 Up for sale we have a 1970 Oldsmobile... More
1967 Oldsmobile Cutlass Supreme Holiday Coupe
Volo, IL
If you are the type that appreciates really clean old cars that have been obviously well cared for, you will love this one. It's... More
Advertiser since 1971
1970 Oldsmobile Cutlass Supreme
Ancaster, ON
1970 Oldsmobile Cutlass S Convertible350 cu in Rocket V-8 4 barrel (310hp) 3 speed autoPS PW PDL PBRally wheelsOwned since 2004Runs and drives greatFun... More
Advertiser since 2010
1967 Oldsmobile Cutlass Supreme 330-4, CLIMATE COMBUSTION CONTROL OPTION
Milford, OH
1967 OLDSMOBILE CUTLASS SUPREME COUPE, RARE DRIVE LINE PACKAGE CONSISTING OF 330-4 320HP V8, MATCHING NUMBERS # 394417 3 HEAD # 4 THREE SPEED... More
Advertiser since 2001
1970 Oldsmobile Cutlass Supreme
Thousand Oaks, CA
Here's a nice California blue-plated Cutlass that's not gutless. It has a nice healthy Mondello built 455 with some performance features such as: Edelbrock... More
Advertiser since 2007
1977 Oldsmobile Cutlass Supreme
Hopedale, MA
1977 Oldsmobile Cutlass Supreme 2 Door Hardtop. 25,000 Actual Miles. 1 Owner Original Survivor. Original Title, Bill of Sale, Owners Manual and Misc Documentation... More
1975 Oldsmobile Cutlass Supreme 2 dr Hardtop
Clarkston, MI
With a Professional Frame off Restoration this 1975 Olds Hurst 442, aka Cutlass Supreme 2 dr Hardtop needs nothing! Only a few tweaks and mild... More
Advertiser since 2007
1971 Oldsmobile Cutlass Supreme Convertible
Roswell, GA
OLDSMOBILE 1971 CUTLASS SUPREME CONVERTIBLE, that is a very, very exciting Dark Venetian Red in terrific condition for great driven, new special dark red... More
Advertiser since 1986


text:
My general approach during the Winter Meetings is to not opine on every rumor or random story out there because, let's face it, most of what you read about isn't really going to happen. Still, I have to smile at stuff like this:
Shortly after Theo Epstein met with reporters tonight, an agent walking the hall of the Bellagio resort and casino gave the Red Sox the supreme compliment.
"They explore everything," said the agent.
Including a name that should be familiar to all Sox fans for obvious reasons.
Andy Pettitte.
Though there is no indication that any deal is imminent or that the Sox have done anything more than kick the tires, the Sox have expressed some interest in the pitcher, according to a source.
I can't see the Red Sox being truly interested in Pettitte. I can see them doing what people always talk about them doing, however, and that's messing with the Yankees and trying to make them overpay for someone. Back when George Steinbrenner was in charge you never gave that sort of thing much credence. He was going to do what he was going to do, and he always made it seem like he was driving the bus. Now it's different, and it seems like the Red Sox are openly and obviously trying to get in the Yankees' head. If Pettitte signs with the Yankees relatively soon, you'll know it worked.


text:
of Forever Tango and The NJ Tango Extravaganza
Come Join this gifted couple for their only USA Workshop!!!
Workshop Schedule
10:30 - 11:30 Turns with Sacadas
to Vals Rhythms
11:45 - 12:45 Change of
Direction Using Different Kinds of Walks
2:00 - 3:00 Combinations
of Sacadas for Men and Women
3:15 - 4:15 Milonga
Steps with Syncopation
4:15 - 5:45 - Guided Practica
Workshop Prices
Morning Session (2 Classes) $40.0
Afternoon Session (2 Classes) $40.
Full Day - $80.00 (Includes Practica)
Individual Class - $25.00
Practica - $15.00
Reserve Your Place Now!
Private lessons available
Jean Torsiello 201.585.8346
Gregory Lordi 908.221.1033
Carolina Zokalski 908.918.9790
Summit is a wonderful town filled with quaint eateries. Also the NYC Train is one
block away.
Metered Parking is available on the street and in
Be sure to come a little early
[going to buenos aires?]
[fridays@la belle epoque]
[join our mailing list]
2000, 2001 La Milonga. All Rights Reserved
by email@example.com


text:
For the last two years, I've looked at the banner on the side of a wall at a Reseda strip mall and wondered: What does it mean?
"Mexican Kosher Ice Cream."
It seems so cryptic. So exotic. So … unlikely.
So one day, on a whim, I pulled into the parking lot off of Lindley Avenue, determined to investigate. Inside a small, narrow establishment — wedged between a liquor store and a 7-Eleven — I met ice cream maker Rafael Algaze, a 63-year-old Jew from Chile.
He stood behind freezers full of exotic ice creams and sorbets. Their colors were electric — bright pink, orange and yellow — while their hard-to-pronounce names referred to fruits I knew nothing about. There was guanabana (a prickly green fruit from Central America), lucuma (a native of Peru with a bright yellow flesh) and mamey (a soft and creamy fruit cultivated in Mexico).
He insisted I try all of them.
Rafael Algaze makes an assortment of authentic, kosher ice cream.
"People are surprised," he said, describing the reaction many people have to his business, known both as La Reyna de Michoacan ("The Queen of Michoacan," a state in Mexico) and, as it says more simply on his business cards, Mexican Kosher Ice Cream.
Explaining the kosher part is easy. He uses only kosher ingredients, separates his dairy products from those that are parve and proudly displays his kosher certification.
Algaze, who attends Chabad and Beit Avraham Community Sephardic Synagogue in Woodland Hills, where he lives, said he decided to keep a kosher store at the behest of his Orthodox children's rabbi.
As for the Mexican part, that's no joke.
"I learned to make the ice cream in Mexico," Algaze said. "It's made with real fruit. Everything is for real. We don't use [artificial] flavors at all."
That's evident at first taste, whether it's the coffee ice cream, whose unadulterated flavor comes through rich and strong, or the queso ice cream, which is peppered with little chunks of real cheese.
Other flavors — all of which Algaze makes in a back room of the shop — vary from the traditional cookies-and-cream to a fluorescent banana-orange sorbet. There's even an authentic-tasting eggnog option.
"I love to do the ice cream," Algaze said. "It's nice. It's good. People love it."
Count among those people, apparently, Los Angeles Mayor Eric Garcetti and City Councilmember Bob Blumenfield, who stopped by for a sample recently during a joint tour of the San Fernando Valley.
Making Mexican kosher ice cream is a relatively new venture for Algaze, who moved to the United States in 1987, returned to Chile, and then came back for good in 2001.
"Everything happens by chance," he said. "I was in Mexico a few years ago, and I tried [the] ice cream and it was amazing. I loved it."
He started talking to a vendor about it and asked the man to teach him the craft. That allowed him to change direction from his career in the clothing industry. Algaze said he had a store in downtown L.A. until the economy tanked in 2008.
These days, he estimates that 20 percent of his customers are Jewish, some of them driving long distances to get the kosher treats, especially for, say, Shavuot. The rest of his clients tend to be Latino, he said.
But, of course, there's always a little left over for him and his wife.
"When you make it, you have to try it," he said. "You're always eating ice cream."
Mexican Kosher Ice Cream / La Reyna de Michoacan / 7147 Lindley Ave., Reseda / (213) 321-1547
Main photo: His sorbets are made from a variety of exotic fruits. Photos by Lynn Pelkey