October 2005 - Development - lists.drupal.org

[drupal-devel] performance improvements - avoiding big unserialize()
by Moshe Weitzman 01 Dec '05

01 Dec '05

In speaking with Rasmus last night, he discouraged us from using unserialize() on large arrays when possible. This eats memory and speed. We do this at lkeast twice on evrry page view: the menu cache and the variables cache (i.e. $conf). Rasmus' suggestion was to store these arrays without serialization in a shared memory system like APC. I have a long term plan to add *optional* shared memory storage for these arrays and maybe others as they arise. Perhaps someone else wants to move this forward quickly. Comments welcome.

12 18

[drupal-devel] Getting documentation patches commited
by andrew morton 05 Nov '05

05 Nov '05

In the process of getting up to speed on 4.7 I've found a few errors in the documentation. I've opened bugs and attached diffs (I hadn't figured out how to make patches at the time). I know people have a lot going on but these changes are pretty small and I think they'd help people avoid some headaches. Could someone take a look at them? This one updates the node_example.module to use the new Forms API: http://drupal.org/node/34306 This one fixes a typo in the hook_user() example: http://drupal.org/node/34330 Thanks, andrew

3 2

RE: [drupal-devel] Security ad?
by Boerland, Bert 25 Oct '05

25 Oct '05

-----Original Message----- From: drupal-devel-bounces(a)drupal.org > Should we add a 'Drupal security announcement mailing list' ad to > drupal.org (much like we have the newsletter ad)? If so, can someone > make one? Since my image.module on mys site is still br0ken (*COUGH help *COUGH*), here as a static image: http://willy.boerland.com/myblog/signupforthedrupalsecuritynewsletter.png Note: I didnt have the font used on these banners and dont think it is there yet, but maybe a real graphic guru can take it form here

2 1

[drupal-devel] icons : go for tango
by Bèr Kessels 25 Oct '05

25 Oct '05

Hi, in 4.7 we will see quite some icons. All designers and a lot of developers know that designing icons is a very very hard tough and difficult job. I propose that we add a line to the develops guidelines that if we include icons, we use the Tango ones. Otherwise we will end up with various styles, inconsistent looks and a lot of reinvented weels. http://tango-project.org/Tango_Icon_Gallery << The Tango Desktop Project exists to create a consistent user experience for free and Open Source software with graphical user interfaces.>> -- http://tango-project.org/ Bèr -- PGP ber(a)webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels(a)gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc

7 10

[drupal-devel] menu memory usage
by Karoly Negyesi 25 Oct '05

25 Oct '05

Hi! Probably most of the devels have not noticed http://drupal.org/node/34755 "when I enable all modules in core, the menu array eats over 800K of RAM". As we now have menu-otf which will be badly abused and (almost) all nodes will be put in the menu hierarchy instead of stuff like About Us, FAQ etc, we can look ahead for situations where someone locks himself out of his drupal cold after a node submission because the menu tree will grow too large. I know this can not be solved for 4.7, it's too late, but let's discuss it. Regards NK

10 13

[drupal-devel] Drupal on SQLite
by Karoly Negyesi 24 Oct '05

24 Oct '05

There is good code at http://mbostrom.us/cowiki/31.html . Unlike my code it's not so ugly, as it fixes the result sets. It's a small performance hit but as SQLite locks the entire DB it's not useable for heavy sites, anyways. But if someone is up for it, go for it. COUNT DISTINCT is, I think, not taken care of, but that can be done by the regex in my version because that's a simple regex. I have clarified with the author that it is GPL. I know there is demand as I get about 1-2 letters on this every week. Regards NK

1 0

[drupal-devel] theme_select should use #attributes instead of #extra
by Vernon Mauery 24 Oct '05

24 Oct '05

Currently, theme_select does not use the #attributes property, but uses the #extra property instead. To make all the form elements consistant and to follow what the documentation says, it should use #attributes and drupal_attributes to format them. Check out the patch at http://drupal.org/node/35114 and review it. --Vernon

1 0

[drupal-devel] Different queries for different SQL systems
by None 24 Oct '05

24 Oct '05

1 0

[drupal-devel] Content creation usability
by Chris Cook 24 Oct '05

24 Oct '05

The new Forms API and collapsible fields are a huge improvement, especially on the content creation page. This page needs to be as easy and straightforward to use as possible and we are getting ever closer to that goal. However, the fieldsets which are now collapsed by default (e.g., publishing options) are optional, given reasonable workflow settings, and should not appear at the top above the title and body fields. In my opinion, content settings should appear near the submit button as those are generally not modified every time and are likely to only be changed just prior to submitting the form (for myself anyway). I have submitted a patch to move these fieldsets below the "content" fields and I would like to see it land in 4.7. Please review and/or comment on this change. http://drupal.org/node/34920 Cheers, Chris

1 0

[drupal-devel] Re: drupal-devel Digest, Vol 34, Issue 65
by David K Norman 24 Oct '05

24 Oct '05

What? With all the talk about making sure Drupal works in a shared hosting environment (ex. sessions stored in the DB instead of /tmp), you can't be serious. drupal-devel-request(a)drupal.org wrote: >Date: Mon, 24 Oct 2005 00:27:40 +0200 From: Gerhard Killesreiter <killesreiter(a)physik.uni-freiburg.de> Subject: [drupal-devel] Fun with mysql grants To: drupal-devel(a)drupal.org Hi there! I just want to point out that as of last week we need a new database grant to run Drupal with mysql (and maybe pgsql too, no idea). Steven's search patch uses temporary tables for which you need the CREATE TEMPORARY TABLES permission. I am not sure, but I think this permission is not a default permission so we should make it clear that this permission is required in big, bold, blinking letters. And keep the flamethrower ready. Cheers, Gerhard

7 8