Hi, following the examples in form.inc, I managed to programmatically create a new user (the import robot) and some new nodes. Now I would like to create a node type for that robot user to post its nodes. My question is how do I guess which arguments to call drupal_execute() with? for the form id, I look at the html source: <input type="hidden" name="form_id" id="edit-node-type-form" value="node_type_form" /> so I do: $values['name'] = 'node type test'; $values['type'] = 'node_type_test'; $values['description'] = 'my description.'; $values['comment'] = 0; drupal_execute('node_type_form', $values); but I get: warning: call_user_func_array(): First argumented is expected to be a valid callback, 'node_type_form' was given in /includes/form.inc on line 181. I don't understand: the function node_type_form($type = NULL) { exists in: modules/node/content_types.inc Is this a bug? What am I doing wrong? Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.
Hi, Also relevant to this thread about programmatically creating a node type, I see the following code: function node_type_form($type = NULL) { if (!isset($type->type)) { $type->has_title = TRUE; $type->has_body = TRUE; which implies that a node type may NOT have a body or a title. Yet, no such setting exists in ?q=admin/content/types/add (body and title are required). Is it possible to programmatically create a node type without a title? In that case, the title being used in node listing as a link to the node, how would we link without a title? Is the code above ($type->has_title = TRUE;) the blueprint for some future development in the next cycle? Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.
On 9/7/06, Augustin (Beginner) <drupal.beginner@wechange.org> wrote:
Is it possible to programmatically create a node type without a title? In that case, the title being used in node listing as a link to the node, how would we link without a title?
Is the code above ($type->has_title = TRUE;) the blueprint for some future development in the next cycle?
It is theoretically possible to create a module-defined node type without a title, yes. For user-defined node types, the code currently in HEAD does not allow for either the title or the body fields to be removed - but module authors are not so restricted. However, I doubt that a node type without a title field would work very well in practice, because of the 'title' field being used in so many places, such as in the node listing links (as you pointed out). To tell the truth, I wasn't that impressed with the whole 'has_title' thing - the CCK module in contrib only uses 'has_body', and I don't see why we also need 'has_title'. It was already in the pre-CCK patch <http://drupal.org/node/62340> when I started working on it, and I just left it in there (I had plenty of other things to fix up with that patch). Chx, perhaps you can answer? Cheers, Jaza.
On Thursday 07 September 2006 08:10 pm, Jeremy Epstein wrote:
Is it possible to programmatically create a node type without a title? In that case, the title being used in node listing as a link to the node, how would we link without a title?
Is the code above ($type->has_title = TRUE;) the blueprint for some future development in the next cycle?
It is theoretically possible to create a module-defined node type without a title, yes. For user-defined node types, the code currently in HEAD does not allow for either the title or the body fields to be removed - but module authors are not so restricted.
However, I doubt that a node type without a title field would work very well in practice, because of the 'title' field being used in so many places, such as in the node listing links (as you pointed out).
thanks Jeremy for confirming this. Blessings, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.
Op donderdag 7 september 2006 14:10, schreef Jeremy Epstein:
However, I doubt that a node type without a title field would work very well in practice, because of the 'title' field being used in so many places, such as in the node listing links (as you pointed out).
The problem lies deeper. We abuse titles for several things: 1 Unique, or semi-unique identifiers in the admin areas (node overviews, etc) 2 Unique, or semi-unique identifiers on the site (title listings in forum, blocks etc) 3 A subject: To show a boldfaced/strong "title" above an article. 4 A subject: To show a boldfaced/strong link above an article, leading to the full article (node). 2-4 could, but should not be required to, come from the same metadata. 1 has absolutely nothing to do with the metadata "title", allthough in a lot of cases/sites it may be a good idea to use the title for this. Again, this comes down to some fundamental "designs" of Drupal. I feel it is wrong to enforce a title, because we want a unique identifier! Obviously a list with "nothings" (a list of nodes w/o that identifier) is horrible. But unfortunately too many people then automatically conclude "then titles are required"! I have made nodes where I hid the title and autogenerated it from other metadata: "feedback on $foo by $bar", or "microcontent: site mission", or "%username's personal profile". etceteras. All are unique identifiers, but none are form fields. Most make no sense at all to store in the database either, because all of these can be build on _view or on _load perfectly fine. Concluding: Titles should be optional at all costs. Titles do not need to be stored in the database as single entity. Unique identifier (wich may be represented in $node->title, if that makes backwards compatibility simpler) is required. Bèr
One of my concerns for title is what gets put in the <title>my title</title> html on a page as that heavily influences how search engines index the page. People who care about their search engine ranking need control over what gets put there. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Bèr Kessels Sent: Thursday, September 07, 2006 11:14 AM To: development@drupal.org Subject: Re: [development] node type without a title? Op donderdag 7 september 2006 14:10, schreef Jeremy Epstein:
However, I doubt that a node type without a title field would work very well in practice, because of the 'title' field being used in so many places, such as in the node listing links (as you pointed out).
The problem lies deeper. We abuse titles for several things: 1 Unique, or semi-unique identifiers in the admin areas (node overviews, etc) 2 Unique, or semi-unique identifiers on the site (title listings in forum, blocks etc) 3 A subject: To show a boldfaced/strong "title" above an article. 4 A subject: To show a boldfaced/strong link above an article, leading to the full article (node). 2-4 could, but should not be required to, come from the same metadata. 1 has absolutely nothing to do with the metadata "title", allthough in a lot of cases/sites it may be a good idea to use the title for this. Again, this comes down to some fundamental "designs" of Drupal. I feel it is wrong to enforce a title, because we want a unique identifier! Obviously a list with "nothings" (a list of nodes w/o that identifier) is horrible. But unfortunately too many people then automatically conclude "then titles are required"! I have made nodes where I hid the title and autogenerated it from other metadata: "feedback on $foo by $bar", or "microcontent: site mission", or "%username's personal profile". etceteras. All are unique identifiers, but none are form fields. Most make no sense at all to store in the database either, because all of these can be build on _view or on _load perfectly fine. Concluding: Titles should be optional at all costs. Titles do not need to be stored in the database as single entity. Unique identifier (wich may be represented in $node->title, if that makes backwards compatibility simpler) is required. Bèr
Op donderdag 7 september 2006 17:51, schreef Walt Daniels:
One of my concerns for title is what gets put in the <title>my title</title> html on a page as that heavily influences how search engines index the page. People who care about their search engine ranking need control over what gets put there.
Wich is what I wrote at:
[mailto:development-bounces@drupal.org] On Behalf Of Bèr Kessels 3 A subject: To show a boldfaced/strong "title" above an article.
SEO is just one of the many reasons why one may not want to have the title hardwired into Drupal. Usability is another one, flexibility is the (IMO) most important one. As long a node === title+teaser+body (story) it is fine to have it harcoded. But the moment one uses nodes for other things, images, events, profiles, business-listings, PHP pages, organic-groups, dashboards, 404 placeholders, etceteras etceterars, titles need to be optional, flexible, and cut loose from the data-structure. Example: an organic group does not have a title, it has a "name". a directory-entry does not have a "title", it has a "company-name", and more of such things. the deeper you dig, the more examples you find where not only the name of the entity (title) is wrong, but where maybe the title has no input (form equivalent) and is generated from metadata (wordpress alike: use the entry date as title), or where the title is generated from a pattern (%type: entry #%number, by %uname). etc. Bèr
On 9/7/06, Bèr Kessels <ber@webschuur.com> wrote:
Example: an organic group does not have a title, it has a "name". a directory-entry does not have a "title", it has a "company-name", and more of such things. the deeper you dig, the more examples you find where not only the name of the entity (title) is wrong, but where maybe the title has no input (form equivalent) and is generated from metadata (wordpress alike: use the entry date as title), or where the title is generated from a pattern (%type: entry #%number, by %uname). etc.
The audio module is one example of this. The title most users would input for an audio node is based on the file's metadata. So, I hacked together a solution where the user can specify a title using placeholders like "%title by %artist" which is passed to t() for rendering. The source formatting string is saved for each node so that the title can be regenerated when the metadata is updated. The nice thing is that the title is "cached" in the node table and only needs to be generated when the node is created or updated. I'd love to see some core support for this type of thing to make it less hack-ish. andrew
I have made nodes where I hid the title and autogenerated it from other metadata: "feedback on $foo by $bar", or "microcontent: site mission", or "%username's personal profile". etceteras. All are unique identifiers, but none are form fields. Most make no sense at all to store in the database either, because all of these can be build on _view or on _load perfectly fine.
I've written a small module, which automatically generates a title: http://drupal.org/project/auto_nodetitle
Concluding: Titles should be optional at all costs. Titles do not need to be stored in the database as single entity. Unique identifier (wich may be represented in $node->title, if that makes backwards compatibility simpler) is required.
I agree that storing titles in the database isn't necessary. Just have the possibilty to define the title per content type (for showing links in the admin interface.). Perhaps a new node hook would do it, so that links to nodes could be generated without doing a full node_load(). -fago
On 9/8/06, Bèr Kessels <ber@webschuur.com> wrote:
The problem lies deeper. We abuse titles for several things: 1 Unique, or semi-unique identifiers in the admin areas (node overviews, etc)
1 has absolutely nothing to do with the metadata "title", allthough in a lot of cases/sites it may be a good idea to use the title for this.
Yep, we do basically use titles as 'unique identifiers' in many places, and with good reason too: 'title' is the only field, apart from 'nid', that can even be considered unique! Therefore, it is the only human-friendly identifier for nodes. I agree that titles, whether explicitly specifed or whether pattern-generated, should be required and should be unique. My importexportapi module, for example, treats the 'title' field as required and as unique, because it is the only field suitable for being an 'alternate key' for nid (i.e. a reliable but more human-friendly identifier, that can be used instead of nid).This is just one more case where having guaranteed unique titles is very useful. Cheers, Jaza.
Re: " I agree that titles, whether explicitly specifed or whether pattern-generated, should be required and should be unique" I have to disagree, I have used the same title for different node types. There is not real reason to enforce uniqueness (it assumes how I am going to use title). In the case where I use the same title, it ties information together for the user. Steve
On Thursday 07 September 2006 22:37, Steve Ringwood wrote:
Re: " I agree that titles, whether explicitly specifed or whether pattern-generated, should be required and should be unique"
I have to disagree, I have used the same title for different node types. There is not real reason to enforce uniqueness (it assumes how I am going to use title). In the case where I use the same title, it ties information together for the user.
Steve
Even if not strictly globally unique, a human-readable identifier for a node is a good thing. I think the simplest answer would be to have a hook_node_title() or similar that takes either a nid or node object, and returns the human-friendly string for the node. The simplest case would just return $node->title, and in fact that could be the default behavior of no *_node_title() is defined. If it's defined, that function can return a semi-unique string based on the node however it likes. Something to consider for 5.1, I suppose. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Op vrijdag 8 september 2006 06:39, schreef Larry Garfield:
Even if not strictly globally unique, a human-readable identifier for a node is a good thing.
Yes. but my whole point is, that this *should not be the same as "the thing you show above a post'*. A unique, human readable identifier may be anything, as long as it is somehow human readable. While "the thing that comes up above the post" may, or may not be unique at all. We can make sure that that "unique humanreadable identifier is always there" while a title, may, or may not be there. It could be as simple as: if (!isset($node->title)) { $node->title = auto_generate_title($node); } But i'd prefer a "real" solution- ie. change the architecture in such a way that we no longer have the title as some hardwired "thing", dangling off the sides of our nodes. I have seen Drupal sites (where nodes were imported from an external "logging app") where there were literally tenthousands of titles like * CHP event log #123123123: Show... * CHP event log #234234234: Show... * ABC event log #345345345: Expo... And so on. Unusable. esp, because the chopping of long titles (the ...) chopped off the only informative part. Above a node it looked good: CHP event log #123123123: Show items that were removed in previous version behind the blocks. Clearly indicating that a title != unique identifier, not always!. But since we have hardcoded such elements into the very heart of Drupal, the only things you can do, is hack up titles on _load, based on some parameters (arg()s). But that is certainly suboptimal.
But Just because all the default themes render the title over the node, doesn't mean you have to. This sounds like more of an argument just about nomenclature. On Fri, 2006-09-08 at 15:07 +0200, Bèr Kessels wrote:
Op vrijdag 8 september 2006 06:39, schreef Larry Garfield:
Even if not strictly globally unique, a human-readable identifier for a node is a good thing.
Yes. but my whole point is, that this *should not be the same as "the thing you show above a post'*.
A unique, human readable identifier may be anything, as long as it is somehow human readable. While "the thing that comes up above the post" may, or may not be unique at all. We can make sure that that "unique humanreadable identifier is always there" while a title, may, or may not be there. It could be as simple as: if (!isset($node->title)) { $node->title = auto_generate_title($node); } But i'd prefer a "real" solution- ie. change the architecture in such a way that we no longer have the title as some hardwired "thing", dangling off the sides of our nodes.
I have seen Drupal sites (where nodes were imported from an external "logging app") where there were literally tenthousands of titles like * CHP event log #123123123: Show... * CHP event log #234234234: Show... * ABC event log #345345345: Expo... And so on. Unusable. esp, because the chopping of long titles (the ...) chopped off the only informative part. Above a node it looked good: CHP event log #123123123: Show items that were removed in previous version behind the blocks.
Clearly indicating that a title != unique identifier, not always!. But since we have hardcoded such elements into the very heart of Drupal, the only things you can do, is hack up titles on _load, based on some parameters (arg()s). But that is certainly suboptimal.
A node's nid is its unique identifier. Period. End of story. Forcing titles to be unique is a mistake -- and forcing users to enter titles all the time is also a mistake. Arguably, in the admin section we should display nid in addition to title. Perhaps we should theme the node title to read <untitled> if there's no value there. But forcing them to be unique is definitely broken. In *some applications* some types of nodes should have unique titles, but that's about as far as I'd go. --Jeff
I think the simplest answer would be to have a hook_node_title() or similar that takes either a nid or node object, and returns the human-friendly string for the node. The simplest case would just return $node->title, and in fact that could be the default behavior of no *_node_title() is defined. If it's defined, that function can return a semi-unique string based on the node however it likes.
This sounds a lot like an object-oriented design pattern where the node object's data is private and has to be requested through accessor methods. This is the second time in two days where I've realized that Drupal is moving towards implementing its own object system, if only a rudimentary kind. At the risk of hijacking this thread and starting a total flame war: is it time for Drupal to embrace the OOP paradigm? (Don't bother sending me the link to the page on api.drupal.org - I've read it) People want CRUD functions for everything. People want accessor methods that inherit from a base class. Some people (e.g. me) want an O/R mapper to make life easier. Can we graft an object system on to the structured array paradigm we already have? Is it worth it? Traditionally drupal has avoided a full object system for performance reasons. When will those benefits be outweighed by the cost of implementing our own rudimentary object system? Thoughts? -Mark "Plays with matches on the devel list" Fredrickson
participants (12)
-
andrew morton -
Augustin (Beginner) -
Bèr Kessels -
Darrel O'Pry -
fago -
Jeff Eaton -
Jeremy Epstein -
Larry Garfield -
Mark Fredrickson -
Sam Tresler -
Steve Ringwood -
Walt Daniels