May 2007 - Development - lists.drupal.org

multiple menus- close to working in HEAD
by Peter Wolanin 08 May '07

08 May '07

For those not following the issue queue closely, this could use some feedback and review: http://drupal.org/node/137767 It should probably be marked "critical". Without a patch like this, there is not good support in HEAD for multiple menus (e.g. "primary links" in addition to "navigation"). I would particularly like feedback on the last patch[1] that proposes a mechanism for tracking the path to the root of the menu tree that should make the system fast. It's also pretty easy to understand the algorithm (good for maintainability), but it has the minor drawback of requiring that we set an arbitrary limit on the depth of the menu tree. Note that the existing menu system in HEAD essentially has already a limit of 6 levels deep. To put these patches in context, the goal is to be able to support the successor to the book module (i.e. a new hierarchical page structure module per Dries' wish list and the writeup I did as a SoC suggestion [2]). So, imagine a {menu_links} table with ~10,000 nodes links in it (i.e. the drupal.org handbook pages). Note that in a quick search I can't find anywhere in the d.o handbooks that more than 4 levels deep. -Peter [1]: http://drupal.org/node/137767#comment-240315 [2]: http://drupal.org/node/128731

1 0

files owned by uid, patch review request.
by Darrel O'Pry 08 May '07

08 May '07

I've got one patch I've been working on for a while. I re-rolled it a couple days ago. I'd appreciate getting it reviewed from a few people. So far in my tests it works flawlessly, I'd really like to see this in D6. The idea to to associate files in the files table to a user id instead of a node id. Upload, Filefield, Imagefield, etc will still be able to associate files to nodes. This particular patch updates Upload to use the file_revisions table to maintain the node>-<file associations, maybe it should become the upload_node table. QUICK OVERVIEW: Problems this patch solves: - any thing related to displaying files on node previews. - hanging files in drupal's temp dir. - centralizes some security features that are in upload to file.inc Problems this patch creates: - no ui to access orphaned files in files table. Features this patch adds: - global quotas and extension limits on uploads per role. - save files with out a node via file_save_data. Possibilities this patch creates: - associating existing files to nodes. - advanced file browsers - extending db handling to file_move, file_copy, file_delete. - extended file functions would be an ideal spot to implement a hook_file VERBOSE OVERVIEW: This patch moves file upload limits and validation out of upload.module and to Drupal Core. This allows administrators to set allowed extensions per role, and quotas that will be enforced for any module using core's file_save_upload function. It also moves upload_munge_filename into file.inc so other modules handling files do no have to reimplement it or depend on upload.module. Database handling has worked it's way into file_save_upload. When you call file_save_upload('upload'), It validates the file by testing quotas and allowed extensions, munges the file name to prevent the mime based exploits, saves the file to its destination, and adds a record to the files table. This patch also completely removes file_check_upload, since it is fully merged with file_save_upload now.. This is a stepping stone to including more database interaction in file.inc. In a better world you would file_copy($file_object, $destination), instead of if (file_copy($file_object->filepath, destination)) { db_query(INSERT ...) }. This doesn't preclude keeping _file_copy($filepath, $destpath) which will probably become a helper function of file_move. It does smell of an end to the mixed parameter file functions that accept both objects and paths and do quite the internal dance to support it. File functions that interact with the database would be a great place to implement life cycle hooks for files, since you have the file object as a container for metadata, which isn't always the case with the file functions in their current state. Fid is a better key than md5_file($path) anyways. This patch introduces one major issue, which is dealing with unassociated files. There is currently no UI for navigating the files table. I'm not sure if I have the time to build a core worthy browser before the freeze. .darrel. ps. ted & nate, if you guys still have time I'd like to actually get the file browser at least started the 3rd week of may.

11 20

.tpl-ifying Drupal
by Earl Miles 08 May '07

08 May '07

Now that the new theming system is basically in (I have one outstanding patch and 2 more in the hopper that are not yet at patch level, but they shouldn't affect this), we now need a coordinated effort to properly .tpl-ify the majority of Drupal's theming functions. At the same time, I think we should also be looking at what isn't themable enough in Drupal and try to correct that at the same time. And this is a good place to try and correct Drupal's HTML/XHTML code to conform to the proper standards. The Themer Pack project was started as a gateway to this, and it hasn't been entirely successful (though I give HUGE HUGE HUGE kudos to dvessel who did a LOT of work on the themerpack, and calebg who started to but got busy).

6 9

Performance patches
by Karoly Negyesi 07 May '07

07 May '07

We have these: http://drupal.org/node/109037 move users.access into its own table http://drupal.org/node/100301 Tidy up the path alias sql problem http://drupal.org/node/78503 use mysql merge tables for log tables http://drupal.org/node/65017 Set cached pages to more reasonable age (helps with performance as the searchbots will hammer you less) http://drupal.org/node/55516 Remove database locking If I get a pledge on any of them from core committers that they will get in this time, then I will reroll, add comments, minor tweaks, ensure code style -- as needed to get into core. I will *not*, however, fight for the concepts. I do not have time for that. Regards, NK

1 1

Two new core modules
by Dries Buytaert 05 May '07

05 May '07

Hello world, there are two existing modules I'd like to see added to Drupal 6: 1. OpenID 2. Actions I think both are important 'enablers' for many future things. I already talked to James (OpenID) and John Vandyck (Actions) and they are supporting the idea and willing to help make that happen. Of course, I'd still like to see better image and forum handling in core too, but more about that later. (I believe webhick was working on some forum module improvements but I haven't checked with her yet.) -- Dries Buytaert :: http://www.buytaert.net/

15 20

Introduce dynamic object translation API (optimize this!)
by Gabor Hojtsy 04 May '07

04 May '07

Hi, There were some misconceptions on this list about the motives of having a defined list of variables, or the usefulness of t() for user defined text translation. So I figured I delve into a complete writeup of the challenge of user defined object translation, as well as provide a simple patch of our current working concept. WARNING: we are looking for optimization junkies and ninjas to help out there! There is a lot to be optimized, while keeping the API simple, or making it even simpler! But even if you are not into optimization, this issue should shed a lot of light on how user defined object translation could work, and why is that so much different from simply using t(). http://drupal.org/node/141461 Excuse me if I will not tack this issue into replies to all your concerns on different ends of the variables refactoring thread. Gabor

1 0

refactoring profile module categories (the other low hanging fruit :)
by Gabor Hojtsy 04 May '07

04 May '07

Hi, So we faced two "generic problems" when preparing localization for Drupal 6 objects (like user profiles, variables, aggregator stuff). The first bomb I already dropped down, and it erupted into a huge thread (variable defaults). The second is refactoring of profile module categories. Yes, I have heard the "deprecated podcast" (see http://www.lullabot.com/audiocast/drupal_podcast_no_38_deprecated) and I know there are possibly better tools then profile module to do the job (lots of comments on the podcast on profile module!). BUT we have profile module there, so we are about to support translation of profile module fields and categories, unless suddenly some replacement for Drupal core shows up, or Dries decides to remove profile module from Drupal 6.x-dev altogether (none of which seems likely so far). We faced some major pains because profile module's category notion is rather broken. Some folks were very happy on the Drupal 5 release including autocomplete support for category names, but that was really driving forces away from the real problem. Jose A Reyero prepared a patch for us to refactor profile module categories into being separate objects. Read on here for the patch and more information: http://drupal.org/node/141419 Gabor

1 0

How to have 2 snapshot releases
by Kieran Parsons 04 May '07

04 May '07

The gallery module now has an official 5.x-1.0 release, and 2 development snapshots (5.x-1.x-dev and 5.x-2.x-dev). I cannot get the 5.x-2.x-dev snapshot to appear on the main gallery module page under "Development Snapshots" without losing the 5.x-1.0 official release. Is there a way to do this, or (even better), have both 5.x-1.x-dev and 5.x-2.x-dev snapshot releases appear? (No reply from the infrastructure list so posting here). Thanks.

3 2

Request for help: split up mail subscription page
by Gerhard Killesreiter 04 May '07

04 May '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, on behalf of the Drupal infrastructure team, I ask the developer community to help with a particular problem which has recently affected drupal.org. The form for mail subscriptions of all projects is getting too long thanks to all the projects you guys are creating. The result is a php OOM error. It would be helpful if somebody could invest some time to fix this issue: http://drupal.org/node/140649 Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGOz/Jfg6TFvELooQRAiffAJ93FtkumOmCUuGlnBuPSZ4mh+4tnACfTq2h dE8dyqHWzvKd4Z3asGLBHn0= =WKyz -----END PGP SIGNATURE-----

1 0

New maintainer for the salesforce module
by Victor Kane 04 May '07

04 May '07

Hi folks, OK, after months of pontificating upon various philosophical subjects here, I have decided to roll up my sleeves and actually get my hands dirty maintaining a module which I hope will be of much service to the community. With the kind permission of Steve McKenzie (the progenitor), I have created the salesforce module project (with the initial commit based on his sandbox version), with the objective of providing and maintaining Drupal integration with the Salesforce API <http://wiki.apexdevnet.com/index.php/API>. As per Steve's excellent suggestion, I have labeled the module unusable until I can guarantee, through thorough testing, that it is ready for the slew of feature requests and bug reports that are sure to emerge, both in 4.7.x and 5.x branches. There are no releases as of yet. An initial version will be released in approximately ten days. Fortunately, since we are working on the revamping of the HelpArgentina.orgsite (where Ingo Boltz pointed me to Steve's work on the module in the first place) and integration with the Salesforce API<http://wiki.apexdevnet.com/index.php/API>is a requirement, we are assured of a prompt initial release with the current set of features, with more in the works, as well as an automatic upgrade path on through Drupal 6.x I would like to thank Steve for his hard work in creating the module, and underline my commitment to provide functionality through the GPL license and modules available to the Drupal community, as a method of assuring not only just credit, but also the central quality of the software. Any suggestions of whatever kind are more than welcome. Victor Kane http://awebfactory.com.ar

1 0