Currently, various modules within core and contrib use various tables to store historical (i.e. "write once, read sometimes, never update") data. The most obvious is the watchdog table, but others exist, including accesslog, and zeitgeist's eponym table.
Would you like your non-english Drupal site to be more responsive ? I just found two-minute hack to speed it up, by a factor of four on the new Riff hosting. Here's how.
While revising devel.module in order to update the french translation, I noticed the queries performed by locale() took on the order of 20ms to be performed, and there are a whole lot of them on most pages when locale.module is enabled.
Since this seemed abnormally slow, I looked at the structure, and saw why. The current MySQL code goes:
In the recently introduced Drupal RC2, a pair of new functions have appeared: theme_search_block_form() and theme_search_theme_form(). They replace the ephemeral (some said "Easter Egg") theme_search_box() appeared and disappeared between RC1 and RC2, and raise important issues for themers.
The recent removal of the quasi-official node_validate_title() function from 4.7 causing various errors with contrib modules, I wondered whether there wouldn't be a way to trap such errors in a way that would be helpful to newbies, instead of the current situation where all they get from their newly haphazard drupal install is a PHP fatal error.
The idea, then, is to register obsolete functions in some form of legacy maintenance module, to generate a useful help page pointing the user to a doc page on drupal explaining why there is an error in his configuration and what he should do. In node_validate_title()'s case, the help is a bit succinct: http://drupal.org/node/22218#node_validate_title.
Find the shiny new release candidate on http://drupal.org/drupal-4.7.0-rc1
Why am I mentioning it here ? Well, much like many others, I contributed bug reports, some patches, and it's great to see the project actually nearing its 4.7 landmark.
Maybe it will even allow the new version of Riff News to go online in time.
A few days ago, the designer working on our sites asked me stats about the browsers visiting the sites. She already had the general data available, but this time what she wanted was the info about the "other" browsers.
Which is quite true: once a site has been designed to standards and the quirks of the two or three major choices, work has to be spent on the non-standard non-mainstream ones. But to what extent ? Here are the data.
As I've been working with Drupal since last august, a recent discussion with the designer for our new sites made me wonder how the cost of time was distributed during a project like this one. What portion of the time has been spent getting up to speed on Drupal itself, on developing/maintaining Open Source modules, on creating the value-added private code, on miscellaneous tools and integration tasks, and eventually on the content itself. Here are the results:
Zend Studio is a convenient environment to code in PHP, which is why many Drupal developers are using it. But some settings are necessary to ease its use, due to the specific extensions Drupal uses.
Ofttimes, when developing a site, you can be led to create or import a large number of custom nodes, for instance flexinodes, only to have to delete them later on. Doing it by hand in admin/content is inconvenient when the number of nodes is large, and for custom nodes like flexinodes, the exact entries to delete in the various Drupal tables may not be obvious. Time for a workaround.
Are you aware of what you're pasting from a browser's rendition of a page ?