- Development - lists.drupal.org

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

22 Jul '06

On Jul 17, 2006, at 2:40 PM, Neil Drumm wrote: > I think this is a good change. Forgiveness is a good thing to have. > But > it simply can't be added without people looking at it. Same goes for > every other feature. just to put everybody in the loop here: chx and i have been discussing the idea of a deletion API for drupal core, which would address killes' modular concerns as regards this functionality, as well as allow us to break out all the confirm code into a seperate module. what this means is that site admins would have the following options for a deletion workflow: 1. the current scheme: no trashbin, with confirm screens 2. trashbin with confirm screens 3. trashbin with no confirm screens 4. no trashbin, no confirm screens (for those who like to live dangerously!) simply enable or disable either of the confirm.module or trashbin.module to get the desired combination. in addition, the API would provide non-core modules with greater access to the core's deletion cycle (which is currently fairly closed) i've already begun work on this, and my goal is to have this up for testing within one week, if all goes well. in the meantime, i would still love to get reviews of the original trashbin patch, as most of that code will be used in this new API schema. patch is located here: http://drupal.org/node/35422#comment-115495 test site is located here: http://undo.xcarnated.com/

16 32

deletion API summary, question
by Chad Phillips -- Apartment Lines 22 Jul '06

22 Jul '06

as i mentioned a short time ago, i've been trying to flesh out a deletion API for drupal. i thought i'd take a few minutes and discuss it's current state, and throw out some unfinished business to get perspective from other developers. in working on the trashbin patch, i discovered that it's helpful to think of deletions as happening in packages. when you delete a node, you don't just delete something from the node table--there are related node tables, then hook_delete calls, then nodeapi delete calls (and possibly other calls initiated from the last two in that list). deletions in drupal proceed from the top down, recursing until all items are deleted. that's what i'm calling a package. my current work is based on that viewpoint. package deletions are started with a call to a helper function (called drupal_delete_package at the moment), all relevant deletion operations are passed into the package via drupal_delete, and then packages are deleted via another helper function (drupal_delete_execute). once a package is compiled, there are two hooks that are called: hook_delete_pre -- this is an opportunity for modules to throw objections to a package deletion. any module calling this hook will have access to the information in the entire deletion package, and can throw two kinds of objections: confirm and abort. hook_delete_execute -- this is an opportunity for modules to perform any last minute operations before the package is deleted. for example, a trashbin module would use this hook to store metadata about the package deletion. workflow is as follows: 1. call drupal_delete_package to start the package 2. call drupal_delete as many times as is necessary to fill the package with deletion data 3. call drupal_delete_package again if you wish to start a new deletion package in the same page call (like for admin/node multi- deletes) 4. call drupal_delete_execute to execute the deletion of all packages 5. hook_delete_pre is called, and modules put in confirm and abort objections 6. if there are any confirm objections, then a confirm screen is generated 7. once confirmed, the packages are resubmitted 8. any packages with abort objections are skipped, and warnings are issued 9. remaining packages are deleted whew! the important remaining question: how are we to perform the actual deletions? do we delete the data from the table, or merely mark it as deleted with the addition of a 'deleted' column to all tables? if we're going to take the latter approach, it's important to note that we can't just have a DELETED flag--we need some way to know which deletions belong to which packages, otherwise it's a real mess :) my suggestion is to record a unique package id in the deleted column for each deleted package. sorry for the long post--this is a big job and a relatively complex feature--there's a lot to say! chad

5 4

RE: [development] Drupal Multi-Site Management
by Boerland, Bert 21 Jul '06

21 Jul '06

-----Original Message----- From: development-bounces(a)drupal.org > Not "in the process of" -- it is open source under the GPL. We have > protected access to the repository at the moment. Contact me for access. Good to see more code comming in! Do you mean restricted access to cvs or restricted access to d/l this module at all? Since I (and serveral other people [1]) looked for it but cant find it. If the restriction / "protected access" holds true for d/l a GPLicences software package, you might get into legal problems. See section 2 of the OSS definition ("there must be a well-publicized means of obtaining the source code") [2] and I dont think a shout out on this ml is qualified as "well-publicized". Then again, IANAL. [1] http://drupal.org/node/65896#comment-124595 [2] http://www.opensource.org/docs/definition.php

3 2

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

21 Jul '06

On Jul 21, 2006, at 3:52 AM, Derek Wright wrote: >> Adding an extra where-clause to all queries is perfectly valid if >> that is the best solution from a technical point of view. We >> shouldn't go with a solution that is sub-optimal, and avoid a >> superior solution just because it is a lot of work. That sort of >> decisions tend to backfire in the long run. > > if we're going to generate a patch that touches "thousands of > queries" and test the results, the "best solution from a technical > point of view" seems to be to port all said queries to some kind of > query building interface so we never have to touch them again for > this kind of thing... i couldn't agree more. my understanding is that we don't have that at the moment because SQL queries are easier to read in the code, and possibly because it's a little more efficient. the efficiency argument i understand, but we really wouldn't know what we're giving up until we tested it. the readability argument is shortsighted in my opinion--it puts us in this kind of position, where somebody has to muck through all the code and fix everything by hand, which seems unnecessary--not to mention more bug-prone and less flexible. in this sense we're really talking about a format change, and i think developers would have little problem getting used to a new way of reading the queries in code. not to mention that if you want to see what the final SQL looks like, just pop open the devel module and turn on the query print thing. :)

1 0

Re: Caching, caching, caching
by Ken Rickard 21 Jul '06

21 Jul '06

In the 4.6 model -- even with the backport url_alias patch -- I altered drupal_lookup_path() to disallow any lookups that didn't come from path aliases. Since I set the rules for that site, it meant paths were only checked if: 1) $path == 'taxonomy/%' 2) $_GET['q'] == $path This prevented the menu, node links, comment links, et. al. from being processed. It cut path lookups from 200+ to under 10 for node page views. Now this isn't a universal solution, but it may suggest a plan. - Ken Rickard agentrickard >>> Maybe we should run the modified devel.module on drupal.org to >>> see what the most expensive queries are? >> >> SELECT * FROM url_alias, I'd be surprized if that had changed. The >> individual query is very short but there are probably 120 per page >> on average. > > Are there reasonable assumptions we can make about certain URLs? > Like, can we assume that people don't want to alias '?q=qcomment/ > reply/123'? Or ?q=contact? Or q=user/register and ?q=user/ > password? If we can make some simple assumptions, we might be able > to save a helluvalot database queries (per page view) ... Food for > thought. Any thoughts here?

1 0

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