- 2014-03-27: MongoDB Watchdog module ported to Drupal 8 at the Szeged Dev Days.
- 2014-01-26: My post on the Symfony web profiler in Silex selected in Week of Symfony. w00t !
- 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
- 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
- 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
- 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ?
Bets are onLater
The problem : Drupal awfully slow on Vista (and Seven) with Wampserver
For some time now, I'd been severiously annoyed by the (utter lack of) performance of Drupal 6 and 7 on my home PC, which happens to be running Microsoft Vista: considering I was used to getting page times around 200ms on a fractional Celeron with Apache 2.2 on a Linux server hosted comparatively far across the net from that same machine, I felt the 5 to 15 seconds response time per page on this local machine with a quad core and 3 GB RAM were really making me lose my time.
After some time spend googling around, I stumbled upon an incredibly simple tip, which made the 5 to 15 seconds per page drop down to around 1 second when logged in, and well below 500 ms when not logged in. It's incredible what ONE single character in a plain text file gets you under Vista :-)
UPDATE 2010-01-23: David Hogg tells us (see below) that this works for Windows Seven too
So at long last, GW8 is becoming reality :
As a long time developer on GroupWise (hey, I did this even before I started on Drupal !), I'm glad to see the product evolve. And already a planned upgrade for a customer :-)
Now, if I could find a project merging both... to this day, I've only used Delphi, both with OLE and SOAP, to communicate with GW.
Having to use Trac instead of our usual Drupal Project* setup for a new Drupal project, I just found out a problem which perplexed me for a moment: after following the instructions from the Trac site for a very basic setup, without SVN integration, all seems to work well, up to the point where I started the server.
# tracd --port 8000 /var/www/trac/proj1
... and went to my browser to http://www.example.com:8000/ only to receive an almost empty page, just saying "Available Projects" and nothing else. No error during
trac-admin initenv. And the page was well-formed, showing it was likely not an actual bug.
Googling around the problem showed the issue to be already known, but offered no hint about the solution. What could be wrong ?
If all of a sudden you notice that the
SELECT elements in your Drupal forms increases to 4 and any smaller size is ignored...
... maybe you've already forgotten you were using Chrome, and it is not a Drupal bug : this is a "usability" feature of WebKit. See http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderListBox.cpp#L67.
Safari users are probably used to it, but for users of other browsers, this is a bit disconcerting.
Using a graphics library, be GD, ImageMagick or anything else, is convenient, but carries a price to pay: unlike most Drupal parts, which are generally database-bound, image generation is typically CPU-bound: generating many images on the fly can significantly increase the CPU load on a system, while Drupal setups are typically not optimized for this, and could result in problems if you are using Drupal on a shared hosting account. So what ?
previous post, we saw how to create a XHTML progress bar widget for Forms API, using
theme_progress_bar. The next logical step is now to create a graphical equivalent to that progress bar, as an example for far more advanced fully graphical widgets made possible using a similar mechanism.
Wouldn't it be nice to have that progress bar available as an extended version of
markup that would graphically display a value in your forms without stuffing it in a
markup element ?
For some reason or another, I've noticed several new Drupal developers these last few days sweating on Forms API, and thought it would be nice to have a smallish example to complement the unavoidable FAPI reference and Guick start guide, for a typical non-basic form: one including set of checkboxes in a table, with a customized display, like the core user, content or modules administration forms. So follow me while we build this example.
Roughly two years ago, I prepared a diagram of the dependencies in the then-current version of Drupal e-Commerce (eC) for Drupal 4.6.
Now, with other eC projects looming ahead, a possible session about eC at Szeged, and eC 4 being in alpha, I figured it was time to update the model. Boy, has it changed ! Click the thumbnail for the full-size view.
If you are [considering] working on an e-Commerce site, and are coming to the Szeged Drupalcon, you may be interested in several sessions around the theme. In order for your session(s) of choice to stand a chance of being actually part of the conference program, you should vote for the sessions you would like to attend.
Subjet to approval by the conference board, I will be animating/presenting a session about the internals of the e-Commerce suite: see http://szeged2008.drupalcon.org/program/sessions/developing-e-commerce for more details. If this is of interest to you, vote on the session to make sure it will indeed be included in the conference program.