January 2010 - Development - lists.drupal.org

Re: [development] 'old' core 6 & new 7, working together..? +crossite
by Ad 07 Jan '10

07 Jan '10

Hi there, Some arguments here are not completely true. Look here how developers spend much time on new issues for core 5 ! http://drupal.org/project/event It's only an example & there is more; this is a clear statement that some developers prefer to spent time on getting 5 better, instead of getting all other lacking modules from 5 to 6, so website owners don't have any reason left to step over from 5 to 6. Waste of time? Yes, one can pay for development. But who is gona pay me for my volunteer work? Many sites are social sites, or small to medium commercial ones. It will cost an enormous lot of money to pay for custom made modules at programmers fees. The smaller social ones that can, have to rely heavy on subsidy and that money can change the social movement in the political and even corrupt direction of the money givers. So I pay for myself, above my volunteer work that ofcourse doesn't generate money to invest in this social network. That situation won't change that easy in a few years. Drupal programming is a blend of non-centralised volunteer work with some agreements through negotiations, and commercial driven projects (even the social ones, if they can arrange money). That's its power, but also its weakness. The positive effect for introducing core 7 in the first year, will maybe lay only in a wake-up call that some modules from 5 can't wait anymore to be transformed to 6, so MAYBE in a year from now websites have no rason left not to stick with core 5 anymore. But for core 7 to run on most drupal installations, will take 2 years? Two years before a development can be practically implemented, is an ENORMOUS waste of time too. So most like to have a core 6 AND 7 website (or even with a 5). But -except for quite simple/basic sites- nothing can be transformed to the 7 website, because there is no integration AT ALL. Not even automatic login for all members of the 6 site? Hey guys & girls; wake-up; most want such a smooth transition. Yes, I understand that bridging and integrating all aspects COMPLETELY, will be an insane waste of time. But what can be bridged PRACTICALLY? (again; I'm not suggesting bridging everything, what indeed would be a waste of time) And can/needs core 7 be revised before the first release, to make bridging less complex? Ofcourse without touching the pro's of core 7. Then I'm not only suggesting what the title says; bridging in general WITH NON DRUPAL programs/sites, is a hot item. Ofcourse not everything is practically possible in bridging. BUT: If the core 7 uses some standardised coding (lack of a standard?), it will be easier to bridge to other programs that use the same standard. So the same work to (partly) bridge 6 to 7, as well as to (partly) bridge 7 to many other programs and sites. All in one basic bridge module/API, implemented on a possible re-written core 7 for more standardisation in these. ABOVE this basic bridge API for core 7 only, specific bridges like core 6, Twitter, Facebook, Mediawiki, social networks, Google Wave: http://code.google.com/apis/wave/ , etcetera. Maybe even 'copy' Google Wave standards into a Drupal API ? If Drupal looses this development, a lot of sites and people might migrate from Drupal to Google,not now, but somewhere in future. Another argument here is that Drupal programmers aren't interested in bridging, mostly because of some unnecesary experiences to bridge to some specific fora. Well, thats old school; there are many new developments and trends... Most Drupal programmers have a good general education and understanding of social issues too. One needs to realise the so called "cultural barriers", withdrawing in subcults, For example: Is the way Mediawikis think wrong, or how Drupals think? They both think in their own same street/culture. But to get to a higher culture, one needs to think how the other thinks and then make some general thinking that is good for both. Also getting a culture to a higher or another culture, will always meet enormous tense resistance. They will kill the first sheep that dares to walk over the dam. If they kill the first sheep, the power balance is back to the old culture. But if the first sheep is very stubborn and succeeds inspite of all the resistance, then slowly others start to follow and met lesser resistance, untill the mass starts moving towards the other culture. But its very difficult, even if the other culture has many more advantages for all. In filosophy cultural study there is something like this in other words, I forgot the official terms. Anyway, all the best.

6 6

Drupal's target audience
by Brian Vuyk 05 Jan '10

05 Jan '10

5 5

Why is Overlay in core?
by Brian Vuyk 05 Jan '10

05 Jan '10

Hi all. I've been using D7 to get familiar with it, testing / writing patches, and to begin porting my contrib module. It is awesome, but the one thing that sticks out to me is the inclusion of Overlay in core. Why are we including Overlay enabled by default in core? What functional purpose does it serve beyond eye-candy? I realize that it potentially allows you to remain on your current front-end page while doing some admin tasks, but isn't that why tabbed browsing was invented? This breaks anyways when you get redirected with a drupal_goto() somewhere. My biggest complaint is that It slows down the admin work of the site considerably, at least in my workflow. I don't mean to take away from the work that was put into overlay - some very talented people have put a lot of time and effort into building it, polishing it, and fixing some oddball performance issues. But it just doesn't seem to stick with the core philosophy. At least this module should be disabled by default in core. Brian

4 6

Re: [development] 'old' core 6 & new 7, working together..? +crossite
by Ad 05 Jan '10

05 Jan '10

(I tried to respond on a particular message, but don't know how) = = = = = Thanks for all the feedback. Ofcourse; backwards programming doesn't make sense. But I encountered several sites running on core 5, because there isn't even an upgrade for the mods they need to core 6, or only a preliminary one. I'm not going to make a report of what I encountered (last 4 days uploading many-many mods); probably all here are familiar with the problem. There are mods that have something about what I suggested, like this 'outdated' module I just encountered: http://drupal.org/project/crossite Many usefull mods are written for 5 and never updated for 6, see for example this hyper-modern site that untill now only can run on 5: http://drupal.org/node/342472 So the question: what is outdated in these? Ofcourse the new core 7, not at all. But the whole package with the mods, will be literally outdated for one year, up to some years. Why not getting crossite running again, in a new and broader & standardized form, for both 6 and 7? Maybe even changing the 7 core before the definitive first release, to anticipate for this development & make some transitions smoother? , IF SO: 1) one could run some parts on core 6 and others on core 7, for the first 2 years untill almost all necessary mods are on 7. Everyone could migrate inmediately to 7, so it would be a step forward with a smooth transition, not backward; 2) The same system (updated) can in future also be used for 7 to 8, so its not a one time case and lost creativity; 3) Several other web-programs have some bridge with Drupal, but quite amateuristic and no broad development support to get the basic/general API ready for all of these specific bridges (, communicators, exchangers, integrators a.s.o.). It might be web-worlds future hype, or already is with integrating gadgets, cellphones, twitter, facebook, groups, mediawiki and so on. Mediawiki was partly running, but with new releases it stopped running again, lacking a protocol for both Drupal and Mediawiki. Yes, it is difficult to get the core optimized for this and make a sort of inter... protocol how programs best can bridge with as many aspects as possible. But because of the importance, to my opinion it should become a main developers community task to get done Do we still need to wait untill core 8 for such a development? Actually I had a test site on 5 and had to wait 2 years before not even all required modules were up to date. So I might start soon in 6, but I'm still missing some features from 5. If possible, I recommend to start working on bridging even before the release of 7, examining if there better needs to be changes in the basics of core 7 first, to optimise for an additional 'general bridge API'. My sincere excuses to all voluntary programmers; but succesfully learning how to program these mods, would cost me too much time. I better concentrate my volunteer work on building the social site with the mods & getting that project running. In doing so, I can check the latest dev's and feedback. Like who knows for example, if I encounter a problem for this 'new' preliminary dev securelogin: http://drupal.org/node/146238/release Good luck with core 7!

5 5

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