Drupal

Background
For the past 6 months I've been lucky to be part of the development team for the newly launched Yoursphere.com, a Drupal-powered social networking site which "provides one of the safest online destinations for youth ages 9 through 18 to interact*". To say that Yoursphere is the most customized Drupal site I've worked on would be quite an understatement. One example of that, and subject of this article, the user registration system went from the standard single page - to one which uses 4 unique user creation forms which are integrated within several possible 'registration flows'. The most complex of these involves two of the user creation forms, 8 total screens and third-party identity verification.

Besides being an opportunity to get to know hook_user real well, at the end of creating this system we were left with a larger-than-normal nightmare of, "Wow, I wonder if my new small change just exploded the entire registration system for the site. Hmmmmmm."

(Since writing this article I've posted a newer article about Selenium here)

Based upon my recent research, there seems to be a sentiment in the Drupal-community-at-large (an undefinable thing to be sure) of, 'there's no need to look any further than simpletest for any testing needs' (unit, integration, acceptance, etc). This is counter to simpletest's own documentation (bottom of page) which explicitly suggests to look for other alternatives for acceptance testing.

After Googling to death 'selenium rc drupal', 'selenium rc php', etc I realized that almost no one seems to be implementing Selenium RC within their Drupal workflows.

Scratching my head at this I decided to figure out 'why' by doing an exhaustive search of all things Simpletest and found that it does indeed have support for making acceptance tests (see bottom of article) - BUT - and it's a big but - there's no javascript support.

So I started tracking down how the Drupal community plans to deal with the lack of JS support in Simpletest, and stumbled upon this effort to get some kind of JS testing framework into Drupal 7 head, which if I read things correctly appears to be more about unit testing than UI/acceptance testing. So the current Drupal roadmap for the latter doesn't seem to exist. (anyone have ideas/links to things related UI/acceptance testing for Drupal that I might have overlooked? UPDATE: Just found this link, but also seems to be more on the unit testing side and it's currently seems to be inactive)

At the moment I'm left wishing that getting Selenium RC to work wasn't so painful (it requires installing PHPUnit, which in-turn requires installing a PEAR extension, which for many requires installing PEAR itself).....or to put it another way....currently I'm feeling stuck between tackling something which does what I want but which isn't embraced (Selenium or acceptance testing) by the larger Drupal community, or else tackling something (Simpletest) which is supported by the larger Drupal community but doesn't offer the level of functionality I'm looking for.

Wondering how I can help.

Related articles:
Selenium and Drupal
Unit VS UI Testing
Develop an automated javascript testing framework

As a follow up to a previous article comes an even more elegant solution than the 3 little lines of code.

The spectacularly awesome savetofile.module lets developers:

1. Exchange the Drupal submission UI for their favorite IDE/text-editor:
Simply click a button and via an ajax call, the contents of your node/block/whatever is auto-injected into a file (with the name of your choice) and all that is left in the node/block/whatever is a one line function call which will load the contents of the file at runtime. So at this point you can choose to never look at the editing page for that item again and instead simply edit the file which was created to affect the item. This can be a massive time saver as well as put all your favorite tools at your disposal.

2. Get code out of the database and into version control and make it searchable (from the desktop):
Ideally all that would be in a site's database is text-only content (e.g., no html/php). Having code in there is a nightmare in-general for editing reasons - but even worse - what happens 9 months later when you forget how you made that little widgety-thing in the first place? Is it a block, is it a node, is it in a theme file? Who knows!?

With savetofile that's less of a problem because now that node/block/whatever content can be version controlled and/or searched for with your favorite desktop tools since it's not in the database anymore.

3. Reverse all of the above with one simple click
Want to develop using the file method but want the contents of the file back in your node/block/whatever when the time comes to go live? Press one button on the edit page of the item and another ajax call will replace the savetofile code with the contents of the referenced file and all is back to 'normal'.

Personally, I won't be building a site without this module from here on out! :-)

Assignment: Create a highly customized page/node in Drupal and:

• Be able to develop the page/node using our text editor of choice and avoid the time-consuming and not-intended-to-be-developer friendly Drupal node-editing interface
• Optionally be able to decide whether to have the page/node be editable by the via the Drupal UI or not.

Sure, we could do this by creating a page-node-xx.tpl.php template file (where 'xx' is the node id number), but that's just a major hassle later on when updating/theming things and it won't give us the flexibility of being able to let an end-user edit things.

In this case, the thing to do is to create a file called my-file.php (.php because we want our text-editor to still recognize it correctly), put it in our theme folder, check the PHP input filter on the node itself, and then place this code in a node:

What this will do is look for the file you placed inside your theme folder called "my-file.php" and render it. Which means that you make changes directly to my-file.php without having to touch the node itself and thus simply refresh your node anytime you make changes to the file.

This method has the advantage of:

• Saving a ton of time and headaches of dealing with the Drupal interface and doing without your favorite code editing tool.
• After you're finished you'll have the option of choosing to replace the include-code with the final code inside your file so that an end-user can edit it within UI...
• ...or you can just keep things like this and be able to do cool things like check the code into version control, which means that you basically get many of the benefits of a tpl.php file without the cost of one.

Enjoy and happy coding. :-)

UPDATE: if this all sounds like a good idea to you, head over to the project page for Save-to-File which was inspired by a conversation in the comment thread below.