Deprecated - Drupal core

I am concerned by the use of static variables to cache data. While they are not permanent from execution to execution, there is no way to clear this "cache" during an execution.

Example: Taxonomy.module

The function taxonomy_get_vocabulary gets a vocabulary from the DB and then stores it in a local static variable by vocabulary ID. However, if the vocabulary is updated and another function later calls taxonomy_get_vocabulary, a stale value will be returned.

I have been going thru the modules listed in cvs and loading and testing them on cvs build (only the ones I have some interest in). This is a work in progress. No obvious core bugs yet, but have not used many features yet. Hopefully these tests won't show any new core bugs.

Is the Forms API a moving target?

After grabbing the latest CVS I discovered that a module I wrote last month didn't work after a submit. Browsing the CVS I found out that the function drupal_submit_form() was changed and that a new form directive called #redirect was added. (form.inc Rev 1.67)

looking around in the DB tables for my (4.6) drupal site using the dba.module, i noticed that drupal is currently doing something very ineffecient for storing the different revisions of each node. the "node" table just has a longtext field called "revisions", which contains serialized copies of the entire node for each revision. looking at the DB schemas for 4.7, i see that things have changed (there's now a "node_revisions" table), but it seems like once again, we're storing the entire node (with separate fields for the teaser and body) for each revision. for nodes with lots of text that are edited frequently, this becomes a huge waste of space in the database. while i haven't done any benchmarking, it's probably slow as hell to unserialize and process all that data once the number of revisions gets big, too (4.7 seems to have at least solved this part of the problem).

my first thought was "why doesn't drupal just record the diff in the DB, like most revision control systems do?"

then i had a (potentially) better idea... why doesn't drupal just use a real revision control system for this? it seems like a collosal waste of time for the drupal development community to reinvent a tool that other people have already made (a far more powerful and mature version of that tool than we've got, for that matter). wouldn't subversion itself be a nice fit for a backend to store the body of any node that has been configured to save revisions? the "revisions" field (or a row in the 4.7 node_revisions table) would just hold a new svn tag identifier for each unique revision of a node (tagging is nearly instantaneous in subversion, unlike cvs). since all nodes have a unique nid, we could use a simple convention for the filenames that each node's body were stored under. we'd still cache the most current revision in the node table, both for performance and for compatibility with all the existing modules and APIs. however, the parts of node.module that are trying to store or retrieve a given revision could just run some svn command(s) to either retrieve or commit and tag a given revision of a given node.

Hi,

can someone explain why the following values where choosen by default:

I want to use Drupal with multiple installations running off the same code base. This will be on a multi-user server where many people can log in (shell access) and write scripts (php and cgi). This means that the web server may never own files that make up the content of any site. (We cannot risk having such files deleted or modified by other users' scripts.)

How can I