[development] idea for an install profile (and "distribution"): devel install
Wim Leers
bashratthesneaky at gmail.com
Thu Mar 1 11:09:29 UTC 2007
Superb idea :)
On Feb 28, 2007, at 10:59 , Derek Wright wrote:
> 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...
>
More information about the development
mailing list