February 2007 - Development - lists.drupal.org

temporary access module
by Alan Dixon 22 Mar '07

22 Mar '07

Hi drupalites: I've been working on a little module i'm calling 'peek' and just wanted to check in on duplication of efforts, existing wisdom, etc. The client wants to be able to create a page, and then fire off a bunch of emails to people who may or may not have accounts, allowing them to access the page temporarily. So an administrator needs to be able to generate a semi-secret url (like the ones generated by the user module) that would give someone temporary access to a single node page. After struggling with the node_access stuff for a while, i realised that i probably want to sidestep the usual permissions by providing access to the node page via a callback anyway. So the url i'm generating looks like '/peek/<uid>/<timestamp>/<hd5 hash>' and my peek table keeps track of things like the corresponding nid, when it was generated, how long it's valid for, when it was first accessed, and how long it remains valid after first access. I've also got a helper function to generate new users for email address that don't already have a user. When the link is generated, the user gets authenticated to this uid. That way all subsequent activity is connected to their userid for tracking purposes. Thoughts anyone? -- Alan Dixon, Web Developer http://alan.g.dixon.googlepages.com/

4 5

idea for an install profile (and "distribution"): devel install
by Derek Wright 01 Mar '07

01 Mar '07

while waiting for Dries to officially RTBC the issue for hosting install profiles on d.o [1], i just had an idea for a install profile: the development profile. things it could do: 1) install/configure devel.module 2) setup some standard roles for testing (non-uid-1 admin, content admin, a role that only has "switch users" permission, etc), and configure all perms appropriately. 3) create a small pool of users in each of the roles, all of which are also in the "switch users" role, enable the switch users block from devel.module, etc. [2] 4) also create a bunch of random users with the generate script from devel.module... 5) create a bunch of test content with the generate script. 6) create a bunch of malicious (XSS-seeking) content: node titles, taxonomy terms, anything we can think of that some module might not be escaping properly somewhere. basically, wrap js alert boxes around just about any possible user-input we can find. ;) 7) install as much of the simpletest.module and framework as possible, and otherwise prompt/warn the user about the external library they should download and install. 8) perhaps install some per-node-access module(s) (tac_lite, simpleaccess, etc) and configure some of the auto-generated content to be private. 9) optionally install some other handy modules folks use for testing (i'm a big fan of diff.module and dba.module, but there might be others that would be useful). 10) perhaps install/configure some kind of benchmarking tools (if any exist that would be appropriate). ... this would: a) save a ton of time whenever one of us needs to setup a local test site b) make it *much* easier for newer developers to get a standard test environment up and running c) facilitate being able to reproduce bugs, since everyone could be working from a more standardized test environment most of the time d) lower the barrier to developers running (and therefore writing) simpletests for their code e) help find XSS more quickly, since folks (and automated tests) would be navigating through a site that was trying to XSS-ify itself all over the place. just having the per-node-privacy content auto- generated would help remind folks to test those sorts of edge cases in their code, too. i don't have time to work on this, but i'd be willing to help someone (s) else. or, if anyone thinks this is such a good idea, they want to pay me to work on it instead of my other consulting gigs, that might work, too. ;) if we could stand to wait that long, this might make a nice SoC 2007 project, too. thoughts? -derek [1] http://drupal.org/node/113939 [2] it'd be nice if there was a setting in devel.module to restrict the choices in the switch user block to users that have 'switch users' permission, so that such a test environment would always allow you to quickly switch back and forth across differently perm'ed users, without ever getting "stuck" on a random user that didn't have switch perms...

8 9

Core developer quiz
by Earnie Boyd 28 Feb '07

28 Feb '07

See http://drupal.org/node/116820#comment-205539 for the quiz. Keep the responses in the ticket. Have fun, Earnie

1 0

link admin/help
by Glenn Wybo 28 Feb '07

28 Feb '07

Grtz, I'm writing a new module for drupal and was just trying to add some help in the module. Adding a description in admin/modules wasn't a problem, nut I also wanted to add some information to the admin/help. The code is : function product_help($section = 'admin/help#product') { $output = ""; switch ($section) { case 'admin/help#products': $output = t('<p>Extends the functionality of the products - menu.</p>'); $output .= t('<p>We have actually added a tree structure to the products - menu, '); $output .= t('which makes it easier to select a group of products and so navigate '); $output .= t('through the store.</p>'); return $output; } return $output; } Unfortunately, I don't see the link under admin/help. I think the code above is just wright, but I have to add a link somewhere. Can anyone help me on this? thks _________________________________________________________________ De meest trendy stuff voor Windows Live Messenger ... http://entertainment.msn.be/funwithmessenger

2 1

Drupal Association
by Dries Buytaert 28 Feb '07

28 Feb '07

Hello world, last week I was away from the keyboard, and earlier this week we announced the Drupal Association. I'm still catching up with e-mail, digging out from the Drupal Association buzz. I did start committing patches again though. Incorporating the Drupal Association was a _lot_ of work -- we worked on it for months. We don't expect that you instantly understand the ins and outs so if anyone has questions regarding the Drupal Association, I'd be happy to answer them. The Statutes are available online (http://association.drupal.org/ about/statutes-and-internal-regulations) and we tried to answer all common questions in the FAQ (http://association.drupal.org/about/ faq), but if there is anything you'd like to see clarified, just ask. The important point (for this mailing list) is Article 4, Section 4 of the Statutes: "The community of Drupal developers decides independently on the functionality on the one hand and on planning the development of the Drupal software on the other. The Association shall not have a casting vote in such matters." This means that the Drupal Association can't enforce that certain features make it into Drupal core, nor can it enforce that a contributed module has to incorporate feature X and/or drop feature Y. Instead, there is a clear separation of powers. The Drupal Association manages the assets in such a way that it supports the (developer) community, and the (developer) community continues to provide support and works on the code. -- Dries Buytaert :: http://www.buytaert.net/

2 1

filtering PHP_SELF
by David Caylor 27 Feb '07

27 Feb '07

bootstrap uses PHP_SELF in conf_init and request_uri, as far as I can tell without filtering. This isn't safe. Is this getting filtered somewhere or somehow that I'm missing? If it isn't getting filtered elsewhere, adding htmlentities to these two functions would be an inelegant but sufficient (for security purposes) fix. See here for a discussion about not trusting PHP_SELF: http://blog.phpdoc.info/archives/13-guid.html

3 2

SVN vs. CVS? (was re: CVS branch work best practices?)
by Derek Wright 26 Feb '07

26 Feb '07

Rob Thorne wrote: > So if we are going to start using branches more, and encouraging > more developers to play with tags and branch tags, it might be > worth studying whether or when to migrate to a more modern system. i'll be the first to admit that CVS can be daunting to the untrained. however, the entire thread about best practices for branching has nothing to do with CVS's failings regarding branches, tags, and merging. when to branch, if/when/what to merge (and if not, what branch(es) to apply patches to) are generic questions that would face Drupal developers, no matter what revision control system we used. as far as i know, the *only* viable alternative to CVS that might be considered for drupal development is SVN. sadly, in spite of the other ways SVN improved things that CVS sucks at (basically, renaming files), SVN still fails to make merging branches easy. sure, the syntax of the command changed from: "cvs update -j [revision_1] -j [revision_2]" to: "svn merge -r [revision_1] -r [revision_2]" but otherwise, all the same suckiness is there in both cases [1]. getting into the details of this is OT -- my real point is that SVN is no paradise for revision control, especially regarding branches. sure, the "svn tag" operation is orders of magnitude *faster* than "cvs tag" in many cases, but it's no *simpler* to understand or get right. and no one is complaining about wasted time while "cvs tag" runs, they're complaining (with some justification) about wasted time thinking about the revision control problems (when/why to branch/tag, where to apply patches, when to make releases, etc), instead of their Drupal code problems. bottom line: nearly all of the confusion is being caused because of misunderstanding revision control concepts (and the incredibly complicated world Drupal has created for itself, see my other post), not the syntax or functionality of a specific revision control tool [2]. that said, i'm not fanatically opposed to moving Drupal development to a different revision control system, but it's going to take a *LOT* of work, and (in a year of *many* people trying) i've yet to hear an argument that holds any water about ways SVN would significantly improve our development practices to offset the very high cost of switching. that said, if someone(s) wants to pay me enough to do all the work (and i won't make the same mistake of wildly under-guessing how many hours this would actually take from start to finish as i did with the release system) i'd be more than happy to do the clean separation/abstraction required so we could use SVN instead of CVS. if you're serious (and have a big budget), talk to me off list. thanks, -derek [1] http://www.dellroad.org/svnmerge/index has promise to solve some of these problems, and is now included in the SVN source, but it's still basically "contrib" as far as i can tell. :( [2] to address Rob's other comment: > First is the notorious "forgot -kb on cvs add" problem. this is a non-issue in a repository with a properly configured CVSROOT/cvswrappers file, which thankfully, the Drupal contrib repo has been for at least a few months now. ;)

7 10

extract events for print publication based on start/end date with grouping
by Tim Archambault 26 Feb '07

26 Feb '07

Looking to extract events (from default event module) based on a specific taxonomy. In this case: "Arts & Entertainment" into a plain text view of the BODY only. I don't want title, location information, dates, or other info, just the BODY to display. I've all ready set the view to require admin privilege. I've created a view called calendar_entertainment_print that selects the correct taxonomy and displays proper nodes. Need help with a) limiting results between a start and end date and b) formatting the results in plain text with node BODY only, and c) group the calendar items by category alphabetically (example below). >From this view, an editor can cut and paste and massage this information accordingly. Thanks for any help. Here's an example of the output below. Start cutting for pasting into Quark Express here............................................ ART Bangor - blah....blah.... Calais - blah...blah... MUSIC Bangor - Nappertandies playing at the Sea Dog Saturday, 7pm. 555-5555. Ellsworth - Bad2theBone playing at the Music Hall Sunday, 5pm. 555-5555. DANCE / THEATER Brewer - Nutcracker at Brewer Middle School, Thursday, 7:30pm. $25. 555-5555. End cutting for pasting into Quark Express here............................................

1 0

Re: [development] sandboxing releases
by Derek Wright 26 Feb '07

26 Feb '07

> I would like to plead -again- to open up the sandboxen for such > modules, > projects and ideas. i personally don't object to this. however, please (re)read my last reply on the previous sandbox thread, for some concrete suggestions on why contributions/modules was a better alternative than contributions/sandbox/ber, even if you don't maintain (or even create) official project nodes for any of them: http://lists.drupal.org/archives/development/2006-12/msg00193.html cheers, -derek

3 4

chasing HEAD? vs remove it? (was Re: CVS branch work best practices?)
by Derek Wright 26 Feb '07

26 Feb '07

re: what to do with your contrib module's HEAD "branch"... i knew this would be a big question, given the increased flexibility the new release system provides maintainers, so i wrote this section: http://drupal.org/node/17570#HEAD my stance on this debate changed a lot in the course of the 5.x core development cycle. i used to agree whole-heartedly with earl: chasing HEAD is a bad idea unless you really know what you're doing. now, i mostly agree with moshe: chasing HEAD is great if you're up for it. there were a handful of (at least to me) fairly serious bugs in the 5.x API that i only noticed once i tried to port project* to it. it's a small miracle that we managed to get all of the core patches to fix them accepted, even though it was after the code freeze (thanks Dries, Unconed, et al!). no blame goes to any of the folks who contributed these otherwise great improvements to core (whomever they were) for not handling these edge cases that project* was hitting... it was my responsibility as the project* maintainer to notice and sound the alarm, not the folks for whom the core patch worked in all the testing they could dream up with sane (ahem) modules. ;) bottom line on this point: if you're up to the task, trying to keep your module's version of HEAD in sync with the (ever-changing) version of the API in core's HEAD is a worthy, noble goal, and it should be encouraged as much as possible. if they keep up with the changes, contrib developers: a) will be more familiar with the new changes to the API taking place, and in general, be more knowledgeable about the core API itself b) will have more chances to find/correct problems with the API changes while there's still room to move c) won't have to do all the porting at once d) will help add momentum to the new version of core, since as soon as the first RC ships, there will already be a set of modules compatible with it ... of course, all of this requires more work, and certainly not every contrib maintainer is up for it. a lot of what earl says is still absolutely true. but, moshe is fundamentally right on this: there's no need to actively discourage people from doing this work if they're willing and able. cheers, -derek p.s. i've got to think about this "just remove all the files from HEAD except a README.txt" approach before i strongly stake a position. part of me recoils in shock, since that's not how You're Supposed to Use CVS(tm). however, part of my loves it, since i positively HATE the problems that come when people try to use HEAD "releases" for real sites... however, i think the impetus for adding this "3rd way" came from not really understanding the simplicity of the first scenario i laid out in the handbook page linked above. it seems the remove-all-the-files scenario creates a handful of problems (some minor, some major) and additional work that should be hashed out before a) anyone actively goes down this route and b) this remains as a recommended approach in our CVS handbook. unless there's strong opposition, i'd like to revert the latest revision to the page, at least until we've clearly decided it's another approach worth advocating for in some circumstances. right now, i'm leaning towards saying this is a bad idea, and people shouldn't be doing this to their contribs.

2 1