June 2007 - Development - lists.drupal.org

JavaScript translation and themeing
by Konstantin Käfer 09 Jun '07

09 Jun '07

Hi all. Today, a patch went in that brings translation of JavaScript files and theming to Drupal. There are new JavaScript functions called Drupal.t(), Drupal.formatPlural() and Drupal.theme(). The usage of these functions is pretty much like their server side equivalent. Thus, you are now required to wrap your strings in JavaScript files in Drupal.t() calls, just like you wrap t() around them in PHP code. Drupal.theme() is a client-side themeing function for JavaScript. It is pretty simple (just several bytes), yet rather powerful. If you have to add HTML code to the page using JavaScript, you should create a theme function in the Drupal.theme.prototype namespace. Themes can override these default theme functions by adding a function to the Drupal.theme namespace. These theme functions can for example be placed in the script.js file in the modules root directory. This file is now automatically added to the page (if present), just like style.css. JavaScript theme functions can return about anything, a plain HTML string, an array of jQuery objects, a regular expression etc. It is advised to return an object (= array with indexes) of jQuery objects, so that the actual module code can easily determine which objects to modify. Thanks to Gábor who continuosly reviewed this patch and brought it to a rtbc state. Konstantin Käfer – http://kkaefer.com/

2 1

Book to Book-Pages... Many to many relationship??
by Daniel Hilton 08 Jun '07

08 Jun '07

Here's my situation: I'm in the process of importing dozens of paper (Word document) manuals into my Drupal intranet site as books. One of the main goals of this project is to reduce redundancy... in the word-document / file share set up, each manual is duplicated five times, once for each region in which my company operates. Some of the documents are identical across all regions, yet we still maintain 5 copies of the document. (Yikes!) Others are unique to a region (thus the separate copies of the manuals). This brings us to my dilema: It seems that the book module won't allow the same node to be placed in multiple books, meaning my goal of redundancy reduction is out the window! Does anyone have any suggestions about how to accomplish the functionality I'm looking for (adding a single node to multiple books)? I'm sure I could hack the book module to make it work, but I've really been trying not to tamper with core modules. Has there been any discussion on this topic before? Does anyone wish to discuss the possibility of adding this to the book module officially? Thanks for any input. Dan

4 3

Re: [development] development] Book to Book-Pages... Many to many
by Ken Rickard 08 Jun '07

08 Jun '07

Dan- Funny enough, I'm writing a "skeleton outline" module for D5 right now to address a similar problem. The skeleton module (when finished) will let you define an outline for new books, including default node content and settings for each book page. Then you will be able to create new "instances" of each skeleton as a new book. The result is cloned nodes across several books, which sounds like your goal. Send me a note offlist and I can send you some code. - Ken Rickard agentrickard ------------------------------ > > Message: 6 > Date: Fri, 8 Jun 2007 14:02:11 -0600 > From: "Daniel Hilton" <dunghopper(a)gmail.com> > Subject: [development] Book to Book-Pages... Many to many > relationship?? > To: development(a)drupal.org > Message-ID: > <3902af2f0706081302h719ada2et13f5b7dbea3e53c0(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Here's my situation: > > I'm in the process of importing dozens of paper (Word document) manuals > into > my Drupal intranet site as books. > > One of the main goals of this project is to reduce redundancy... in the > word-document / file share set up, each manual is duplicated five times, > once for each region in which my company operates. > Some of the documents are identical across all regions, yet we still > maintain 5 copies of the document. (Yikes!) Others are unique to a > region > (thus the separate copies of the manuals). > > This brings us to my dilema: It seems that the book module won't allow > the > same node to be placed in multiple books, meaning my goal of redundancy > reduction is out the window! > > Does anyone have any suggestions about how to accomplish the functionality > I'm looking for (adding a single node to multiple books)? > > I'm sure I could hack the book module to make it work, but I've really > been > trying not to tamper with core modules. > > Has there been any discussion on this topic before? Does anyone wish to > discuss the possibility of adding this to the book module officially? > > Thanks for any input. > > Dan > >

4 3

Drupal Slurper (Tips on keeping up?)
by Allister Beharry 07 Jun '07

07 Jun '07

http://pipes.yahoo.com/pipes/pipe.info?_id=iIl9uSMV3BGGFHrsouNLYQ I made a Yahoo Pipes mashup of 3 d.o feeds: http://drupal.org/node/feed http://drupal.org/aggregator/rss http://groups.drupal.org/group/tracker/feed with more to come as I get time It ain't really finished because I haven't figured out completely how to map the different feed element attributes to a unified set (categories don't work at all) and I have add stuff like author and date, but feel free to clone, modify, copy. Allister. -- Muppet Show > Monty Python

1 0

pair Networks upgrades to PHP 5
by Barry Jaspan 07 Jun '07

07 Jun '07

FYI, regarding the ongoing discussions re: PHP 5, note that pair Networks is upgrading all their servers to PHP 5.2.3. PHP 4 will remain available as a CGI script via some .htaccess settings. http://www.pair.com/support/notices/62-upgrade.html So, the switch to PHP 5 *is* happening, if not as quickly as everyone would like. Barry

2 1

weight for roles
by ufuk bayburt 07 Jun '07

07 Jun '07

is there an ongoing discussion or progress on role weights in core? (search results are all about the module.)

3 3

Re: [development] Go PHP 5, Go!
by Michelle Cox 07 Jun '07

07 Jun '07

On 6/6/2007 9:20:09 AM, Larry Garfield (larry(a)garfieldtech.com) wrote: > Thanks for the catch. I wasn't > sure which sounded less pushy toward hosts. > At least some of them, I think/hope, will be just as in favor of breaking > the > deadlock as we are. We can tweak the exact wording as needed. I don't think "give them a reason" is pushy... Maybe "provide them a reason" would be better? "Allow them a reason" just doesn't make sense, IMO. But, as you said, you can tweak it later. :) Michelle

1 0

directory handling (after the great file API)
by ufuk bayburt 07 Jun '07

07 Jun '07

do you think it would be useful to store directories in DB? is it a core thing or should it be in a contributed module? anybody working on it?

2 4

One-to-one tables considered harmful
by David Strauss 07 Jun '07

07 Jun '07

== What's bad about the current approach == The arguments for splitting table into one-to-one relationships are: * Improving performance on systems that can only use table-level locking * Minimizing invalidations of the query cache These are not good reasons considering their impacts. First, I'd like to adopt a development philosophy on the Drupal project: screw scalability if the database running Drupal doesn't support row-level locking. Sites using only table-level locks are doomed to scale poorly anyway because of the over-aggressive locking. We won't be able to prevent that disaster with the tiny improvements in lock granularity afforded by splitting tables into one-to-one table pairs. Drupal should still run on hosts allowing only table-level locks. We just need to stop weighing their unique performance concerns so heavily. Second, the query cache is a luxury, not a key part of database design. A site needs to run fast without the query cache because -- at some point -- the database will need to be restarted, which will dump the query cache. If the site can't survive without the query cache, it will enter a cycle of crashing/overloading the server before it can populate the cache. The query cache provides minimal support for the large variety of queries hitting the system. For example, a cached tracker query for me does nothing to help a cached track query for you. The query cache only works after the first run. If a query takes 45 seconds to run, the page load is in jeopardy. A failed page load to populate the query cache is unacceptable. Minimizing invalidations to the query cache by splitting tables yields far worse performance overall because we can't have keys span the tables. This will be discussed in detail in the next section. If we rely on the query cache, we're also being hypocrites with our stance on the first reason because many low-end hosts don't run the query cache. Either we care about scalability on low-end configurations or we don't. I'm suggesting "don't," but if people truly do want to care about low-end scalability, we can't use the query cache argument. == Why avoiding one-to-one joins is a good idea == Many of the slowest queries in Drupal (as seen on Drupal.org) are products of the following query plan: 1. Join the two one-to-one tables, maybe after a WHERE restriction on one. This creates a temporary table. 2. Finish processing the WHERE restrictions on the temporary table. 3. Filesort the results to meet ORDER BY criteria. An example of such a query would be finding all published nodes in order of most recent comments. Another would be finding all published nodes in order of most views today. These are extremely common queries in Drupal. The problem is caused by an insurmountable restriction in MySQL (and probably PostgreSQL): we cannot create a key that spans tables. Because we cannot create such a key, any query with WHERE or ORDER BY criteria spanning two one-to-one tables is doomed to a temp table and a filesort. To have these queries run without temp tables and filesorts, we need to have a key that has all WHERE criteria as a prefix and then has the ORDER BY criteria left over. The greatest paradox to me is that many of the worst one-to-one offenders are denormalized tables designed to improve performance. Because these denormalized tables contain calculated values that many queries use for WHERE and ORDER BY, the JOINs with them inevitably sink the query into temp table/filesort hell. == Where one-to-one is good == It's fine to have one-to-one tables if one table is only used in the JOIN and doesn't have WHERE and ORDER BY restrictions on it. For example, the one-to-one tables created by many content types that JOIN with {node_revisions} are great. You simply INNER JOIN {node_revisions} with the content type's table at little performance penalty. For this same reason, there's not much argument for denormalizing user names into other tables unless we're allowing people to sort on them. Even the forums don't allow sorting by user name. A simple JOIN from {blah}.uid to {users}.uid places almost no burden on the query. == What I'm doing about it == I'm working on a patch: Merge {node_comment_statistics} and {node_counter} into {node} http://drupal.org/node/148849 It also makes more intelligent choices for which calculated values to manage, which removes GREATEST() from numerous queries.

21 60

Should I submit a new module?
by Richard Morse 06 Jun '07

06 Jun '07

Hi! I found a recent need to be able to force clear the caches, but didn't want to install devel.module. I created a small module that just provides a menu item for clearing caches. (The scenario is that I have a page which is generated by the php filter; it wasn't being updated for anonymous users due to caching.) Is this something that other people would find useful? I would probably have the menu item be optional and use hook_form_alter to put a button on the performance settings page. If others are interested, I'll create a project on drupal.org and release it, but I wasn't certain if something already did this, or if people felt it just wasn't worth bothering with. Thanks, Ricky The information transmitted in this electronic communication is intended only for the person or entity to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this information in error, please contact the Compliance HelpLine at 800-856-1983 and properly dispose of this information.

6 9