May 2007 - Development - lists.drupal.org

Beware of static and unset together
by Karoly Negyesi 14 May '07

14 May '07

Hi, So says the PHP manual about unset "If a static variable is unset() inside of a function, unset() destroys the variable only in the context of the rest of a function. Following calls will restore the previous value of a variable." This will lead to really weirdo stuff if you have: function foo($refresh = FALSE) { static $storage; if ($refresh) { echo "refreshing\n"; unset($storage); } if (!isset($storage)) { $storage = microtime(); } return $storage; } echo foo() ."\n"; echo foo(TRUE) ."\n"; echo foo() ."\n"; Observe how the third and the first results are the same as if the refresh did not happen. As Drupal often uses such constructs. Use $storage = NULL instead of unset, for example -- or some other appropriate initial value like '' or array(). list_themes() in core for example has been biten by this, thanks goes to dww for reporting it. The patch is at http://drupal.org/node/134161 btw. I think it's better known that if you have global $x; unset $x; then $x will be unset only in local scope, as global $x is same as saying $x = &GLOBALS['x']; The above issue is actually the same because -- according to my knowledge -- static is a global which has a special flag 'you are only visible to function foo', so basically you have $storage = &$GLOBALS['_static']['foo']['storage']; and then you destroy this reference (of course GLOBALS['_static'] does not exist, I just used it for illustration). Regards, NK

12 15

Re: [development] mode column in {users}?
by Peter Wolanin 14 May '07

14 May '07

Thanks Dries- that was the clue I needed. It is indeed still used here: http://api.drupal.org/api/HEAD/function/_comment_get_display_setting But it's never referenced directly as $user->mode so the regex I tried missed it. -Peter > ---------- Forwarded message ---------- > From: Dries Buytaert <dries.buytaert(a)gmail.com> > To: development(a)drupal.org > Date: Mon, 14 May 2007 18:15:57 +0200 > Subject: Re: [development] mode column in {users}? > > On 13 May 2007, at 02:26, Peter Wolanin wrote: > > Does anyone know if any core module uses the 'mode' column in the > > {users} table? A quick search with grep didn't turn up anything so I > > was thinking about using it as a flag for per-user behavior for a > > custom module for a little site. > > It belongs to the comment module -- it used to store the comment > viewing mode (i.e. threaded, flat, nested, collapsed). If that's no > longer used, we can remove it from the users table. > > -- > Dries Buytaert :: http://www.buytaert.net/ > > >

1 0

mode column in {users}?
by Peter Wolanin 14 May '07

14 May '07

Does anyone know if any core module uses the 'mode' column in the {users} table? A quick search with grep didn't turn up anything so I was thinking about using it as a flag for per-user behavior for a custom module for a little site. -Peter

5 4

Re: [development] update/replace the book module - poll, questions
by Peter Wolanin 14 May '07

14 May '07

Steven, I appreciate your perspective on this, and I'm well aware that the final decision on this will need to be an "executive" one- that poll is just one way to gauge the community sentiment. Note that a change to "Outline" would actually make it more consistent (as some have noted) with part of the existing UI for book module. Anyhow, there are at least 4 possible courses to take: 1) leave it as "book", with the data upgraded appropriately. 2) kick "book" out to contrib and put in a new module with an upgrade path. 3) eliminate "book" and put in a new module with an upgrade path. 4) Keep a minimally updated "book" in D6 and a new module which can convert over your existing book structure. Eliminate "book" in D7. -Peter >---------- Forwarded message ---------- >From: "Steven Peck" <speck(a)blkmtn.org> >To: <development(a)drupal.org> >Date: Sun, 13 May 2007 15:23:22 -0700 >Subject: Re: [development] update/replace the book module - poll, questions >Oh yes, let's just rename it. After all we have no years of historical need >to be consistent with our names. The rename of taxonomy to categories in >the UI has worked out excellently for everyone. Especially as someone >submitted a contrib. module named categories. That hasn't resulted in any >support/forum or documentation issues at all. > >There is no need to concern anyone with the vast number of forum and >documentation posts (or the few bits of marketing material) that reference >book module as a way to make a site. > >Renaming it will result in years of confusion. Which has been a PAIN with >taxonomy/category UI. IF it does get renamed, then we get to hunt down >_anyone_ who submits or approves a contrib. module named 'book'. > >It would have been better to write documentation that educated people. > >-sp

2 1

update/replace the book module - poll, questions
by Peter Wolanin 14 May '07

14 May '07

We're hoping to have a replacement for the book module that will be more general for creating a hierarchical site structure. What should such a module be named? Poll here: http://groups.drupal.org/node/3941 joshk indicated a willingness to be involved in the coding, but we really need feedback on what kind of UI such a module should have: http://groups.drupal.org/drupal-dojo/book-project Also, a question- any suggestions for how the upgrade/install path should look (at the code level) if the module name changes? -Peter

10 12

Module Annoucement: Views Mail
by Ron Parker 13 May '07

13 May '07

I was just reading this thread, "Code duplication, collaboration, and sandboxes. Oh my!", and thought it might be wise to post this message. I've developed (or, re-developed) a module called "Views Mail". Essentially, this module uses Views to create lists of users to whom you can send e-mail. The original discussion on how this came about is here: http://drupal.org/node/134931 The module can be downloaded from here: http://ftp.scbbs.com/pub/drupal/views_mail/ I've not requested a cvs account for it yet. Decided to run it by this list first to make sure I'm not duplicating effort. Thanks for any feedback. -ron -- Ron Parker Software Creations http://www.scbbs.com Self-Administration Web Site http://saw.scbbs.com SDSS Subscription Mgmt Service http://sdss.scbbs.com Central Ave Dance Ensemble http://www.centralavedance.com R & B Salsa http://www.randbsalsa.com

1 0

New module announcement
by Darren Oh 13 May '07

13 May '07

I have just released a module that can return the sabbath time for any week and any location: http://drupal.org/project/sabbath

2 2

PHP4 support
by Dries Buytaert 12 May '07

12 May '07

http://www.derickrethans.nl/php_quebec_conference_rip_php_4.php -- Dries Buytaert :: http://www.buytaert.net/

5 6

avoiding duplicate issue followups
by Derek Wright 10 May '07

10 May '07

yes, i know it's annoying that d.o keeps dying during issue followups (500s, squid errors, etc). we're looking into it. meanwhile, y'all should know: YOUR FOLLOW-UP WAS POSTED THE FIRST TIME ... ;) you don't have to keep reloading and pressing "submit" over and over again. that just produces duplicate follow-ups, and makes issues harder to read. if you get an error, just navigate yourself back to the issue's page and you'll see your reply is there. thanks, -derek

1 0

The Drupal Diet - Making bootstrap faster
by Larry Garfield 10 May '07

10 May '07

This is more of an RFC than a DEP, so please forgive the looser format and trademark verbosity. :-) My current push for Drupal 6 is to make it faster for non-opcode non-cached users. Drupal 5 was, according to Dries' benchmarks, a slight step backwards from Drupal 4.7 in that regard, so let's reverse that trend with a vengeance. Far and away the slowest part of the Drupal life-cycle is bootstrapping. According to Rasmus' keynote at Drupalcon, we spend just over 50% of the entire process just pulling code off disk and parsing it. A typical page load, however, uses only a small fraction of that. Thus, the biggest target for optimization is "load less code", but without violating the corollary, "load fewer files". As an example, I recently tried breaking up some core modules and loading page callbacks and form only when needed[1]. Even with that primitive breakup, we were able to get an 8-18% improvement in page load time and a 23% decrease in memory usage. I hate sayings like "the numbers speak for themselves", but in this case they do. On-demand loading of lesser-used module code has the potential to be a huge win, and the extra code required to make it possible is minimal. (The code linked in that issue only adds ~10 lines of code; the rest of the patch is just moving code around.) That of course begs the question, how to split up the code in a module? In general, I see 5 logical divisions of code within a module: 1) Rare hooks. hook_install() and hook_update() are the classic cases here, although I think hook_menu() in Drupal 6 may be moving in that direction. These are hooks called only at very specific, rare times. The other 99% of the time they're dead weight. 2) Common hooks. This is basically every hook that isn't one of the few rare hooks. These may be called at any time, more or less often. (For the time being I am going to lump hook_load(), hook_update(), etc. in here, even though they're technically not hooks as we've discussed previously.) 3) Page handlers. These are functions whose primary purpose in life is to be called from menu_execute_active_handler(). They serve no other serious function. 4) Form builders. These are the form definition, validation, and submission functions, as well as their sub-call helpers. 5) API functions. These are functions specifically exposed to other modules to do stuff, for some definition of stuff. 6 (nobody expects the Spanish inquisition!)) Utility functions. These functions are mostly intended for internal use but can sometimes be useful to other modules. The line between a utility function and an API function is very blurry since PHP functions have no concept of namespace or visibility. There aren't that many Rare Hooks, and most of them are already in .install files so I will ignore those for now. Common Hooks by nature need to be readily-available at any time. It is possible to dynamically load those, too, but that's a more complex issue, and one that merlinofchaos[2] and chx[3] have already started to address. I am therefore not going to deal with those, either. API functions also have to be readily-available, and utility functions probably should, too. So now that we've said we need to load most types of code, what does that leave us? That leaves us the two types of code that are used the least but take up the most lines of code. merlin and webchick recently went through a few core modules and cataloged what functions were of what type[4], and the results are clear: We spend most of our code on page and form handling, and yet only one page is ever handled per page load and, generally, only 1-2 forms! In terms of actual lines of code, all four modules in question (system, user, comment, block) are majority pages and forms, in some cases by over 2/3. That means page handlers and form handlers are the safest to factor out into separate on-demand files but also the biggest win from doing so. It's nice how that works out. So now we need a mechanism for on-demand loading of page handlers and form handlers, subject to the following conditions: 1) It should be an optional optimization. We don't want to force all modules to break up, because many, I'd say the majority, are small and simple enough that it would be a case of over-optimization to require, say, every form to be in a separate file or every module to have a .pages file. We also don't want to make module authoring an overly-difficult process with a dozen magic files. The degenerate case should be exactly how things work now. 2) It should be flexible. Different modules need to be optimized differently. Putting all page handlers into a single .pages file for a module could still mean loading 10x as much code as we really need. Module authors need to be able to factor their own modules in the way that makes the most sense for that module, which could mean one on-demand file or several. 3) It is impossible to determine the module that provides a function from the function name alone. Sure all functions (should) use $modulename_<something> as their format, but many modules have an underscore in their name. Given a function named "foo_bar_baz", is that the "bar_baz" function of the "foo" module, or the "baz" function of the "foo_bar" module? We can't tell. Therefore, unless we are going to simply exclude modules with such names from this system (and I think that's a really bad idea) we will have to explicitly specify the module or path for a given auxiliary file. 4) Modules may call page handlers and form handlers from other modules. Core does this in places (node.module calls a page handler from system.module, for instance) as do various contribs, so we can't assume that the calling module is the providing module. 4) Page handlers are called from the menu system; therefore, the logical place to decide if additional code is needed is the menu system. Since we can't presume or deduce a module from the handler, that means it has to be specified explicitly in hook_menu(). 5) Form handlers are called from drupal_get_form(), or from drupal_execute(). Many are parameters to drupal_get_form() being used as a page handler, but not all. drupal_execute() may be called from anywhere at any time, too, so forms need to be either already loaded or loadable on-demand at any time. I therefore propose (finally I get to this part!) to split off page handlers and form handlers in similar ways. == Page Handlers == Only one page handler is called per page load, so we only need to worry about a page handler becoming available in menu_execute_active_handler(). Modules provide information to the menu system via hook_menu(), so each menu item can optionally specify information on what file to load in order to make the handler available. That could be one of two ways: Pass a full path (eg, drupal_get_path('module', 'foo') . '/foo.pages.inc' ) or specify a file name and module name separately. For simple flexibility I favor the former. It's simple and effective and works for cross-module calls. It's also what's already implemented in the patch I mentioned earlier[1]. == Form Handlers == Forms are nearly always accessed via drupal_get_form() or drupal_execute(). We can therefore do the same sort of centralized improvement for the form system in those functions as we can for page handlers using menu_execute_active_handler(). That is, add a key to hook_forms() to specify a file in which the form lives. Here we can safely presume that the module implementing hook_forms() is also the home of the form functions in question, so we need specify only a file and not a module or path. If a module author wishes to split off one or more forms to another file, hook_forms() becomes a requirement just as it does for specifying an alternate callback function. drupal_get_form() and drupal_execute() then simply check for the existence of that key and include_one() the file if necessary. The total code involved should, like the page handler, be quite limited. Note: I will likely want to wait on implementing the forms part until the FAPI 3 patch lands, because I really don't want to tangle with both eaton and chx on that. :-) The nice thing about this approach, too, is that it doesn't have to be implemented all at once. Because the degenerate case still works, the initial implementation can work on only one or two core modules as a demonstration. The rest of core can be optimized module-at-a-time. That makes the patch easier to review as well as easier to maintain with the rest of core still being actively developed. Given the benchmarks that merlin found with the initial attempt, I'd say whatever the total performance gain is it should be substantial. To the potential problem of module authors "over-factoring" and hiding useful utility functions in a page handler when they shouldn't, I believe that really is solved by best practice guidelines. As a worst-case, a module author can manually include_once() a file out of another module's directory at no worse a cost than the extra parse time. It's still a net-win overall since even if one module gets sloppy-loaded the rest of the system is still well-factored, so there's still a net-reduction in the amount of code involved. Sooo... Now that the three of you who made it all the way through this email have gotten here, thoughts on this approach? Any caveats I'm missing? Any use cases I don't know about? Does this have a snowball's chance in hell of being accepted? <dons flame-retardant suit> [1] http://drupal.org/node/140218 [2] http://drupal.org/node/116165 [3] http://drupal.org/node/140218#comment-236614 [4] http://drupal.org/node/116165#comment-229856 -- Larry Garfield AIM: LOLG42 larry(a)garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

10 16