July 2006 - Development - lists.drupal.org

making 'read more' themeable?
by Tim Jones 10 Jul '06

10 Jul '06

Has there ever been discussion of making the "Read More" link themeable? The node_link() function adds this link with preset text that can't be edited. This can be a problem; For instance, I often need to add an » or arrow graphic to the end of all my site's "Read More" links, or to have the link's "alt" tag read something other than "Read the rest of this posting." There's currently no way to do either of these without hacking core. (My non-core-hacking solution on a few sites has been to use CSS: ".read-more{display:none;}", ugh.) Would it be a worthwhile DEP to replace this line of node_link() with a call to theme("read-more") or something similar? =T=

1 1

_settings hook deprecated
by Dries Buytaert 10 Jul '06

10 Jul '06

Hello world, I just committed a patch that reorganizes the settings page, and that deprecates the _settings hook. Settings pages are no longer a special case. Modules that want to add a settings page should now use the regular menu callback system. Add a MENU_NORMAL_ITEM to your modules _menu() function and register your module's settings page(s) under ?q=admin/settings/<some-path>. In your callback, you need to define the form using the forms API. You don't have to implement a _validate or _submit hook. Just use the helper function system_settings_form(). It takes no more than five minutes to convert your existing settings page. I documented that change at http://drupal.org/node/64279#hook-settings. Kind regards, -- Dries Buytaert :: http://www.buytaert.net/

2 1

replacing hook_user('form') with hook_form_alter()
by Moshe Weitzman 10 Jul '06

10 Jul '06

hook_user('form') should probably be deprecated in favor of simple hook_form_alter() implementations. one wrinkle though is that hook_user('form') returns its fields in 'categories' which map to different tabs when editing a profile. do people think this multiple tab model is useful? if so, can modules achieve this in some way without help from user.module? Any ideas on how to improve this? -moshe

3 2

drupal.org timing out
by sime 10 Jul '06

10 Jul '06

drupal.org groups.drupal.org have been timing out for me over the last few days. (at least 20% of the time) as well as being much slower than in previous months. I think maybe it's not happening to anyone else, no talk on IRC, no talk on dev list... but I don't know why that would be, so I thought it best to say something. sime

7 8

user_mail() becomes drupal_mail() and gets hook_mail_alter()
by Dries Buytaert 10 Jul '06

10 Jul '06

Hello world, I just committed Goba's hook_mail_alter() patch: http://drupal.org/node/71194 If your module uses user_mail() it needs to be updated the use drupal_mail(). The upgrade instructions in the handbook still need to be updated. -- Dries Buytaert :: http://www.buytaert.net/

1 0

moderate flag
by Dries Buytaert 10 Jul '06

10 Jul '06

Hello world, I committed Chris' moderate-flag patch to CVS HEAD: http://drupal.org/node/72343 The module upgrade instructions in the Drupal handbook need to be updated. A number of modules need to be updated as well. -- Dries Buytaert :: http://www.buytaert.net/

1 0

Re: [development] hook_nodeapi vs. $form['#submit']
by Dave Cohen 10 Jul '06

10 Jul '06

Resending mail that didn't make it to the list... > I've come to realize for my node relationship code, I need to handle node > deletion and do some things when loading as well. So to answer my own > question, hook_nodeapi is required, and for more than just the inserting > and updating. > > So thanks but never mind! > > On Sunday 09 July 2006 18:57, Dave Cohen wrote: > > I'm building a site which has two custom node types with a one-to-many > > relationship. That is, one type is a container for items of the second > > type. > > [blah blah blah...]

1 0

hook_nodeapi vs. $form['#submit']
by Dave Cohen 10 Jul '06

10 Jul '06

I'm building a site which has two custom node types with a one-to-many relationship. That is, one type is a container for items of the second type. When creating/editing container nodes, I want the form to allow the user to choose from nodes of the contained type. Similarly when creating/editing the contained type the user may choose a container in which to place it. I know about the node relativity module, but without going off on a tangent I don't think its appropriate for this case. The way I see it, I have two ways to implement this. Because I'm defining the two node types, I can put all the code I need into hook_form, hook_insert and hook_update. That's the first option. Another option is to not modify the modules defining the node types, and instead introduce another module which is aware of the two types and defines the relationship between them. In this module I would use hook_form_alter to add what is needed in the edit forms and hook_nodeapi for the insert and update events. I'm partial to using this second option, because in the end I'll have a nifty code snippet that I could use anytime I want to make one node type a collection of other node types. So my question is, for the second option, do I really need hook_nodeapi? Wouldn't it be nice to use hook_form_alter to add fields to the forms, and define $form['#submit'] to call callbacks to handle inserts and updates? That way, my callbacks would only be called when necessary whereas hook_nodeapi gets called an aweful lot (every node load, for instance). And my answer is yes, I really do need to define hook_nodeapi. Because the $form['#submit'] callback does almost what I need, but not quite everything. In particular, when the submit callback is called during a node insert, there is no way to learn the new node's id. And for my code the node id is necessary. What do you think? Would it make more sense to use the combination of hook_form_alter and $form['#submit'] callback, rather than hook_form_alter and hook_nodeapi? Is there some way to get the inserted node id that I'm not aware of? Should there be a way? Thanks, -Dave

2 1

Moderation bit behavior
by Neil Drumm 09 Jul '06

09 Jul '06

Right now we have an inconsistency with our moderation bit. Is it supposed to control the visibility of posts, or is that solely dependent on status? 13 queries say it should have an effect and /up to/ 38 queries say no. The issue for this is over at http://drupal.org/node/71730. I think the underlying problem may be that published (status) is not mutually exclusive with moderation. -- Neil Drumm http://delocalizedham.com/

25 66

Extend database abstraction layer, to include table creation.
by Adrian Rossouw 09 Jul '06

09 Jul '06

http://drupal.org/node/63049 Now that we have .install files for modules, I believe it is time we extended our database abstraction layer. I recommend we create the following extra functions : 1. db_create_table($tablename, $columns); // columns is an associative array with the 'name' => 'type' 3. db_drop_table($tablename); 3. db_create_index($tablename, $columns); // columns is an array of column names, or just a single column. 4. db_drop_index($tablename, $columns); 5. db_add_column($tablename, $column, $type); // PGSQL already has a similar function, but it isn't in both systems. 6. db_drop_column($tablename, $column); The installer that is coming in, will be converting the database.*sql files into a system.install file, and with these functions, we can collapse ALL THREE SCHEMA FILES, into a single, much simpler file. This will also _drastically_ simplify updates, and it will give us consistent usage of types across the database. Certain things will still need to happen only on postgres (like create function calls for instance), but this DRASTICALLY decreases the amount of work we have to do to support multiple db types. At the moment, there are no create table statements that can be changed in core itself (until we have a system.install) , however, contrib modules can already be ported to use these functions, which would mean that we have (preliminary) postgres support across the board on all contrib modules. These functions should possibly keep track of what tables / columns / indexes have already been created, that would allow us to check (in a cross db way) what tables are available, and maintaining this information could possibly be useful in the future, such as not creating tables which have already been created. Additionally, each of these functions can be used to trigger a process for entering additional database credentials, in the case that the specific database user is not allowed to create tables and the like. This also helps make the patch for the installer a lot simpler, so if you want to help out with the installer, this would be a good thing to get involved with =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

31 110