May 2009 - Development - lists.drupal.org

behaviors context
by David Cohen 01 Jun '09

01 Jun '09

I'm trying to implement a Drupal.behavior. I realize my behavior function is passed a "context". But it's unclear to me what that context will be. If I understand correctly, when the behavior is first invoked, it is passed document, a variable built into javascript. Later, when some module's javascript adds content to the page, my behavior will be invoked again. This time, context could be anything. The module which added the content can pass whatever. So for example in ahah.js, Drupal.attachBehaviors() is passed a jquery object representing the new content. While in modules/views/js/ajax.js, Drupal.attachBehaviors() is passed a string or id, either of which could be used in a jquery selector. Do I have this right? What I need is the javascript element (not jquery object) that is the added content. Does anyone have a snippet of code which returns this, given a context? Thanks, -Dave

7 13

Fwd: Re: behaviors context
by David Cohen 29 May '09

29 May '09

I think I get what you're writing about. It makes sense when you're behavior affects, say, all elements of a certain class. And you can update the class after the behavior acts. But in my case, I need to operate over all elements. So to do what you're talking about I'd need to add classes all over the place. Specifically, I'm working with Facebook Connect. And I need to tell facebook's javascript to parse any markup added to a page. They provide methods to do this, http://wiki.developers.facebook.com/index.php/JS_API_T_FB.XFBML.Host. One method parses the whole dom tree, another limits the parse to specific elements. For performance reasons I prefer to use the more limited method, but I'll resort to the other if I really have to. -Dave On Fri, 29 May 2009 14:34 -0500, "Matt" <matt(a)aleph-null.tv> wrote: > There are two patterns in Drupal JS to "prevent" the same behavior > from processing the same data twice. One is the :not(processed-X) > pattern, which seems to be pretty reliable, and is pretty much > entirely in the hands of the author of the behavior (barring a > misanthrope who decides to remove your processed classes). > >

1 0

preprocess page doesn't take all variables
by Ernst Plüss 28 May '09

28 May '09

Hi I'm trying to do a simple thing in D6: Add a variable to the page template. Unfortunately it seams, that it gets lost in theme_render_template. This is my code in the template.php: function ylt_preprocess_page(&$vars) { $vars['rabarber'] = 'rabarber'; } theme_render_template looks like this: function theme_render_template($template_file, $variables) { extract($variables, EXTR_SKIP); // Extract the variables to a local namespace ob_start(); // Start output buffering include "./$template_file"; // Include the template file $contents = ob_get_contents(); // Get the contents of the buffer ob_end_clean(); // End buffering and discard return $contents; // Return the contents } I can see rabarber in $variables, but it never ends up beeing extracted. Actually $variables contains about 47 entries but only about 12 of them get extracted. Is this a bug or am I doing something wrong? Best Regards Ernst

2 1

noderefernace cck
by Caleb O'Connell 28 May '09

28 May '09

I am looking to get info about the cck module in drupal. I've been trying to write a cck module that will basically do the exact same as nodereference but with two free entry text fields to go along with it. Basically, one field to be the noderef lookup and two to add prices to associate to the referred field. I wasn't sure who I could get in touch with in the cck development who is familiar with this so I can ask some questions about where to put the code I want in place to make the custom module I was looking for. Thanks again in advance. -- -- Caleb Dylan O'Connell -- caleb(a)caleboconnell.com -- 207.319.4746 -- http://blog.caleboconnell.com

4 6

Announcing DRUPAL-7-0-UNSTABLE-7
by Angela Byron 28 May '09

28 May '09

Bonsoir, devel list! It's been a *stupidly* long time since our last interim Drupal 7 unstable release. Sorry about that! I'm going to go ahead and blame this on taxes. And traveling. And a general lack of delicious ice cream in my freezer. It's a tragedy, really. But the *good* news is that DRUPAL-7-0-UNSTABLE-7 is jam packed full of awesomeness! That's right! JAM packed! The complete commit log is attached. There's also a full list of API changes in UNSTABLE-7 at http://drupal.org/node/224333#UNSTABLE-7 We are just about at the *three-month mark* until code freeze. That means the time to make your wildest Drupal dreams come true is RIGHT NOW. Check out the Drupal core initiatives page at http://drupal.org/community-initiatives/drupal-core to see what folks are tackling now if you're looking for a place to jump in. Or, feel free to add your own! Ok. Here we go! Changes for developers: ======================= - A spangly new Job Queue API which allows for batch processing of items. See http://api.drupal.org/api/group/queue/7 for more info. - Some nice performance improvements: o SimpleTest module no longer has to instantiate every test class in order to simply read its metadata. $memory_usage--; o There's now a taxonomy_vocabulary_load_multiple(), user_delete_multiple() to improve performance around massive amounts of these types of data. o Drupal now serves more sensible headrs for reverse proxies. o Core now defaults to using MySQL's InnoDB storage engine rather than MyISAM. - A new centralized static caching mechanism, so we don't need to litter $reset parameters all over the dang place. - New hooks hook_node_access_records_alter() and hook_node_grants_alter() to allow for complex interactions between multiple node access modules. - Field API improvements, including a pluggable storage mechanism, increased test coverage, and de-coupling from Form API. - Lots of DBTNG conversions. Less than 10 more to go! http://bit.ly/DBTNG_Conversion Yeehaw!! - Tests for OpenID module. We actually got a lot of tests, but these were *extra* awesome (and sorely needed), so I wanted to mention them specially here. ;) Changes for themers: ==================== - There are now nice extra body classes added to match a page's template suggestions. So for example node/1/edit would give you classes of page-node, page-node-edit, and page-node-1. The Zen theme offers this too in Drupal 6. - box.tpl.php is DEAD. DEAD, my friends! In its place are far more sensible theme_comment_form_box() and theme_search_results_listing(). That's right. There was absolutely nothing about box.tpl.php that had anything to do with block.module. Go figure. - A whole gaggle of formerly "special" things are now just regular old blocks. Footer message, feature-specific help text, mission statement, and even $content! This means they can be more precisely positioned and have the same configurable visibility as other blocks in the system. Changes for users: ================== - Those tired and ugly collapsed fieldsets on the node form have now become nice looking and useful Vertical Tabs! See http://buytaert.net/drupal-7-usability-update for a screeshot. - The horrible frankenstein "dumping ground of random crap" monster that is the default "Navigation" menu has now been split up into: o User menu: Contains "My account" and "Logout" links. This is positioned in the upper-right corner. o Management menu: Contains "Add new content" (formerly "Create content") and "Administer" links. Think of this as the "do stuff" menu. o Navigation menu: The same as before, but now at least with fewer links! :D - There's a slick new input format selector. Goodbye, 3-foot long collapsed fieldset with radios showing every godforsaken option known to mankind, hello compact, JS-ified select box! - There's a new top-level "International" administration menu for any localization/translation-related modules to put their stuff and a "Development" administration menu for developer tools. - On the permissions page, permissions checked for authenticated users will auto-check the same permissions for all other roles on the client side. This helps make it more obvious to people what checking that box actually does. - Removed Clean URL choice from installer. Seriously, are you ever going to opt *not* to have Clean URLs? If so, there's a settings page for that. :P - Some security improvements: o A watchdog event is now fired whenever modules are enabled/ disabled. o PHP module is now the "global killswitch" for whether users can use PHP anywhere in the system. Catch you next month, Drupalistas! :D -Angie

3 3

Status update: WYSIWYG support in Drupal core
by Daniel F. Kudwien 27 May '09

27 May '09

<Digital7> tha_sun: on the previous subject..so you know, wysiwyg is less customizable than straight up fck[editor.]module <Digital7> tha_sun: it's missing the ability to re-skin the buttons <Digital7> tha_sun: and it won't drop down a 2nd or 3rd bar for a full set of menu bar buttons <tha_sun> If you can code, you know how to alter the default skin. <Digital7> tha_sun: i mean by standard configuration <tha_sun> sure <tha_sun> We've got a lot to do in the area of wysiwyg api... <Digital7> tha_sun: no complaints though, that is definitely a better module once it is a bit more mature <tha_sun> OTOH, unlike fckeditor.module, wysiwyg api requires no hacks in other modules, manual config file changes, etc. <Digital7> tha_sun: that's a plus...fckeditor.module burned several hours of my time <Digital7> tha_sun: initially ... <Digital7> tha_sun: what's keeping you from getting that module standardized in drupal? <tha_sun> Digital7: I guess you mean in core? <Digital7> tha_sun: yes--if that's the proper term for a module included with the standard installation <tha_sun> Digital7: There are many reasons. <tha_sun> Digital7: Starting with http://drupal.org/project/libraries <tha_sun> Digital7: A few others... <tha_sun> But ultimately ending in: countless support and feature requests, which Drupal core most likely can't handle. <Digital7> tha_sun: seems like it'd be a top priority for the project..given how significantly it improves the usability <tha_sun> We have yet to find a solution for this issue. <tha_sun> You know. <tha_sun> I'm an evil maintainer. <tha_sun> You get a won't fix before you submit an issue. <tha_sun> Drupal core, though, depends on many volunteers to do this job. <tha_sun> And, many of them, don't know the innards of the system. <Digital7> i still see it happening whether it be sooner or later <tha_sun> So, insane feature/support requests live too long, although they won't ever fix. <tha_sun> If we add wysiwyg to that list, we will double or even triple the size of all open core issues. <tha_sun> It will happen. We just have to find out _how_.

22 27

HEAD broken for a few hours tonight
by Angela Byron 25 May '09

25 May '09

Really sorry, folks. :\ I made the fatal error of jumping the gun before waiting for testing bot results on a "trivial" patch http://drupal.org/node/471234 which just so happened to break the installer. Oops. :\ I'm pretty sure I reset the statuses of all the issues that were mistakenly "needs work"ed but if you see that testing bot has said that your patch has "Failed: Failed to install HEAD." sometime tonight, go ahead and submit it for re-testing, as it was probably a mistake. /me dons the dunce cap of SHAME... -Angie

3 2

need a standard for contrib node build_mode constants
by Peter Wolanin 22 May '09

22 May '09

When doing some cleanup of my Modr8 module, I wanted to define a new build_mode for use by http://api.drupal.org/api/function/node_build_content/6 I realized that we don't have any standard for picking new int constants for this case in specific, or more generally. So, here's a suggested standard that I think is nearly fool-proof: When defining an additional build mode constant (or similar constant) in a contributed module, the suggested standard is to use the unix timestamp of when you write the code to minimize the likelihood of two modules using the same value. I think it's sane and nearly perfect since a new module will then never pick the same value as an existing module, and in general it's very unlikely that 2 people will by writing a new constant the same second. Am I missing anything? Any reason not to suggest this as a standard? -Peter PS - a couple easy ways to get the timestamp on you command line: date -j "+%s" php -r 'echo time() ."\n";'

10 17

The future of hook_node_info()
by Arancaytar Ilyaran 22 May '09

22 May '09

Hey all, This is just a bit of idle speculation (and it may even have been discussed before) but I wanted to share my observation. There may be a changing trend in how Drupal perceives node types. Way back, a node type was handled by exactly one module. Most type-specific functionality could only be applied to the native type. For example, CCK defined "cck-clones" of all existing content types in 4.7. You need to go back as far as 4.0 (see changelog) to see book.module adding support for non-book nodes, but that's still where we came from. Even in Drupal 4.7 we had story.module and page.module providing what have since become custom content types created by the installation profile. Between Drupal 4.7 and Drupal 5, a lot of these type-specific features became universal. CCK stopped implementing hook_node_info and expanded hook_nodeapi (which had only watched the 'delete revision' action before). story.module and page.module got axed. In Drupal 6, book.module stopped implementing hook_node_info() too, in favor of creating a type handled by node.module, and treating all node types the same way. Altogether, we're down to three hook_node_info implementations in Drupal 7 (from six in Drupal 4.7), which are blog.module, forum.module and poll.module. Coincidentally, these modules are all somewhat notorious: forum.module's has a very frustrating visual style, poll.module has been called our "regression test", and both poll.module and blog.module have been considered for removal (Google "remove X from core"). Only poll.module can still make a convincing case for using hook_node_info, but even poll stuff could in theory be added to generic nodes. Will hook_node_info() eventually die entirely, in favor of working on nodes centrally handled by node.module? Should it? Thanks for reading all the way, :) -Aran -- PGP: http://ermarian.net/downloads/0x27CA5C74 XMPP: arancaytar.ilyaran(a)gmail.com AOL: 282026638 @icq / RealArancaytar @aim URL: http://ermarian.net

8 8

drupal Windows and PostgreSQL
by Ivan Sergio Borgonovo 20 May '09

20 May '09

I was recently positively surprised to see that the Windows installer of PostgreSQL offers you the chance to install Drupal as well. This honour our CMS and it should be an incentive to avoid to consider Postgresql as a poster child. I wonder if any other open source DB comes bundled with Drupal on Windows. -- Ivan Sergio Borgonovo http://www.webthatworks.it

2 2