On a website with software documentation, I need to create a new version for a node always that the information changes for a new software release.
Here is an example:
For the product x version 1.0, I have a node (ID: 1000) that explains how to install the product.
When this product has a new release, the instructions need to change. Currently, what I do is to create a different node (ID: 1001) for product x version 2.0, also called how to install. The issue is that, since these two nodes are totally disconnected, as my database grows, managing these versions is getting too painful.
Ideally, I wouldn't have totally disconnected nodes for the same kind of information, but version that node as the product version changes. Is there any module that allows me to do it? If not, any idea on how to solve the issue?
Thank you
It sounds like you want to use node revisioning
https://www.drupal.org/node/320614
My approach would be to use a makeshift solution via entity reference and/or Rules. On a similar project, we used the Rules Link module to remove the author/ownership of the post but keep a reference for later processing by cloning the user entity in said rule to another field.
You could do the same: Automatically generate a new node with a reference to the old one and maybe copies of certain fields.
Depending on how much content you want to reuse, there's the Node Clone module and the Node clone on Save project seems like a fitting case, too (didn't test it).
Before the entity reference module got to be so mighty in Drupal 7 I often heard that sharing a common taxonomy term between 2 nodes would be another easy way to keep nodes „bundled“ – I'm not sure about the UX implications though.
Sorry, seeing that you're talking about documentation, another solution would be to simply activate the Books module and define a book for each product with the different versions as pages (see Drupal documentation as reference – you can easily style the structure, e.g. as tabs).
The module uses the menu system (up to Drupal 7) to keep a simple structure on top of the existing nodes. This approach has its UX limits on very large node counts.
Using the Book Made Simple module you can automatically generate a book on node creation.
Related
When trying to update a Custom Content Model in Alfresco I decided to upload and activate a new copy and delete the old one. I found out this doesn't work.
So my question is what will happen now and how can I fix this?
What will happen where the two content models are the same?
What will happen where the two content models define the same aspect, but differently?
Does one take precedent over the other?
Would editing the 2 in the properties to be identical get around the problem?
Starting from scratch with this repository is an undesirable option at this time. I'm looking for the simplest solution possible.
It's not simple as that. If you already have some documents or folder associated with a model, you can't delete it without breaking your datas.
Also, Alfresco doesn't support multiple declarations of a model or type or aspect. If it's the case it doesn't start.
The only way you have to upload a new version of your model is by uploading a version containing ONLY added properties, types or aspects. If your new model's version contains modificated or deleted properties, types or aspects, you will have to migrate each node programaticaly.
I am working with the commerce module to create an online store. I am modifying the products .install file to create a content type (as I have been told this is required) and as part of that content type, I need to create lots of fields. The list will be around 50-60 different pieces of information.
Ideally I would like to store these in a single table with the productID at the beginning and all the other information along, but this doesn't seem to be the case; all the fields are stored in different tables.
I noticed that the "Address" module that is also used with commerce creates a field-type that has about 15 different values all stored in the same box. How is this possible? I noticed that if I set the cardinality up to 5 for example, it creates different rows. I just want a table with the following:
ID - value1 - value2 - value3 etc etc.
I also don't need any modules/extensions as this all needs to be written in the files. I also don't think that changing to the mongoDB ( I think ) is an option, so what are my options in this situation?
That's not how the Drupal field system works I'm afraid, one field == one table (well actually 2 tables if you include the revision table for each field).
The Address module uses hook_field_schema() to define several columns for that particular field (have a look in address.install and you'll see what I mean).
So if you want to put everything in one table you'll simply have to define your own field type (see the examples module, specifically field_example for help with that).
Bear in mind though that the number of columns you define in hook_field_schema() will be static once the module is installed, and the only way you're going to be able to increase/decrease it is with an _update hook for your custom module.
Also, if you're hacking at files that are included in the Commerce module...stop!: Commerce is still very much in it's infancy and you will likely have to update it soon...once you've done that your code changes will be gone and there's a good chance your site will be in an inconsistent state.
The whole point to Drupal is that everything is hooked/farmed out so that it can be altered by other parts of the system. There's nothing you can change in product.install that can't be done by implementing a Drupal hook in another module.
If you're unsure, post another question detailing what you're trying to accomplish by directly editing a contrib module file and one of the Drupal gurus on SO will point you in the right direction :-)
EDIT
Just to say I've been working with Ubercart in Drupal 7 for quite some time now and find it a very, very good solution (a lot of Commerce contributed modules are still in dev/alpha/beta; this is less so for Ubercart contributed modules). It might be worth a look.
Some more info
I think you've basically got two options here but either way you'll need to create a custom module (excellent set of instructions here).
Option 1: Create a custom field
If you're a Drupal coding beginner I'd suggest this is probably the easiest way to accomplish what you want, but it's still not totally straight forward. Grab the field_example module from the Drupal Examples module link above and have a look in the .install file, specifically the field_example_field_schema() function. That defines the columns that will be in the table for that field. Then have a look in field_example.module...pretty much every function that's commented with Implements hook_x is one that you're going to want to copy into your module and tweak for your own needs.
I think this will be easier because Drupal will handle the table/form field creation for you
so you don't have to mess with the database, schema or form APIs.
Option 2: Create a custom module
This option involves implementing your own table (like you suggest in your comment) where the primary key would be the entity ID of the product and would also contain all of your custom columns. (See the Schema API documentation for help with this).
Then you'd implement hook_form_alter() to add the form fields necessary for a user to input the data, and then implement hook_node_insert() and hook_node_update() to persist this data to your database table. It's quite hard to go into any more detail without actually writing code and it's quite a bit of code!
Hope that helps, sorry I can't be any more specific but it's not easy without knowing all the ins and outs of the situation
I have several custom datatypes in drupal 7
restaurant
menu
recipe
chef
i want to create associations between this data chef -> restaurant -> menu -> recipe
so that recipe can get the chefs name and the restaurants address
and menu can get a list of recipes, etc
In SQL land, i'd call this a foreign key, but i'm having a lot of problems finding how to do this in drupal 7.
I suspect that there must be some module or functionality i'm not familiar with. But drupal uses it's own lingo and I think i'm falling down on my google-fu
anyone know what i'm looking for ?
These are probably not datatypes but most likely content types. What you are looking for are
A way to relate nodes (ie. content) of one content type to nodes of another (chef to restaurant, menu to restaurant, recipe to menu, etc.).
A way to display information from related nodes (direct or indirect relations) when displaying a particular node.
The relation between nodes can be achieved using the References module (a Drupal 7 port of the nodereference module included in CCK for Drupal 6). This allow you to add references to nodes when editing another. The relation can be configured to allow only nodes of the specified type to be referenced. These kind of reference aren't bi-directional and can only (easily) navigated from the referrer node, not from the referenced node. In Drupal 6, the Node referrer provided a complementary field to navigate the relation both way. Unfortunately, it has not (yet) been ported to Drupal 7.
References may be deprecated in a near future in favor of the Entity reference module. Entity reference clains to provide bi-directional queries via views and proper integration with the Entity API module. The later should ensure that relation defined with the module are fully (problematically) navigable and usable with modules using the Entity metadata (Seach API and others).
Another solution which is also using the Entity system, is the Relation module. It provide complete bi-directional relations. These relations are themselves fieldable entitiesm which means that you add properties to the relations (for instance the dates at which a chef started and ended working at a restaurant).
Once you get the relation, there is various ways to display the related information on a node page. I don't known for Relation, but if References behave like the Drupal 6 version, it will only allow basics display of information from the directly related nodes. One solution is to implement hook_node_view() in a custom module to navigate the relation, retrieve the different nodes, format the gathered information using a custom theme hook and add it to the $node->content for rendering.
Since Entity reference integrates with view, you should be able to build a view to display the node related to the currently displayed node (using the current node as contextual argument). You can then embed the view programmatically in your node view (again, via hook_node_view()) or use a block display.
In Drupal 6, you would use a sub-module of the CCK project called Node Reference. A node reference is a field in one content type that points to another node. In Drupal 7, since the majority of CCK's functionality has been moved to core, the Node Reference submodule is now part of the References project.
We have a content-type built using CCK. One of the fields is a node reference. The node picker is using a view to build the options.
A few days ago, everything was working well.
Today, it looks like all node reference fields using views to populate the selection options are displaying the wrong label. Every single label in the option is ``A'', but the actual node number is correct. The form actually works, just the labels are incorrect.
We have tried just about every combination of edit/save, disable/enable, reboot, clear cache, clone the view, rebuild the view, new view, etc, but we still have a big list of As.
If we create a brand new content type with a brand new node reference field, we get the problem.
Through some backup/restore exercises, we have determined that the problem is actually in the database and not in the code.
We can restore our last good backup, but we will lose a decent amount of work we have put into other parts of the database.
We enabled mysql query logging, and the view is actually being called properly, but we cannot track down where the problem is creeping in after that (unraveling the CCK / Views / Drupal plumbing is a challenge).
The install was build with latest stable versions as of April.
The problems referred to in http://drupal.org/node/624422 is similar, but our code versions include the patches mentioned.
Any ideas would be appreciated. Thanks.
I had a similar problem with using views for node reference, after quite a lot of hair pulling it turned out to be that my caching layer was buggy. I was using memcached, but memcached wasn't truned on on the server. It may be worth checking.
Thanks for the responses. We finally got to the bottom of this.
There was a module that was doing a custom hook_views_post_render() that did a prep_replace to rewrite some output. Unknown to us, there are instances where the $output parameter isn't a string, but an array, and this was causing the problem. One of those instances happens to be when you attach a view to a build a select in CCK.
I have a need to build views in drupal of non-nodes, actually objects external to drupal. The api that I am calling against passes me back a stdClass object.
Anyone have ideas on how to get Views2 to display non-node objects?
My understanding of Views 2 is that it is meant to work with information stored in a database.
If you don't have access to the database against which the API was written, then consider writing the objects the API returns into a table. The easiest thing would probably be to create nodes from the objects. Then you could access them with Views 2.
This is similar to the approach taken by the Acitivty Stream module (http://drupal.org/project/activitystream). It creates nodes from the data returned by various APIs. Check out the module's code for examples of how to create the nodes:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/activitystream/activitystream.module?view=markup
On the other hand, if you have access to the source database, you might consider exposing the tables of that database to Views directly. This is the approach taken in the latest Views 2 integration code included with CiviCRM v2.2.3, which you can review here:
http://svn.civicrm.org/civicrm/trunk/drupal/modules/views/
CiviCRM is a Drupal module that writes data to tables outside of the Drupal database -- not into nodes. The views integration code exposes most of those tables to Drupal.
Hope this helps.
-- Andrew B.
According to the Views 3 roadmap, Views will eventually work with non-SQL data sources. In the meantime, some very preliminary work has been done in this area, using the Flikr API as a proof-of-concept.
Fixed in latest 6.x-1.x-dev branch. VBO now supports users and comments in addition to nodes. A special hook_object_info can be used to support any other type of object. Please try it and let me know!
you have to expose custom data to views like described here:
http://www.darrenmothersele.com/drupal-blog/drupal-views2-handlers
http://views-help.doc.logrus.com/help/views/api-tables
Views is built for working with nodes + CCK exclusively. If you want to create views for custom pages, you'll need to code some additional module + theme pages.