- Development - lists.drupal.org

user_roles() at hook_boot()
by Lluís 12 Jan '10

12 Jan '10

I need to check roles for a permission at hook_boot; but I recive a "Fatal error: Call to undefined function user_roles()". Is it possible that user_roles() is not defined at hook_boot? or am I missing something else? thanks. -- *Les normes hi són perquè hi pensis abans de saltar-te-les *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 3

build/deployment experiences or suggestions
by T L 12 Jan '10

12 Jan '10

Hello Everyone, Happy 2010! I've been researching different build and deployment technologies (phing, xinc, hudson ci, drush make, phpundercontrol, etc). Our requirements are pretty minimal. So, ideally, we would like just like to be in-step with the majority of the Drupal community here--what do y'all use or what are your recommendations/caveats? Thanks so much! Tim -- Tim Loudon (781) 686-6096

1 1

Need another pair of eyes - page callback & form
by Jeff Greenberg 11 Jan '10

11 Jan '10

I've been staring at this an hour now...time go ask for help! I have two reports. The menu entries are below. Each works. They are identical other than name. At the top of each, I provide a button to request a CSV. The report's callback checks for the get value associated with the button. The buttons are each submits. The action for the form in each report is the final part of the callback path. Report 1 successfully returns to the callback function for it. Report 2, when the button is clicked, just spins and spins. If I change the action in report 2 to 'customers'... it finds its way to that callback function, but can't seem to find its own. Of course, the callback function is found when simply clicking on the menu link for the report...so I'm thinking it's the form action...but can't figure it out. function my_reports_menu() { global $user; $items = array(); $items['admin/store/reports/my/customer'] = array( 'title' => 'Customers', 'description' => 'Customer name and address list', 'page callback' => 'my_reports_customers', 'access arguments' => array('view reports'), 'type' => MENU_NORMAL_ITEM, 'weight' => 10, ); $items['admin/store/reports/my/orders'] = array( 'title' => 'Orders today', 'description' => 'Orders placed today', 'page callback' => 'my_reports_orders', 'access arguments' => array('view reports'), 'type' => MENU_NORMAL_ITEM, 'weight' => 10, ); } From report that doesn't work $output .= '<div><form id="csv" action="orders" method="get" /><input type="hidden" name="csv" value="true" /><input type="submit" value="CSV" style="background-color: gold" /></form></div>'; The one that does work ...and if the action above is changed to 'customer' as below, it gets processed $output .= '<div><form id="csv" action="customer" method="get" /><input type="hidden" name="csv" value="true" /><input type="submit" value="CSV" style="background-color: gold" /></form></div>';

6 10

ISAPI Rules
by Ashraf Amayreh 11 Jan '10

11 Jan '10

Hello all, I'm using ISAPI rules to rewrite a URL transparently. As far as I know, this acts like a proxy. Let's say the browser access URL is "abc.com" and this is rewritten transparently to "xyz.com", all works great except, the Drupal session is saved with the domain "xyz.com", making me unable to read it when accessing the site on "abc.com" because it's outside the domain. I believe optimally I'd want Drupal to write it under the domain "abc.com" rather than "xyz.com". I thought this might be a setting read from the $base_url inside the settings.php but apparently not. Is there a way to force the domain Drupal uses to set its cookies? I hope I got this right and it makes sense. I appreciate any help or ideas. -- Ashraf Amayreh http://aamayreh.org

2 1

All hands on deck for Drupal 7 alpha 1 this Friday!
by Angela Byron 10 Jan '10

10 Jan '10

Greetings, folks! As you may or may not have heard (http://webchick.net/node/73) on Friday we are going to roll Drupal 7.0 Alpha 1. This will be the very first time that the *vast* majority of the community (not to mention the outside world) will download Drupal 7, and play around with all of the hard work you've all been doing for the past ~24 months. So! I would love to do everything we can to really shine it up over the next couple of days. There are three queues that I would love people to focus on if they have even *one hour* this week sometime to help Drupal 7: 1. webchick's D7 alpha hit list: http://drupal.org/project/issues/search/drupal? status[]=Open&issue_tags=webchick%27s+D7+alpha+hit+list A variety of either *seriously* critical bugs (lingering critical API breakages, the broken upgrade path, missing security updates) or really glaring user-facing bugs that just make D7 look really sloppy. Some of these are real head-scratchers, but others I think are pretty obvious things that can be fixed in just a few lines of code. We will still release the alpha regardless of the state of this list on Friday, but progress here will help determine how many bold, flashing disclaimers I can remove from the announcement. ;) (Note that this is called *webchick's* D7 alpha hit list. Please do not add/remove stuff to/from this tag. If you feel something is drastically amiss, come find me on IRC and talk to me about it.) 2. API changes lacking documentation list: http://drupal.org/project/issues/search/drupal? status[]=Open&version[]=7.x&issue_tags=Needs+Documentation Another thing that I'm really hoping to see along with the release of alpha 1, is a torrent of developers beginning to make good on their #D7CX pledges, by porting their modules and themes to Drupal 7. Right now, however, there are *two pages* of issues whose API changes are *not documented* in either the modules or theme upgrade guide. This is an extremely critical situation that we need to resolve *ASAP* in order to not stall the updates of 6.x modules to 7.x. (We all remember how much that 5.x -> 6.x lag was, don't we?) If you choose to help with this (bless you!), please both edit the appropriate handbook page(s) for the change: * 6.x => 7.x module upgrade guide (http://drupal.org/update/modules/6/7) * 6.x => 7.x theme upgrade guide (http://drupal.org/update/theme/6/7) ...and also cross-file issues into the Coder module queue (http://drupal.org/node/add/project-issue/coder ) against the "Upgrade Routines" component. Helping whittle this queue down not only will give me fewer gray hairs and make the D7 alpha 1 launch a huge success, but it will *also* help get you acclimated to the changes forthcoming in Drupal 7 *now* so that you are prepared when D7 is officially released in a few months. Plus, you can make a mean living with your brand new "Drupal 6 to 7 module/theme porting" business. ;) (Incidentally, I highly encourage the Drupal 8 maintainer to create a "Wall of Shame" for developers whose patches end up on this list for longer than 24 hours. ;)) 3. User interface text: http://drupal.org/project/issues/search/drupal? status[]=Open&version[]=7.x&component[]=user+interface+text The docs and usability teams are doing one final pass on all of the strings in core before we turn the translators loose on Friday. A lot of these require no more skill to review than the ability to read English. :) Thank you all SO much in advance for your help, folks! Let's blow 'em all out of the water! :) -Angie P.S.: I am probably going to be doing a "commit freeze" starting Wednesday night when I go to bed, in order to give 24 hours or so for any follow-up bugs to be shaken out prior to rolling the release, so we don't accidentally break something horribly in the final hours. GULP.

1 0

how template suggestion inherits default header&footer of page.tpl.php
by Wang Zi Feng 08 Jan '10

08 Jan '10

Hi, There is a rookie question. I use template_preprocess_page function in a module to specify a template file (news.tpl.php) based on the hook_menu path (?q=news), utilizing the news.tpl.php every time click on ?q=news, it works fine. But I have to copy the footer&header from page.tpl.php to the new template file (news.tpl.php) to print them, I wonder if there is an approach to inherit automatically the footer and header section? here is the code function news_menu(){ $items['news'] = array( 'title' => 'News', 'page callback' => 'news_page_default', 'access callback'=>TRUE, 'type' => MENU_CALLBACK, ); return $items; } function template_preprocess_page(&$variables){ if(drupal_strtolower(arg(0))=='news'){ $variables['template_file']='news' ; } } Thanks Wang

3 3

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