September 2009 - Development - lists.drupal.org

Announcing DRUPAL-7-0-UNSTABLE-9
by Angela Byron 15 Sep '09

15 Sep '09

Tonight seemed like as good a night as any to roll another interim unstable release for Drupal 7, so say hello to DRUPAL-7-0-UNSTABLE-9. I'll detail the exciting changes in a bit here, but first a few procedural things. For those who missed Dries's keynote at Drupalcon Paris (http://www.archive.org/details/TheStateofDrupal ), I'll give a recap of the parts that pertain to Drupal 7's development/release cycle: * Code freeze was extended an extra week until 9/8 to allow people in Paris (as well as abroad) to collaborate on last-minute frenzied features. Dries and I are working through last week's RTBC queue now that we're both home for a couple of days. ;) * We're now in a "code slush" phase, which means that Drupal 7 is feature frozen, apart from a few hand-selected exceptions, as well as API and markup clean-ups for existing features. Additionally, we allow improvements to Drupal's usability (minor changes), accessibility, performance, testing framework, documentation, and user interface text during this phase. Code slush is time-boxed until Oct. 15, at which point we'll enter a "hard" freeze. Then, no more XHTML markup changes, no more function signature changes, and no more database changes. * That means it'd be a /really/ good idea to begin poking at your Drupal 7 module/theme porting, oh... now-ish... so that if we missed something blatantly obvious during development of D7, we can fix it while the code is still somewhat malleable. Coder has a 7.x version to help with this: http://drupal.org/project/coder, and also consider taking the #D7CX pledge for your project: http://drupal.org/project/modules?solrsort=sort_title%20asc&text=d7cx&displ… * From Oct. 15 to Nov. 15 will be the "strictly polish" phase, where we can continue to do things such as minor accessibility and usability improvements, performance improvements, and documentation and string improvements. November 15 will then mark both a string *and* UI freeze, so that the documentation and translation teams can get busy preparing for the Drupal 7 release. * Patches that expand Drupal's automated test coverage, as well as bug fixes, can be accepted at any time up through release. * Drupal 7 will be released "when it's ready", which is when all critical issues are resolved. Keep your eyes on http://drupal.org/project/issues/search/drupal?status []= Open&priorities[]=1&categories[]=bug&categories[]=task&version[]=7.x, or enable the "Contributor block" in your drupal.org user profile to get a handy count (currently at 400). Here are some "hit lists" along with helpful deadlines for you all: * Feature freeze exceptions (Oct. 15): http://drupal.org/project/issues/search/drupal?issue_tags=Exception+code+fr… * API clean-ups for existing features (Oct. 15): http://drupal.org/project/issues/search/drupal?&issue_tags=API%20clean-up * XHTML markup (Oct. 15): http://drupal.org/project/issues/search/drupal?issue_tags=tpl-refresh * Testing framework (Oct. 15): http://drupal.org/project/issues/search/drupal? component[]=simpletest.module * Minor usability improvements (Nov. 15): [some of] http://drupal.org/project/issues/search/drupal?issue_tags=Usability * Accessibility (Nov. 15): http://drupal.org/project/issues/search/drupal?issue_tags=accessibility * Performance patches (Nov. 15): http://drupal.org/project/issues/search/drupal?issue_tags=Performance * Documentation improvements (Nov. 15): http://drupal.org/project/issues/search/drupal? component[]=documentation * String fixes (Nov. 15): http://drupal.org/project/issues/search/drupal?component[]=user +interface+text * Test coverage (Any time): http://drupal.org/project/issues/search/drupal?issue_tags=Needs+tests Ok, now that the whip-cracking is out of the way, here are the changes in this snapshot! :D As always, the full change log is attached below. Changes for developers: ======================= * Database-wise, core is now fully DBTNG-compliant! YAY! We also added basic support for 'date' and 'time' types to Schema API, update_sql() is dead, dead, dead, AND now hook_uninstall() and hook_install() will automatically handle your schema definitions. Ahhh. * The File API now uses stream wrappers for accessing files, which basically means that all functions that used to take a file path now take a URI like public://old_photos/banana.jpg. Core ships with three default stream wrappers: temp://, public://, and private:// (which means that public and private files FINALLY co-exist!) with support for contrib to offer wrappers such as s3:// for Amazon S3, flickr:// for getting data into/out of Flickr, and so on. We also added a hook_file_url_alter() for content delivery network (CDN) support. w00t! * Remember that awesome code registry I talked about back in UNSTABLE-1 or so that was going to solve all of our performance woes? Yeeeah... Turns out, it caused severe developer experience issues, in addition to not offering performance improvements on par with more well-supported systems such as APC, so this got partially rolled back. The registry no longer caches functions, though we do still offer a class registry, which means that $foo = new Foo; will work from anywhere. * Field API improvements: Taxonomy terms are now fields, comments and taxonomy terms are fieldable, and fields are also now translatable. * In terms of clean-ups, we now have the R part of a real CRUD API in core with standardized, swappable entity loaders. We also have a *real* user and permissions API, as well as a filter API. We also renamed 'box' to 'custom_block' in the name of sanity. * Performance-wise, we now ship with "smushed" images that are lighter on bandwidth, and we've now added a caching system to the render API which is currently implemented by blocks, and because it happens early in the page render cycle, it works for both authenticated users and with node access modules. Yum. * Install profile improvements! Shock! Install profiles are now basically modules with .install files, .info files to declare dependencies, etc. If you can write a module, you can write an install profile, and you can also do everything from install profiles you can do with modules including use the full Drupal API and write update functions to move from one version to another. Speaking of versions, you can now specify version-level dependencies in your .info files, so you can say your module depends on at least Views 2.0-rc1 but less than Views 3.0. And finally, you can run update.php and install.php from the command line without Drush having to do unholy things. Yay! * In terms of our testing framework, there's now a debug() function which can be used as a 'lite' version of dsm(), and also prints debugging data as SimpleTest assertions. There's also a new "verbose" mode which logs screen captures of the pages SimpleTest hit on its way through, along with the assertion messages. This should make figuring out why tests are failing MUCH easier! Thanks to the testing sprint in LA back in mid-August, we also greatly grew our test coverage and cleaned up a lot of lingering test patches from back in Szeged. Changes for themers: ==================== * Regions $sidebar_left and $sidebar_right are now called $sidebar_first and $sidebar_second, for better semantics and to make them more RTL-friendly. * The AJAX framework from CTools is now in core, and core now supports a new .once() method for ensuring that a behaviour applies only a single time. I don't really know what any of this means, but the JS folks are really excited about it. ;) * You can now use a "wildcard" operator in tpl.php files, for example page-user-%.tpl.php to affect any user/xxx while letting page- user.tpl.php affect only the actual page /user. * In accessibility news, there are now system-wide classes for marking elements as either completely hidden (.element-hidden: equivalent to jQuery's hide() function) or invisible (.element-invisible: visible only to screen readers). We're now working to apply those classes to various points in core, as well as other important accessibility improvements. Changes for end-users: ===================== * CC-FREAKING-K IN CORE! OH YEAH! :D Not to mention Token, FileField, and Poormanscron! * As a trade-off, lots of extraneous features were removed from core in favour of either contributed modules or field API alternatives: minimum number of words on the body field, related terms for taxonomy terms, per-user theme selection, Blog API module. * The D7UX IA is fully in place; no more confusing "half the items are in 'Site configuration' and half under 'Configuration & Modules'" stuff. Thanks for bearing with us while we went through that transition! * Some nice security improvements. Users are now prompted at install time to get notified via e-mail about security updates for their sites. This is great because I'm pretty sure almost no one realizes this is a setting in Drupal 5 and 6. :P We also now limit the number of login attempts to help prevent brute force attacks. And running update.php is now tied to a permission rather than having to open it up to the entire universe if you don't like sharing your user 1 password. Oh, and last but not least, SSL support in core! :D

3 2

Re: [development] How to reuse uploaded files
by Peter Droogmans 14 Sep '09

14 Sep '09

You can also have a look at the webfm project. Met vriendelijke groeten, Peter Droogmans Attiks Ketsstraat 94 2140 Borgerhout peter(a)attiks.com 03-288 61 17 0497-44 44 77 ________________________________ From: Ken Winters <kwinters(a)coalmarch.com> Sent: zondag 13 september 2009 18:37 To: development(a)drupal.org <development(a)drupal.org> Subject: Re: [development] How to reuse uploaded files Unfortunately file management is one of the big weaknesses in Drupal 6, and I've never found a solution that I really liked. There are a lot of efforts toward improving that in D7 (the Media project, and assorted core file handling improvements) but for now there are only half-measures. John's suggestion is one of the reasonable methods, and IMCE plus TinyMCE is the common way to manage embedded images. - Ken Winters John Fiala wrote: Hey there, Gaston. (I aplogize for not spelling your name quite right, but I'm not sure how to produce that o with my keyboard.) Basically, once a file is uploaded, it exists in the files directory - so if you know the name, you can fairly easily use it (as in an image tag) anywhere you like. As for associating that file with another node, that I'm not as familiar with off of the top of my head. (Indeed, for re-using image files, I've tended to use an image node, which consists of a simple node with an imagefield, and then using nodereference to associate it with various nodes.) 2009/9/12 Gastón Pablo Pérez <gpperez(a)gmail.com><mailto:gpperez@gmail.com>: Hi everybody! I'm using the upload module to upload files into the Drupal nodes. The question is, how can I reuse the files uploaded in a particular node in other nodes? Exists a module to do this? thanks Gastón Pablo Perez Email:gpperez@gmail.com<mailto:Email:gpperez@gmail.com>

1 0

Why I don't Upload a Module to Drupal
by Sam Polenta 14 Sep '09

14 Sep '09

I have made a few custom modules for clients. Some of them maybe other people would want. I would be happy to give them to whoever wants them, BUT it's not necessarily so simple as that. Mostly they have some customization for the particular site so I would have to generalize them like with a settings page etc. Then I would have to clean up the code a bit. Some would need an install and uninstall routine which I didn't do because it's only for one site anyway. I would be happy even, in theory, to release them on drupal.org but aside from the time to prepare them, which I don't really have, I also don't have time to support them. So I figure even if I did fix it up a bit and put it online, I am then expected to support it. I am not a lazy person nor do I just suck the blood of everyone else who contributes to Drupal without giving back. I do try to help people on the forums a bit and the truth is that I help to "make the world a better place" in other ways. I volunteer at a local NPO to help people--when I sit down at the computer, it's mostly to work. I need to make a living and this is how I do it. So I don't think I'm a total pig--not at all really because I do volunteer my time, but just for other causes aside from Drupal. Do people think my reasons are wrong for not releasing my code? I guess the main thing is that I'm not prepared to support any issues or requests etc. that may come up. Thanks.

14 16

How to reuse uploaded files
by Gastón Pablo Pérez 13 Sep '09

13 Sep '09

Hi everybody! I'm using the upload module to upload files into the Drupal nodes. The question is, how can I reuse the files uploaded in a particular node in other nodes? Exists a module to do this? thanks Gastón Pablo Perez Email:gpperez@gmail.com <Email%3Agpperez(a)gmail.com>

4 3

Generating page output for your pages
by rajasekharan 13 Sep '09

13 Sep '09

Hi all, How do you generally accumulate the output for the various pages in your module functions that have to return some HTML? I have been directly printing all my desired output and using the php output buffer functions to get the page's output. I haven't seen many other authors do this. May be I am doing something wrong, what is the generally followed method for this? Raj

3 2

Consulting about Couloir slideshow
by Gastón Pablo Pérez 10 Sep '09

10 Sep '09

I'm using the module Couloir slideshow to create some galleries in a Drupal 6 web site, the module is amazing but the problem is that in the configuration section of this, the module allows me to add only 10 blocks of the type Couloir slideshow, I want to create more than 10, how can i do this? Greetings Gastón Pablo Perez Email:gpperez@gmail.com <Email%3Agpperez(a)gmail.com>

1 0

Creating separate registration forms for each role
by rajasekharan 10 Sep '09

10 Sep '09

Hi, In a current project, I have to create a separate registration form for each role. For example, "customers" has a registration form and "vendors" have a registration form that is separate. Any idea how I may achieve this using existing drupal modules? Thanks in advance, Raj Sekharan

4 11

Re: [development] development Digest, Vol 81, Issue 7
by sagar ramgade 09 Sep '09

09 Sep '09

Hi, Yes there is a way for separate fields for seperate roles provided you are using auto assign role and content profile. When you mark a content as content profile, you can find a tab called content profile. At the bottom you can see an option stating use this content for a specific role which appears only if auto assign role module is installed. Hence for each role there will be a single content type. So create another content type and use it for other role. I hope this helps. Regards Sagar www.biigpiic.com --- On Wed, 9/9/09, development-request(a)drupal.org <development-request(a)drupal.org> wrote: From: development-request(a)drupal.org <development-request(a)drupal.org> Subject: development Digest, Vol 81, Issue 7 To: development(a)drupal.org Date: Wednesday, 9 September, 2009, 10:07 PM Send development mailing list submissions to development(a)drupal.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.drupal.org/listinfo/development or, via email, send a message with subject or body 'help' to development-request(a)drupal.org You can reach the person managing the list at development-owner(a)drupal.org When replying, please edit your Subject line so it is more specific than "Re: Contents of development digest..." Today's Topics: 1. RE : Creating separate registration forms for each role (fgm) 2. Re: Creating separate registration forms for each role (rajasekharan) 3. Re: Creating separate registration forms for each role (Ken Winters) 4. Modify environment before & after block is rendered (Olivier Jacquet) 5. Re: Modify environment before & after block is rendered (Daniel Honrade) 6. Re: Modify environment before & after block is rendered (Olivier Jacquet) 7. Re: Modify environment before & after block is rendered (Fred Jones) 8. Re: Creating separate registration forms for each role (rajasekharan) ---------------------------------------------------------------------- Message: 1 Date: Tue, 8 Sep 2009 22:11:59 +0200 From: fgm <fgm(a)osinet.fr> Subject: [development] RE : Creating separate registration forms for each role To: "development(a)drupal.org" <development(a)drupal.org> Message-ID: <AB5758215C066A4D8CE78D21A77DA1FC0981576C25(a)MBXVS01.hosting01.active24.com> Content-Type: text/plain; charset="iso-8859-1" A combination of auto-assign-role and content-profile-register does it. NikLP could tell you more... ________________________________________ De : development-bounces(a)drupal.org [development-bounces(a)drupal.org] de la part de Ken Winters [kwinters(a)coalmarch.com] Date d'envoi : mardi 8 septembre 2009 21:30 ? : development(a)drupal.org Objet : Re: [development] Creating separate registration forms for each role I believe he wants the actual form to be different. We did something similar using the Profile module to create the fields for all roles and then hook_user, hook_form, etc. to make sure that only the right fields are displayed based on arg(2) (or whatever) and then processed correctly. - kwinters Aradhana wrote: > Hi, > > There is a drupal module names auto assign role.. which provides same > functionality. We can differentiate forms on the basis of url. e.g > assign different url for vendors registration and different url for > customers. > > http://drupal.org/project/autoassignrole > > Regards, > Aradhana > > rajasekharan wrote: >> Hi, >> >> In a current project, I have to create a separate registration form >> for each role. For example, "customers" has a registration form and >> "vendors" have a registration form that is separate. Any idea how I >> may achieve this using existing drupal modules? >> >> Thanks in advance, >> Raj Sekharan >> > ------------------------------ Message: 2 Date: Wed, 09 Sep 2009 02:33:37 +0530 From: rajasekharan <websweetweb(a)gmail.com> Subject: Re: [development] Creating separate registration forms for each role To: development(a)drupal.org Message-ID: <4AA6C6A9.60603(a)gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Thanks much! I got what I wanted. I am going to use autoassignroles module and then use the method Ken has mentioned - add profile attributes and then use the necessary hooks to modify the form to show the necessary fields. Ken Winters wrote: > I believe he wants the actual form to be different. > > We did something similar using the Profile module to create the fields > for all roles and then hook_user, hook_form, etc. to make sure that > only the right fields are displayed based on arg(2) (or whatever) and > then processed correctly. > > - kwinters > > Aradhana wrote: >> Hi, >> >> There is a drupal module names auto assign role.. which provides same >> functionality. We can differentiate forms on the basis of url. e.g >> assign different url for vendors registration and different url for >> customers. >> >> http://drupal.org/project/autoassignrole >> >> Regards, >> Aradhana >> >> rajasekharan wrote: >>> Hi, >>> >>> In a current project, I have to create a separate registration form >>> for each role. For example, "customers" has a registration form and >>> "vendors" have a registration form that is separate. Any idea how I >>> may achieve this using existing drupal modules? >>> >>> Thanks in advance, >>> Raj Sekharan ------------------------------ Message: 3 Date: Tue, 08 Sep 2009 17:26:05 -0400 From: Ken Winters <kwinters(a)coalmarch.com> Subject: Re: [development] Creating separate registration forms for each role To: development(a)drupal.org Message-ID: <4AA6CBED.1040707(a)coalmarch.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Great! I just wanted to mention that the hooks method might not be required for your particular needs. Autoassignrole plus content_profile are pretty handy, but our specific case had some elaborate requirements so we needed the hooks anyway. - kwinters rajasekharan wrote: > Thanks much! I got what I wanted. I am going to use autoassignroles > module and then use the method Ken has mentioned - add profile > attributes and then use the necessary hooks to modify the form to show > the necessary fields. > > Ken Winters wrote: >> I believe he wants the actual form to be different. >> >> We did something similar using the Profile module to create the >> fields for all roles and then hook_user, hook_form, etc. to make sure >> that only the right fields are displayed based on arg(2) (or >> whatever) and then processed correctly. >> >> - kwinters >> >> Aradhana wrote: >>> Hi, >>> >>> There is a drupal module names auto assign role.. which provides >>> same functionality. We can differentiate forms on the basis of url. >>> e.g assign different url for vendors registration and different url >>> for customers. >>> >>> http://drupal.org/project/autoassignrole >>> >>> Regards, >>> Aradhana >>> >>> rajasekharan wrote: >>>> Hi, >>>> >>>> In a current project, I have to create a separate registration form >>>> for each role. For example, "customers" has a registration form and >>>> "vendors" have a registration form that is separate. Any idea how I >>>> may achieve this using existing drupal modules? >>>> >>>> Thanks in advance, >>>> Raj Sekharan > ------------------------------ Message: 4 Date: Wed, 09 Sep 2009 09:13:18 +0200 From: Olivier Jacquet <ojacquet(a)jax.be> Subject: [development] Modify environment before & after block is rendered To: development(a)drupal.org Message-ID: <4AA7558E.2080100(a)jax.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, When themename_preprocess_block() is called the content of the block is already rendered. I am looking for a way to modify the environment before the block is rendered and a way to restore the environment afterwards. The specific use case is that I have two blocks, generated by views, one showing the terms from one taxonomy and the other the titles of the nodes belonging to that taxonomy. When one navigates to a node the link to that node is active but I would like the link to the taxonomy to be active as well. An easy way to accomplish this would be to do a menu_set_active_item('taxonomy/term/tid') before the taxonomy block is rendered and reset it afterwards. Unfortunately this doesn't seem to be possible. The only other way I can think of is to modify the block content via regular expressions in themename_preprocess_block(). Thank you for your time, Olivier ------------------------------ Message: 5 Date: Wed, 9 Sep 2009 17:49:53 +0800 From: Daniel Honrade <mail(a)danielhonrade.com> Subject: Re: [development] Modify environment before & after block is rendered To: development(a)drupal.org Message-ID: <db20d290909090249i3ef287b1x1ceb75f412a3ee4e(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" have you tried taxonomy menu module? On Wed, Sep 9, 2009 at 3:13 PM, Olivier Jacquet <ojacquet(a)jax.be> wrote: > Hi, > > > When themename_preprocess_block() is called the content of the block is > already rendered. I am looking for a way to modify the environment before > the block is rendered and a way to restore the environment afterwards. > > The specific use case is that I have two blocks, generated by views, one > showing the terms from one taxonomy and the other the titles of the nodes > belonging to that taxonomy. > > When one navigates to a node the link to that node is active but I would > like the link to the taxonomy to be active as well. An easy way to > accomplish this would be to do a menu_set_active_item('taxonomy/term/tid') > before the taxonomy block is rendered and reset it afterwards. Unfortunately > this doesn't seem to be possible. > > The only other way I can think of is to modify the block content via > regular expressions in themename_preprocess_block(). > > > Thank you for your time, > Olivier > -- Daniel Honrade, Jr. mobile: +63 915 903 3561 alternate email: danielhonrade(a)gmail.com websites: http://danielhonrade.com http://webtheming.com When you signup for PayPal, you can start accepting credit card payments instantly. As the world's number one online payment service, PayPal is the fastest way to open your doors to over 150 million member accounts worldwide. Best of all, it's completely free to sign up! To sign up or learn more, click here: https://www.paypal.com/ph/mrb/pal=GE47NYP4D94XA

1 0

Modify environment before & after block is rendered
by Olivier Jacquet 09 Sep '09

09 Sep '09

Hi, When themename_preprocess_block() is called the content of the block is already rendered. I am looking for a way to modify the environment before the block is rendered and a way to restore the environment afterwards. The specific use case is that I have two blocks, generated by views, one showing the terms from one taxonomy and the other the titles of the nodes belonging to that taxonomy. When one navigates to a node the link to that node is active but I would like the link to the taxonomy to be active as well. An easy way to accomplish this would be to do a menu_set_active_item('taxonomy/term/tid') before the taxonomy block is rendered and reset it afterwards. Unfortunately this doesn't seem to be possible. The only other way I can think of is to modify the block content via regular expressions in themename_preprocess_block(). Thank you for your time, Olivier

3 3

using variable in node_add callback
by Lluís 08 Sep '09

08 Sep '09

I have added a menu to insert nodes but I need use %variable inside node_form; how could I achieve this? $items['node/%/pressupost/afegir'] = array( 'title' => 'afegeix', //trans 'access callback' => 'cc_projects_isProject', 'access arguments' => array(1,'create pressupost'), 'type' => MENU_LOCAL_TASK, 'weight' => 10, 'page callback' => 'node_add', 'page arguments' => array('cc_pressupost'), 'file' => 'node.pages.inc', 'file path' => drupal_get_path('module', 'node'), ); thanks -- *La vida és com una taronja, què esperes a exprimir-la? *Si creus que l'educació és cara, prova la ignorància. *La vida és com una moneda, la pots gastar en el que vulguis però només una vegada. *Abans d'imprimir aquest missatge, pensa en el medi ambient.

3 4