October 2005 - Development - lists.drupal.org

[drupal-devel] Multi-Configs and User Pictures?
by Morbus Iff 16 Oct '05

16 Oct '05

I'm fixing to launch a multi-config/single-codebase site (ie., multiple domains pointing to the same Drupal installation, with differing sites/ configuration pointing to different databases), and I'm a little worried about how user account pictures are going to be handled. Currently, pictures are saved as just files/pictures/4.jpg for uid 4. But, what happens when uid 4 from BOTH sites tries to upload their pictures? -- Morbus Iff ( my name is legion, for we are many... ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

3 3

[drupal-devel] Bugbite hours
by Gerhard Killesreiter 16 Oct '05

16 Oct '05

hi there! I've added a book page for the bugbite sessions. Please add your favourite bugs in comments. Please check for duplicates. I will add the bugs to the list and delete the comments. Cheers, Gerhard

2 1

[drupal-devel] MySQL ENUM vs. TINYINT (possible performance boost?)
by Angie Byron 16 Oct '05

16 Oct '05

I was dinking around in PHPMyAdmin today and noticed this thing called "Propose table structure" which runs: SELECT * FROM `tablename` PROCEDURE ANALYSE ( ) ...and attempts to discover the most optimal fieldtype for each field, based on the data it's currently storing. You'll notice there are ENUMs just about everywhere. And a lot of its output is largely irrelevant. For example, in the watchdog table it recommends as the hostname field: ENUM('127.0.0.1') NOT NULL Which obviously would not be good. :P However, we do have a lot of TINYINT fields that are only ever going to store either 0 or 1, which could be changed to ENUM('0','1') NOT NULL as the analyzer recommends. Any MySQL gurus who could shed some more light on this? Is it worth doing? Would we gain any performance benefit from this or would it be too negligible to notice?

3 2

[drupal-devel] bug in xmlrpc_value_calculate_type() for empty arrays
by Axel Kollmorgen 16 Oct '05

16 Oct '05

while trying to post to Drupal via blogapi/ecto 1.8.2, i discovered a bug in xmlrpc_value_calculate_type() that makes posting impossible. it happens here: case 'array': return range(0, count($xmlrpc_value->data) - 1) === array_keys($xmlrpc_value->data) ? 'array' : 'struct'; for empty arrays, this returns 'struct' while it should return 'array'. because: $xmlrpc_value->data: array () range(0, count($xmlrpc_value->data) - 1): array (0, -1) array_keys($xmlrpc_value->data): array () latter 2 apparently aren't identical. i'm a little uninspired at the moment, especially regarding this range() construct, and thought i post this here before i post a bug report and give it a try myself. maybe someone else (who wrote this? :)) is faster than me. a nice weekend everyone! -- ax [Maris's gardener Yoshi passed away] Dr. Niles Crane: He had a heart attack when he was out trimming Maris's elaborate hedge maze. The paramedics never had a chance.

2 3

[drupal-devel] PHP 101: isset() does not check for zero length (empty) strings
by Steve Dondley 15 Oct '05

15 Oct '05

I literally spent hours trying to track this down (running Drupal 4.6.3). Please take a moment to review my findings. I was having a problem with the bug at http://drupal.org/node/20795 (I beg to differ that it is fixed as reported, by the way) on a couple of different feeds. The problem went away when I changed the following line in node_invoke_nodeapi() from: else if (isset($result)) { to this: else if (isset($result) && $result != '') { The problem, of course, was is that isset() returns true on an empty string. This caused an undesirable result in this particular instance. I've seen this bug elsewhere in Drupal's code. Should we be going through Drupal's code and fixing this problem which is probably pretty common? -- Dondley Communications http://www.dondleycommunications.com Communicate or Die: American Labor Unions and the Internet http://www.communicateordie.com

7 13

[drupal-devel] Forms API conversion help
by Chris Johnson 15 Oct '05

15 Oct '05

I am in the process of trying to convert the ezmlm module to the new forms API. I am doing this so I can learn the forms API. I am one of the maintainers of the ezmlm module and it is a very, very simple module. Once I learn the forms API fairly well, I will be happy to help other people with their conversion efforts, write more documentation on the API and/or convert more modules. I just need to get it all clear in my head first. However, I'm having some problems converting a simple form in my module. I spent several hours reading all the latest documentation and working on it last night, and I've run into a few things where I am not clear on how it should work. If anyone is willing to give me some help, you can view the before and after code here: http://phpfi.com/82366 Questions: 1. Is the #action key in the first form[] element the right way to specify where to post the form? 2. What's the proper array element index where it says "WHAT_GOES_HERE" for a non-form item message that needs to be injected into the form at that point? Is #markup the right type? Seems like it is. 3. What's the correct #type for my hidden form element? 4. What's the correct form array secondary index for an array of checkboxes? In the old form API, one used names like 'my_checkbox_list][' in order to generate HTML like this: <input type="checkbox" name="edit[my_checkbox_list][]"> How is that done with the new API? Thanks, Chris Johnson 31 hours until I leave for Amsterdam! :-)

3 2

[drupal-devel] Forms API conversion help
by Apartment Lines 15 Oct '05

15 Oct '05

chris, thanks for writing in about this. atm, i'm sort of the point person for forms API doc. it's a big task, but we're slowly making progress! first thing to note is that even though the form you're converting seems simple, there are a few tricky parts to it. so... 1. i'd specify the #action at the root of the form tree, like so: $form['#action'] = request_uri(); Also, the '#fieldset' attribute is making everything in the tree under $form['subscribe'] into a form group--is that what want? If your goal is to get those div tags in the right place, you can just place them at the right spot in the form tree using the #markup attribute. for this form that's how i'd handle it, and just scrap the entire ['subscribe'] layer of the form tree. 2. yep, #markup it is. WHAT_GOES_HERE? is where the name of the markup element goes. since this isn't getting passed to $_POST['edit'], you can name it whatever you like. remember $form['foo'] means that the value will be available under $_POST['edit']['foo'] 3. the easy answer is: '#type' => 'hidden'. the more complete answer is, depends... :) under the new forms API, the 'correct' way to submit a form is writing a form execute function (instead of the old $op/switch approach). if you do write a form execute function, then you want to use '#type' => 'value'. this has the nifty benefit that the hidden fields don't get output as HTML. forms magic! 4. you build those arrays like this now: (and i'm hacking out your ['subscribe'] layer as i mentioned above) $form[ezmlm_list]['#tree'] = TRUE; $form[ezmlm_list][trim($list_text)] = array('#type' => 'checkbox', '#title' => trim($list_text)); in this case, you don't need to declare #return_value explicitly, because form code already has this as a default for the checkbox form element, and i'm *pretty* sure the same applies to #default_value the big tricky part of this section of code is that you need to preserve that tree structure in $_POST['edit']. by default, the form code squashes it, meaning that $form[ezmlm_list][trim($list_text)] will appear in POST as $_POST['edit'][trim($list_text)]. oops, you lost the [ezmlm_list] layer... :) to preserve the full tree for that section of the form array, you need to set the tree attribute to TRUE, which is what i did in the above section of code. 5. for drupal_get_form, the first arg is the form_id for the form--it's a string and the convention so far has been to name the form based on the function that it's created in. so for this form, it would be: return drupal_get_form('_ezmlm_subscribe_form', $form); hope this helps :) and if anything still doesn't work, let's talk about it at drupalcon... chad Chris Wrote: I am in the process of trying to convert the ezmlm module to the new forms API. I am doing this so I can learn the forms API. I am one of the maintainers of the ezmlm module and it is a very, very simple module. Once I learn the forms API fairly well, I will be happy to help other people with their conversion efforts, write more documentation on the API and/or convert more modules. I just need to get it all clear in my head first. However, I'm having some problems converting a simple form in my module. I spent several hours reading all the latest documentation and working on it last night, and I've run into a few things where I am not clear on how it should work. If anyone is willing to give me some help, you can view the before and after code here: http://phpfi.com/82366 Questions: 1. Is the #action key in the first form[] element the right way to specify where to post the form? 2. What's the proper array element index where it says "WHAT_GOES_HERE" for a non-form item message that needs to be injected into the form at that point? Is #markup the right type? Seems like it is. 3. What's the correct #type for my hidden form element? 4. What's the correct form array secondary index for an array of checkboxes? In the old form API, one used names like 'my_checkbox_list][' in order to generate HTML like this: <input type="checkbox" name="edit[my_checkbox_list][]"> How is that done with the new API? Thanks, Chris Johnson 31 hours until I leave for Amsterdam! :-)

2 1

RE: [drupal-devel] I do not care about PHP 5
by Boerland, Bert 14 Oct '05

14 Oct '05

-----Original Message----- From: drupal-devel-bounces(a)drupal.org > Perhaps we should report this as a concern to Rasmus or whomever. He will be at the DrupalCON and is willing to talk about issues like these.

1 0

[drupal-devel] Allow annoymous users to log in on access denied
by Chris Cook 14 Oct '05

14 Oct '05

I would like to draw some more attention to this issue. All commenters appear to be in favor of it and there are several patches available. Perhaps Dries is waiting for additional support or review of the attached patches. It would wonderful to have this in 4.7. http://drupal.org/node/24050 Cheers, Chris

1 0

[drupal-devel] Criticism of Drupal
by Khalid B 14 Oct '05

14 Oct '05

This guy is giving up on Drupal. Better respond to some of his concerns. Even if he leaves for good, others may read the responses. http://drupal.org/node/34007

1 0