December 2005 - Development - lists.drupal.org

Re: [development] Counterintuitive but true: Caching makes a high-traffic site slower
by piotr＠mallorn.ii.uj.edu.pl 31 Dec '05

31 Dec '05

[I've sent this mail yesterday, but it didn't arrive...] On Thu, Dec 29, 2005 at 12:24:46PM -0500, John Handelaar wrote: > > The same table-level locking is *lethal* on a heavily- > trafficked site which has both There is a talk about dropping locks completly on http://drupal.org/node/39460 (yes, postgresql issue, but I think might apply to mysql too), with some performance tests (see link from http://drupal.org/node/39460#comment-58541) -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!

1 0

Re: [consulting] the Ultimate forum based Malinglist Manager
by Gerhard Killesreiter 31 Dec '05

31 Dec '05

[Note: I am moving this discussion to the developmen list where it belongs.] Allie Micka wrote: > So that's easy! you save yourself a ton of headaches when you stop > trying to shoehorn Drupal into being a mailing list manager, using a > real MLM to do your heavy lifting. Why would you want to use a MLM at all? All it does (cum grano salis) is to tell you which addresses belong to which list. > Subscribers can use the list the way they always have and you don't > have to do much coding at all. I think that the traditional way of using listservs (trough email commands) will die out sooner or later. Since we already use a web based service (Drupal) why bother with another interface? Recreating the few options that listservs offer isn't that hard if you use an establshed CMF. > > But the problem isn't solved yet: It would be nice to manage > subscription status from within Drupal. Not only nice, it is a requirement. > Necessary too, since Drupal will post to the list on behalf of a > user, and it would be nice if that user is subscribed. ezmlm-idx > uses a MySQL/PostgreSQL database for managing subscriptions, > moderator addresses, allowed and denied users. It is absolutely > trivial to access these tables for the purposes of subscriber > management. > Yes, that sort of thing is nice, I did the same for Sympa. Unfortunately neither Sympa nor ezmlm-idx are the morst favoured MLMs. People usually want mailman which interface to its user data is hideous. Of coure, Mailman 3 will do all we ever will need. The question is when. :p > And a great nice-to-have if you can create lists on-the-fly. Since I > know ezmlm, I know how to do this by setting up a script that > responds to a catchall email address. If the list referenced is > valid but does not exist, it is created. That is the sort of thing we will be doing too. Not sure we will use a catch-all address. > > So, these are the functions we would build as MLM-specific in a > pluggable way: > - subscribe/unsubscribe functions > - post to the archive from the list server > - auto-create lists > > And these would be on the Drupal side: > - database/forum structure > - display and access control > - subscribe/unsubscribe interfaces > This short list already has too much duplication for my taste. I'd like to discuss possible shortfalls on my idea to replace the MLM with a script that directly accesses Drupal's database to get subscribers and mail content to feed it to the MTA (and also does the reverse for incomign mail). Cheers, Gerhard

4 4

Counterintuitive but true: Caching makes a high-traffic site slower
by John Handelaar 31 Dec '05

31 Dec '05

In the continuing absence of anywhere to discuss these performance edge-cases (more below)... I've already mentioned recently that MyISAM is the enemy of Drupal performance. Because it requires a full-table lock, if you have lots of active members logged in at once, the process of posting a comment causes page rendering to cease entirely for several seconds. Onto today's point: The same table-level locking is *lethal* on a heavily- trafficked site which has both a) Content which alters regularly (like a busy forum), and b) Caching turned on. Try turning it off if your slow query log starts showing cache-related things taking 90 seconds (!) or more (!!). And then take a backup of your database and change these table types to InnoDB format. And then start looking at delayed inserts. jh PS: Still no bigsite/performance forum. Have we decided that Drupal doesn't *need* to scale? I missed that meeting.

10 17

node_access table
by VJ 30 Dec '05

30 Dec '05

How does this table work? If I want to remove comment and update rights to a specific user (or role), whats the exact SQL query? Thanks, V

2 1

Taxonomy Selection and the new 4.7 Forms API
by Raven Brooks 30 Dec '05

30 Dec '05

All, I posted a forum topic on this the other day but I thought I'd try this route too. I'm in the process of upgrading several modules to the new 4.7 forms API. I noticed this http://drupal.org/node/36899 which basically states you don't need to write code to invoke a taxonomy selection box any more, it is automatic. This seems to work out fine except I haven't found any way to control the placement of the taxonomy section on the form. Since you don't invoke it yourself it doesn't seem to respond to my efforts to control where it is placed. Is this an oversight or is there some hidden tip I'm not aware of? Any help would be greatly appreciated. Regards, Raven Brooks

3 2

RE: [support] node_access table
by VJ 30 Dec '05

30 Dec '05

Thanks. I have node_privacy_byrole installed, but setting everything to 0 for both node_privacy_byrole_role and node_privacy_byrole_user has no effect..i.e anyone can access it. Anyway, Ive had problems with that module before which is why I was wondering if I can bypass it...i.e set the permissions myself in code. On my site, when an user clicks 'complete' (which is a custom button), the node should immediately become read only. >From your email, I get the impression that I have to use a module. Why is that? do these modules change the node_load query? Thanks, V > The short answer here is that it depends on which access control modules > you're using. If you're using the "og module" it's different then if > you're using "node privacy by role". If I understand it correctly, > without additional modules installed this table doesn't do anything. > > You should be extremely careful about modifying this table without using > the API's for the appropriate access module. More info is in the > hook_access on the Drupal Api documentation. > > If you still want to do th is programatically then here's and example: > > If you're using node_privacy_by_role, then an example insert would be: > > Insert into node_access > (nid,gid,realm,grant_view,grant_update,grant_delete) > values > (<node>,<role_id>,'node_access_byrole_role',<grant_view>,<grant_update>, > <grant_delete>) > > > > With the followign replacements: > <node> The node id that you're protecting - find from node edit screen > <role_id> the role ID for the role your granting access to. > <grant_view> 1 if the role can view, otherwise 0 > <grant_update> 1 if the role can update, otherwise 0 > <grant_delete> 1 if the role can delete, otherwise 0 > > > -----Original Message----- > From: support-bounces(a)drupal.org [mailto:support-bounces@drupal.org] On > Behalf Of VJ > Sent: Thursday, December 29, 2005 9:20 AM > To: support(a)drupal.org > Cc: development(a)drupal.org > Subject: [support] node_access table > > > > How does this table work? If I want to remove comment and update rights > to a specific user (or role), whats the exact SQL query? > > Thanks, > > V > > -- > [ Drupal support list | http://lists.drupal.org/ ] >

1 0

RE: [development] Counterintuitive but true: Caching makes ahigh-traffic site slower
by Steven Peck 29 Dec '05

29 Dec '05

It just hasn't been added yet. Holidays, poeple time.... was that what people thought would work? I think the conversation sort of drifted out and got sidelined with Drupal 4.7 stuff. Now that you have reminded folks of it we'll see what Dries decides next week. Someone created a request for database issues forum too I think. Change on Drupal.org is evolutionary over time. Discuss refine, repeat, refine, drift, remind, refine... stuff suddenly happens :) -sp ________________________________ From: development-bounces(a)drupal.org on behalf of John Handelaar jh PS: Still no bigsite/performance forum. Have we decided that Drupal doesn't *need* to scale? I missed that meeting.

1 0

authentication hooks - PLEASE HELP
by Sheryl (Permutations Software) 29 Dec '05

29 Dec '05

I downloaded the Webserver Authentication module because it's very similar to the module that I need to write for my own site. It's a simple module, but I can't get it to work and I've hit a brick wall. Nothing works - Drupal doesn't recognize when I'm logged into my other authentication system, let alone create Drupal registrations on the fly. It doesn't even appear that the hook_auth module is being called, but I can't trace through the execution because Drupal doesn't use output buffers so inserting echo statements causes errors. I have tested my login and authentication functions in a separate test program, so I know that they work. I don't know why my module doesn't work. It's probably something simple, but there is virtually no documentation on authentication modules, and I can't figure it out for myself because I can't trace through execution with echo statements. I need information on these basic questions: - Which hook functions are called when (and not just from within the Drupal code, but from what user action)? I thought that hook_auth() might be called when the user logged in (that was a wild guess), but I can't get Drupal to call this function no matter what I do. - Exactly how the returns of each function are used - in what other parts of Drupal. Without knowing this, I don't know what's required. In particular for hook_auth, but also for hook_info. When/how are the hook_info functions used? By what part of Drupal? What might call these, and why? - What values are set in the database to control authentication, and what does each value mean? In particular, what is the meaning of the different values for "status" in the user table? - How can I echo values while the script is executing to I can debug my modules??????????????? Please, someone help. I've posted message after message, and no one helps. Thanks in advance.

14 31

Re: [drupal:unconed] /includes common.inc
by Karoly Negyesi 29 Dec '05

29 Dec '05

On Thu, 29 Dec 2005 06:28:53 +0100, <drupal-devel(a)drupal.org> wrote: > User: unconed Branch: HEAD Date: Thu, 29 Dec 2005 05:28:53 +0000 > > Modified files: > /includes common.inc > > Log message: > - #32785: Allow external URLs in menus (and make url() more flexible) Everyone rejoice! External URLs supported by url()! Big hurray for Richard Archer and Steven Wittens!

2 1

Node options
by Neil Drumm 28 Dec '05

28 Dec '05

I've been working on "Allow post options to not be reset" (http://drupal.org/node/38451) for awhile now. That patch currently adds a per-node-type setting which controls what happens to the 5 publishing options (published, promoted, etc) when a user who doesn't have permission to change those options edits a node. The options are either reset to the defaults for the node type (the current behavior) or are left unchanged. There is some need for making this setting per-node, but I'm not sure if the need is large enough to justify adding that setting to every node editing screen (sure, it would be hidden by default, but it is still there). I expect the awkwardness around this to go away when the revisions system gets a bit more work and workflow is added to core (I think it will happen). I have various (mostly unfinished) ideas for changing all of the 5 publishing options. But those are larger changes that should wait for 4.8. -- Neil Drumm http://delocalizedham.com/

5 5