- Development - lists.drupal.org

possible cache improvement
by Ivan Sergio Borgonovo 05 Jan '10

05 Jan '10

Hi, I was trying to solve a cache problem with D5/D6 and I thought to check how D7 solved those problems. Generally I was trying to have more control on page cache to still be able to exploit it even when some content has to be "tailored" for anonymous users or to switch cache off responding to "external" input. eg. suppose I'd like to show a greeting on all pages to people having a certain IP or the site should write a message on all pages to anonymous users that filled in a form or from time X to time Y I should display a banner on all pages. So pages may be retrieved from cache or not according to some condition that I should verify at page request. I may save something into $SESSION but still be willing to save cached version of certain pages. Furthermore I should be able to control $expire at content creation time, not as a general parameter (some content may have a longer expected TTL). I started to partially solve this problem in D5/6 in include/bootstrap.inc if (!$user->uid && $_SERVER['REQUEST_METHOD'] == 'GET' && count(drupal_set_message()) == 0 && $_SESSION['cacheable']!==false) { Then I thought that modules could switch on/off cache for different reasons... So the above became if (!$user->uid && $_SERVER['REQUEST_METHOD'] == 'GET' && count(drupal_set_message()) == 0 && !in_array(false, $_SESSION['cacheable'], true) I think a similar system could be applied to D7 and not just consider un-cacheable a page if $SESSION is not empty. Still this is not enough to decide if a page has to be returned from cache or not depending on "external" events. If hook_boot could be anticipated before the cache is filled this could be exploited for controlling the cache too. It would be nice to be able to explicitly set $expire at content creation but this look a bit more invasive to obtain. Does it sound reasonable? -- Ivan Sergio Borgonovo http://www.webthatworks.it

1 0

Calendar display not right
by Nancy Wichmann 04 Jan '10

04 Jan '10

When I first display the monthly calendar (example.com/calendar) the columns are narrow but if I go forward a month, then back (so now at /calendar/2010-01), the calendar looks like it should. Anyone have an idea how to fix this? Nancy E. Wichmann, PMP Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.

1 0

'old' core 6 & new 7, working together..?
by Ad 04 Jan '10

04 Jan '10

Hello, To my opinion, the imminent release of the 7 core might better be delayed. Untill today, many mods for 5 and even 4, are not available for the 6 version. And there are several mods that are neccesary on some websites, so in some cases one better doesn't migrate to 6 (or even not from 5 in fewer cases). Do I propose waiting untill maybe all the mods are available for 6? No; that would not change anything to the fact, that it will take many years before almost all interesting mods are programmed for core 7. What I propose is a bridge, cloud, integration of TWO cores; the 6 and 7 core: Two installations (might be on another server too). Waste of time that better can be used programming core 7 mods...? Maybe, but that bridge_cloud could serve also for 7 to the future 8, bridging and clouding the same Drupal versions, Mediawiki and many other programs. Especially when its written like: 1) a very broad multifunctional adapter, 2) with additional the 6 to 7 bridge 3) and many other specific bridges to make for other programs. I'm not a programmer except for a blue monday and not familiar with internal details of how Drupal works. So there probably are many hughe problems to resolve to get something like this done. But: 1) a General Bridge-Cloud-Adapter for core 7? 2) then a 6_to_7_Bridge working with GBCA? 3) then other bridges working with GBCA, like Mediawiki, etc.? If this is practically possible, my opinion is that first the core 7 software should be revised thoroughly to make this core perfect for such external connections/communications/integration... Related question: Doesn't there exist a uniform protocol how different programs can integrate? If so; the core better should already be build according to these characteristics. If not, maybe some developers can form a broad based group to get such a protocol into practice? Thanks, Ad

7 6

Proposal: Drupal University
by James Benstead 02 Jan '10

02 Jan '10

I've spent sizeable chunks of the last year or so trying to learn Drupal. To start with, I had a problem understanding the documentation. Now I've overcome that hurdle, I'm experiencing issues with the *structure* of documentation. I am usually able to solve individual problems for individual projects, but if I want to learn something in a more abstract fashion - for example, learning how Drupal works with Javascript so that I can understand a JavaScript-based module - I come a bit unstuck. I also hit problems if I want to sit down and just learn something new about Drupal. Sure, I can (and do) go onto IRC and ask a question along the lines of "I can do x, y and z with Drupal; what should I learn to do next?", but this doesn't always work and the quality of the answers I get just isn't consistent. So, what I'm proposing is something along the lines of Wikiversity ( http://en.wikiversity.org/wiki/Wikiversity:Main_Page) for Drupal: a set of structured (but informal) courses that bring together different pieces of documentation from both within and without d.o. Has anything like this been tried before? What do you think of the idea? --J. -- Google Talk/Windows Live Messenger/AIM: james.benstead(a)gmail.com Yahoo! Messenger/Twitter/IRC (Freenode): jim0203 Jabber: jim0203(a)jabber.org // ICQ: 7088050 Skype: jimbenstead

10 22

Form element wrapper IDs
by Martin Stadler 02 Jan '10

02 Jan '10

Hi! I stumbled upon the issue that there are no form element wrapper IDs for radios and checkboxes without the #title or #description attributes in D6 (http://drupal.org/node/215301) I need an ID to hide the label with CSS for accessability. I checked how this is in D7 and it seems to me that there are no wrapper IDs at all, only classes which are in the case of radios and checkboxes not unique (I know that classes are not supposed to be unique, that's why I want IDs): <div class="form-item form-type-radios form-item-myformelem"> <label>My Form Element </label> <div class="form-radios"> <div class="form-item form-type-radio form-item-myformelem"> <input type="radio" id="edit-myformelem-0" name="myformelem" value="0" checked="checked" class="form-radio" /> <label class="option" for="edit-myformelem-0">Option 1 </label> </div> <div class="form-item form-type-radio form-item-myformelem"> <input type="radio" id="edit-myformelem-1" name="myformelem" value="1" class="form-radio" /> <label class="option" for="edit-myformelem-1">Option 2 </label> </div> </div> </div> In modern browsers this may be ok but in IE6 I can't access the wrapper div nor the top label directly. If #title is omitted in the PHP form api code then we get <div class="form-radios"> <div class="form-item form-type-radio form-item-myformelem2"> <input type="radio" id="edit-myformelem2-0" name="myformelem2" value="0" checked="checked" class="form-radio" /> <label class="option" for="edit-myformelem2-0">Option 1 </label> </div> <div class="form-item form-type-radio form-item-myformelem2"> <input type="radio" id="edit-myformelem2-1" name="myformelem2" value="1" class="form-radio" /> <label class="option" for="edit-myformelem2-1">Option 2 </label> </div> </div> How can I style this individual wrapper now? I may have multiple radios in my form. Actually the problem is the same in D6 and D7. In D6 we have wrapper IDs but not for radios and checkboxes and in D7 we have kind of unique classes for the wrappers but these are not unique for radios and checkboxes. Why were the wrapper IDs removed in D7? Pseudo-unique classes seem strange to me. How can we have a unique accessor for wrappers for radios and checkboxes? Can we add the wrapper IDs for them in D6? Why were these wrapper IDs unset in D6? Martin

3 2

Taxonomy Menu Version 3
by Neil Hastings 01 Jan '10

01 Jan '10

Hello fellow developers. This is an exciting time for Taxonomy Menu<http://drupal.org/project/taxonomy_menu>. I have just released the new UI that will be the base for creating menus in version 3. The plan for the new API will allow for any module to use the UI to create the menu structure, but give them the ability to create the menu in their own method. No longer will you be restircted to only menu links. As of version 3, Taxonomy Blocks <http://drupal.org/project/taxonomy_blocks>and Taxonomy Navigator <http://drupal.org/project/taxonomy_navigator> will be mergin with Taxonomy Menu. Please join in the dicussion. <http://groups.drupal.org/node/42014> You can see a screencast of the new UI here<http://code-dreamers.com/taxonomy_menu_ui.mov> . I hope to here from all of you! Thanks, Neil

3 3

Deploying content from master site to subsites
by Brian Vuyk 01 Jan '10

01 Jan '10

9 15

Field name in view template woes
by Jeff Greenberg 01 Jan '10

01 Jan '10

I have a view row template, and one of the fields in the row is an imagecache version of a cck image. If I elect for the field settings of it to allow it to be shown, the image appears. It does not, however, appear in a dump of the $rows object, whether the field is excluded from being displayed or not. In following the naming convention of other content, and going by a dump of $view where the table name for the field is node_data_field_image_cache and the field name is field_image_cache_fid, I have tried setting the field in the view settings to be excluded from display, and then print it manually in the template. I've tried both $row->node_data_field_image_cache_field_image_cache_fid and $row->node_data_field_image_cache_field_image_cache with neither working.

2 4

Drupal 7.0 Alpha 1: Coming soon to a downloads page near you!
by Angela Byron 31 Dec '09

31 Dec '09

Hm. Trying this again. I sent this Wednesday night but apparently it didn't make it? --- Drupal 7 first opened for development back in February 2008. At Drupalcon Boston a month later, we brainstormed on how to tackle some of Drupal's toughest challenges: our usability was not up to par, we were burning time fixing the same bugs over and over, our database abstraction layer suffered many limitations, upgrades were a nightmare, and critical modules such as CCK not being ported were harming our adoption rates of Drupal 6. Drupal 7 has made tremendous strides since then to solve each of these problems, as well as many others. Among the improvements are a revamped UI, a testing framework, a new database abstraction layer, a browser-based upgrade system for contributed modules and themes, and CCK in core. Now it's time to head into the final stretch: stomping down the list of critical bugs, so that we can release Drupal 7.0 out into the world! :D To help this along, Dries and I will create the first alpha release of Drupal 7 on January 15, 2010, Drupal's ninth birthday. For developers working on Drupal 7 clean-ups, particularly around anything that is touching APIs or the UI in a fundamental way, your changes will need to be completed by then. Once the alpha is released, we will start to treat Drupal 7 as an actual stable release, which means nothing but non-API-breaking bug fixes. The initial brainstorming at Drupalcon just a few weeks after development opened for Drupal 7 was <strong>instrumental</strong> in laying a strong foundation for the entire release, I would love to see Drupal 8 get the same opportunity. However, this means releasing Drupal 7 <em>before</em> Drupalcon SF (mid-April), so that our attention is not divided between getting our past efforts out into the world, and deciding what our future efforts will be. And when does Drupal 7 come out? When the list of critical issues [1] hits zero (currently at 340, though this will fluctuate all over the place for awhile as non-critical issues are marked such as and new critical issues are found). To spook you with a little math, if we want to see a Drupal 7.0 release by the end of March, at the current total we need to solve roughly 120 issues per month, or 30 issues per week, or 5 per day. Yipes! :) Obviously, the more people we have helping out with fixing critical issues, the faster this number will go down. So if you haven't yet played around with Drupal 7, now's a great time to start! Pick a critical bug that looks interesting/achievable, and take the opportunity to learn a bit about the changes in Drupal 7 at the same time while you solve it. There are always folks in #drupal and #drupal- contribute on irc.freenode.net to help you, and there are a variety of bugs for all skill levels and areas of expertise. Let's rock! [1] http://drupal.org/project/issues/search/drupal? version [0 ]= 156281 &status [0 ]= 1 &status [1 ]= 8 &status [2]=13&status[3]=14&priorities[0]=1&categories[0]=bug&categories[1]=task

1 0

Drupal developers in local government or with transparency/participation projects
by Steven Clift 30 Dec '09

30 Dec '09

We are gathering software developers interested in local government transparency and community participation here: http://e-democracy.org/locallabs It is a new e-list/online group. It would be great to have a healthy Drupal contingent among us. Steven Clift E-Democracy.org

1 0