I am trying to write a relationship handler for Views 3 in Drupal 7, but am failing even to begin.
Basically, I have a bunch of nodes of various types all with the same field attached to them. This field is a reference field linking off to a Civicrm contact - but that's not important, as essentially these fields just contain integers.
Now, let's say I have a node of content type 'story', and its reference field contains the integer, oh, let's say 55. In addition, there are nodes of content type 'news' which also contain the reference ID 55.
I want to build a block view, that sits on the story page, that reads in the node's nid as its argument, and then through a relationship it discovers all other nodes that contain the same reference integer as itself.
(In my head, the sql looks something like: SELECT n.nid FROM node n INNER JOIN node n2 ON n.reference = n2.reference [Assuming, for the sake of simplicity, the field data is kept in the node table]).
How do I create a Views handler that caters for this relationship? The only documentation I can find is the views api, which is for version 2 and not 3, and besides is utterly unhelpful. Reading various module's views handlers is not helping either, and views tutorials on the web are almost non-existent.
What are you doing and what is the problem? It sounds like you have everything you need right here...the nid as an argument and the reference field as a relationship. What are your filters set to? and what display type are you using? You could just have the block display some information without sorting, arguments, or relationships and then using the devel module you can change the tpl file for the block to dpm($views) and see what information you have access to.
Let us know what you have configured so far and what your results are if any. Remember that you can use the nid as an argument in the preview, so if the nid is 213 you can type 213 in the preview field (make sure the display is set to the block you are talking about) and see what comes up.
Good luck.
Related
I have a content app with a dominating unique field that I would like to use as the node name for new nodes. The problem is that it contains characters that cannot be part of a JCR node name, and thus if I were to link it to jcrName rather than a custom property it will get mutated into something that isn't useful for the fields original purpose (among others, the field value will contain slashes).
My current solution adds an additional field for the node name, and while this certainly works, it adds a UI field to the detail for no reason that is apparent to the users of the app.
Is there a way to have a field that reads and writes a string value to a custom property, yet that is also used (in its clened form) to name the node?
You could use this as a base, paying special attention to the code in 2.b.ii. (especially setNodeName), and ignoring the yaml bits.
I hope this helps!
i have the following case: I am building a website that has information on filmmakers and their films. I have a node type for the filmmaker, with biographical content, etc and another one for the films, with a field 'author' that references one or more of the filmmakers (since one film may have been made by several of them).
I also have a views block called 'filmography' that lists all the films whose author is the filmmaker (node) the user is seeing. Setting this up with a contextual filter was quite easy.
But now I want to present in this block along with the film name, all the filmmakers that may have made the film ('author' field in the film node) and that are different from the filmmaker being viewed. Displaying all the filmmaker nodes referenced by the author field is immediate, but I want to remove the filmmaker that I am using in the contextual filter. The goal is to get something like this:
Filmmaker 1
Movie 1
Movie 2 (with Filmmaker 2)
Movie 3
I have the notion that this might be done using views php and filtering the node references returned, but I wonder if there is an easier solution for that...
Thanks
Update: I have managed to get a result using the Views Field View module, passing the list of referenced nodes (filmmakers) as a contextual filter (node ID) and then adding another contextual filter (node ID as well) as an exclusion, and getting the default value of the letter from 'node id from URL option' (that is, from filmmaker's page the filmography view is embedded in). Keeping the question open for a while to get other, possibly more efficient, alternatives.
As I read your question, the Views Field View module popped into my mind as the obvious solution (then I saw your edit). I think this will still be your best bet. Definitely avoid using php fields as that is not a good practice in general from a security standpoint. If you are concerned about efficiency/performance, then you should just use views caching setting under the advanced options. Seems like this option is always looked over.
If you are looking for alternative options, one might be to use rendered nodes as your View style instead of fields, then use Display Suite to generate additional display modes beyond "Default" and "Teaser," create a view with the filters, then use the Entity Views Attachment (EVA) module to insert a view as a display mode field. While this is certainly a robust approach, it adds a lot of processing overhead with the rendered entities, so you definitely want to cache the results of that as well.
p.s. You might get faster/more responses over at https://drupal.stackexchange.com/
I am currently trying to create a custom post type for recipes. My goal is to include the schema.org/Recipe and or hrecipe microformat and also have the ability to filter for ingredients in the future.
To do this I intend to have an interface with fields for title, photo, description, ingredients and instructions.
My question is: Should I create separate fields for each ingredient and each amount? Or would you say it is sufficient to just create one field for all ingredients? (also keeping the aforementioned microformats in mind).
http://schema.org/Recipe
http://microformats.org/wiki/hrecipe
Having ingredients as a single field is what is expected in both formats you linked to. Querying / filtering based on ingredient name will be slightly more complex...but you should be able to handle it.
There are 3 parts to this answer.
How should you save ingredients in WordPress
How should you allow users to modify the ingredients list
How should you display ingredients publicly
For point 1, you will have to give a bit of thought as to how you save the ingredient list and how you retrieve/display it along with how it is queried. One of the formats indicate you could have properties for each ingredient (still in draft).
You could save an ingredient list as a serialized PHP array, something like this:
$ingredients[]=array('milk','value'=>'125','type'=>'ml');
$ingredients[]=array('sugar','value'=>'1','type'=>'cup');
Since serialized PHP arrays are standardized, you could fairly easily write an WP query that takes it into account.
Keep in mind you will want to have a plan for when the 'value' and 'type' modifiers are set in stone and how to migrate what you saved if they are different.
For point 2, you could create a custom meta box that deserializes the PHP array saved and render individual controls for each ingredient along with controls to allow management (Add, Deletes, Updates).
For point 3....the easiest would be to get the value and manipulate it how you want in the output.
I need to create a fairly complex rule in Drupal - I am willing to use either code or the interface to do so.
I am more familiar with the interface, however, as opposed to the Rules API.
Anyway, the rule will be as follows:
It will happen based on a form submission from entityforms (which is one entity). It will take the checkbox value of a field (not just the true or false, but rather the value submitted when a value is true or false). It will convert this number to an integer.
At this point things get interesting - I want to create a new entity of registrations (a different entity), which as far as I can tell, means I'll have to bring a registration into scope. I also need to bring node (and not just node: type and other data selectors, but specifically node) into scope, because the next step requires it.
So at this point, I should have three entities loaded into scope:
entityforms
registration
node
I believe the best way to bring registration into scope would be entity is of type? The documentation page says that content of type should be appropriate - but that seems like it might be related to the specific use case of the example - not in my more complex example where registration isn't the first entity dealt with, but rather a second.
https://drupal.org/node/1463042
So anyway, if all three of these entities is called in correctly, the ultimate result should be the following:
Value from boolean field (not the straight 1 or 0, but whatever the value to be submitted is switched to) from the entityform is converted to an integer, and inserted where entity host ID is required. In the section where host entity type is the value should be node.
I am also open to alternative suggestions if this seems overly complex or poorly architected.
The Host Entity Type cannot be of Entityform? Why be a Node since a Registration can be attached to any entity? Then you will get the id of the Entityform as also as any other fields from that entity type instead of Node. Next steps are the same.
I can save/update on regular fields but I'm having trouble saving/updating CCK fields. here's an example node.save() XML request - http://pastebin.com/m5ceca16
I'm assuming your XML data mirrors the node object format.
A CCK field 'field_custom' will be accessible via $node->field_custom. Regardless of type and the limit on number of entries, fields are always arrays. If the CCK field only allows one entry, it is $node->field_custom[0].
The indexes below that level depend on the field type. Most, especially numeric and text fields, are 'value' (eg., $node->field_custom[0] = 'foo'). I've used Nodereference fields which use 'nid', from which I would assume Userreference fields use 'uid'.
The structure of your XML seems correct. I would check the structure of a node object on the site (using a var_dump() or the devel module) to make sure all of your array keys and variable names are correct for your field and field type.
2 things to check:
A var_dump of the results of a node_load() doesn't give you the exact format you should use. Your XML must emulate the input format of the node edit form. So while a var_dump might show you several taxonomy terms in an array, the node edit form may expect the taxonomy terms separated by commas. Off-hand I don't see any fields in your example that this would seem to apply to but I mention it anyway.
Your "changed" timestamp must not be in the future, nor must it be too far in the past. The node will not save if this is off by much. This can be an issue if the clocks on one of the computers isn't very accurate. I had an issue where my services server was about 20 seconds behind my services client so all the updates were getting rejected (the server apparently rejected them on the grounds that they were from the future).