- Development - lists.drupal.org

External database handling
by Chris Johnson 27 Aug '08

27 Aug '08

Is it generally desirable that contributed modules use the Drupal database abstraction whenever possible when accessing external databases? That is, is it generally preferable to use db_query() and friends, instead of mysql_connect(), mysql_query(), etc. whenever possible? I personally think so at the moment, but would certainly like to hear any arguments to the contrary. An argument that it doesn't really matter is an argument against generally using Drupal's DB layer. If one agrees it is generally better to use the Drupal DB layer, there is a significant problem to doing so. The code which supports multiple databases (of which I admit to being partially the author), such as db_set_active(), requires the additional databases to be listed in an array version of the global $db_url variable (up to and including Drupal 6) and $databases (Drupal 7). This array is set in the settings.php file. When using the Drupal 6 installer, this file can be written for the user doing the install. One can assume that most installations will thus likely not involve someone hand editing that file. Yet, except for some ugly kludges involving overwriting the $db_url or $databases variable (a scalar by default) with an array form including the extra external database(s), the only way to add an external database is to hand edit that file. If one wants to write a contrib module which has all the ease of installation which D6 and D7 core have, and which uses an external database, one is rather stuck. One can either (1) kludge up the $db_url or $databases variable by overwriting it, (2) require the user to expertly hand-edit the settings.php file or (3) not use the Drupal DB abstraction layer. Or so it seems. The contrib modules I've looked at so far mostly resort to #3, not using the DB abstraction. I'd especially like to chat with the folks working on the DB layer for D7. It would be nice to provide an interface to allow adding an additional DB programmatically from the contrib module. ..chris

4 6

Questions about views
by Roberto Bermejo Martinez 26 Aug '08

26 Aug '08

Hello I'm working with the version of drupal 6 with the modules and views cck 2. I need some way of creating a block to me shows a tree with links to the documents as the publication date. I make a page, but can not block. It would enable the block to obtain the arguments of the page? Sorry for my English. Thank you very much.

2 2

DrupalWebTestCase and changing permissions of authenticate user role
by Maarten van Grootel 25 Aug '08

25 Aug '08

Hello all, I'm currently in the process of writing a 7.x patch to create the 'edit own comments' permission, to give admins the option to prohibit editing of comments. The functionality is working, but I would like to write a testcase for it, just to be complete. Here I found either a limitation of my understanding of the drupal testing framework, or a limitation of the framework itself. Because the 'edit own comments' permission is on by default, (the 'authenticated user' role has the permission checked by default), any user created with drupalCreateUser($roles) will inherit the right to edit their own comment. Therefore, I can't make a test that checks that a person gets a 403 when trying to edit their post without the right permissions, because I can't disable the permission in the testing environment. What I need, and can not find, is a function that will change the role_permission values for the 'authenticated user'-role, something like DrupalWebTestCase->drupalSetPermissions($role-id, $permissions). Am I right to conclude that this can't be done with the current state of the Drupal WebTestCase? If so, do you have an idea how to solve this in an other way, or should I just leave the testcase out of the patch? Thanks, Maarten

2 4

Module needs good home
by Larry Garfield 25 Aug '08

25 Aug '08

So I've been trying to put this off thinking I'd find time for it, but it's become very clear to me that I won't. NodeReview (http://drupal.org/project/nodereview) is in need of a new maintainer. I simply do not have the time or, honestly, interest to maintain it, as evidenced by the lack of activity by me in its issue queue. There is currently one other committer but he hasn't really done much with it either. Judging by the issue queue there's a fair number of people who really dig this module, and judging by the number of times I've gotten direct contacts asking to pay for upgrades and enhancements to it I'd say it definitely has a future with the right maintainer. NodeReview was also my very first released Drupal module (despite the fact that I have never used it in production, ironically) so it has a special place for me. I am hoping for a maintainer that can treat it well and give it the good home it deserves. Interested parties, please contact me directly. Be sure to include why you'd be a good maintainer for it; as I said, this module has a following and is a module I care about (just not enough to actually make time to work on it). -- Larry Garfield larry(a)garfieldtech.com

1 0

Drupal and acceptance testing
by Caleb Gilbert 25 Aug '08

25 Aug '08

Thanks for the reply, Catch - good stuff. I'm going to take a look at what it would take to get Selenium RC to work with simpletest instead of PHPunit (the unit testing framework the Selenium RC docs refer to). An interesting note about Selenium's ties to Drupal - the new AutoPilot 2.0 beta - which was just released in time for Drupalicon - http://twitter.com/workhabit heavily relies on selenium (e.g., selenium's macro recorder/playback is being used in this case for handling change management [pushing changes from dev to staging to production], so apparently it is not just for acceptance testing!). - Caleb I suggested an automated javascript testing framework for gsoc, was thinking watir rather than selenium based on a few discussions about both, but it didn't go anywhere:http://groups.drupal.org/node/9511, While I'd love to see testing with Selenium or Watir or some other browser remote control that can handle stuff that simpletest or straight up javascript unit testing can't, like cwgordon said, it's a matter of effort and returns. The testing framework we have in core has the advantage that anyone can download and run tests without needing to install other software, tests can be written in PHP, and we're getting close to the tipping point where our coverage is high enough to start finding regressions before they're committed. On the other hand, and unfortunately, at the moment we don't have that many jQuery intensive patches - yes, it's really annoying trying to get cross-browser tests when a new jQuery is released, but that's once every few months - so in terms of saving click around time SimpleTest is giving higher returns at the moment. While it might appear to be a lack of interest at the moment, it's more a case of 1. a lack of resources (the 'testing brigade' is still pretty small) 2. a need to get the testing framework we actually have up to a point where it begins to actually save some work - it'll only do this when we're closer to 100% test coverage and tests are being run on patches automatically via testing.drupal.org That said - it's very clear that the core testing framework can't cover everything, so extending it would be the natural next step - and given the amount of time and work it's taken to get to where we are now, starting early surely wouldn't hurt.

1 0

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