June 2006 - Development - lists.drupal.org

Overiding #theme in hook_form_alter()
by Barry Jaspan 16 Jun '06

16 Jun '06

I've written the module that wants to override the #theme of another module's form. I discovered that in hook_form_alter I cannot set the #theme field because drupal_get_form overrides #theme after calling hook_form_alter it if the function theme_<formname> exists or the $callback argument is provided. This seems like an unintentional restriction to me. Is it? Hook_form_alter can change everything else about a form, so why should it not be able to change the #theme field? I know the theme function can be overridden by the site theme but that forces the module not to be self-contained. The workaround I found is to add a callback to the form's #pre_render array that sets the form's #theme field. This works fine (because #pre_render is invoked after drupal_get_form overrides #theme) but is certainly not intuitive; if this really is the best way to do it, I'll author a new page for the Forms API Tips and Tricks book section. Thanks, Barry Note: This message was dictated using voice recognition software. Please excuse any errors I missed.

2 2

losing value somewhere after validate.
by sime 16 Jun '06

16 Jun '06

Hello. I keep losing values that I modify in the 'validate' op of hook_nodeapi(). This occurs by the time I get to the insert or update ops. It has to be something simple I am overlooking. I normally wouldn't hassle the list over such things, but I am starting to write bad code to compensate, so I need to work out what I'm doing wrong. It is a little hard for me to track the $node through core, so are there any suggestions about what I might be doing wrong, or where a problem like this can arise? Kind thanks for any advice. Simon PS. I have checked the nodeapi docs: "validate": The user has just finished editing the node and is trying to preview or submit it. This hook can be used to check or *even modify the node*. Also, I have double-checked that i am using a version of form.inc that is after this issue was fixed: http://drupal.org/node/63704

3 3

Module to view/edit module weights
by Barry Jaspan 16 Jun '06

16 Jun '06

[ I posted this to the consulting list but since discussion has already arrived here I figured I should re-post the original message. FYI, this is what caused me to discover the problem with #theme and hook_form_alter. ] A client needed to be able to change the weight of a module I developed for him. Rather than hard code the setting in the module's .install file, I developed a small module called moduleweight that adds a Weight column to the modules table at admin/modules. I was not aware of any existing way to do this. Module moduleweight is available in CVS. If other people find it useful, I will promote it to a 4.7 project. Thanks, Barry Note: This message was dictated using voice recognition software. Please excuse any errors I missed.

1 0

Re: [consulting] Module to view/edit module weights
by Khalid B 16 Jun '06

16 Jun '06

(Cross posting to development) There was criticism about weights in the past (I think it was Ber?) However, I think the lack of an interface to manipulate the underlying data structure was the main objection to this. Remember that a mechanism similar to weights is used in UNIX/Linux init scripts (each daemon is given a 3 digit number and they are started in order). Now that we have an interface that can manipulate the weights, perhaps the main criticism is moot. This is similar to update-rc.d in Debian/Ubuntu. But perhaps we will move to a before/after scheme as hinted to (Adrian? Vlado?)

2 1

Re: [development] Test automation
by Khalid B 16 Jun '06

16 Jun '06

Just an aside here whichever way it gets done ... The potential for abuse here is very high. Someone may craft a patch that executes arbitrary PHP code that can be effectively anything. Having a virtual server to do this will help with some scenarios, but others (e.g. sending spam, crawling, phishing) can still be useful to the cracker ...

2 1

User registration without *password*
by Chad Phillips -- Apartment Lines 16 Jun '06

16 Jun '06

> I'm currently thinking I can accomplish most, if not all, of this by > hacking/patching the LoginToboggan module. I would need to modify it > to use an empty string for the password, customize the login form, and > suppress the confirmation email. I would use the it's Immediate Login > feature to create the users and put them into a "non-authenticated > role" I'd create called "registrant". My intention would be to leave > them there permanently. I'd also need to implement the ability to > forward the new user to the requested page. i've been getting a lot of special requests for functionality additions to the logintoboggan module. i'm actually not all that thrilled about throwing 50 new features in there--i think it makes the code harder to maintain. > > I'm looking for an any thoughts on this approach, and any pointers if > it has been done already. If there are any gotchas I'll likely run > into, or if--for some reason that isn't yet apparent to me--this is > just a Bad Idea, I'd like to know that as well. > > Also, if there is any broader interest in this type of functionality > let me know. I'm happy to work as closely with the LoginToboggan > maintainers as they would like, and would appreciate any help or > guidance they can offer. i think the best options in cases like this are: 1. a seperate module that provides the functionality you need 2. installing an adequate hook system in logintoboggan so that it may be used as a base to write contrib modules for it, which would add features such as this. this provides a modularity which ensures that we won't be breaking the module all the time w/ new features, and people will only have to enable the contrib mods that they want. i'd be willing to take a look at approach #2 if you'd like to take a crack at that... chad

1 0

User registration without *password*
by Samuel Charrington 15 Jun '06

15 Jun '06

I followed the recent "user registration without email" thread closely, as I'm about to start working on a related issue. Prior to moving my site over to Drupal, I had implemented a password-less registration system [1] for our downloads area that was based on the user's email address. It basically worked like this: 1. When a user requested access to a 'protected' resource, we would first check for a registration cookie. If the cookie is present, we would send them on to the requested resource. 2. If no cookie is present we would throw up a registration lookup form requesting their email address. When submit, we'd look for their email address. If found, we'd set the cookie and forward them to the requested resource. 3. If the email address isn't found, they would be asked to 'register', by providing an email address along with personal info such as company name, address, phone, etc. Upon successful registration we'd set a cookie and forward them to the requested resource. I'd like to implement a similar scheme for my Drupal-based site. One option is to port over my existing code and tables and keep the registration stuff separate from the Drupal system. However, it seems like a more flexible approach would be to make each of these registrants "users" in Drupal, allowing me to use Drupal features and contrib modules for managing the resources and controlling access to them. I'm currently thinking I can accomplish most, if not all, of this by hacking/patching the LoginToboggan module. I would need to modify it to use an empty string for the password, customize the login form, and suppress the confirmation email. I would use the it's Immediate Login feature to create the users and put them into a "non-authenticated role" I'd create called "registrant". My intention would be to leave them there permanently. I'd also need to implement the ability to forward the new user to the requested page. I'm looking for an any thoughts on this approach, and any pointers if it has been done already. If there are any gotchas I'll likely run into, or if--for some reason that isn't yet apparent to me--this is just a Bad Idea, I'd like to know that as well. Also, if there is any broader interest in this type of functionality let me know. I'm happy to work as closely with the LoginToboggan maintainers as they would like, and would appreciate any help or guidance they can offer. Thanks, Sam [1] The use case here is a corporate/brochureware site where the security of the resources is not a major concern, as they are typically marketing materials. (Site security is still a concern, of course.) It is desirable to avoid requiring users to create/manage a password, yet we'd like to somehow accomodate the repeat visitor.

2 1

Separating configuration vs data tables
by Barry Jaspan 15 Jun '06

15 Jun '06

One thing I'm not aware of a good way to do with Drupal is sandbox testing or controlled change management on a running system. There are some posts talking about how have a test site and test database for development, but you always have the problem of re-integrating your changes back into the running system. You either have to (a) re-make the changes on the production system one step at a time or (b) transfer the development database to the production database, losing any new content/users/data. I do (a), but it is annoying and error prone. If someone has a better system, I'd love to hear it. My suggestion is to identify which database tables contain administrative or configuration data vs. which tables contain content and then store them in separate databases (brief research indicates that MySQL supports cross-database queries but Postgres does not, so this functionality would be turned off with Postgres). Ideally, it would then be possible to clone both databases, add modules or change settings in the sandbox until happy, and then copy back only the admin/config database and any filesystem mods. In one step, the production system would be upgraded. We would have to decide which tables fall into each category and possibly refactor some tables if they span both categories. Perhaps it is not possible to separate them all cleanly in this way, but it seems worth trying. As for implementation, we already have the $db_prefix array that can be used to convert {tablename} syntax into database-qualified values. That could be set up manually. Even better would be to have this separation work automatically for core and contributed modules by specifying which category each table belongs in a data driven way: function system_schema() { $tables['variable']['#category'] = DB_CAT_CONFIG; ...; } function node_schema() { $tables['node']['#category'] = DB_CAT_DATA; ...; } Comments? Barry

10 10

Split modules into their own directories.
by Dries Buytaert 15 Jun '06

15 Jun '06

Hi guys, I think we ready to go with: http://drupal.org/node/64280 ... last minute comments? -- Dries Buytaert :: http://www.buytaert.net/

4 3

4.7 maintenance: Bugs & Patches
by Gerhard Killesreiter 15 Jun '06

15 Jun '06

Hi there! There are a number of patches pending that are specifically filed against 4.7: http://drupal.org/project/issues?projects=3060&states=8,13,14&versions=10696 Most of them need some work. There also a lot of bugs filed: http://drupal.org/project/issues?projects=3060&states=1&versions=10696&proj… And a few leftovers from before the release: http://drupal.org/project/issues?projects=3060&versions=10634%2C10412%2C103… I intend to make Drupal 4.7 the least buggy Drupal there ever was, but in order to get there I need your help. If we can get a reasonable number of bugs fixed, we can aim for a maintenance release sometime this summer. I also invite people to run Drupal from the 4.7-CVS branch in order to test such a potential release. Cheers, Gerhard

1 0