Deprecated - Drupal core

Frankly drupal's file handling is in need of serious love. I know several people have taken stabs at it... I'm hoping this thread will create a space where we can discuss/document what we want for file handling in 4.8/5.0. I've been giving this a lot of thought lately.

What I've had on my mind....

1) Why files should be independant of nodes...
I would love to see everything in drupal be a node, but I don't think we can really get away with that where files are concerned. a) we do not store their contents in the database. b) we need a fast path like alternative for private downloads to avoid the full drupal boot strap when delivering local files.

2) all files table functions be moved into the file.inc/File API, and to redefine the file api...
file_upload - saves newly uploaded file to Drupal's tmp dir.
file_save($file,$dest) - copies file into Drupal's file area - INSERTS into files table.
file_copy($file,$dest) - copies file to destination - INSERTS into files table.
file_move($file, $dest) - moves file to destination - UPDATE files table
file_derive($file, $dest) - create a derivative file - INSERTS into files table, parent = $file->fid
file_delete($file) - remove file from file system.
file_download($path) - send file to user.
--convert upload module to just manage file<->node relationships...

3) Fastpath file downloads. Store a download key in the database when a file is rendered as a private file

The following error appears in function Search:

Access denied for user: 'BLUBBER@111.122.4%' to database 'BLUBBERDB' query: CREATE TEMPORARY TABLE temp_search_sids SELECT i.type, i.........

Seems that the IP address in USER is not complete somehow, or is 4% a normal behaviour?

Fact: I do not have the rights to create a TEMP TABLE at my DB provider. I would like to change this to a static TABLE for the search.
How to do that and/or I would like to see this as a core setting (TEMP or STATIC).

Any help here?

RaRi

Cross posted from http://www.angrydonuts.com/practical_growth_how_to_implemen

I should’ve written this up last month sometime, as it mostly results from conversations I had with JonBob and jvandyk over above average but not exactly stellar Thai food in Vancouver.

Drupal’s growth rate has reached the point where individuals testing individual bits is no longer keeping up with the other problems that the type of patching we do can cause: the problem, of course, being that one change here can break something seemingly unrelated over there. This kind of problem exists on almost every type of software, but previously I believe the methodical nature of patch committing by Dries and Steven has helped to mollify it somewhat, and the general smallish nature of patches being committed have made it easier to see what might happen.

Drupal’s growth is skyrocketing, though, and major changes have been put in and are coming in the future.

During the google Summer of Code, which is almost but not quite before my time with Drupal, a student wrote a simpletest module, and populated it with some tests. Moshe, at the very least, still works with this somewhat, but it’s been some months before the project’s been touched. And for simpletest to be useful, it needs to be very, very important to the development process.

Hi, I added two settings to user.module, giving a little more control over the distributed authentication.

- Textfield 'Default Auth Server': A server to authenticate against if
a) the username entered does not contain the @ sign and there no such local account
b) the setting 'restrict to default server' is set. This will make Drupal ignore anything
after @ in the login and force the usage of the default server.

- Checkbox: 'Restrict to default server': Forces authentication against the default server even if the
user enteres something like user@example.com into the login box.

Local accounts always take precedence. The admin account is local after all and we don't want to be locked out of our site, do we? Works for me with distributed auth via jabber.module.

YMMV. Comments and suggestions welcome.

-silence


854,857c854,862
< // Strip name and server from ID:
< if ($server = strrchr($name, '@')) {
< $name = substr($name, 0, strlen($name) - strlen($server));
< $server = substr($server, 1);
---
> // Handle distributed authentication
> list($name, $server) = explode('@', $name);
>
> if(variable_get(only_default_server, 1) &&
> (variable_get(default_auth_server, '') != '')) {
> $server = variable_get(default_auth_server, '');
> }
> elseif(($server == '') && (variable_get(default_auth_server, '') != '')) {

I just upgraded my operating system to Mandriva 2006.0.1 (previously on Mandriva 2005 LE). My Drupal site stopped working, but other static pages on my site were still functional. Also, pointing to the Drupal folder with http://mysite/ would not serve up an index.html, but I explicitly included the name of the file in the URL, it would appear.

My new configuration consists of: Apache 2.054, PHP 5.04, MySQL 4.12, and Drupal 4.65.

I have an account, for testing porposes, in a free webhosting provider that put a top banner on each page that has a little js with an winodw.onload event.

This bug was described in http://drupal.org/node/31755 and http://drupal.org/node/27884, and it's still a problem in 4.7 beta 5.

My thought about this was to put in an

$conf = array ('can_collapse' => 'FALSE');

or a

$can_collapse := FALSE;

in settings.php and an if statement in form.inc, in order to disable that collapsible sections, when needed. This sounds reasonable?

thanks in advance

Gustavo