Drupal

Researching Drupal and acceptance testing. Or where Simpletest admits it falls short. (so what'd we gonna do about it?!)

(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

21 August, 2008

Drupal productivity - savetofile module saves time and aggravation

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! :-)

18 April, 2008

Three little lines of code that you may learn to love

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:

<?php
// Include a file with the rendering of a node so that you can edit in text editor and just refresh without having to use Drupal UI
$filename = 'my-file.php';
$path_to_file = drupal_get_path('theme', 'your_themes_name') .'/'. $filename;
include(
$path_to_file);
?>

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.

22 March, 2008

Design debt, Drupal.org, and the Drupal project itself

Published in: 

The community will begin to realize (in part due to the above stalled project) how much design debt Drupal has accrued over the past several years of rapid expansion and development. While the problem will not be solved in 2008, the realization that it IS a problem will help prevent a long-term meltdown. - Jeff Eaton January 4, 2008

Design Debt and Drupal.org
Indeed as Jeff suggests, this "realization" seem to be a bit of a challenge at the moment for parts of the Drupal community right now, at least if the reactions to Harry Slaughter's post regarding a Drupal module ratings site which John Forsythe just launched are taken into account.

Given the possible reactions it was disappointing to me that some people chose to attack Harry and John (e.g., the messengers) rather than the processes which have lead to a situation whereby one of the largest open source software projects on earth can't get SOMETHING up to help it's users deal with their number one feature request for Drupal.org. As John, myself, and any number of people have proven there has been no lack of volunteers, or lack of resources, but rather just grid lock on this issue. (for instance, this thread was just one of many that tried to get the ball rolling).

Contrast how this scenario with module ratings works with how core development works. With core - people submit patches, other people give opinions and review, but eventually one person just makes a judgment call on whether or not the patch is committed and life moves on. With the module ratings it's been more a game of 'waiting for consensus' of a handful of well intentioned people who all each seem to have the power to hold things from going forward but none of whom have the authority to 'just call it' - and thus move the issue on toward *actual* implementation. Thus more time passes by without a solution...

While on the subject of design debt - design debt and Drupal 6/7
Drupal 6, a great release in it's own right, is unfortunately not production-ready for many site-types due to the lack of some very important contributed modules. Since my time with Drupal (4.5) I've never seen anything quite resembling the lag between a Drupal release and it's 'production readiness' that I'm seeing now (Views is not even out of alpha - and CCK is waiting for views to be done before finalizing itself).

Won't pretend to know what needs to be done to fix it all, but from my own personal perspective I can't fathom being concerned with anything regarding Drupal 7 and probably won't be able to until I've got some productive months of being able to use Drupal 6 under my belt. This is NOT to say that current development for Drupal 7 is a waste of time - I do see the value of forward-thinking development, but I also feel there is a rapid rate of diminishing returns for it at the moment.

If there is any point to the above statements, it's that a) I don't think that I'm alone in my feelings and, b) I'm somewhat concerned about Drupal achieving an 'Emperor has no clothes' moment in the near future if these issues aren't eventually addressed.

17 March, 2008

Advanced Theme Construction Kit (ATCK) updated for Drupal 6

The Advanced Theme Construction Kit, which integrates a derivative of the Yahoo grids CSS library within a Drupal framework, was updated and released for Drupal 6 today.

Something new
After religiously following the changes to Drupal 6's theme-layer for many months now, as well as actively coding a Drupal 6 module for the past month and a half, I was thinking that upgrading ATCK was going to be a snap...

In some ways it was, but the Drupal 5 to Drupal 6 theme conversion was by far the most complicated theme update I've seen since being involved with Drupal (4.5 onward). As it turns out the Drupal 5 template.php file for ATCK was almost completely useless, and it was with great thanks that I (again) borrowed heavily from Hunchbaque's template.php in order to get the desired granularity for classes/id's.

One area I did depart from core and the Hunchbaque theme on is the handling of css files. Allowing for the possibility that there is something that I'm 'missing', I can't say that I'm currently very happy with Drupal's new method of adding stylesheets via .info files, nor with the functions that Hunchbaque currently uses in it's template.php to add IE-only css. The core method of stylesheet handling makes stylesheets a bit of a pain to refresh, and I found both methods to be unreliable with respect to conditionally adding stylesheets.

In the end 'old fashioned' conditional statements were implemented within page.tpl.php, and a custom function added to template.php. Along with being reliable, this combo provides the ability to tell Drupal to NOT import specific core css files (e.g., if you don't want the node.css file loaded - simply add a line to the function inside ATCK's template.php and node.css never gets loaded).

Something old
The most satisfying part of the upgrade was that the centerpiece of ATCK, the Yahoo Grids-inspired CSS library, did not require a single change. So this part has proven to indeed be modular and Drupal version independent. :-)

Future development plans for ATCK
* Possibly add the edit functionality that the Zen theme has introduced to make managing blocks and views easier.

~~~

HigherVisibility is looking for assistance!

15 March, 2008

Speeding up Drupal Forums

The Drupal forum.module has become, well, somewhat infamous for less than awesome scalability. Recently I had a chance to see this firsthand, and track down a solution for managing the long page load times for a client who has a highly trafficked forum. This was not a case of a site that was un-tuned - actually this particular site had a lot of good work and performance enhancements already done to it, including block caching and even some modifications to the forum module that were allowing to work better than it would have without them. But still 5-6 second page load times on /forum persisted.

As this was my first time working on the site, I began by reviewing all of the main configuration files for Apache, MySQL, and PHP, since they are the foundation for everything else. After making some adjustment there, I headed over to the Drupal admin interface and check /admin/setting/performance/ and made sure all was happy there as well. Finally, I went to the block admin page and double-checked all of the blockcache settings, which as it turns out were set a bit to aggressively, resulting in slow form submission times (every time anyone submitted anything a gazillion blocks were being re-cached whether they need to be or not).

With the foundation of the site now looking good and everything, except the forum pages flying along (and the tracker, but that's a story for a later article) - it was just down to forum.module.

Here are the steps that led to cutting the page load time in half from what they were:

1. Disable the forum.module, rename it to something like "forum.module.orig", make a copy and then rename the copy "forum.module".

2. Download the advcache module and apply the forum patch includes to your new copy of the forum.module.

3. If want the cleanest solution and are comfortable with coding/debugging at all, instead of just copying the forum module and working on it directly (and thus having a hacked Drupal core file around all the time) - name the copied file something completely different than forum.module and edit all of the hook/function calls with in it with new name and place it where you keep the rest of your contributed modules.

4. (Note: this step is an option only if all your forums are public)
Open the module and remove all references to db_rewrite_sql. This will keep Drupal from doing a lot of expensive and uneccesary queries in order to check access rights. (thanks Khalid)

28 February, 2008

Pages

Subscribe to RSS - Drupal