July 2006 - Development - lists.drupal.org

File transfer patch by Arto Bendiken
by Boris Mann 21 Jul '06

21 Jul '06

Just wanted to post a pointer to a file transfer patch made by Arto Bendiken (a name you might recognize from a large static page caching module: http://bendiken.net/2006/05/28/static-page-caching-for-drupal or the infamous Drupal vs. Mambo article: http://bendiken.net/ 2006/02/08/drupal-vs-mambo). See http://drupal.org/node/74472: > This is a simple & short patch against HEAD that adds a new file > download method, "Custom", to the admin/setting/file-systems > screen. With "Custom" selected, the "file_transfer_handler" > configuration variable is expected to contain the name of a > function that will handle the actual file transfer, and > file_transfer() (in includes/file.inc) is modified to delegate the > transfer process to that function. We were working together last week and my small contribution was to lean over his shoulder and go "hey -- can't we abstract that?". This should make it possible for implementing some alternate file transfer methods -- like my current personal favourite, Amazon S3. Cheers, -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com

1 0

Minimum required for a login
by Chris Puzio 21 Jul '06

21 Jul '06

I need to be able to manually force a login without using the login subsystem. I was wondering if anyone knew the minimum needed to consider a user 'logged in'. It looked to me that setting the $user variable was key but I wasn't sure what else was necessary - and if its possible to do outside of the framework just by setting certain variables. Chris Puzio

3 2

DrupalCON Europe, call for suggestions
by Dries Buytaert 21 Jul '06

21 Jul '06

Please post your suggestions, motivations and ideas at http://drupal.org/node/74812 Thanks! -- Dries Buytaert :: http://www.buytaert.net/

1 0

[development] RFC: new perspective on issue tracking, source control, and Drupal
by Derek Wright 21 Jul '06

21 Jul '06

request for comments: http://groups.drupal.org/node/1047 "Trac, JIRA and Drupal: integrate, don't reimplement" thanks, -derek (dww)

1 0

Wizards, multi-part forms, and you
by Jeff Eaton 21 Jul '06

21 Jul '06

Time for some shameless patch pimping for Drupal 4.8/5.0. FormAPI has made lots of things much much easier, but has also made other things harder. Namely, dynamic forms that are built based on user input, or that submit to themselves and add additional fields. (building them is easy, but validation, submission, etc gets incredibly complicated.) <http://drupal.org/node/74660> http://drupal.org/node/74660 aims to simplify that process for modules that need very complex multi-step forms. It breaks up the currently-monolithic drupal_get_form() function into bite sized ones like drupal_build_form(), drupal_render_form(), and so on. drupal_get_form() continues to work as it always has, but modules in need of complicated multi-step and multi-form processes can sidestep it completely, using the more granular functions. This has always been possible, but it required copy-and-paste re-use of almost a hundred lines of code from drupal_get_form. With this patch, it's easy for those who need it and transparent to those who don't. Reviews from any formapi gurus much appreciated. --Jeff

3 2

Re: [development] Have you ever laughed fate in the face?
by Chad Phillips -- Apartment Lines 20 Jul '06

20 Jul '06

On Jul 20, 2006, at 11:26 AM, Dries wrote: > My problem with the trashbin patch is the way it works. I'm not > convinced that it should transfer deleted records to a dedicated > table. Right now, the trashbin patch stores deleted records in a > separate table in serialized format. not exactly. there is no serialization involved. the deleted_data table stores data one row per column for each row of data deleted from the table. kind of expensive for large deletions, i know... > This is a little bit awkward as it has to circumvent the auto > increment IDs or the sequence table when re-injecting the data. correct, although i haven't seen that to be a problem, since we never go backwards. the data slips right back into where it was. > > Why don't we add a status-field with two states -- STATUS_ACTIVE > and STATUS_DELETED -- to each of the database tables with records > that want to take advantage of the trashbin functionality? Then, > the trashbin patch might be a lot easier to grok -- and from an > architectural point of view, less awkward. It wouldn't be > particularly clever but that is OK: it is super-easy so there is no > point being clever to begin with. I'd like to see us explore this > path instead. this would be great, but as i've said before we'll need an SQL query engine in core (or at least functionality that can handle all of the ins and outs of filtering out the deleted data automagically, but allowing access to it when necessary, etc.). also, i think we need to consider how contrib modules will interact with this. will we require a status field in all database tables, or maybe have core auto-add one if it's not already present? the current approach while a little awkward is able to work around all of this. > > Plus, this has a number of advantages. Most of all, we'd still > able to query deleted data. For example, the filter form on the > administer content page (?q=admin/content) would allow us to access > delete nodes and we'd be able to use advanced query methods like > 'show all deleted nodes from user Joe with the taxonomy term > 'Apple'. That is, we get to reuse a lot of the existing UIs and > modules. yes, this would be great as well...

1 0

DrupalCON Europe
by Dries Buytaert 20 Jul '06

20 Jul '06

Hello, as you might have read, we started planning this year's DrupalCON Europe. We're currently looking for a venue, and would like to know what the 'ideal setup' looks like in terms of meeting rooms and presentation rooms. Please share you ideas at http:// groups.drupal.org/node/363#comment-1371. Your input is required to move forward. -- Dries Buytaert :: http://www.buytaert.net/

2 1

Drop MySQL 3 support
by Gerhard Killesreiter 20 Jul '06

20 Jul '06

Hi there! MySQL AB (the company behind our most used database) has announced a change in support options for their database products. http://www.mysql.com/company/legal/mysql_lifecycle_policy.pdf According to this document, the active support for MySQL 3.23 will end at the last of this month (ie on two weeks) and the extended support will end on the end of this year. I therefore propose that we formally drop support of MySQL 3 as of Drupal 4.8 which will appear later this year. MySQl 4.0's active support will end the last of September, we could consider dropping support for it too. Extended support will run until the end of 2008. Dropping both MySQL 3 and 4.0 would enable us to rewrite some parts of our SQL queries. The extend of this would need to be researched. I know that people will argue with "but there are so many ISPs that still run 3.23". ISPs that still run 3.23 after it has been retired by the supporting company are probably not worth the money you them. Cheers, Gerhard

17 20

Re: [development] Deleted records [Have you ever laughed fate in the face?]
by Chad Phillips -- Apartment Lines 20 Jul '06

20 Jul '06

On Jul 20, 2006, at 6:00 AM, Farsheed wrote: > How is this different than "unpublishing" a node? > Perhaps the Delete button should become an Unpublish > button. > > Then an admin would use the regular admin interface if > a node needed permanent deletion. that accounts for node data, but what about other kinds of deletions? how are they to be handled?

1 0

Re: [development] Deleted records [Have you ever laughed fate in the face?]
by Chad Phillips -- Apartment Lines 20 Jul '06

20 Jul '06

On Jul 20, 2006, at 6:00 AM, sime wrote: > So just for the record, I would like a "deleted" column in Drupal. i would love to do that--it would be a far more elegant approach than the current trashbin code uses. but after a lot of analysis, i concluded that without a proper SQL query engine in core to pass things through, it would be a mess--especially considering that contrib modules don't have the same strict requirements as core...

1 0