We have done 2 D7 sites so far, and over 50 D6. However, there is so much already done on 6 that we can roll out D6 sites much quicker for our clients, at much lower cost, for all but the most simple brochure sites. The reason? There are still a ton of very useful modules that are not yet available for Drupal 7 - and many that are not even close.ĭrupal 7 is a far better platform to develop on. Anybody who has built a Drupal site starts out with the big question: what version should I use?ĭrupal 7 isn't yet the slam-dunk answer. And we're still building most of our sites in Drupal 6. Version wars.ĭrupal 7 has been out for 10 months now. So our assessment: Security issues are no longer worse than most other available languages, caching can mitigate some of the lack of threading (and it does make it a lot easier to program), and Drupal works around the lack of UTF-8 support with its own functions (but why should it have to?). We've had UTF-8 for way over a decade now, but PHP cannot accurately tell you the length of a Unicode string? This is supposed to be fixed in PHP 6, but for the time being, this means doing much localization work in PHP involves having your own string management functions. Drupal does not really have a way of registering functions that implement hooks - it does cache many of them, but not all. Lack of long-running threads, worker threads, or other things along those lines means that a huge percentage of the Drupal framework needs to get loaded on every request - it can't just sit there in RAM waiting to get called. I would really call out 2 weaknesses of PHP: no threading/inter-process communication, and very poor Unicode support. But PHP has kept the reputation for having shoddy security baked in. Historically it has had a slew of security problems due to a bunch of convenience things that went so far as to conveniently include remote code in every request, if you passed a certain GET parameter! These are pretty much a thing of the past - PHP 5 did away with most of the glaringly easy ways to hack PHP sites. I actually really like coding in PHP - it's easy to learn, easy to understand, and pretty powerful. But this does mean you need quite a bit more hardware to run a large site than you would with a static site or a leaner, more efficient framework. If you only have a couple GB of RAM available, you could run out with 20 active requests.įortunately, hardware is relatively cheap, and with the various caching strategies we typically use with Drupal, we can get sites speeding along. Generally we need to allow PHP to use at least 128MB per request, and on some large sites running lots of modules, even more. On low-end commodity hosting, there may not be enough RAM available for the web server to load a large Drupal site. Since PHP is process-based and doesn't have any long-running threads, this means there's a performance hit. This power comes at a cost - Drupal has to load every single enabled module on every single request to see if it implements a necessary hook. All a developer has to do is follow a specific naming convention, implement a specific hook, and the code gets auto-discovered and called in the appropriate spot. Under the hood, Drupal has a really powerful hook system, which auto-detects and auto-loads functionality. Here are our top 6, and why they're not enough to keep us from recommending and using Drupal for nearly all our work: 6. There are some very legitimate downsides to Drupal from a technical perspective, however. A couple weeks ago I wrote a post on why customers complain about Drupal - the short version is that they either had incorrect expectations, or "developers" who were in over their heads.
0 Comments
Leave a Reply. |