What is the most efficient way to go through and update every single node in a drupal site, to, for instance mechanically add tags? Drupal 6 has a shiny new batch API, but what to do in Drupal 5?
I started writing a script that keeps a pointer and then goes around all nodes on a cron, loads them and then saves them, but I wonder what else could be done.
I don't suggest working directly on the database level since some modules might want to update some other related tables. The most reliable and flexible way is to write a script to load, change and save nodes in a loop. You can also try using additional special modules for Drupal 5:
Taxonomy Node Operations
Taxonomy Multi Editor (similar functionality)
and more general module Views Bulk Operations
Consider the Job queue module. Here is a quote about it (from the module's project page):
... used by modules to queue function calls for execution on cron. The job_queue_add() function is used by modules to add a job to the queue
This module is end of life for Drupal 7, there is a queue in core.
hmm i'm not familiar with drupal 5's database structure, but if it's similar enough to drupal 6, you could just modify this all pretty easily by just working off the term_node table. it's a mapper of node id's to term id's:
term_node
- nid
- vid
- tid
nid is the node id of course, vid is the revision id, if you use revisions, and tid is the term id. terms are all stored in term_data
term_data
- tid
- name
are the more interesting columns. so if you already have existing terms, you can create a quick map of existing tid's, then add to whatever nodes you want in term_node. anyhow, being careless in this regard could possibly cause weird data issues, so i wouldn't suggest this approach unless you feel pretty comfortable with the raw database.
Related
I am reviewing a old system that another developer did with Drupal but i do not understand very well this problem:
There is a node table.
There is another table which it's field_data_field_worker.
field_data_field_worker has a entity_id which makes the relation between node table and field_data_field_worker, that's ok.
There is a node table.
There is another table which it's field_data_field_vacations
field_data_field_vacations has a entity_id which makes the relation between node table and field_data_field_vacations, that's ok.
The problem is that... how i can know this:
When i go to the worker detail, it shows the vacations belong to that worker... but how does Drupal make the relation between the worker and the vacation? because i just see that the unique relation it's node with worker and node with vacation but how Drupal realates worker with vacation? it's not with the node table because... the nodes belong to worker are not same nodes belong to vacation.
Thanks!!
Drupal's database structure is fairly complex so you should make custom queries only if you really need to do that. In all other cases do it "drupalish" way.
Use node_load() function to get whole node object, node_save() (or alternative for D8) to save the node.
For querying multiple nodes use views module.
Point is - you don't have to understand Drupal's database structure - it's under the hood. Use the tools Drupal provides to work with database.
I have a special content type named "example". I want to show new nodes of this type to anonymous users of my site.
What I need: after 1 week the node was created, content access permissions (Content Access module is installed) are changed that only users with particular role are able to see this node.
Should this be triggered on cron or what? Or just how to do something to nodes that are older than 1 week?
Could you provide some instructions on how to do that? Because I'm new to the Rules module and have no any ideas.
You should be able to do this with Rules (see this question, not exactly what you want but close), but I'd go for a tiny custom module implementing hook_cron, where you fetch all nodes with creation date < (now - 1 week), and modify the permissions for each of them.
It should be more efficient than the Rule approach explained in my first link, where you need to loop over all nodes on each cron execution. And Rules can be quite more annoying than writing plain PHP. I prefer learning Drupal API than spending hours clicking in Rules interface (Rules is great, but it's hard).
Good luck
Yes you should be able to get this to work using the Rules module to implement what you're looking for, but I recommend you to also combine that with the Rules Once per Day and the Views Rules modules, as further explained below.
Step 1: Rules Event
Your question doesn't really specify anything that could/should be used as the Rules Event (for the rule to be triggered. And even though it's like "up to your own imagination" (any Rules Event will do), something that will work for sure is to use the Rules Once per Day module. Here is how it works (as per the comment in issue 2495775, from the module owner):
You specify a trigger hour on the administration settings page for this module.
The Rule trigger will then run when cron tasks are first run after the start of that hour. The actual run time will depend on your cron task timings.
So this is another way to understand/read this:
The "Event" will only be triggered when a cron job is run.
And that event will only be triggered 1 time / day, i.e. "next time cron runs after the trigger hour has passed".
Step 2: Rules Actions (and optional events)
Some details about the Views Rules module (from its project page):
Provides Views directly as Rules actions and loops to seamlessly use view result data.
The previous quote may seem a bit cryptic (it may make you think like "so what, how can this help me?"). Therefor some more details about how to move forward using these modules:
Create a view (using Views) so that you have 1 Views result (row) with all the nodes (of at least 1 week old) you want to be processed, whereas that view has fields (columns) for whatever is needed in subsequent steps, eg the node ID, but possibly other fields as well. You'll need these View fields later on as values to be processed by your rule, "to change the content access permissions (using the content_access module) so that only users with particular role are able to see such nodes" (similar to what you mentioned in your question). Important: use a Views display type of "Rules".
Create a custom rule in which you use the Views Rules module to iterate over each of these Views results in a Rules action, using the Rules technique known as a "Rules Loop".
For each iteration step in your Rules loop, perform a Rules Action to "do your thing" (= change the content access permissions). At that point you'll have all data from each column of your Views results available as so called Rules Parameters. So at that point it's a piece of cake to adapt the content access permissions for the node you're processing in that loop.
Optionally, you may also want to add whatever extra Rules Condition(s), also up to your own imagination.
Easy, no?
I'm trying to build a Drupal site in which users can input records containing data about "customers", "employees" and "sales".
I would like to be able to create a form(s) which takes data about a sale/customer/employee and can be associated with a record of a customer/employee(who made the sale)/sale.
I would also like to be able to display records showing a list of sales or customers or employees in which when clicking one record, it will open a page displaying all the relational data.
I'm new to development and am searching around like a headless chicken lol. I was thinking of using content types for sales/employees/customers and using individual nodes for each record then using something like views to displays filtered lists, but I am unsure if this is the best way to go about/structure it (maybe I should use separate custom tables or database and use a custom module to fetch the data?). It would also be nice if some of the fields can populate other fields based on it input and also if some fields can utilize a sort of auto-complete by garbing data from other records, or is that asking way too much?
Thank you for any suggestions you might be able to give me.
I, for one, would certainly prefer using a custom separate database and leave drupal databases to its own devices, if you would ever need to upgrade the site to a higher version of drupal it helps if you don't modify it, and also consider using webform (http://drupal.org/project/webform) as it makes development easier both in components and hooks.
I want to allow the user to create 10 content nodes on a single page instead of clicking on "add a new node each" time. This is just to save the users time when he/she wants to create 80 nodes at one time.
Is there any such module which supports this functionality or will I need to write a module for my own?
The first module I can think of (reading your description) is Nodes, which is described using the following text:
The Nodes module allows a user to edit multiple nodes at once. The module provides a simple table layout, similar to Editview, so that multiple nodes can be seen at once, and quickly and easily edited.
Changes to a node are done using AJAX like calls, so that as each field is edited, it is changed on the live version of the node. This means that any edits that take place are not submitted in bulk, and therefore any problems that arise as editing takes place can be dealt with on a field by field basis.
Unfortunately, the project doesn't have any public release.
Editview, referred in the description, is a Views plugin that allows to create a view where all the listed nodes are editable.
Other modules you can find on drupal.org are:
Mass Content Creator
Node Repeat, which allows to create duplicates/clones of nodes
Multiple Node Add
Slickgrid can be used for this purpose.
I effectively want two nodes:
Normal Node
Premium Node
The only difference will be that the premium node can take more images and a few other features. What is the best strategy to go about this?
have two distinct nodes with the differences
have one nodes and somehow find a to apply an UPGRADED attribute to it?
I would prefer (b), as I want users to be able to upgrade nodes. And migrating a normal node to a premium node will be very difficult.
Any idea how I can accomplish b?
I would create two different content types (CCK), and either write custom code to translate between the two or use a module like Node Convert (in order to upgrade a node); it might be complicated at first, but you would have the advantage of being able to apply all of your restrictions (allowed image count, permissions etc) on a per-content type basis.
Here is an excerpt from the Node Convert project page:
... adds a menu tab "Convert" on the node view page, i.e. node/1/convert, which gives the ability to convert the node from its current node type to another node type. The module provides the means to transfer all the field values of the current node type into fields on the destination node type, or discard them.
The module integrates with Actions, Rules, Views Bulk Operations and Admin Views nicely. It has support for exporting templates into Features using CTools Exportables. It also provides a hook that enables developers to execute additional code on conversion.
You might be able to implement (b) as two different input filters - one for non-upgraded and one for upgraded. Then "upgrading" the node would be as simple as changing the input filter applied to its contents.