August 2007 - Development - lists.drupal.org

Re: [development] New Module Ideas and Announcements
by FGM 07 Aug '07

07 Aug '07

Your terminology is probably more accurate than the one I used, so yes it seems what you describe :-) There is at least one point of view from which an issue queue on d.o. seems better than a group on g.d.o., and that is visibility: to know that group exists, you have to be led there by someone, at least today, just like you did, whereas the project issue tracker is a central feature on d.o. This could be alleviated by some writing in the module developer's guide, though, specifically pointing new developers to that group, for instance from http://drupal.org/node/7765 The fact remains, though, that g.d.o. can never be as central as the tracker, and the latter also provides a definite workflow for such ideas, from birth to closure, while a g.d.o. group seems to be an endless discussion, without workflow. Frederic ---- Original Message ---- From: drupal(a)dwwright.net To: development(a)drupal.org Subject: Re: [development] New Module Ideas and Announcements Date: Tue, 7 Aug 2007 08:38:15 -0700 > >On Aug 7, 2007, at 3:05 AM, FGM wrote: > >> Another solution might be to add an issue category to the project >> tracker, like: > >What project's issue queue would these issues go in? ;) > >Seems like what you're really asking for is a new issue queue >entirely for "project ideas" with components like "module", "theme", > >"install profile", etc. > >I'm not sure that's much different (neither better nor worse) than >the group [1] John created in the first place. > >Cheers, >-Derek (dww) > >[1] http://groups.drupal.org/contributed-module-ideas

1 0

Re: [development] New Module Ideas and Announcements
by FGM 07 Aug '07

07 Aug '07

This recently happened with the themesettings project, actually, although the project author had taken the time to talk with me separately about it prior to project creation. The way to go suggested at the time, IIRC, was to announce any module project intent on this (archived) mailing list prior to project creation, so that any interested party could chime in. Another solution might be to add an issue category to the project tracker, like: - adding a "Future contributions" category - adding several "ideas" subcategories: - "project idea" - "theme idea" - "translation idea" - "profile idea" These could be closed just like other issues when the project was created. Maybe we could even require the project creation form to include a mandatory issue nid pointing to such an issue. This would allow persistence, traceability, and searchability. What do you think of it ? FGM ---- Original Message ---- From: darthsteven(a)gmail.com To: development(a)drupal.org Subject: Re: [development] New Module Ideas and Announcements Date: Tue, 7 Aug 2007 10:10:59 +0100 >I think that that is the point that John is trying to make. People >are >duplicating work and code and polluting the namespace. If you could >post to somewhere, saying: 'I've got this idea', then someone could >let you down gently, and say they'd already done it. Then you'd be >free to extend their work, and improve upon it, collaboratively. [...]

3 2

problems with shutdown function in search module
by Gerhard Killesreiter 07 Aug '07

07 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, our search module uses a shutdown function in its cron hook. While re-indexing scratch.d.o to test Doug's patch, I encountered the following situation: 1) There are runnign several update routines from search_update_totals in parallel. 2) The final select query in that function run for hours. I believe that 1) is caused by the fact that the shutdown function isn't governed by our cron semaphore. That is, it runs until it is done and it won't stop other cron jobs from running. So if there are enough dirty workds to update, it is possible that there are several of them running in parallel. I've seen as many as 5. Does anybody consider this a problem? I have no idea what causes 2 but would be grateful for suggestions on how to fix the problem. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGtwc4fg6TFvELooQRAnfvAKCsAuBwTKd1cXBwO4QZ0LzEnLrbkgCgzEMm 7ZYafVkZRStDqb3tILCycqk= =dyMQ -----END PGP SIGNATURE-----

3 4

Permissions Caching
by Ron Parker 07 Aug '07

07 Aug '07

Does Drupal cache permissions? If so, how can I clear that cache for a particular user at a particular time? I have a module, og_user_roles (http://www.drupal.org/project/og_user_roles) which adds group roles to the $user object when it is loaded. So, when function "user_access" executes, my module looks to see if the user is in a group context, and if so, adds whatever role(s) the user might have within that particular context. A user is having a problem that he explains here: http://drupal.org/node/164932. In short, each time he clicks on a new group link, and the group menu is calculated (i.e., what nodes the user can create), the user still initially has the same roles from the previous group instead of the new group. Therefore, the group menu will display "create" links for which the user may not necessarily have permissions in this group. My guess is that there is some role/permissions caching going on so that, for some reason, the $user object isn't loaded when the user initally enters the new group, so the permissions remain the same as before when the new group menu is calculated. If I'm correct, then I need to figure out a way to clear this cache so that the correct group menu links will always be calculated and displayed. Thanks in advance for any suggestions. -ron -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com

1 0

FYI: packaging cron jobs not running
by Derek Wright 05 Aug '07

05 Aug '07

Not seeing your new release nodes getting a tarball and being published? Here's why: http://drupal.org/node/164592 Cheers, -Derek (dww)

2 1

IRC cloaks
by Karoly Negyesi 05 Aug '07

05 Aug '07

Hi, It never occured to me that IRC is this important for us. Time to get Drupal cloaks. Let's discuss for real what cloaks we want, who can get one and so on and I will deal with the rest. When someone joins a channel or whois run on her/him/it then you see: Druplico(a)rm-1006-10.serve.com versus chx@pdpc/supporter/professional/chx I wear a pdpc cloak at this moment while Druplicon is uncloaked. Only identified users get a cloak, they get it automatically upon idenitifcation. A cloak usually serves to show that you belong to the project. Example: https://wiki.ubuntu.com/NewMemberHowto and http://www.mail-archive.com/community@apache.org/msg04083.html Regards, NK

7 10

DrupalCon poor planning around Jewish Holidays two years running
by Doug Green 05 Aug '07

05 Aug '07

Not sure where to put this, so hear goes... I was in Europe the week before DrupalCon last year, but went home before DrupalCon so I could observe my religions Holiest day of the year. This year I decided to make at least a couple days of DrupalCon. But I'm confounded by the poor planning two years running. Could the powers-that-be please schedule my sessions on the first 2 days (Thu or Fri morning). And further, could we not schedule DrupalCon during these Holidays next year? I'll be observing the Jewish High Holidays in Barcelona this year. Does anyone on this list belong to any congregation in Barcelona? I'm hoping to go to services on Rosh Hashanah (evening Wed 9/12 and morning Thu 9/13) and Yom Kippur (evening Fri 9/21 and daytime Sat 9/22). I've tried to contact the Reform congregation, but have had no success. Since I suspect most of the Reform Congregation will be in Spanish, I'd be happy to try any other synagogue. http://www.kosherdelight.com/SpainSynagoguesBarcelona.htm * Comunitat Jueva Atid De Catalunya (Reform) The Jewish Community of Catalunya* Tel: +34 93 417 37 04 Fax: +34 93 417 37 04 Email: info(a)atid.es <mailto:info@atid.es> , secretary(a)atid.es <mailto:secretary@atid.es> Website: http://atid.es/en/index.php Thanks!

4 3

Clustered Drupal through Quercus, Terracotta and Ehcache
by Gabor Hojtsy 04 Aug '07

04 Aug '07

Hi, More and more people are experimenting with running Drupal on non-PHP Group developed interpreters. I have seen some quite interesting existing experiences on Drupal developer blogs before, but this just caught my eye, and thought it might also be interesting to share: Clustered Drupal through Quercus, Terracotta and Ehcache http://rifers.org/blogs/gbevin/2007/8/1/clustered_drupal_terracotta Gabor

1 0

Drupal 5.2 and 4.7.7 released
by Neil Drumm 04 Aug '07

04 Aug '07

Killes and I have released Drupal 5.2 and 4.7.7. These are bugfix and security releases; upgrading is strongly recommended. Further details are at http://drupal.org/drupal-5.2 The CVS tags are DRUPAL-5-2 and DRUPAL-4-7-7 The direct downloads are http://ftp.drupal.org/files/projects/drupal-5.2.tar.gz http://ftp.drupal.org/files/projects/drupal-4.7.7.tar.gz Thanks goes to the security team, everyone who reported and reviewed security issues, and everyone who worked on bugs. -- Neil Drumm http://delocalizedham.com

8 16

Drupal performance patches: call for action
by Dries Buytaert 04 Aug '07

04 Aug '07

Hello world, I provided a list of what I believe are the top-6 most important performance patches for Drupal 6 and drupal.org (which will run on Drupal 6). If you know people that want to help, please point them to http://drupal.org/node/163216#comment-257631 or wherever the latest version of that list continues to live on. The slowest queries on drupal.org are the ones for (1) the tracker page, (2) the forum blocks, (3) the forum topics' next/previous links and (4) the search module. Since we disabled most of those features, drupal.org is again more usable. Of course, we want to re-enable all of those feature as soon as possible. To make that happen, we need help from developers and database experts. To provide some focus, I compiled a list of the 6 most important performance patches that you can help with. I truly hope to get some of these into Drupal 6, and to backport them to Drupal 5 so we can use them on drupal.org until we upgrade drupal.org to Drupal 6. Important note: these patches are still allowed to change the APIs in Drupal 6, and are about the _only_ patches that can break our APIs before Drupal 6 beta 1 is released. This policy will hopefully help us focus -- these issues is where all of our Drupal core action should be. So here is the list: 1. http://drupal.org/node/147160 - Database replication: database replication will help us distribute the load among multiple database server. This will help us with (1), (2), (3), (4) and more. Without this patch, we can't even take advantage of the extra hardware that we're installing. Needless to say, this patch is critical. Some extra background information and thoughts are available at http://buytaert.net/scaling-with-mysql-replication. 2. http://drupal.org/node/148849 - Merge {node_comment_statistics} and {node_counter} into {node}: looking at the slow query log on Drupal.org we have reasons to believe that this patch could help us with (1) and (2) and (4). There are some reservations as well so we need people to help benchmark this patch so we can weigh the advantages and the disadvantages. After some good testing and benchmarking, we should be able to drive this patch home. 3. http://drupal.org/node/80951 - Block caching: being able to cache expensive blocks would help us with (2) as it eliminates expensive queries. 4. http://drupal.org/node/105639 - Tracker query rewrite: would help us with (1) because it rewrites an expensive query. 5. http://drupal.org/node/146466 - Link handling in search module: this patch reduces the complexity of the search module and will help with (4). I helps performance and it makes for a better search. 6. http://drupal.org/node/106559 - Path lookups: we're brainstorming about how we could reduce the number of look ups required for URL aliasing. I think we need to look at de-normalizing the path alias table, but there are some other ideas that are being proposed, measured and discussed. There are likely to be more patches, but I'd like to start with those. It's more than enough work already, and it is better not to spread ourselves too thin. If you're convinced that there might be a more important performance patch, you can work on that too. I recommend that you bookmark these issues in your browser's toolbar and that you ask you boss whether you can spend some time working on these patches. ;) Thanks, -- Dries Buytaert :: http://buytaert.net/

11 19