August 2008 - Development - lists.drupal.org

Handling multiple e-mail log in IDs and passwords . . .
by Jason Flatt 25 Aug '08

25 Aug '08

I'm in a bit of a quandary and I'm seeking ideas, opinions, insights, whatever to help me move forward. I am, for the third time, building or modifying a module that has as one of its requirements the collecting of user data for logging into an e-mail account, i.e.: the user ID and password. For the previous two modules, I simply gave the administrator the option of specifying whether to use the account id and password from the users' account or to add additional fields in the users' registration and edit forms for collecting that information. During the process of, basically, doing the same thing, it occurred to me that some folks might not want to use the Drupal account information, but they also might not want to have two or three or more areas to put in, quite possibly, the same information. So, the question is, how to approach this? Do I go into every possible module that collects e-mail information, see where and how they store it and make it available for the users of my module(s). That seems like an effort in futility. Is there a module that already handles this and related situations? I didn't see any that looked like they did. How about API calls? That would be the ideal way, but, again, I didn't see any that looked like they did what I'm looking for. (That's not to say that neither module nor API call exists, just that I didn't see any that I thought addressed my needs.) Does anyone have any ideas or suggestions on where to go, or do I just stick with the old stand by methods and end up with what I've been doing all along? -- Jason Flatt http://www.oadaeh.net/ Father of Six: http://www.flattfamily.com/ (Joseph, 15; Cramer, 13; Travis, 11; Angela; Harry, 8; and William, 2) Linux User: http://www.kubuntu.org/ Drupal Fanatic: http://drupal.org/

2 1

Preprocess flaw
by Aaron Winborn 23 Aug '08

23 Aug '08

I raised an issue at http://drupal.org/node/297951 originally for the Filefield module, and then at http://drupal.org/node/297952 for the Drupal core theme preprocess hook architecture. The second issue was marked 'by design', but I believe the design is flawed, and that this needs to be addressed. As the preprocess theme hook has only been opened for developers in Drupal 6, this wasn't much of an issue before, and the flaw has only now become apparent. Without any documentation I can find, the $file variable is reserved, meaning that theme developers may not expose a variable named $file to a template file when inserting a preprocess hook, as outlined at http://drupal.org/node/223430. The $file variable is well established in Drupal, and often used in contributed module theme functions. Now that it's relatively easy for themers to override theme files with their own template files, this issue will begin to crop up. The current work-around is that if the theme function you wish to override uses a $file variable, then you have to copy that variable in your preprocess hook to another variable, such as $original_file. This is unwieldy, unfortunate, and currently undocumented (as far as I can tell). I have a feeling we'll see this problem become more prevalent as developers move to Drupal 6. In core, $file appears only 22 times, and not in any core theme functions (that I'm aware of). However, that is misleading, as core Drupal currently does a poor to middling job of file handling (which will hopefully be remedied soon). In the contributed DRUPAL-6--1/modules branch, $file appears 265 times, and 1186 times in the contributions/modules branch. There are several contributed modules using $file in theme functions, such as the aforementioned Filefield, Imagefield, Media Mover, and File Framework. (I'm sure there are others, those are just from a quick grep). And I suspect that at the very least, Imagefield and Filefield will warrant relatively frequent theme overrides for individual sites. Assuming hook_file (http://drupal.org/node/142995) makes it into Drupal 7, I suspect we'll see even more use of the $file variable in themes, particularly as more developers jump into file asset management. Here are some options available to us. There are probably other options as well: 1) Do nothing. Let themers struggle when they try to override a theme $file variable using a preprocess hook. 2) Document the flaw, so at least developers know the difficulties involved in doing this. 3) Declare $file a restricted variable, forbidden in theme functions. 4) Encourage developers to find all instances of $file in contributed module themes and rename them. 5) Use another magic variable name for use in theme_render_template, such as $file__ or $template_file, and declare it restricted. 6) ??? I believe we are doing a disservice to developers if we tell them to use a flawed preprocess system. I strongly suggest we implement option 5 before this problem becomes more severe, ideally for Drupal 6, as many developers are migrating there as we speak. Thanks, Aaron Winborn -- Aaron Winborn Advomatic, LLC http://advomatic.com/ Drupal Multimedia available in September! http://www.packtpub.com/create-multimedia-website-with-drupal/book My blog: http://aaronwinborn.com/

1 0

how to restore devel.module query log in HEAD
by Moshe Weitzman 23 Aug '08

23 Aug '08

I'd appreciate suggestions on how to implement the query log for devel.module now that the new DB layer has landed. I've already submitted a patch to add timing info: http://drupal.org/node/298669 But, it seems that PDO will not show us the SQL that was executed for any given prepared statement. We have access to the statement with placeholders, but that can be verbose as sin, and can't be copy/pasted into a console. Here is a statement for cache_set(): INSERT INTO {cache_registry} (serialized, created, expire, headers, DATA, cid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5) ON DUPLICATE KEY UPDATE serialized=:db_update_placeholder_0, created=:db_update_placeholder_1, expire=:db_update_placeholder_2, headers=:db_update_placeholder_3, DATA=:db_update_placeholder_4 Not so readable, eh? So, should we grab the executed SQL from the DB itself? I had some success with mysql SHOW PROFILES command - http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html. In order to fully implement that, I need a hook before and after the query is executed so i can start and stop profiling. The profiler will only log 100 queries at a time and our pages require more than that. Other DB backends would need a different approach.

3 3

access module
by Balazs Dianiska 22 Aug '08

22 Aug '08

Hi all, for work I am thinking on implementing an access logging module, but before I would start head on I would like to ask your opinion on the subject. Drupal core provides a logging module (the access module), which effectively logs on hook_exit. The problem I have with this approach is that this a) as far I know will get ignored for aggressive caching, b) it gets triggered for page load from any source. I thought about using a JavaScript snippet placed into the page (maybe with token so it couldn't be misused, but then a cached page is not trivial) as most bots cant run the JS. Is there any way a callback like this could be validated for a cache stored page? What do you think of the approach? Would appreciate any feedback, Balazs

5 5

Drupal and acceptance testing
by Caleb Gilbert 22 Aug '08

22 Aug '08

The Drupal SimpleTest module has progressed far beyond the original SimpleTest we started with - we now have a more powerful, although Drupal-specific testing framework which still retains the somewhat misleading name "SimpleTest" (there's an issue somewhere to rename SimpleTest to testing). We currently do have both functional and unit tests working under the current framework - although javascript tests currently remain impossible, although there are several issues addressing that point (feel free to help!). I think what you're saying confirms that while 'far-beyond the original simpletest' - the current testing framework in Drupal still has this in common with the standard version of Simpletest -- it's primarily focused on unit/functional testing - not acceptance testing, which is a whole different focus. ( http://en.wikipedia.org/wiki/Acceptance_testing ) To help make what I'm talking about more understandable, here's a list of what selenium (for instance) offers that simpletest (and the Drupal implementation) does not: a) a top-rated browser plugin which offers an interface for scripting, exporting, and running tests specifically aimed at the browser-based aspect of a web application (again *not* unit/functional testing) (screenshots and explanation http://www.spreadfirefox.com/node/980 ) b) an additional tool, Selenium RC, which includes functionlity to automatically launch a variety of browsers and step through the tests in each browser - as an end-user would do c) testing of ajax/js ui elements But basically, our Drupal-specific extension of SimpleTest meets our needs for functional testing and unit testing so well, I don't think there's really any point to looking into other harder-to-install automated testing tools - they'll never be used by a sizable percentage of the Drupal community, whereas the SimpleTest module for Drupal requires very little in order to function properly. The current framework covers the vast majority of our testing needs; the tests are lagging far behind the testing framework here. We don't really need to rethink our framework or consider other frameworks until we've reached the limit of what the current framework can do. JavaScript tests would certainly be nice, but should we really worry ourselves with them when much important core php code remains entirely untested? Again, acceptance testing/selenium does not just = adding-javascript support to unit tests - it equals a whole other kind of testing - one I believe that a very sizable percentage of the Drupal community is interested in I'm sure - testing from the end-user/client perspective. So this would not be a matter of rethinking the existing framework - it's would be adding on to it and/or getting a way to more easily get selenium working with Drupal so that Drupal developers can include accetance test within their workflow. For anyone who doesn't have the bandwidth or the interest to work on finding solutions to better acceptance testing within Drupal I can understand - but I just wanted to point out the difference between what is in Drupal now and what I'm talking about. They are different and it's not just about what's in Drupal 'missing javascript support'. - Caleb

2 2

Drupal and acceptance testing
by Caleb Gilbert 21 Aug '08

21 Aug '08

So far all documentation and comments I can find on Drupal.org seem to give the impression that the Drupal project/community-at-large is taking the stance that simpletest should be used for acceptance testing (please correct me if I'm wrong). This, however, would be counter to simpletest's own documentation which suggests to look at other solutions for acceptance testing: http://simpletest.org/api/ (bottom of page) In the interest interest of stimulating solutions/attention/discussion to these subjects I've posted an article which contains information and links to other Drupal.org resources about this: http://highervisibilitywebsites.com/researching-drupal-and-acceptance-testi… Cheers! Caleb

2 1

autocomplete.js and http error 0
by Roger Leigh 21 Aug '08

21 Aug '08

I'm working with an autocomplete text field in a module, and some users were getting an alert error, "An HTTP error 0 occured". I was finally able to reproduce this error, not only on my form but on a standard CCK form as well; if you click the form submit button while the autocomplete is retrieving entries (the 'blue wheel' is present), it triggers the error. Surprisingly, I couldn't find a lot of info on a drupal search, though I did see some related reports in other projects. Looking at the autocomplete.js file, I see the alert at line 285. Obviously I can change it here, but always hate to hack the core. Any ideas? Regards, Roger

4 4

delete menu not appearing
by Lluís 21 Aug '08

21 Aug '08

I have developed several node types for an application, and in one of them "delete" menu doesn't appear when viewing it; first I thought it could be a permission problem, so I wrote: function hook_access($op, $node) { return true; //debug ... } but nothing happend; then I tried with user 1 and it is the same (I cleared all cache tables using phpmyadmin). besides hook_delete and hook_access is there anything else necessary for the menu to appear? From the administrative interface I can delete the node without problems. thanks -- *La vida és com una moneda, la pots gastar en el que vulguis però només una vegada. *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les il·lusions. *Als llocs desconeguts només s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient.

4 9

form_set_value and multistep
by Caleb Gilbert 21 Aug '08

21 Aug '08

This link starts off the most helpful thread/thing I've seen about form_set_value() - might be worth a look before filing an issue: http://drupal.org/node/160160#comment-820709 - Caleb

1 0

form_set_value and multistep
by Dave Cohen 21 Aug '08

21 Aug '08

Hi, I've written a form element for drupal 5.x which, in it's #validate callback, converts a comma-seperated string into an array of ids. It uses the form_set_value() function to change the string value to an array. My element fails in multistep forms. The reason being that first the form is processed, then the $form_values which my call to form_set_value() affected is discarded (at the end of drupal_process_form()) then drupal_retrieve_form() is called again, this time passing in $_POST (this happens in drupal_get_form()). Because my call to form_set_value() affects $form_values and not $_POST, my changes are lost. I've noticed that if I also change the $_POST after I call form_set_value(), I can work around the problem: // Here's the call usually make: form_set_value($element, $items); // Here's the workaround that modifies $_POST: _form_set_value($_POST, $element, $element['#parents'], $items); For a number of reasons, I feel that call to _form_set_value() is hacky and does not belong in my code. However, it might be a reasonable addition to form_set_value(). If I were to submit that as a patch, any chance it would be committed? I'm not the only one who's had problems with form_set_value(). Most people find workarounds usually avoiding it entirely, but I have yet to find one for my case. For example, http://drupal.org/node/264743. Thanks, -Dave

1 0