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.
Related
I'm new to Drupal, and wish to understand how this platform works.
Specifically, I'm mystified by the Node object.
What is it, how does Content-Type get in?!
It seems like the whole of Drupal is just nodes, nodes, nodes.
Would love to hear you insights.
The node, in Drupal, is an odd animal when you first encounter Drupal, but once you get it you'll find that it's quite useful.
A Drupal Node is a unit of information. Usually, it's a unit of interrelated information that for the site is not usefully divisible. For example, if you had a node that represented people and their addresses, you could split it into address nodes and people nodes and associate them, but unless you've got functionality that displays how many people are at a given address, it's not useful to split it into two nodes, and better to keep them together as one unit. Consider: If you were sorting the data out onto index cards, or pages of paper, would you list the information together, or would it be more useful to keep it apart? If together, then they probably belong together on a node.
Since most of the data on a Drupal site are nodes, it's useful to classify the nodes so you can find the ones you're interested in. One of the most basic of these classifications is the Content Type, which is basically what kind of information the node represents, and is not changeable once created. Each Content type has it's own separate form for creating and editing the node type, and represents a different type of information. Page nodes are nodes that represent static pages on your site - like an About page. A Story node represents an article or story which should show up in lists of content. A Blog node would represent a blog entry... in Drupal 6 you can create as many Content Types as you like.
Once you go beyond Content Types, there's quite a lot of different ways to classify your nodes. CCK (The Content Construction Kit) is a wildly useful one, and it's so useful that in Drupal 7 most of the functionality in CCK has been included in the core of Drupal. CCK allows you add many types of fields to a node out of the box, and then there are other modules (Filefield, Imagefield, Link, Location) that create new field types to add.
In core, another way of sorting out your nodes is the Taxonomy module, which allows you to define vocabularies of tags or terms that can be assigned to nodes. These terms can be defined by the site admins ahead of time, or they can create a 'Tag' vocabulary which allows users to create terms as they create or edit their nodes.
A node is a content container. Nearly all content in Drupal resides in nodes. Non-content data (e.g. users) does not typically reside in nodes. As most data on a website is content, nodes are a central concept in Drupal. There are several ways to assign content types to nodes, but the most common is the CCK module.
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 need to adjust the way which a content is determined as published or not published. The editor of particular content (this is a separate non-administrative role) should have a possibility to set the published flag for particular node (it can be achieved using Override Node Options module directly or by implementing it's techniques). He should also be able to set two additional publication attributes, i.e. publication start date and publication end date (the fields can be added using Content Construction Kit). These optional fields should be used to determine node's published status. Let's say that if specified, they will override published flag.
Basically I would like to be able to add my bits of SQL code to the WHERE section of proper query or to postprocess result of such query. Maybe to overwrite some function or provide some callback. Solutions based on writing of custom modules are fully acceptable.
I am using Drupal 6.
It sounds like one of either the Node Expire or Scheduler modules should do what you need.
Having trouble in views creating what seems like a very simple query. Display the number (count) of nodes of a given type. I'm not finding the option in any obvious place...
How to?
You want the Views Group By module. Some more details about this module (from its project page):
This module enriches Views2 functionality with SQL Grouping and Aggregation capabilities.
Ever wanted to design a view that displays top terms for a specific node type and number of nodes for each top term? You could not build such query before, but now you can.
A new field group: SQL Aggregation is added, in Views, once you install the module. The field group has one available field: SQL Aggregation: Group By Fields. The field allows to configure many aspects of "group by" SQL clause and "count()" fields.
Currently only SQL COUNT() function is available due to a limitation in Views2 API. We are working on a Views2 patch to overcome the limitation. Patch will be submitted to Views2 project and, hopefully, applied shortly thereafter.
Maybe instead of views it is better to use light custom SQL-query, something like this http://drupal.org/node/105375#comment-1095529
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.