I am learning Drupal. I saw youtube videos which teach Drupal. I frequently hear the word Term Reference while learning it.
I google out and searched reference link but could not get clear concept of it.
So can you please briefly explain
what is the Term Reference and why to use?
tl;dr Read blockquote for basic understanding, rest is examples to clear your thoughts.
In drupal, taxonomies(terms and vocabularies) are a type of
entity like nodes, users. And reference fields are used to refer
these entities in another entities.
So, a term reference field will be used to refer a term. So if I place
a term reference field in a content type, then I can successfully
access terms(related to term reference field) in nodes.
These terms are used to organize contents. Please refer this for more
info: https://www.drupal.org/documentation/modules/taxonomy.
A good example of organizing contents will be in E-Commerce sites. For example: All the products(nodes) can be organized into Shirts, Pants, Shoes etc. using term references(shirt, pant, shoes respectively). And then I can use this field to fetch only shirt products or shoes products.
In vanilla drupal, tags is a reference field used in Article content type. When you create many articles tagging them to some terms like first. Then you can fetch all the article with term first.
Related
I’m interested in defining relationships between custom taxonomies but I’ve been unable to find much in the way of documentation on this topic. Perhaps this can be done using the Pods framework (?), but I'm not sure. What I’d like to be achieved is the following:
There’s the ‘found_object’ custom post type.
There’s the ‘materials’ custom taxonomy for terms like plastic, wood, glass, etc. attached to the ‘found_object’ post type.
There’s also the ‘physical_properties’ custom taxonomy for, say, electrical conductivity and other properties that a given material is known to possess.
I would like to assign the above properties to my materials so that the physical_properties taxonomy terms for each of the found_objects get auto-populated once the materials of an object are selected. Or to reiterate: if an object has one or more materials assigned to it manually this will automatically assign all the properties of these materials to the object and different materials should obviously be allowed to share the same properties.
I need this to let the user arrive at these objects by filtering them by physical properties directly (not by materials per se) using the FacetWP plugin.
I vaguely understand that this can hopefully be done using the Pods plugin by setting up a relationship between my taxonomies by creating a relationship field. But other than that I don’t quite understand what to do.
I would greatly appreciate your help or suggestions.
Kind regards, Svetlana.
The problem can be solved by using the Pods framework in tandem with the FacetWP plugin (by taking advantage of one of its indexer hooks) as is demonstrated here (with the link to the relevant code snippet included).
I'm designing a Drupal 7 website where nodes/entites have complex relationships (1-many, many-to-many). For example:
Student (registered user) can belong to one ore more classes
Student can take one or more exams each semester
Teacher will take a note about each student in his class after each semester
My main concern is about:
Performance: queries should be fast and simple when rendering pages
Relationship: need to have two way relationship ( => can list related content based on content or vise versa)
Views Integration: should be fieldable and easy to list related content in Views
==> I come up with 2 solutions:
Method 1: the Drupal way
I know that there are some modules like EntityReference, Field Collection,... but don't know how to use, mix them the right way. Let's say how to create content type for a class, it's fields that link to user table and then easy to show the list of students on a given class?
===> The question is: What is the best practice for my case and what modules I should use and mixing together to solve this problem. What content type, it's field, and relationship I should create?
Method 2: could be not the Drupal way
Normally, I will design some tables in 3rd normal form (3NF) for those entities and their relationship: student, teacher, class, exam...I mean that this approach could be not the Drupal way as normal with field_xxx magical tables for each field of an custom content type, right? Hereunder are example of them:
Student table ( uid, name, full_name, other meta data columns) , of course the uid is foreign key point to Drupal user table
Class table (id, name, code_name,...)
Student_Class junction table (student_id, class_id, semester_id)
etc,.....
===> The question is: If I do it this way, is there any module which support to auto generated create CRUD forms, or API to create form to manipulate those tables, easy to allow field-able with Views module.
Please correct me for any misunderstanding and your ideas are welcome.
Thanks
The Drupal way with Entity Reference, Views, Field Collection (I would add Inline Entity Form, Views Bulk Operations, Views Megarow) is, in my opinion, the good one : you will be able to create back-office (and front end) screens very (I mean very) quickly using Views, related content (using Entity Reference) can be fetched both way, Inline Entity Form allows you to set up creation forms containing the related entity creation form (so create an entity and its related entity at the same time). Drupal Commerce is a good example of what you can do with these modules (see this entity relationship model). Rules can help to set up your business logic. So points 1 & 2 are (can be), in my humble opinion, satisfied with the Drupal way.
BUT...
This flexibility comes at the cost of complex requests, and eventually bad performance. You'll find all over the web posts about how Drupal is slow, and when you start playing around with a complex setup, it can be a serious problem. But with a good server configuration (cache, proxy...) and no PHP in Views :), it can be done (I run several Drupal Commerce sites, with a good server and a good sysadmin it's ok).
And you'll have to dive into Drupal logic, Views logic, Rules logic, which can be frustrating at some points : something you would code in a few PHP lines will take you a lot of clicks in Drupal interface. Of course, for tricky things, you can always build a small custom module doing just what you need.
About the second solution, I have no experience to share on Drupal and custom data model, but I guess you should consider applications frameworks (Symfony, Zend, CakePHP...) if you want to be free for the DB design.
Good luck
Just started using Drupal and tried to understand the core concepts. I have a developer background but I would like to use Drupal as a site builder and not digging into the code.
I'm trying to build a website which lists various vendors. One could be a Restaurant, another can be Photographer and other possible services (I have like 15 different ones).
They all have some things in common like Title, a Location (used Taxonomy/Vocabulary for that), description, image gallery, address, website, office hours and so on.
But they also have some custom fields. Restaurants can have fields like Facility options:Parking, Smoking area, etc or Capacity; Photographers can have others.
So there are lots of fields which are common for each vendor and some are are unique per each vendor.
What's the best way to implement this kind of structure as a Site builder?
I tried using Entities via ECK (Entity Construction Kit) and defining Entity types (as Vendor) and Bundles (as specific Vendors) but then I'm really limited in defining the common fields on Entity type level since Properties does not seem to be flexible in this regard, meaning that I cannot define them as normal fields and can't associate to them various widgets but only as a text input. Not sure if this a limitation of ECK or of Drupal 7 itself?
On the other hand I see the option of creating normal Content types for each kind of vendor which seems like alot of repetitive work, not sure if this is the right way (that's my only option at the moment)?
Maybe I should start learning more of Drupal and do some coding to create specific entity types? - but this means being more than a site builder. Since it will be a big project will this save me of some trouble later on or you see that I can accomplish the task easily without this extra effort?
Also by coding I'm not sure if there are easy ways of defining fields/widgets for Entity type Properties.
I would later on want to use faceting as well for filtering which will be based both on the fields which are common and unique for each vendor type, not sure if this is an important factor when creating the structure.
Any feedback is appreciated!
I would like to have a special "sub-node" that could be attached to other Drupal nodes, that allows authors to include commentary (from the author, so this isn't a comment node) and sample text, to the parent node.
I plan to use the exact same fields for the author commentary and sample text, and to create a view that lists both together. So, it would be OK to use the same node type for both the author commentary and sample text, or at least the same fields. This might also be useful for having an "address" node that could be attached to various nodes and then displayed together on a listing page.
I think the solution would include using node reference fields, but I get tripped up when it comes to theming the parent node form.
My question is similar to this one:
Create multiple CCK nodes with single custom form in Drupal
I think the best way to do this would be to create a view to display nodes that use the node reference field. It's tricky the first time you do it, but easy once you understand how views arguments work.
I found this helpful http://drupal.org/node/161867
I'm creating a web application and I just want to know how to think about Drupal's db coming from an MVC background.
I have tables to represent people's data such as SSN, First Name, Last Name, Zip Code, Address, Language, Location. Now on the front end I want to create a form to populate this information for a bunch of subjects (people). I have my database normalized so the Zip Code has its own table (with a foreign key link to the person table). The "person" table has stuff such as First Name, Last Name, Address etc... and the "language" table will have the different language abbreviations (again with a foreign key back to the person table).
I would like to know how to move something like this to drupal's schema. I know I could create my own tables and link them back to the "node" table and then I guess build my forms to accept user input...but is this the suggested way to do it? I was looking at webform, but it seems this should be used for simpler forms where the database isn't normalized and everything is just stored in one large table. I'm not sure, but I would definitely love to hear what you guys think...and if you could point me to some resources that'd be great.
Drupal is flexible enough that you can create whatever tables you want and then write code to link them back to the node table. However doing this will mean that you end up with a lot of code which is very specific to your schema, and is not very interoperable with other Drupal modules.
You will find that you get on better with Drupal if you mostly do things the Drupal way. And only go for a very customized solution where you are doing something which isn't covered by standard Drupal modules.
For example you may find that the profile module fits your needs as far as standard information about people goes. The location module (specifically user location) will cover users addresses. By using these modules you are more likely to find other modules which work with them in future and overall you will find you have less code to write.
One thing you may find useful is the migrate module for getting your existing data into Drupal.
It sounds like you're just storing information and the subjects (people) won't be users of the Drupal site.
Leveraging the node and CCK modules to make this happen would remove most of the development work. For example, each of your tables (e.g. Person, Zip Code, Language) could be represented by a content type with a number of fields. The foreign keys would be represented by node reference fields. So the Person content type may have one or more node references to nodes of type, Language.
The migrate module seems well used (626th most popular of 4000+ modules used in at least 10 distinct Drupal sites), but it may be easier to whip up your own migration script, but I'm not familiar with either your situation, your familiarity with Drupal's API, or the migrate module.
Node reference fields display as links to the referenced nodes by default, but can be themed to load and display the referenced node instead (e.g. displaying Language information in a Person node). There's a handy screencast that illustrates how to go about theming node reference fields to load and selectively display the referenced nodes' contents.
Coming from an MVC background you may not like how Drupal stores data in the DB.
Profile module was mentioned, but I find I get more flexibility with Content Profile and CCK combined.
I've written some migration scripts before from Coldfusion to Drupal, and it's not too involved.