November 2007 - Development - lists.drupal.org

hook_form() and multistep
by Ryan Courtnage ☠ 22 Dec '07

22 Dec '07

Hello All, I'm attempting to make a multistep node submission form in D5 All the examples using #multistep I find assume the form is being rendered by drupal_render_form(), which passes the form values as the 2nd argument. These form values can contain the step number that is used to decide which form fields to render, and what to validate/submit. In my case, however, it's a node submission form .. hook_form() is being used (not drupal_render_form()). hook_form() gets passed the node object, but not the form values. As a result, I'm not able to determine what step I'm on. I'm assuming it's possible to make a multistep node submission form. Can someone point me in the right direction? Thanks! Ryan

3 2

Mischievous registration of projects
by Thomas Barregren 19 Dec '07

19 Dec '07

Hi all, Maybe I talk through my hat, but I suggest a policy against mischievous registration of projects for the purpose of claiming namespace, e.g. opensocial, or for other reasons than providing a module, e.g. cvsdemo? Thomas

6 6

Forms API -- default values without anything in database
by Syscrusher 19 Dec '07

19 Dec '07

I've been pounding my head against this one all afternoon, and have been all through the documentation, and am utterly stymied. I can't even find an extant module that does this, but I'm certain _someone_ has already invented this wheel. I'm working with a fresh CVS checkout of Drupal 5.x. I have a module that creates and maintains a database table that is NOT related in any way to nodes. I am implementing a search function that presents a form allowing users to enter the desired match values, then presents a table with a list of matching records. No problem on any of this. The problem is how do I get the form to REDISPLAY the search values when it has been submitted, so that they become the default values for the search fields next time? My form creation code looks similar to this: function mymodule_form_query($form_values = null) { $form = array( 'basic' => array( '#type' => 'fieldset', '#tree' => false, '#title' => t('Basic search'), 'last_name' => array( '#type' => 'textfield', '#title' => t('Last name'), '#size' => 35, '#maxlength' => 35, '#weight' => -10, '#value' => $form_values['last_name'], ), [...snip...] return $form; } and the page that processes the query has a menu callback akin to this: function mymodule_query_page() { $form_values = $_POST; $html = drupal_get_form('mymodule_form_query', $form_values); return $html; } Now, if I do a var_dump() in the page function, it shows that the last_name field is set in the $_POST array when the form is submitted. But it seems to have no effect in the mymodule_form_query function. That function is called TWICE, once with values in $_POST and again with nothing. It seems that the only time it pays attention to its #value (or #default_value -- I've tried both) options is the second time it's called, that is, when $form_values is empty. Ergo, no values for the fields. I've tried this as well, with no effect: function mymodule_form_query_submit($form_id, $form_values) { $GLOBALS['mymodule_query'] = $form_values; } and then querying $GLOBALS['mymodule_query']['last_name'] in the mymodule_form_query() function to obtain the value. Although trace code within the submit shows that the value is in fact present there, somehow my global variable is erased or ignored by the time it gets to the form building process. Oddly, if I change the form to GET rather than POST method, the $_GET variable behaves the way I would have expected $_POST to work, and the fields are filled in. But it's really ugly to do it that way, because among other things the URL then contains the form_token and may be bookmarked by users as such -- Not Good. What am I doing wrong here? Someone has to have done this before, so I'd greatly appreciate any assistance. What's the RIGHT way to do this? Is there a place where Drupal actually nukes all global variables during initialization, and where it erases $_POST? Kind regards, Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/

4 5

Re: [development] Do not let postgresql hold back great patches
by Edward Z. Yang 05 Dec '07

05 Dec '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Take, for example, that COUNT(*) is _really_ fast on MySQL + MyISAM, > but is slow on just about every other DB. So, replace it with > $db->count(), which does an SQL COUNT(*) on MySQL + MyISAM, but uses > some other technique on other databases. The programmer no longer > cares _how_ such a thing gets done, he only cares that he wants to > know how many rows are in a particular query The primary problem with this approach (at least in my experience) is that the moment you need to create queries that are even somewhat complicated the abstraction layer proves to be insufficient. Ad hoc queries are often very useful for performance reasons, but you'll have to get a PostgreSQL guru to write an equivalent. Then again, for most people writing SQL performance/complex joins/etc are not a primary concern... - -- Edward Z. Yang Portable GnuPG: 0x995A2C84 HTML Purifier <http://htmlpurifier.org> Anti-XSS Filter [[ C8D5 9E3C 15AD 1467 5561 2C0E 719A 2D9D 995A 2C84 ]] This Message Courtesy of Thunderbird Portable -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFHUE9NcZotnZlaLIQRAomgAJ9JvBtXwUnv94O873gXej1pmTUVhACfSr3e q5b1On3RkByDzPboq9PM2zI= =CPMZ -----END PGP SIGNATURE-----

3 2

Do not let postgresql hold back great patches
by Karoly Negyesi 04 Dec '07

04 Dec '07

In my opinion, any patch should be committable to core once it works on mysql and has a decent hope (use common sense) to work on postgresql. Once it's committed those who care about postgresql, if they so want to, can test and if there is a need, fix it. Prime example: http://drupal.org/node/146466 this is the most important patch we have currently as it makes Drupal search speedy and nice. And it is more or less on hold just because noone is sure whether the postgresql update works or not. Regards, Karoly Negyesi

25 79

Re: [development] Mischievous registration of projects
by Michelle Cox 30 Nov '07

30 Nov '07

My understanding is that this is already considered unacceptable but I don't know if any concrete action is being taken against it. It might be one of those things where the people who are able to do something about it are simply too busy to play police. It should be common sense that you don't create a project unless you're going to do something with it. Michelle On 11/30/2007 8:54:27 AM, Roman Chyla (roman.chyla(a)gmail.com) wrote: > Please don't make the registration process difficult or slower. It is > better to focus on post-checking - if the module has not proven any > activity, some action might be taken, but not sooner than that. > roman > > On Nov 30, 2007 1:57 PM, Thomas Barregren <thomas(a)webbredaktoren.se> > wrote: > > Hi all, > > > > Maybe I talk through my hat, but I suggest a policy against mischievous > > registration of projects for the purpose of claiming namespace, e.g. > > opensocial, or for other reasons than providing a module, e.g. cvsdemo? > > > > Thomas > >

4 3

Re: [development] How many modules is too many?
by Khalid Baheyeldin 30 Nov '07

30 Nov '07

(Changing the subject) I regularly see 80+ to 110+, and that causes Apache to eat 100MB per process, which is really not good ... This is the open buffet binge syndrome detailed here: http://2bits.com/articles/server-indigestion-the-drupal-contributed-modules… On Nov 21, 2007 12:50 PM, Jim Li <jimmydami(a)gmail.com> wrote: > Cool, thanks! > It'd be interesting to have a poll on how many modules people use on a > social network site. I heard someone uses 160 modules at his dev site, > it may go down a bit later, but it probably will still in the 100+ > ragnge :) > > On Nov 20, 2007 6:31 PM, Earl Miles <merlin(a)logrus.com> wrote: > > On the other hand, having 150+ modules load *is* going to eat a whole > > lot of memory; so actually activating all these modules is a really bad > > idea. > > > > And yes, the modules page under 4.7 is going to choke like [insert > > really bad sports team metaphor here]. > > > > > > Sean Robertson wrote: > > > As I understand it, Drupal 5+ no longer does that. That's what the > > > .info files are for. Those files are only a couple hundred bytes each > > > so the full page even with a ton of modules downloaded should only use > a > > > small amount of memory unless you enable them all (which would affect > > > all pages, not just that one). > > > > > > > > > > > > Jim Li wrote: > > >> Hello, > > >> > > >> I saw some complaints that admin/build/modules page loads all modules > > >> and eats up lots of memory. And I heard a story that somebody new to > > >> drupal was trying to evaluate >150 modules and eventually drupal > > >> 'crashed' on this page due to memory limit. So I am just wondering is > > >> it a good idea that we use tabs to separate module groups on > > >> admin/build/modules page? Will it help with the problem? We can have > > >> three tabs: core, contrib, oh and uninstall (which will need some > > >> speical css rendering). > > >> > > >> Thanks, > > >> Jim > > > > > > > > -- Khalid M. Baheyeldin 2bits.com http://2bits.com Drupal optimization, development, customization and consulting.

2 2

Fatal error : install profiles and the use of hook_install
by Augustin (Beginner) 30 Nov '07

30 Nov '07

Hello, There seem to be a critical bugs hiding behind the way the install profiles are implemented. At the very least, there seem to be a gross inconsistency in the documentation. I could have fixed the api documentation myself, except that I am not sure what is the 'normal' behavior. When creating an install profile, one runs against such errors: "Fatal error: Call to undefined function xxx()" http://www.google.com/search?q=site%3Adrupal.org+profile+install+Fatal+erro… This happens when one includes a few specific modules in hook_profile_modules(), including book.module: http://drupal.org/node/164458#comment-643884 The api says that all functions are loaded when running hook_install(): http://api.drupal.org/api/function/hook_install "Note that since this function is called from a full bootstrap, all functions (including those in modules enabled by the current page request) are available when this hook is called. Use cases could be displaying a user message, or calling a module function necessary for initial setup, etc." But the profile documentation implies the contrary: http://drupal.org/node/67921 the modules (including core required modules and their functions) are NOT yet included when running hook_profile_modules() (which calls hook_install()). The modules are included only at a later stage, hook_profile_final(). A similar problem occurred with forum.module, until a certain function call was moved to hook_enable(): http://drupal.org/node/157519 This begs the question: what is it ok to include in hook_install()? Is hook_install() only for the DB schema, or can heavier lifting be done using any function call? If this cannot be fixed for D6, some warning should be included in the documentation, especially here: http://drupal.org/node/67921 . I didn't do so myself because I am uncertain about all the above. Blessings, Augustin.

5 6

Re: [development] Suggestion for User Permissions
by Simon Roberts 30 Nov '07

30 Nov '07

Agree. If someone really wants an "admin role" they can use (ta-da) http://drupal.org/project/adminrole > Date: Thu, 29 Nov 2007 09:45:53 -0800 > From: "Steven Peck" <sepeck(a)gmail.com> > Subject: Re: [development] Suggestion for User Permissions > To: development(a)drupal.org > Message-ID: > <a151b5a00711290945y37f9f5acsc3ff989a4104365d(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > When creating a site admin role, there are several items I do not turn > on for the users, nor do I want them on for those sites. > > Creating roles is generally a one time deal per role. It is something > that 'even it is a 'pain' or 'inconvenient' should not be 'globally > allowed turn on'. This comes to a security issue in that you should > determine your permission model. It is not an 'OMFG usability issue'. > It is a security issue. I have always liked the default 'everything > is off' model because I then have to turn on things. > > It may be inconvenient but it doesn't seem to be something to go into > hysterics over or claim usability as an overarching trump card. > > If we are going to do this, then allowing it only once per role 'at > time of creation' seems the least harmful approach to easily allowing > people to shoot themselves in the foot to solve some users > 'inconvenience'. > > Steven Peck :: www.blkmtn.org > > On Nov 29, 2007 5:14 AM, Earnie Boyd <earnie(a)users.sourceforge.net> wrote: > > Quoting Darren Oh <darrenoh(a)sidepotsinternational.com>: > > > > > Giving a permission to the authenticated user and the anonymous users > > > gives it to all roles. If you are speaking of giving a single role > > > all permissions, I would be careful. It would be better for modules > > > to set defaults for their permissions and then change each permission > > > individually. > > > > > > > IMO, the set/unset all function should be applied to created roles at > > the time of creation only. This solves the issues being discussed.

4 3

Re: [development] Do not let postgresql hold back great patches
by Larry Garfield 29 Nov '07

29 Nov '07

On Thu, 29 Nov 2007 09:28:28 -0500, Bill Moran <wmoran(a)potentialtech.com> wrote: > *) The argument has been made that PostgreSQL compatibility is holding > Drupal back, then 1 (One!) patch is referred to again and again. > How important is this one patch? If this _1_ patch is holding > Drupal back, please commit it! I think these issues were also stalled on cross-database compatibility issues: http://drupal.org/node/174025 http://drupal.org/node/83738 > *) The argument was made that PostgreSQL is too complicated to install > and test on, yet I described the setup in a single email. If anyone > found my instructions too difficult to follow, _please_ let me know > and I will go to efforts to clarify. Please make a handbook page out of them, and put it near (probably as a child of) the "setting up a dev environment" handbook page. We should probably have one for MySQL and one for Postgres (and if we add SQLite at a later date, one for that, too). Email is far too ephemeral to be a good reference. Thanks! --Larry Garfield

3 2