December 2005 - Development - lists.drupal.org

drupal php requirement : more than 8 Mb now?
by Christophe Chisogne 14 Dec '05

14 Dec '05

I had a strange problem while importing a new po file in drupal 4.6.4/5. Finally, I found the solution [3] : memory_limit should be higher than 8Mb. The module causing seems to be locale. As it is in drupal core, I think the "System requirements" page [1] should be updated, because the next line isnt really true in my eyes: "php memory of 8MB for a Drupal core install." I know there is another web page [2] telling sometimes drupal needs more PHP memory, but I fear the exception had become the rule. What do you think ? On one side, a 12Mb requirement may scare users, but on the other side, it would help users to avoid problems. Ch. [1] System requirements http://drupal.org/node/270 [2] My admin > modules page is blank http://drupal.org/node/31819 [3] Locale doesn't work for me http://drupal.org/node/12020#comment-18732

8 8

About options... :)
by piotr＠mallorn.ii.uj.edu.pl 14 Dec '05

14 Dec '05

Hi, Linus opinion (and mine btw ;)): http://lists.osdl.org/pipermail/desktop_architects/2005-December/000390.html http://lists.osdl.org/pipermail/desktop_architects/2005-December/000395.html -- Piotrek irc: #debian.pl Mors Drosophilis melanogastribus!

7 8

Re: [consulting] managing many sites
by Ber Kessels 14 Dec '05

14 Dec '05

Op dinsdag 13 december 2005 09:53, schreef Dries Buytaert: > Yes. I have been thinking exactly that. We could re-use the > aggregator module's RSS parsing routines to suck in important > announcements and show them on a dashboard (main administration page). For our hosting environment I am writing a module that does exactly that. My plan for using it, is a tip of the day for admins. but we can use it for this too. The hard part, is getting a proper XML parser out :) Ive started this, and its in my sandbox, but RSS/XML parsing on php < 5 is a nightmare :) and aaggregator.module is far too specific and needs nearly complete rearchitecturing if it wants to become a general RSS parser. XML gurus please hop on :) -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber(a)jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |

7 7

Re: [development] new form api: dates works?
by Fabio Varesano 14 Dec '05

14 Dec '05

Thank you... but I'm doing a print_r($node) before inserting to the database.. so getting [closing_date] => 1 printed should mean that there are some problems in getting the date values from the apis... I made some investigations on other modules wich uses calls to form api for dates... found profile.module (in core). I created a new profile field as date (birthdate) and tryed to assign it a value on my profile page.. but also this seems not to work... Alwais getting 01/01/1 as birthdate.... Fabio p.s.: I didn't find where you used date form api on your sandbox Simon Lindsay wrote: > Fabio Varesano wrote: > >> function goods_request_insert($node) { >> print_r($node); die(); >> db_query('INSERT INTO {goods_request} (nid, vid, tid, closing_date, >> shipping_address) VALUES (%d, %d, %d, %d, %s)', $node->nid, $node->vid, >> $node->tid, $node->closing_date, $node->shipping_address); >> } > > > I think you need to have > > VALUES (%d, %d, %d, %s, %s) > > as using %d will convert it to a number, and 2005-12-12 15:41:09 +0000 > wont convert well ;-) > > It looks like you might be making a purchase order type of module? > > I'm working on an estimate/invoice/purchase order system for my small pc > shop, my code is in contribs/sandbox/simon/pcshop. > > Take a look if you like, comments/assistance/code reuse appreciated ;-) > > TIA > > Simon >

1 1

[bug] nodeapi calls terminated because of node_loads
by Bèr Kessels 13 Dec '05

13 Dec '05

Issue status update for http://drupal.org/node/40886 Post a follow up: http://drupal.org/project/comments/add/40886 Project: Drupal Version: 4.7.0-beta1 Component: node system Category: bug reports Priority: critical Assigned to: chx Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch (ready to be committed) @dries. I have no clue, really :p This array-memoy-space-pointer-stuff is way over my head. CHX, mind sharing your knowledge here? Oh, and chx, do you mind changing this to 'normal' instead of critical? so far, in about two years, i'm the only one who ever encountered it, and that even for a rather unpopular module. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Mon, 12 Dec 2005 16:38:36 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/node_module_nodeapi_oddness.patch (873 bytes) in clipper module I ran against a breally odd issue. When enabled, about half the other modules' nodeapi hooks would not get called. flevour [1] hopped on for a wild bughunt, and came with this solution: instead of doing a <?php foreach (module_implements('nodeapi') as $name) { ?> we call the module_implements('nodeapi') before. Here is how to reproduce: Just add a random node_load(1) to any nodeapi insert, update or validate, in a random module (well, not upload, because that is the last one ran, most prolly :) ). You wil then notice that half of the data in your node/add or /edit screens are no longer saved, nor checked. This tiny patch fixes the issue. I have no clue why, but it does fix it. :) [1] http://www.flevour.net/ ------------------------------------------------------------------------ Mon, 12 Dec 2005 16:59:44 +0000 : chx This is sheer impossible. I'll investigate more but there is no way module_implements' internal cache (a static variable) gets overridden, after that cache is build it's only returned. There is no reset facility as there is no need. ------------------------------------------------------------------------ Mon, 12 Dec 2005 17:02:00 +0000 : chx I am babbling because of the shock. foreach operates on a copy. it does not matter whether module_implements is immutable. Ber, what PHP version do you run? ------------------------------------------------------------------------ Mon, 12 Dec 2005 17:38:39 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/node_module_nodeapi_oddness_0.patch (900 bytes) I find it funny that you say it is impossible, while the preactice proves that this fixes the issue. "One should really learn to beleive reality, even if theory doesnt allow that reality" anyhow, a slighly modded patch, one that adds a comment. ------------------------------------------------------------------------ Mon, 12 Dec 2005 18:08:04 +0000 : chx As said, I am babbling. Second, while the patch is patch good, I told you, I fear about what else is broken. Not what your patch brokes, but there is an unknown cause and that cause might have broken other stuff too. ------------------------------------------------------------------------ Mon, 12 Dec 2005 18:39:36 +0000 : chx Attachment: http://drupal.org/files/issues/php_bug.patch (312 bytes) I chatted with Goba and we worked around the problem at its root. ------------------------------------------------------------------------ Mon, 12 Dec 2005 18:48:41 +0000 : chx Attachment: http://drupal.org/files/issues/php_bug_0.patch (521 bytes) Much better comments. This is super-duper hard. ------------------------------------------------------------------------ Mon, 12 Dec 2005 18:56:36 +0000 : Goba This fixes the issue much more generally, and should be committed. (The issue is that arrays in arrays are stored with references). +1 ------------------------------------------------------------------------ Mon, 12 Dec 2005 19:15:04 +0000 : chx Attachment: http://drupal.org/files/issues/php_bug_1.patch (570 bytes) Linking relevant Zend docs. ------------------------------------------------------------------------ Tue, 13 Dec 2005 15:55:43 +0000 : Dries I'm not sure I understand the PHP comment. What do you mean with 'the array pointer will be off'? Can you try to clarify that part of the code comment? Thanks.

1 0

[bug] if no 'access statistics' permission, don't show stats @ node
by Bèr Kessels 13 Dec '05

13 Dec '05

Issue status update for http://drupal.org/node/41034 Post a follow up: http://drupal.org/project/comments/add/41034 Project: Drupal Version: 4.7.0-beta1 Component: statistics.module Category: bug reports Priority: normal Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch (code needs review) forgot: that last option might be the best. but i'm not coding it :p Though imho it should just be as simple as a nodapi thing that adds a $node->viewcount. or even $node->viewcount->daily $node->viewcount->alltime. That would be soooo usefull :) Bèr Kessels Previous comments: ------------------------------------------------------------------------ Tue, 13 Dec 2005 16:49:38 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/stqts_lost_perm_check.diff (954 bytes) under each node, we render a number of views or that node. IF a user does not have "access statistics" we should not show this. Patch fixes that. its a small one-liner. ------------------------------------------------------------------------ Tue, 13 Dec 2005 16:53:22 +0000 : rkerr Seems to make sense... :) ------------------------------------------------------------------------ Tue, 13 Dec 2005 17:42:54 +0000 : jvandyk Yes, this is good. Current behavior is a bug and this patch fixes it. But I'd rather see a new permission 'access view counts' or some such so that I can turn on view counts without having to give full statistics access to that role. ------------------------------------------------------------------------ Tue, 13 Dec 2005 19:05:39 +0000 : Bèr Kessels Thinking about it a bit more. * any $link[] can now be filtered. thus this patch is not at all needed to get the same result: just a theme function that strips out the count 'link' should do. * any themer can add $count data . so *not* showing this at all by default makes sense too. I guess its al about what we want as default behaviour. My vote goes to: Apply this patch. Then anyone who wants to show anyone the node-view count can do so in a theme function. But Im perfectly fine if people decide to: Won't fix this patch and let me+others, who do not want to show this to users, 'hack' it out in a rather simple theme function. But I am not for a separate permission for this. its not really a permission. And if we go for an option/permission, it should live in the "admin > settings > content-types" and be a per-node option, imnsho.

1 0

[bug] if no 'access statistics' permission, don't show stats @ node
by Bèr Kessels 13 Dec '05

13 Dec '05

Issue status update for http://drupal.org/node/41034 Post a follow up: http://drupal.org/project/comments/add/41034 Project: Drupal Version: 4.7.0-beta1 Component: statistics.module Category: bug reports Priority: normal Assigned to: Bèr Kessels Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch (code needs review) Thinking about it a bit more. * any $link[] can now be filtered. thus this patch is not at all needed to get the same result: just a theme function that strips out the count 'link' should do. * any themer can add $count data . so *not* showing this at all by default makes sense too. I guess its al about what we want as default behaviour. My vote goes to: Apply this patch. Then anyone who wants to show anyone the node-view count can do so in a theme function. But Im perfectly fine if people decide to: Won't fix this patch and let me+others, who do not want to show this to users, 'hack' it out in a rather simple theme function. But I am not for a separate permission for this. its not really a permission. And if we go for an option/permission, it should live in the "admin > settings > content-types" and be a per-node option, imnsho. Bèr Kessels Previous comments: ------------------------------------------------------------------------ Tue, 13 Dec 2005 16:49:38 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/stqts_lost_perm_check.diff (954 bytes) under each node, we render a number of views or that node. IF a user does not have "access statistics" we should not show this. Patch fixes that. its a small one-liner. ------------------------------------------------------------------------ Tue, 13 Dec 2005 16:53:22 +0000 : rkerr Seems to make sense... :) ------------------------------------------------------------------------ Tue, 13 Dec 2005 17:42:54 +0000 : jvandyk Yes, this is good. Current behavior is a bug and this patch fixes it. But I'd rather see a new permission 'access view counts' or some such so that I can turn on view counts without having to give full statistics access to that role.

1 0

Administration Survey: Theme improvements, theme help system, theme mailing list
by Kieran Lal 13 Dec '05

13 Dec '05

As part of the Drupal administration user experience survey we identified Drupal theme issues as the most difficult administration issues( http://www.surveymonkey.com/DisplaySummary.asp? SID=1425065&U=142506581557). There was some confusion about the results so Trae McCombs, from CivicSpace Labs, conducted six additional theme development interviews. Trae identified some common goals of theme developers, basic theme tasks, and difficult theme tasks. I have created a documentation page, http://drupal.org/node/39451, which outlines all this. I also spoke with Dries yesterday and requested that a theme developers mailing list be started to focus on helping with Drupal's most difficult administration task. In summary here are the actions we are taking to improve administration specifically focused on Drupale theme development. 1) Identified Drupal theming as the most difficult Drupal administration task. 2) Improved the project module to allow for categorization so that themes can be categorized to help themers pick a solid base theme. Designed by Dries and implemented by Nedjo Rogers for CivicSpace Labs. This is coming in the next few weeks on Drupal.org. 3) Provided a "Manage inconsistency in themes" documentation page with best practices. http://drupal.org/node/37156 4) Created a support channel #cstheme to support development of the CivicSpace theme. This may lead to a dedicated Drupal theme channel. 5) Added a link to theme help from the theme admin interface using the CivicSpace theme. Added several base layouts to the CS theme for theme developers to customize with styles. 6) Created a theme help documentation page to focus on basic and difficult theme tasks. http://drupal.org/node/39451 7) Requested a themers mailing list to focus specifically on the tasks of Drupal theme development Please help us to develop theme help documentation(http://drupal.org/ node/39451). Understanding basic and difficult theme tasks, and how to solve them, will allow us to attract more themers to the platform and make it easier for all of us to theme our sites. I'll leave you with a quote: Dries_:it's the reason I didn't convert buytaert.net yet -- it takes too f*****g long to make a theme Cheers, Kieran Development Manager CivicSpace Labs

18 33

auto_increment
by Knite 13 Dec '05

13 Dec '05

This has probably been discussed in depth before, and I've found a few nodes on drupal.org that captured some of the ideas, but I'm relatively new to this list, so please forgive me and enlighten me if there's more history I should know about. AUTO_INCREMENT looks like a database feature that is supported in the databases that drupal currently supports, namely mysql and pgsql. From what I gather from documentation at mysql.org and from previous comments in our forums, it seems that AUTO_INCREMENT is an improvement over the current system of creating nid's using the sequence table (and having to lock it). I'd like to look into moving drupal to use auto-increment instead of table locking, for both performance reasons (1 query vs 3) and webhost compatibility reasons. (There are some webhosts that do not grant LOCK TABLE permission.) Has anyone attempted this conversion before? Any words of advice? Is this something that's supposed to be left to the core developers? Ken

9 15

Drupal 4.7.0 beta1
by Dries Buytaert 13 Dec '05

13 Dec '05

The Drupal 4.7.0 beta1 bug reports: http://drupal.org/project/issues? projects=3060&versions=9728&states=1,8,13,14,2 Clearly, we need more help fixing bugs! Please take a moment to fix a bug or two. Give me something to review and commit. Thanks! -- Dries Buytaert :: http://www.buytaert.net/

1 0