- Development - lists.drupal.org

Plans for this week
by Dries Buytaert 08 Jan '07

08 Jan '07

Hello world, here are the plans for this week: 1. Release a second (and last?) release candidate. I hope that the final Drupal 5 release will simply be a 'rename' of RC2. 2. Open up CVS HEAD so we can start Drupal 6 development. More about that later, I'll create a new thread for that. It would be great if we could focus all our energy towards the Drupal 5 issue queues for one last time. Drupal 5 is probably going to be _the_ 2007 release and is what many of our users will stick with throughout 2007. Let's make it rock. -- Dries Buytaert :: http://www.buytaert.net/

1 0

Re: [development] QA: Consensus on comment formatting
by Angela Byron 08 Jan '07

08 Jan '07

Excellent! Thanks for the summary, Derek!! > Here's a new draft of the conventions given everyone's input, my > votes above, and a few other suggestions: > > > * Comments should be written in English, with correct spelling[2], > punctuation, and grammar. > * Being concise is best, but never at the expense of clarity. > * Comments are capitalized and end in periods. They should be > complete sentences on their own line unless they are documenting > lists, or are describing a line of code that only needs a few extra > words to be clear. sentences are separated by a single space.[3] > * @file documentation begins with a sentence in present tense, and > has a blank line before any further comments. > * Function documentation begins with a single sentence in the form > "Do such and such." rather than "Does such and such.", and has a > blank line before any further comments. > * There is a blank line between @param and @return sections in > function documentation. > * Comments should not use all caps, e.g, NOTE. Instead, use @note, > @todo, @warning, @bug, etc. > * Any comment that refers to a variable should include the dollar- > sign in front of the $variable_name. > * Any comment that refers a database table should use {table_name} > to make it visually unique, not "table_name", 'table_name', etc. > * In general, URLs, code snippets, file names, etc, should not be > enclosed in quotation marks (") or inverted commas (') unless it > significantly enhances readability. Where necessary, inverted > commas should be used rather than quotation marks. > * No comment should be, or cause a line of code to become, wider > than 80 characters. > * In general, comments should not refer to issue node ids (for > example, "// This is crazy, and we fixed it in #12345."), since > that's what the CVS annotation and commit logs are for. However, > links to issues are allowed (recommended?) in a @todo or @bug. In > this case, a full URL should be used. For example: > // @todo These queries are very expensive, see http://drupal.org/ > node/105639. > Now, just one (technical) question. Does this: > // @todo These queries are very expensive, see http://drupal.org/ > node/105639. > ...actually work and get parsed by doxygen?? I thought doxygen only worked on function headers. This would make @todo less useful, imo, since: // TODO: this can be an expensive query. Perhaps only execute it every x minutes. Requires investigation into cache expiration. if ($user->uid) { db_query("UPDATE {users} SET access = %d WHERE uid = %d", time (), $user->uid); } Tells me that the queries immediately following that line are expensive, vs. /** * Reads a session variable. * * @todo the update query used here can be expensive.... */ function sess_read($key) { Anyone know? -Angie

1 0

Break tag issue compromise
by Karoly Negyesi 08 Jan '07

08 Jan '07

Hi, I suggest a compromise, a variable for the break -- without an interface. To use best, this will need a contrib module to be written but jadwigo already said that such a module could be reused for multipagecontent breaks etc. I believe that such a module would be quite simple. Please give your *thoughtful* review and test http://drupal.org/node/87145#comment-173683 Regards NK

7 6

Project Monitor Module
by Doug Green 07 Jan '07

07 Jan '07

I've made some improvements to the UI of the projectmonitor module (originally version2) based on the initial feedback from this list and one user's experience. The current 5.x-1.x-dev release is now somewhat stable and ready for another round of testing. This version works on both 4.7 and 5. It's working pretty well for me on sites where the contrib modules were downloaded with CVS. I've done much less testing on systems that pull directly from the Drupal release system. While I'm pretty happy with the process of identifying out-of-date modules (.at least on systems pulling from CVS), I'd prefer to provide better "download" links. I think that I'm going to have to use/improve the new Drupal release system to get these. Anyways, I hope I'm moving in the right direction. Doug Green 904-583-3342 www.civicactions.com Changing the world one node at a time!

1 0

Forum Access module
by Earl Miles 06 Jan '07

06 Jan '07

Is there anyone out there with an interest in working to help improve the forum access module? It's a great little toy and something I realize I don't really have the time to commit to continuing along the path that it deserves. 1) One requested feature that I resisted initially but have softened up to is that in the same way that it adds moderators to forums, it could also add user exceptions to forums. Instead of 1 acl attached to the forum it could have 2; the second acl would provide only view privileges, while the first acl provides maintainer privileges. 2) It could really use some better moderation tools. Some API to make it easier to determine if there is a forum moderator and give them tools to actually moderate a forum and not simply give them edit access, which is a start. Obvious tools include some node links to make it easy to unpublish a forum. This might do very well to work with whomever out there is currently maintaing a decent moderation module such that forum access and the moderation module could work in concert (and in so doing allow other forum access-style modules to utilize the same tools) to create a nice suite of tools to make it easy for *whatever* type moderators to do their jobs. Anybody willing to take this up?

1 0

Re: [development] Rename *_load and friends
by Peter Wolanin 06 Jan '07

06 Jan '07

A patch for the HEAD developer docs is here: http://drupal.org/node/107225 While everything is still referred to as a "hook", the name placeholder in the last patch is altered to "method_". I think these *are* different from the other hooks, in that one module can implement an unlimited number of node hooks (e.g. mymodulename.module can implement story1_load(), page1_load(), press_release_load(), etc), whose names may be totally unrelated to the module name, but can only implement mymodulename_nodeapi(). if you don't like "method_" as an alternate placeholder, please post a better patch. -Peter

3 2

Rename *_load and friends
by Karoly Negyesi 06 Jan '07

06 Jan '07

Hi, We have had a discussion about this already under a different subject. My opinion here is that hook_foo is something that gets implemented by N modules and at call time these are called, one after the other. hook_menu , hook_form_alter etc etc Note that 'hook' is always replaced by the module name. Despite hook_load is called a hook, it's a different animal: at call time, only one implementation is called. Not to mention that since we have a node information hook, 'hook' is not necessarily replaced by the module name. Larry Garfield suggested calling these method_load, method_view and so on. This I find a good idea and now would like to get opinions on this name. Thanks ChX Ps. By the way, theme hooks are also not hooks...

3 2

Re: [development] Any Drupal Tools for Automating Staging Site Creation?
by Metzler, David 06 Jan '07

06 Jan '07

I've taken a different approach, as said, not up to drupal distro standards, but I create and configure skel databases, and use scripts to copy sites, and run sql queries, including modifying some site variables. Adding a few scripted svn update commands to some of these scripts might accomplish what you're looking for or might not. The code's not pretty, so use at your own risk. http://www2.evergreen.edu/dave/node/72 They only work on linux environments. Dave -----Original Message----- From: development-bounces(a)drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Mike Cantelon Sent: Friday, January 05, 2007 1:43 PM To: development(a)drupal.org Subject: [development] Any Drupal Tools for Automating Staging Site Creation? Hi all, Has anyone created any tools for automating site setup? Basically what I'm doing now each night via a script is: 1) Cloning my production site 2) Replacing certain directories with versions checked out from Subversion 3) Running a series of Linux commands and SQL queries to set up modules that are in development but have not been deployed to production Whenever I start development on a new module I have to add to my mirroring script to automate Drupal setup. I can write some PHP functions to encapsulate this, but maybe something already exists? Cheers, Mike

1 0

Re: [development] Seems I need to take sandbox in my own hands
by Chad Phillips -- Apartment Lines 05 Jan '07

05 Jan '07

i'm just going to toss this out there as a general proposal: 1. move the sandbox completely out of the contrib repo, and make a new one -- this has the dual benefit of moving our 'messy' space away from our 'clean' space, and making the checkouts of the contrib repo faster/cleaner. you can then checkout the mess if you choose to. :) 2. in the new 'sandbox' repo, put a limit on how much each user can have in their active folder -- maybe 1 or 2 MB, which should be plenty for an experimental code home. i think this would be a pretty easy thing to implement. this would allay any bandwidth/space concerns about our chaotic space. i love the idea of having a more clear policy of what goes where, and setting up systems that encourage collaboration. i feel that a community place for chaos belongs in that map somewhere...

7 6

Any Drupal Tools for Automating Staging Site Creation?
by Mike Cantelon 05 Jan '07

05 Jan '07

Hi all, Has anyone created any tools for automating site setup? Basically what I'm doing now each night via a script is: 1) Cloning my production site 2) Replacing certain directories with versions checked out from Subversion 3) Running a series of Linux commands and SQL queries to set up modules that are in development but have not been deployed to production Whenever I start development on a new module I have to add to my mirroring script to automate Drupal setup. I can write some PHP functions to encapsulate this, but maybe something already exists? Cheers, Mike

1 0