- Development - lists.drupal.org

gotcha: menu wildcards, foreach() and MENU_SUGGESTED_ITEM
by augustin (beginner) 17 Jul '08

17 Jul '08

Hello, I just noticed a bug in directory.module, and I see the exact same bug in tagadelic.module. This bug involves the new menu system. In D5, we used to be able to dynamically create a series of menu items with a foreach loop within hook_menu(). When upgrading to D6, the tendency has been to remove the foreach loop, and replace the arg(n) with a wildcard loader, but it is the wrong solution. In most cases, you don't want to remove the foreach() loop you had in D5. Within D6, it is perfectly ok to have a loop, recursively declaring several well defined menu items, e.g. one item for each vocabulary. When you have such a loop, do not use the wildcard loader. For a detailed example see this issue: http://drupal.org/node/283198 I have updated the documentation in the handbook. Blessings, Augustin.

4 5

GSoC Aggregator patch
by Novák Áron 16 Jul '08

16 Jul '08

I rolled out the patch against HEAD aggregator: http://drupal.org/node/236237#comment-923418 I would like to ask everyone interested in aggregation topic: please review it and tell your opinion. Important to know: It will definitely break your tests because the new tests are still under construction and the old ones are not suitable for the modified module. More verbose explanation and instructions can be found at the linked d.o. ticket. If you'd like to see my plans for testing and more: http://drupal.org/node/282570 Thanks, Aron Novak

1 0

New Developer - for Tamil from Tamil Nadu-India
by vin vin 16 Jul '08

16 Jul '08

Hi Everyone I am Vinoth, New joiner. Please let me know if any one from TamilNadu or for Tamil Development in the Great group. -- vin

2 1

Question on #theme attribute in D6 FAPI
by Syscrusher 16 Jul '08

16 Jul '08

Good evening! I have a form that works fine in Drupal 5 and uses the #theme attribute to invoke a user-defined function. I'm trying to update the module to Drupal 6, and am getting no errors, but the #theme function is no longer being invoked (I placed trace statements there, and am using devel.module for diagnostic printing using dprint_r()). I checked the upgrade-your-module documentation (which is excellent, btw), but there's no mention of a change to how #theme works. Have I overlooked a change that's documented elsewhere? Here are the code snippets. In the code that generates the $form array, I have this: $form['links_related']['#theme'] = 'links_related_form'; and the theme function is defined thusly: function theme_links_related_form($form) I have a trace print() statement right inside that function as the first line, so I know the function isn't being called. By the way, the form itself generates and executes correctly, with all fields working. The only problem is that the theming isn't being called, so I'm getting plain vanilla output rather than the table that is supposed to neatly align the columns (my theme function calls Drupal's core theme('table', ....) function to do this). Again, this worked in D5, so I'm looking for what needs to change for D6. Thanks for any suggestions. Scott -- Syscrusher <syscrusher(a)4th.com>

4 9

Drupal could be 10x times faster with correct indexing
by Jean-Michel Pouré 15 Jul '08

15 Jul '08

Dear friends, Today my Drupal 6.2 server was flooded and I discovered that there was a real lack of indexing in Drupal. Here is the issue with solutions: http://drupal.org/node/276742 When using MySQL, you don't really know how SQL queries are treated, except execution times that may be monitored (?). On the converse, PostgreSQL offers full logging of queries and access to query plans, showing how the database executes data. In the above issue, I could speed-up a simple query by 10 times. You may not notice this issue when using small Drupal sites (because the whole database executes in shared memory) or when using Drupal with caching. But ... on large installations like mine, you cannot cache everything without a huge amount of memory. And the result is SLOW. Using PostgreSQL, normal queries should run in less than one millisecond, usually 0,2 millisecond. Long queries with difficult JOINS should run in less that 5 milliseconds. This way, the database server is always faster than anay kind of PHP cache. And you can use large sites on small sites. There is an extensive query debugging needed on Drupal: 1) Turn on extensive logging in PostgreSQL, including query execution times. 2) Whenever a query executes in more than 1 millisecond, run psql or pgAdmin (graphical client) to run EXPLAIN ANALYSE. 3) Find sequential scans and fix them. Most of times, JOINS and clauses and ORDER BY should be on indexes. 4) Add proper indexing 5) Run EXPLAIN ANALYSE again. Times usualy are divided by 10. 6) Add indexes everywhere. After this hard work, a normal Drupal 6.2 installation should be able to answer thousands of queries. Do not hesitate to answer my issue : http://drupal.org/node/276742 The issue offers a pratical example. Again, this kind of problem will only show on large sites (like Drupal.org) not a small installation. But I consider this as a bug, a very important issue which should be fixed ASAP. Kind regards, Jean-Michel Pouré

8 9

Wanted: Version Control API maintainer
by Jakob Petsovits 15 Jul '08

15 Jul '08

Hey list, for the near future, I won't be able to do module maintainership anymore - on Saturday I'm leaving for a month-long trip abroad, and after that I'll be working pretty much exclusively on my diploma thesis. So if I (hopefully) manage to concentrate on the important stuff, you won't be noticing lots of Drupal related activity from my side until next year or so. Filefield is taken care of by dopry, and my other modules are both small and nonessential for the community, I'll trust those to fago and my employer. That leaves Version Control API, which has been my largest undertaking but didn't yet take off as the 5.x-1.x branch had some conceptual issues yet and I wasn't able to finish the 5.x-2.x branch that fixes those with a simplification of concepts and database structure. The Summer of Code project for revamping Version Control API and extending it for usage on drupal.org unfortunately failed as my student disappeared without notice (I heard he's healthy, but on the coding side he's gone for good). So essentially the situation looks like this: If you don't help out then Version Control API is likely to die, drupal.org will keep running on CVS, and all the work will have been for naught. This is a call for help - if Drupal-based support for SVN, Git, Mercurial or Bazaar is of importance to you, then please take care of Version Control API, finish the 2.x release and port it to Drupal 6. It's a considerable amount of code, and for some extension modules it would probably make sense to split them out into separate projects. The only thing that's really crucial at this point is the core API module and the Commit Log. Everything else can be reinstated once these are in good shape again. And of course, major rewards are awaiting you if you take this on. Like, having the own code running on drupal.org once it's ready to run there. If you want to contribute, drop me a note before Saturday, or otherwise get in contact with dww, hunmonk or aclight. Thanks, Jakob P.S.: Bye community, I hope to come back next year! Oh, and see you at the Drupalcon, despite the above :P

1 0

drupal_rebuild_form on node preview
by Dave Cohen 15 Jul '08

15 Jul '08

I'm running into a problem having to do with drupal_rebuild_form. I hope someone can explain to me what is going on. The symptom, briefly is this: I have a custom form element, with its own #process function. The function relies on $element['#post'] to do some of its magic. In Drupal 5, it works fine. However in Drupal 6, when my form element is in a node form and I hit Preview, things break. On Preview, my process function is called normally, then my process function is called with #post unset (as if the submit button had not been pressed). And the form rendered to the screen is a result of this second invocation. So in trying to debug this I learned about drupal_rebuild_form. I've read the comments, but its still unclear why this function exists. Its also unclear why its being invoked on node preview. Is it because node module is setting $form_state['rebuild']? Most important, can anyone suggest a workaround? Do I have to implement a process function that can somehow detect whether its been called before? Do I have to keep my own copy of #post around? Is FAPI really supposed to process my element twice? Thanks for any help, -Dave

1 0

transferring session info across login event
by Joe Murray 14 Jul '08

14 Jul '08

I have a use case where anonymous users can do a bunch of work, and then at the end request to save it, which requires logging in (and possibly also creating an account). The login event regenerates the session, and so far as I know 5.x does not provide a hook that can be used to copy info from the old session into the new so that it can be saved in a way that is associated with the correct uid. I suppose such a hook so would open up lots of security issues. Still, this is the second time I've confronted this sort of an issue, and I don't know the correct design pattern to handle it in Drupal. Comments and suggestions welcome. Cheers, Joe Murray, PhD President, JMA Consulting @ The Centre for Social Innovation 215 Spadina Ave, Suite 400, Toronto, Ontario, Canada M5T 2C7 416.466.1281, (416) 644-0116 (f) <mailto:joe.murray@jmaconsulting.biz> joe.murray(a)jmaconsulting.biz Skype: josephpmurray

1 0

Panels nearly at RC/ready for port, BUT
by Sam Boyer 14 Jul '08

14 Jul '08

Hi fellow devs - If you've ever wanted to help with Panels - now's the time! As of tonight, I've crossed off (very nearly) all the items on our list of todos before releasing Panels2 RC1. However, we want to leave -dev basically as-is for the next week, just to be sure, before we officially release RC1. So for all you excellent folks who've said "just let me know how I can help!" over the past few weeks - well, here's how you can help! 1. We need folks to put -dev through some paces in production-like settings - so if you have a heavily panels-based site and could drop the DRUPAL-5--2 branch of Panels onto a test server and poke around with it for an hour or so and let us know of any problems, that'd be VERY helpful. 2. I've got two issues tracking the status of important Panels issues: one is must-have patches for RC1 (http://drupal.org/node/281934) and the other is potentially worthy issues that we don't have time to get to right now (http://drupal.org/node/281829) If anyone feels like hunkering down and working on rolling some patches/testing existing patches in any of those issues, it'd be great. The other important thing that Panels2 RC1 means is that Earl and I are now both actively working on the D6 port. Just a heads-up :) Sam

1 0

HELP: Need a new mentor for the Document API SoC project
by Angela Byron 13 Jul '08

13 Jul '08

Ken Rickard needs to step down for a bit and take care of some personal stuff that came up suddenly. Dan DeGeest is on as backup mentor, but we really need someone to step in and take over as primary mentor while Ken takes care of some stuff. The project is Document Import API - http://drupal.org/project/docapi. The idea is to be able to import files from a variety of office programs such as OOo, Word, and Excel. The student is Christopher Bradford, who was a SoC student last year, so knows Drupal, but needs help with hammering out the various interactions. Some design documentation has already been created at http://groups.drupal.org/files/DocImport_Process2.png to give you an idea. We basically need someone fluent in file handling, XML formats, and that sort of thing. Any takers? -Angie

4 3