If your client can't live without WYSIWYG then check out htmlbox. Originally by Remiya Solutions, this editor sucks less.

The other day we had a discussion on #drupal about the speed of various foreach constructs and webchick said I should blog this. First of all, let me give you a crash course on PHP references. Imagine variables values as drawers and names as labels on the drawers. One drawer can have more than one label and that's what we call a reference. So when you write $a = &$b then PHP slaps a label on the drawer that holds the value of $a. Now, if you unset($a) then PHP removes the "a" label from the drawer, however the "b" label is still on it.

It's so nice to have many theming sites. Provided they are Drupal themer sites:

Although some of their demos have the "Mambo license" menu item running, which is quite frankly not a testament to their understanding of Drupal. However, starting off from a ported theme could still be nice, those buying Drupal themes might not want to fiddle as much customizing the theme further.

However, starting off from a ported theme, with invalid xHTML and almost none of the detail will give you frustration and the customer service would be better off noneixsting because then it'd be at least clear what's on. There is one thing to do with TemplateMonster: avoid. Support those who work with Drupal, for Drupal!

Just today I could read that

Beginning with ignorance of major programming paradigms that make for secure and scalable web services (e.g. model-view-controller), and what amounts to criminal negligence in the design of a basic hook and trigger system.

and

Although I haven’t used it, Drupal sounds like Wordpress on steroids, with an attached boat anchor to slow you down.

now hear me: I do not care and I do not even want to know.

In short, htmlbox is best currently, NowPublic will contribute back numerous fixes and will deploy it on its production servers tomorrow or so. Research done mostly by Balázs Nagykékesi for NowPublic.

So far, Google has sponsored Jakub Zygmunt and Thomas Ilsche in Summer of Code 2005 to create the simpletest module in the first place. Summer of Code 2006 saw Rok Zlender writing the automation framework. And then came the Highly Open Participation Contest, smartys has written two tests for core, Charlie Gordon written also two and Jimmy Berry has written, huh, seven :) And then Google sponsored Charlie and Jimmy so they were able to come to Paris. And so now we have simpletest in core...

As numerous others are blogging about all that's done, I can concentrate on one thing: unit testing. As the unit testing plan on Drupal.org says

To perform unit testing each function needs to be isolated from all other functions. To do this all "sub calls" to other drupal functions need be located and each drupal function needs to be overridden to return a static value. The current plan is to use runkit.

.

And because of that we need Drupal specific theme sites like http://www.topnotchthemes.com and not generic template sites like Template Monster selling you an oversimplified template that's so simplified it's unusable.

Edit: oScommerce users have already been burned. Beware!

We all make mistakes; that's how we learn. Sometimes, though, we need someone to point out our mistakes, to sift through the chaos that is Drupal's contributions repository. Inspired by jpoesen's comment on Morbus's code quality entry, Morbus and I have taken up the task of giving some tough love to Drupal's greatest strength: the army of developers using its APIs. Want your own code publicly reviewed?

If you suppose that Drupal growth is linear (it was always faster than that) and then crunch the numbers in webchick's Drupal 6 announcement then you will quickly see that we will need to deal with about 1200 contributors and 20000 patches for Drupal 7. If we want to keep up Drupal quality this needs automated testing. We are past the point where a few fanatics (catch, webernet and webchick, mostly) can click around to find obvious glitches.