idea for an install profile (and "distribution"): devel install
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...
Great idea! 1. Should include Earl Miles' new Update Status<http://drupal.org/project/update_status>module for constant module status. 2. Should include some software development process plugins on a simple level. I am thinking of adding some kind of xp (extreme programming) tracker stuff, which could be as simple as an alternative set of issue status and types, plus some way of indicating issues by teams. 3. Along these lines, some way of integrating the following concepts with issues: a. User Stories (node type with additional fields (cck) and view) b. Test Cases (node type with additional fields (cck) and view) That way this could come with an "XP Tracker" option built in as another layer without changing anything "core". saludos, Victor Kane http://awebfactory.com.ar (upgrade to 5.0 awaiting upgrade data path for projects and project issues modules from 4.7: sorry I don't have time to help more :( ) On 2/28/07, Derek Wright <drupal@dwwright.net> 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...
Derek, that is a totally awesome idea. I actually just finished writing my first install profile for our internal use at my company (and need to report a few bugs from the process yet), so profiles and macros have been up in the front of my mind this week. Very often I'm developing modules against a real site I'm building, but I agree that having a test harness environment with dummy data to test against ready-to-wear would be very helpful. Encouraging the use of unit tests is a good thing, too. Before we get into a debate over which modules should be part of this "stress testing" profile (not being a pessimist, just a realist <g>), my I suggest two different environments? One for normal development and one for security stress testing. There are some things that the security stress tester may do that could make normal development more difficult. OK, I know that sounds lame now that I read it over again, but I can see the performance hit and mental overhead hit of having a security test suite running every time I tweak one variable being highly annoying and slowing me down, even though I see the great value of running it through a security-testing environment before releasing. --Larry Garfield On Wed, 28 Feb 2007 01:59:11 -0800, Derek Wright <drupal@dwwright.net> 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...
Brilliant idea, Derek.
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...
i'm glad folks agree this is worth while, but the point of my email wasn't just to solicit +1s and praise... ;) On Feb 28, 2007, at 10:59 , Derek Wright wrote:
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.
a) does anyone actually have time to work on this? ("talk is silver, code is gold"). b) does anyone have money to hire someone to work on this? c) should we suffer without this for 1/2 a year and propose it as a 2007 Summer of Code project? d) any other bright ideas on how to actually get it done? i'm way more interested in having the profile than hearing everyone say how much they like my idea (though a little positive feedback is nice for a change). ;) so, if this thread is going to be valuable for the community, it should quickly move towards "who/how/when" for an implementation... thanks, -derek p.s. i should mention that the "fill up with malicious XSS content" aspect was inspired by something Heine (and perhaps Killes) were talking about once that really struck me as a grand idea. however, they were talking about a DB dump to use for testing, whereas i like the idea of just autogenerating the malicious content via the install profile, so you can always test the latest DB schema, instead of being stuck with something fixed.
I can contribute bits and pieces to a larger project, but don't have the time to drive it. However, having it be an SoC project seems like a perfect idea. Sure, we won't have it as soon as if someone picked it up right now. But on the other hand, the scope and skill set involved in building it seems just about perfect for an SoC project. I'd suggest perhaps a couple other modules might be useful on a dev install profile: Arto's trace module and Angie's module_builder module. In fact, if this becomes an SoC project, I'll volunteer to be one of the mentors for it.
Please write it up as a summer of code project. The page is here: http://drupal.org/node/121626 Doing so in the next couple of days is best as we soon need to finalize our proposals as students will start applying to them quite soon. Chris Johnson wrote:
I can contribute bits and pieces to a larger project, but don't have the time to drive it. However, having it be an SoC project seems like a perfect idea. Sure, we won't have it as soon as if someone picked it up right now. But on the other hand, the scope and skill set involved in building it seems just about perfect for an SoC project.
I'd suggest perhaps a couple other modules might be useful on a dev install profile: Arto's trace module and Angie's module_builder module.
In fact, if this becomes an SoC project, I'll volunteer to be one of the mentors for it.
-- * * * * * Lullabot's First Ever Advanced Workshops Are Here! Drupal API & Module Building - Advanced Drupal Themeing April 9th-13th - Providence, RI Early Bird Discounts Available Now http://www.lullabot.com/training * * * * *
Op donderdag 1 maart 2007 12:26, schreef Derek Wright:
b) does anyone have money to hire someone to work on this? Can we not make some reverse bounty for this? I am sure all the +1s aer willing to give some money instead of merely a +1, resulting in a nice buget to get someone going.
If I recall correct, Robert Douglas was involved in a reverse bounty system a while ago, can h, or someone else think of a way to organise this. Provided its a good idea, off course :) Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Derek Wright wrote:
if we could stand to wait that long, this might make a nice SoC 2007 project, too. But does it really involve any amount of coding? I'd hate to think we were offloading this to a student if all it involves is collecting a bunch of modules, running some scripts and reading the install profile manual. Is it really the best project for a student to learn from?
a) does anyone actually have time to work on this? ("talk is silver, code is gold"). Indeed the idea of a database of content for theme developers to work with had been raised before but never materialized, this is a much bigger project. There's also the issue of maintaining it moving forward.
b) does anyone have money to hire someone to work on this? This is perhaps the sort of thing that comes under the Drupal Associations aim of 'supporting developers'. In the mean time, I'd make a small contribution to a reverse bounty, but it would be very small.
-- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
participants (8)
-
Adrian Simmons -
Bèr Kessels -
Chris Johnson -
Derek Wright -
Larry Garfield -
Robert Douglass -
Victor Kane -
Wim Leers