- Development - lists.drupal.org

feeds as an attack vector?
by Chris Johnson 09 Aug '06

09 Aug '06

At http://intertwingly.net/blog/2006/08/09/Attack-Delivery-TestSuite Sam Ruby writes: "It is just a matter of time. One of these days, some hacker will deface a popular site like Engadget. But instead of putting something visible on the site, they will put something invisible in the feed. By the magic of syndication, that data will then be distributed like spores to untold thousands of locations. In the process it will be transported from a relatively untrusted location (like BoingBoing) to a place of equal or greater trust. Places like popular portal sites, or just perhaps, to your very own hard drive. From there, it will lie in wait until you check for news. Invisibly it will spring into action. You won’t even notice it running. It will be able to do things that vary from uploading your preferences and passwords to a remote location, to downloading malware onto your machine. Shortly thereafter, this entry will be marked as read, or scroll off the bottom of your river of news, and you will never know how you just got p0wned." It seems like it would be worth thinking about this when working on any part of Drupal that aggregates or generates feeds. ..chris

3 2

another awesome example of jquery in action
by Adrian Rossouw 09 Aug '06

09 Aug '06

http://be.twixt.us/jquery/treeView.php and so little code too.

10 14

Add a "unique value" function to profile fields
by Fredrik Jonsson 09 Aug '06

09 Aug '06

Hi, I have submitted a patch that add a "unique value" setting/function to profile fields. If this is a feature you are interested in please have a look. http://drupal.org/node/74800 http://drupal.org/files/issues/profile_uniquevalue-2.patch The patch is used on a production site with Drupal 4.7 where this feature is needed and it seems to work as it should. I'm interested in hearing if the implementation is good and to make it part of core, making it easier to update the site. Fredrik -- Web site: <http://xdeb.org/wiki/Fredrik> Drupal stuff: <http://xdeb.org/drupalpage>

1 0

CCK status?
by Ray Zimmerman 09 Aug '06

09 Aug '06

Does anyone know where things stand with regard to further CCK development these days? It seems that JonBob has gone pretty quiet in recent months (in the issue queue at least). Thanks, Ray

13 15

archive module for core or not
by Gabor Hojtsy 08 Aug '06

08 Aug '06

Hi, As I have indicated, I taken care of updating and fine tuning the contrib archive module (originally by codemonkeyx) to work nicely with node access modules and timezones. Morbus Iff and Kazuo Oishi was of great help. This modules does not have a calendar block, but the date browsing is handled with an easier to use 'multilayer' interface. http://cvs.drupal.org/viewcvs/drupal/contributions/modules/archive/ Since we need to compute the timezone according to site/user settings, we need to deal with the date values of nodes in PHP (or if someone knows a better solution, please speak up). This means that the module is not terribly efficient, using 14 SQL queries to build up the browser interface. We can push this down to 3, but then one of them would select the dates for all nodes in a year, which might be big. We should talk about this, I have no hard data. If core should have an archive module, then this should be reviewed and refined. I have added phpdoc comments, and tried to name every piece in the code sensibly, so that it is understandable. If an archive module is not needed in core, the current one could be removed, since there is a viable working alternative now. The current one, which has timezone and node access problems is not liked much in the development community, and Dries already indicated that it has no future in core. The issue: http://drupal.org/node/29676 Gabor

4 5

archive module removed from core
by Gabor Hojtsy 08 Aug '06

08 Aug '06

Hi, A few hours ago Dries removed archive module from core [1]. I created a contrib project for "the codemonkeyx replacement module", which several of us prepared to get up to multiple SQL database and timezone standards [2]. Since this new contrib module does not yet (?) have the archive block the core module had and there might be some possible performance problems, testers are welcomed. There are of course several possible implementations of an archive module, this is a simple one, which is very similar in nature to the previously available core one (and has the same name). Note that adding that calendar block is only possible, if the block is cached per user, since otherwise node permission compatibility is not maintained. Caching that block per user and then removing the cached copies on all node additions/deletions might be quite expensive. This is why there is no block yet. If you would like to see that block come back, please prepare some ideas, and start an issue on the contrib archive module. I am also trying to go through the core archive.module related bugs, and updating them as needed (some are relevant for the core module for a possible 4.7.x release, some are feature requests for the contrib archive module). [1] http://drupal.org/cvs?commit=37837 [2] http://drupal.org/project/archive Gabor

1 0

{Short issue queues need care - 4} critical issues on the rise again!
by Augustin (Beginner) 08 Aug '06

08 Aug '06

Hello and welcome to the fourth edition of {Short issue queues need care}. This week: 1} Report on progress since last time. 2} Featured short issue queues. 3} Why this report and how to cooperate? ******************************************* 1} Report on progress since last week. ******************************************* I apologize for the few weeks lapse since the last report. The ready-to-be-committed issue queue is no longer featured in this report. Dries has dealt with the old RTBC 4.6 issues. The RTBC queue is the only one that is permanently very short. Thank you to Dries, Neil, Gerhard and Steve. List manager: is it possible to know how many people are subscribed to this list? If a portion of those, say 20 developers and reviewers, pick a list below and help sort one or two issues, each list should be somewhat shorter next week. The queues featured below are all short. Select one and see if you can help bring the number of issues down by one or two until next week. Thank you for your cooperation. ******************************************* 2} Featured short issue queues. ******************************************* Pick one list. See at the very end if you wish to officially 'adopt' one queue. The number in parenthesis designs the number of issues 2 weeks old or more (i.e. issues most likely forgotten and not being dealt with). (Queue #1) DRUPAL-4-6 critical issues: http://drupal.org/project/issues?projects=3060&versions=11555,11262,10237,9… 18/06/2006 : 24 (19) issues. 25/06/2006 : 8 (5) issues. 02/07/2006 : 5 (4) issues. 07/08/2006 : 5 (5) issues only. Those are really critical issues, already fixed in head and 4.7. Can 3 or 4 developers agree to cooperate on one of those, so that there is one less issue next week? (Queue #2) DRUPAL-4-7 critical issues: http://drupal.org/project/issues?projects=3060&versions=11551,11252,10634,1… 18/06/2006 : 31 (19) issues. 25/06/2006 : 12 (8) issues. 02/07/2006 : 7 (5) issues. 07/08/2006 : 19 (13) issues only! Hmmm.... What happened? 4.7 is supposed to be stable! (Queue #3) CVS critical bugs: http://drupal.org/project/issues?projects=3060&versions=6487&categories=bug… 18/06/2006 : 6 (1) issues. 25/06/2006 : 13 (1) issues. 02/07/2006 : 15 (1) issues. 07/08/2006 : 16 (3) issues only! A few are marked as fixed already... (Queue #4) DRUPAL-4-6 Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&versions=11555,11262,10237,9… 18/06/2006 : 26 (25) issues. 25/06/2006 : 26 (25) issues. 02/07/2006 : 25 (24) issues. 07/08/2006 : 24 (23) issues. Most need to be bumped to cvs, if the bug still exists. If the bug hasn't been fixed yet, try to reroll the patch for head, or else set as "patch needs work". (Queue #5) DRUPAL-4-7 Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&versions=11551,11252,10634,1… 18/06/2006 : 17 (5) issues. 25/06/2006 : 16 (7) issues. 02/07/2006 : 21 (8) issues. 07/08/2006 : 15 (11) issues only. Make sure to note if the bug has been fixed in HEAD already: it would be silly to have a fix in 4.7, to see the bug reappear when 4.8/5.0 comes out. (Queue #6) CVS Patch Needs Review bugs: http://drupal.org/project/issues?projects=3060&versions=6487&categories=bug… 18/06/2006 : 72 (67) issues. 25/06/2006 : 71 (67) issues. 02/07/2006 : 77 (66) issues. 07/08/2006 : 72 (59) issues. As you see, only 13 issues are still active (less then 2 weeks old). Most are very old, so we have the choice between re-rolling the patch for current head, set as code needs work, or set as already fixed if appropriate. (Queue #7) DRUPAL-4-5 old bugs: http://drupal.org/project/issues?projects=3060&versions=10236,9738,9702,769… 25/06/2006 : 5 (4) issues. 02/07/2006 : 3 (2) issues. 07/08/2006 : 2 (2) issues only. Bump to head is the issue is still valid or close if they have been fixed. We need to do for this old branch what has just been done for the 4.7 Beta releases: review each one individually, and close or bump to head as appropriate until no issue is left in this branch. ******************************************* 3} Why this report and how to cooperate? ******************************************* There are now over 2200 issues in the queue. The figure sounds daunting: how can a very few volunteer developers deal with such a huge amount of bugs? The point is that we don't need to worry of the whole issue queue, but by getting somewhat more organized, the most important of those issues can be definitively dealt with. To start with, there shouldn't be anything critical within the Drupal project issues. Critical bugs must be dealt as a matter of priority. But one can get easily discouraged when facing 4 four pages of critical issues. The first step is therefore to sort out what is really critical from what is not. Having a shortlist of what is really critical, two or three developers can focus on a single issue, helping each other, so that one week later there is one really critical issue less. Similarly, 10-12 developers could get rid of 3-4 critical issues and in a few weeks, the list of critical issues would be down to almost nothing (only 1-2 issues caused by a large patch recently introduced in head, for example). If you wish to participate in tackling one of the 7 short issue queues featured here, please reply to the list, quoting only the issue you wish to 'adopt', changing also the subject title of your email to reflect the queue you have chosen. Hopefully, two or three more developers will reply to you, saying they want to help you with the issues in that same queue. Thank you to all the volunteers for your cooperation. Blessings, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

2 3

DrupalCON, GovCamp (schedule change)
by Dries Buytaert 08 Aug '06

08 Aug '06

Hello world, there has been a slight change in the DrupalCON schedule: GovCamp will run on Thursday rather than on Wednesday. I updated the schedule at http://drupalcon.org/schedule. Note that the deadline for DrupalCON presentation proposals is next week. Please, submit your proposal as soon as possible so we can move on with the schedule. Thanks! I would also like to point out that the GovCamp (http://govcamp.org/) people are going to offer us some room(s) to use for coding and brainstorm sessions. There has been some interest to work on identity and profiles, for example. More details will follow but suffice to say we'll be able to get together at GovCamp. We'd love to have some Drupal presentations at GovCamp. If you've done work with Drupal in the goverment, I suggest you get in touch with Bart Van Herreweghe, the organizer of GovCamp (in CC). As mentioned before, there will also be some Joomla! people at GovCamp. Should be fun to hang out with. :-) -- Dries Buytaert :: http://www.buytaert.net/

1 0

Filter cache
by Gerhard Killesreiter 08 Aug '06

08 Aug '06

Those of you who actually read my recent treatise about my "split cache table" patch might recall that I mentioned that drupal.org had a modification to stock Drupal, namely that it would cache filter items only for 4 instead of 24 hours. When we did this we had on average have about 70000 cached filter item. Now, we are actually caching the items for the full 24 hour period. One could be afraid that the number of cached items would grow a lot. It indeed did grow, but not by a factor of 6 but only by a factor of about 2. I am inclined to further increase the cache period and try to see where the number of cached items goes and if it helps drupal.org's performance. One would hope that the filter table would become somewhat stable and could maybe reside fully in memory on the sql server. However, there is of course a memory limit to this, the cache_filter table already has about 120 MB. Cheers, Gerhard

1 0

Interesting observation...
by Gerhard Killesreiter 08 Aug '06

08 Aug '06

01:55 < killes> http://drupal.org/node/817 <== i enjoy closing old issues. :p 01:55 < Druplicon> http://drupal.org/node/817 => Watermarks on uploaded images 01:56 < eaton> 817! hah 01:57 < killes> http://drupal.org/node/8 <== still open. :p 01:57 < Druplicon> http://drupal.org/node/8 => let a user delete its own account 01:58 < killes> it is amazing, between these two nodes are about 10 months and only 800 nids. :p 01:58 < killes> we do 800 nids now in what? a week? 01:58 < killes> yeah, about. :p 01:58 < killes> *rofl* 01:59 < ffh> wow 01:59 < ffh> thats a lot of nodes 01:59 < killes> you bet 01:59 < oadaeh> About 6 days. 02:00 < oadaeh> No, 5.5. Time to do another drupal.org growth diagram... Cheers, Gerhard

6 5