In Drupal 8, besides settings.php I would like to see a non-PHP settings file, writeable by the webserver. settings.php would contain the secrets, the database settings, site key etc but most things that are variables now would become settings, loaded from a file. This would avoid the chicken-egg problem of how to load settings that are required to get to the database? In Drupal 8 we want to have plugins (like the cache in D7 just more generic) and this would provide an excellent place to put the plugin registry.

Drupal is in the business of throwing the doors wide open so setting bear traps beneath the windows is wasted effort. In other words: I am not going to oppose any OOP in Drupal 8 as long as no more protected keywords are added and the current ones are removed.

Much to my surprise, someone decided to warm up the old debate about field storage, stating that Drupal 7 will be much less performant because of it. That Drupal 7 is a little slower than Drupal 6 is true, but that's not because of how we store fields (rather because the increased use of rendering) and it's not a terrible slowdown either (one can say it's a win when used wisely because of the render cache).

Drupal 6 modules typically defined their own tables, had their own code to maintain them and then used nodeapi to hook into the system. Or, defined node types but still maintained their own tables. In Drupal 7 instead you should just create fields, instance them on node types you want to work with. Instead of altering a form directly you can write a widget. Display your data with a formatter. Don't worry about data storage, field API handles that for you. And then there is the EntityFieldQuery class to help with finding things.

Continuing from the Scraping webpages with Python and QWebElement post here is the second in this series where finally a real search happens.

#!/usr/bin/python

# These lines will get us the modules we need.
from PyQt4.QtCore import QUrl, SIGNAL
from PyQt4.QtGui import QApplication
from PyQt4.QtWebKit import QWebPage, QWebView
import pprint

class Scrape(QApplication):
  def __init__(self):
    # Apparently there are a number of versions of this init and PyQT

The Drupal community is remarkably not sexist and yet... Yesterday, Dries' keynote, alas, had a sex scandal slide which probably just wanted to be a (rather tactless and tasteless) joke but it had rather sexist undertones which have managed to piss off a number of women. But, my frustration is not just from the keynote but the reaction, let me quote two tweets here: "Woman on stage at #drupalcon, Dries can have his sextape in 2010." and even more importantly, from someone who retweeted it and got called out for it "Don't take it so seriously. It was a joke, right?" Now, head over to http://rocktreesky.com/reacting-sexism and you can see that three years ago (exact to day) the documentation team leader of Drupal have written exactly, word-for-word about this. It is absolutely unacceptable behaviour and not a joke to degrade women who have made DrupalCon possible for you to sex objects. As Addi noted in her linked blogpost, sexism won't stop just because we write about it, however, I hope this accident will actually make the community even more refusing about sexism and it will be unnecessary to write about it for at least another three years and we can work together on releasing an awesome Drupal 7, 8...

Let's say you have an UPDATE query which uses old values to calculate new ones. The best example for now is swapping two columns: UPDATE table SET f1 = f2, f2 = f1. There is one SQL engine as far as I am aware where this breaks: MySQL (it works on PostgreSQL, SQLite and MS SQL). On MySQL, f1 and f2 both will have the old value of f2 instead of swapping.

While Drupal 7 has been quite long in the making, it's going to be very different from every release before: we have added tests that make sure core works well. (BTW it took quite some time to write so many of them!) This allows the core developers to focus their attention on deeper problems which are much, much harder to fix. Instead of "OMG node preview is broken!" we now contemplate "you know, this new File API is great, but it won't work well with Amazon S3 because..."

Everyone knows I am not too fond of OOP. And yet, I had some role in crafting DBTNG. I now admit: DBTNG in its current implementation is a mistake. Making the stream wrappers a class -- although PHP mandates that -- is a mistake.