Deprecated - Drupal core

The current code contains:

function db_query($query)
	{
	$args = func_get_args();
	$query = db_prefix_tables($query);
	if(count($args) > 1)
		{
		if (is_array($args[1]))
			{
			$args = array_merge(array($query), $args[1]);
			}
		$args = array_map('db_escape_string', $args);
		$args[0] = $query;
		$query = call_user_func_array('sprintf', $args);
		}
	return _db_query($query);
	}

$args = array_merge(array($query), $args[1]); could be reduced to $args = $args[1]; which would reduce processing the array merge and in the array_map. The query string could be reintroduced by replacing $args[0] = $query; with array_unshift($args, $query);.

The result would be:

function db_query($query)
	{
	$args = func_get_args();
	$query = db_prefix_tables($query);
	if(count($args) > 1)
		{
		if (is_array($args[1]))
			{
			$args = $args[1];
			}
		$args = array_map('db_escape_string', $args);
		array_unshift($args, $query);
		$query = call_user_func_array('sprintf', $args);
		}
	return _db_query($query);
	}

There are four major changes in the queue for the upload and file system (That I am aware of). This page summarises them, but please have a look at the patches and proposals ,and add your voice or vote. If you are interested in improving the file and attachment handling, that is.

Shouldn't this:

$result = db_query(db_rewrite_sql('SELECT n.nid, n.title, b.parent FROM {node} n INNER JOIN {book} b ON n.vid = b.vid WHERE n.nid = %d'), arg(1));

Notice: n.vid = b.vid

on http://drupaldocs.org/api/head/function/book_block

Read Like This?

The objective here is to keep IO costs at the minimum..... so

Been wondering about the process flow of drupal and its modules and it appears that the core iterates thru its modules too many times and thus 'slowing down' the whole 'serving' process.

try it yourself - put drupal_set_message("Module X loading"); at th top of any of your modules and ...

The people at MayFirst.org have created a utility which lets you create static file copies of a Drupal home page, and the most recent 20 nodes (pieces of content). It's called "Drupal File Cache Generator" (dfcg) You can see the various files for this utility at:

• http://www.benslade.com/drupal/dfcg/
  (php files were given a .txt ending to make them displayable)

You can also see a high volume site that's using this file cache utility at AfterDowningStreet.org

I got very little (read: NO) interest when I posted on this topic earlier with a different phrasing. So, here's my second shot at this.

I propose that there is a problem with the ways that program function URLs are written in Drupal, that causes Drupal to be a disproportionate target for trackback and comment spammers.

The problem with comment and trackback spam in Drupal is this: It's too easy to guess the URL for comments and trackbacks.

In Drupal, the link for a node has the form "/node/x", where x is the node id. In fact, you can formulate a lot of Drupal URLs that way; for example, to track-back to x, the URI would be "/node/x/trackback"; to post a comment to x would be "/node/x/comment". So you can see that it would be a trivially easy task to write a script that just walked the node table from top to bottom, trying to post comments.

Which is pretty much what spammers do to my site: They fire up a 'bot to walk my node tree, looking for nodes that are open to comment or accepting trackbacks. I have some evidence that it's different groups of spammers trying to do each thing, but that hardly matters -- what does matter is that computational horsepower and network bandwidth cost these guys so little that they don't even bother to stop trying after six or seven hundred failures -- they just keep on going, like the god damned energizer bunny. For the first sixteen days of August this year, I got well over 100,000 page views, of which over 95% were my 404 error page. The "not found" URL in over 90% of those cases was some variant on a standard Drupal trackback or comment-posting URL.