January 2007 - Development - lists.drupal.org

About CSS3
by Steven Wittens 05 Jan '07

05 Jan '07

Drupal 5.0 will be the first Drupal that includes some CSS3. Several people have brought up concerns or 'bug reports' about this. Facts: - CSS3 is a huge standard which is still in draft form, although many parts of it haven't been changed in the past couple of years. It consists of several modules, which are usually independent from each other. - Several parts of CSS3 are already well supported by some (e.g. 'display') or even all the major browsers (e.g. 'opacity'). - CSS has always clearly specified how parsers are to deal with unknown styles. e.g. Setting "bunnies: fluffy" or "display: foobar" should not have any effect in any modern browser, as it is not part of any CSS standard. Both rules are treated as if they weren't there at all. - The W3C provides a CSS3 option in their CSS validator, showing that they promote active use of the spec. With that in mind, I'd like to set an official policy on CSS3 in Drupal, namely that we allow it. By definition, it should not cause any problems in older browsers, and it can be used to provide extra UI cues (opacity for disabled items) or nice style enhancements (e.g. text-shadow in Garland, for Safari). The only big problem for now is that some of the CSS3 throws a warning in Firefox's debug log (e.g. "display: inline-block" in core). While annoying, this is IMO Firefox' fault, not ours. Especially because Firefox is happy to accept the other CSS3 in Garland (e.g. "opacity: 0.5"). It is also only visible if you have some sort of development tools active. It seems most of the reactions against this are knee-jerk: "Drupal doesn't care about valid CSS" or "What's this scary error message?". IMO this is the price to pay for progress. Drupal is still sticking to a standard, and one which has real-world implementations. Objections? :P Steven Wittens

10 13

hook_nodeapi()
by Fernando Silva 04 Jan '07

04 Jan '07

Hi, In the following page http://api.drupal.org/api/HEAD/function/hook_nodeapi it says: "If you are writing a node module, do not use this hook to perform actions on your type of node alone. Instead, use the hooks set aside for node modules, such as hook_insert() and hook_form()." My question is why is it better to use the standalone functions instead of the centralized one? Regards, Fernando Silva

13 25

Slow query log
by Gerhard Killesreiter 04 Jan '07

04 Jan '07

Hi there! Today i had a look at drupal.org's slow query log after I found out it is collecting data. Note that the slow query log now also contains queries that don't use an index, no matter how fast. There were 2 queries responsible for about 2/3 of the entries. One is the query from drupal_is_denied, which is run on each bootstrap. This query has been improved for Drupal 5, but I think it coul dbe further approved by doing away with the two LOWER()s in there in case you just check an IP. The other one was the harmless looking query: SELECT * FROM files f INNER JOIN file_revisions r ON f.fid = r.fid WHERE r.vid = 38515 ORDER BY f.fid; an EXPLAIN revealed that it did not use any index. The reason is that we have defined its index as PRIMARY KEY (fid, vid). Chris Johnson explained: vid is a constant, and we are ordering the resulting fids. But in a composite key, MySQL cannot use (at least in version 4.x) any of the components of the composite key if the first component is not used. So what I did is to switch the keys around: alter table file_revisions drop primary key, add primary key (vid, fid); Somebody might want to roll a patch or Drupal5. Cheers, Gerhard

6 9

OT: Future of Transactional Engine with MySQL
by Khalid B 04 Jan '07

04 Jan '07

As most of us know, Oracle has purchased InnoBase, makers of the InnoDB transactional engine for MySQL. This leaves MySQL in an awkward position. Although the code is GPL'd, it cannot be sold under a non-GPL license should Oracle change the licensing terms, or the cost of the license. So, MySQL needs another transactional engine. Two have emerged solidDB, via acquisition of the parent company that makes that database http://solutions.mysql.com/solutions/item.php?id=219 http://www.mysql.com/news-and-events/news/article_1206.html And Falcon, which is build by Jim Starkey (ex-DEC, Firebird co-creator). http://www.mysql.org/doc/refman/5.1/en/se-falcon-features.html http://forge.mysql.com/wiki/Falcon So, just a heads up on what is going on. Not clear if MySQL intends to push two engines, or just hedging their bets to see which one pans out.

4 6

how to watch for modules/themes being enabled
by Gabor Hojtsy 04 Jan '07

04 Jan '07

Hi, I am in the process of implementing autolocale module, as you might already know (by reading the development list). This module now nicely imports PO files in install time and can import PO files later for all enabled components (modules/themes) with an optional database cleanup. The next (and for basic operation the last) step is to automatically import PO files for modules/themes enabled on the admin interface. I have tried to look into Drupal HEAD source to quickly solve this issue, but there was no immediate help. The drupal_install_modules() function seemed to be an inviting place, since it knows what modules are being installed the first time. Also drupal_enable() is called for modules previously disabled but being enabled again. None of these "call out" with a hook to inform possible evesdropping modules that a new module is installed or a previously disabled module is being enabled again. My autolocale would however would love to get informed. I also looked into themes, and found that the logic enabling themes is in system_themes_submit(). Interesting fact that the block initialization is wired in, because block module cannot watch for a theme being enabled (lines 1198-1201): "If theme status is being set to 1 from 0, initialize block data for this theme if necessary." After all it seems that my only option is to look for the module/theme list form appearing on the admin screen and alter the form to hook my module to the submit action. When the form is submitted, do the same checks the system.module does to identify installed/enabled/disabled modules/themes, so I know what autolocale should do. Maybe it is not too late to stuff a few module_invoke_all() calls to the proper places so module/theme changes are advertised for modules to watch for. If it is too late, I would be very interested if others faced the same problem and how did they solved it. Gabor

8 21

Porting - Quick security reminders
by Heine Deelstra 04 Jan '07

04 Jan '07

Dear all, Porting a module is an excellent opportunity to keep an eye out for security problems (evidence: <http://drupal.org/node/103943>). Here's a quick security reminder regarding input (user-supplied data). Code samples are only included to make a point, do not hold them against me. Escape or filter text before display ==================================== If you do not escape or filter text before display, you enable a user to insert arbitrary HTML and scripts into pages. This type of attack is know as cross site scripting aka XSS. For more information, see: <http://drupal.org/node/28984> Escape / filter: - check_plain or theme('placeholder') for plain text - check_markup or filter_xss for markup containing text Drupal 5 brought a (brilliant IMO) change to t(): Depending on the placeholder's sigil, it is passed through theme('placeholder') (%) or check_plain (@) automatically. t('I escape %user_data', '%user_data'); // I escape <em>user_data</em> (safe) t('I escape @user_data', '@user_data'); // I escape user_data (safe) t('I don't escape !user_data', '!user_data'); // XSS vulnerability Sometimes the difficult part is to know whether a function requires escaped text or does the escaping itself: * Automatically escapes: l() - Escapes text and attributes unless you pass TRUE for the $html parameter. In that case only attributes are check_plained. - menu items & breadcrumbs - block descriptions (*not* titles) - theme('username') * Common pitfalls: watchdog - you have to provide a safe $message drupal_set_title - you have to provide a safe $title Form elements - #description and #title of form_elements need to be safe Form elements - #value of #type markup and item need to be safe. Note that the default form element #type is markup! Examples: drupal_set_title($node->title); // XSS vulnerability drupal_set_title(check_plain($node->title)); watchdog(content', t("Deleted !title", array('!title' => $node->title)); // XSS watchdog(content', t("Deleted %title", array('%title' => $node->title)); // or @ $form['unsafe'] = array('#value' => $user->name); //XSS $form['safe'] = array('#value' => check_plain($user->name)); or $form['safe'] = array('#value' => theme('username', $user)); $form['bad'] = array( '#type' => 'textfield'; '#default_value' => check_plain($u_supplied), // bad: escaped twice '#description' => t("Old data: !data", array('!data' => $u_supplied)), // XSS ); $form['good'] = array( '#type' => 'textfield'; '#default_value' => $u_supplied, '#description' => t("Old data: @data", array('@data' => $u_supplied)), ); Database (ab)use ==================================== See also <http://drupal.org/node/101496> Summary: Whatever you do, *never* use user supplied data directly in a query. Use db_query as it was meant to be used: data goes in arguments. And make sure to enclose %s in single quotes: '%s'. BAD, BAD, BAAAD: 1.db_query("SELECT t.s FROM {table} t WHERE t.field = $from_user"); 2.db_query("SELECT t.s FROM {table} t WHERE t.field = %s", $from_user); Good: db_query("SELECT t.s FROM {table} t WHERE t.field = '%s'", $from_user); BAD ($from_user is an array of numbers): db_query("SELECT t.s FROM {table} t WHERE t.field IN (%s)", $from_user); Good: $placeholders = implode(',', array_fill(0, count($from_user), "%d")); db_query("SELECT t.s FROM {table} t WHERE t.field IN ($placeholders)", $from_user); Anything else: bad. Why is this bad? Suppose you check the data that you stuff in to a query (e.g. 'all numeric'). Or, you know a user name is validated to contain only certain 'safe' characters. The problem is that you open the possibility that a code path develops where unfiltered content ends up at your query. In that case you're toast. This code path can arise because you 1) accidentally remove validation in future development, 2) a user adds a module that is more lenient in the data it accepts or 3) you add a bunch of code that skips validation (recent xTracker problem). Writing secure code ==================================== If you want to read more about security, I suggest that you start at "Input the root of all evil" <http://drupal.org/node/101495> in the "Writing secure code" <http://drupal.org/node/62304> pages. I hope to expand and improve those pages in the future, but some of them are already useful. You found a vulnerability? ==================================== What to do when you find a vulnerability in your module? Simple; write us at security(a)drupal.org. Thank you for listening, Heine Deelstra

5 7

Simple XML Import
by Dave Fletcher 04 Jan '07

04 Jan '07

Hi all. I created a quick XML import method and I'm wondering if others are interested in it. This thing defines a simple XML format with tags: drupal (doc element), vocab, term, user, node, comment. It imports each of these things by calling the relevant xxx_save() function. Each of those tags can define a "fields" child element. The children of <fields> are turned into object, array, or primitive values and passed to the save func. Node elements located inside term elements are categorized by that term. The system holds a legacy ID which is mapped to a Drupal ID. It is used to ensure a piece of content is not imported multiple times. Therefore, an XML document can be updated and imported again without causing dupes. The system can also use this ID to reference existing content, for example in a uid field or the taxonomy array. Since it's just calling node_save to do all the work, this system can import custom node types simply by providing the right 'type' field in a node element and providing the fields that the custom node module expects. I have imported 5 different content types using this method: a custom review type, polls, blog (converted the mt2drupal script to this XML format), a custom newsletter type, and galleries. I of course know about Jaza's work on import/export API but it seemed like an overkill solution to me and I didn't want to really learn an API. I just wanted a quick XML format to do some dirty work which I tried to do by hand on the first rev. The XML format mainly allows me to inspect the data before I run the import. So my question for you, fellow Drupallers, is does this sound useful to you? Would it be worth my time turning this thing into a real module? Currently it's a command-line hack that lives in Drupal root directory and bootstraps. It would be neat if there was a module page, an upload form, and perhaps some support functions for creating the XML format from code. Cheers, --fletch

3 3

I unsubscribe
by Karoly Negyesi 04 Jan '07

04 Jan '07

Hi, Apparently it is more important to write mails that make people feel welcome here than to develop and I am actually advised not to read the list or at least parts of it. So, I unsubscribe now and stuck to places where actual development happens: the issue queue and the channel. Yesterday a totally new guy proposed an interesting idea on #drupal and in private and today the patch is submitted. I like this. Still I will post questions/proposals to the list occassionally and read the archives but I am off the list. All the best, Karoly Negyesi

2 2

Please test http://drupal.org/node/106370
by Gerhard Killesreiter 03 Jan '07

03 Jan '07

Hi there, yesterday a bug was fixed in Drupal 5RC, but I'd like to backport the fix to 4.7. I'd also like to release 4.7.5 soon, so some speedy help would be appreciated. It would be useful if people could test the patch on either 4.7 or 5RC sites (for 5-HEAD it is already in cvs) and report back on the issue tracker. Testing is only relevant if you use a node access module such as OG, tac_lite or one of the others. Please report your results on the issue tracker stating the node access module you use. Cheers, Gerhard

1 0

Re: [development] Community, mailing list and IRC (was: I unsubscribe)
by Khalid B 03 Jan '07

03 Jan '07

Karoly Please allow me to respond. On 1/3/07, Karoly Negyesi <karoly(a)negyesi.net> wrote: > > Apparently it is more important to write mails that make people feel > welcome here than to develop and I am actually advised not to read the > list or at least parts of it. It is important (not more important, just important) to welcome and encourage new comers. Correcting their mistakes in a non-confrontational, non-frictional way would most likely cause us to gain one more developer, as well as a better sense of community as a whole, not to mention the community reputation. So, I unsubscribe now and stuck to places where actual development > happens: the issue queue and the channel. Yesterday a totally new guy > proposed an interesting idea on #drupal and in private and today the patch > is submitted. I like this. Karoly, IRC is a valuable collaboration tool, but not for everybody. Others, including myself, find the "everyone talking to everyone" distracting, and just aggravates the ADD ( http://en.wikipedia.org/wiki/Attention-deficit_hyperactivity_disorder) factor. Moreover, IRC is transient. One cannot go back and check what has been discussed, or what drawbacks a certain approach has, ..etc.. Dries has repeatedly stated that IRC is not an official communication channel because of the above reasons. We've also seen some "surprise" decisions for the rest of the community when a small group discusses/decides on IRC and then things are implemented without proper notification to the rest of the community. So, by all means, use it for collaboration and whatever you find useful, but don't make it the sole conduit for everyone else.

1 0