July 2008 - Development - lists.drupal.org

Tmp directory
by Miriam Natanzon 12 Jul '08

12 Jul '08

Hi all, I’m working with Drupal for several months, and today I’v noticed that in the “Tmp” directory (which holds the files till the uploading process complete), There are several “old” files. As I understand this phenomenon, these files are files that their upload-process wasn’t completed successfully , And from some reason they were forgotten in the temporary library… even cron run didn’t delete them. Is there any built-in way to get rid of that unnecessary files? Many thanks! Miriam

7 9

programmatic creation of node
by Novák Áron 11 Jul '08

11 Jul '08

Hi! While the development of FeedAPI, i faced with a problem. FeedAPI has to create nodes programmatically, i believed that this is a really easy thing to do, feedapi now works like this: $node->data1 = "foo"; $node->data2 = "bar"; node_object_prepare($node); // this is about the default values node_save($node); But I got a report that this is not a good way to do: http://drupal.org/node/196273 Summary: "node_object_prepare() and node_prepare() functions are meant to simulate the demonstration of a node" And some users, who use FeedAPI + 3rd party modules together, really experience bugs around node creation / handling: http://drupal.org/node/195105 (summary: the core forum module uses form_alter to pass taxonomy-like data. And this data is lost now.) Can you suggest me a perfect way to handle this problem? mustafau (http://drupal.org/user/207559) suggested to use drupal_execute($form_id, $form_values), but in this case, i had another problem: drupal_execute has no useful return value and $node structure remains unaltered, so i had to do a node_load after this, which is quite expensive. Thanks, Aron Novak

11 20

Drupal 7 node_load and node_save caching behavior bug
by David Goode 11 Jul '08

11 Jul '08

Hello fellow developers, In fixing an error related to the notifications module in Drupal 5 and 6, I came across an unexpected behavior that merits discussion, and possibly a fix in Drupal 7, as the functionality doesn't appear to have changed. The immediate issue is on pages such as the node edit form when using the notifications module with immediate sending, but applies in many other places. It occurs when these actions occur sequentially, which is quite commonplace: 1: a node_load is performed for [nid] 2: a node_save is performed on the same [nid], updating the database accordingly 3: either during the nodeapi('update') hook or afterwards, a node_load is performed on [nid] When number 3 occurs, it will load the OLD node, prior to the update, because the node will have been CACHED in the static variable of the node_load function. ------------------------------ ----------------------------------------------- I believe this generally hasn't been found to be a problem because the new $node is passed around through all the update hooks, so node_loads aren't generally required. However, I came across the problem in fixing an issue for the notifications module (http://drupal.org/node/278530) What happens is notifications_content_nodeapi adds an event to the queue, but the $node object is not passed around. If notifications is set to send immediately, it will call the sending stack, which does a node_load on the node and creates the message. However, it was sending the old message when an update event occurred (because it had been cached), causing a user to report the issue. For notifications I have fixed this issue by simply node_loading and telling it to clear the cache in notifications_content_nodeapi. However, I wonder whether a better default behavior would be to have node_save clear the cache itself? I don't know of modules that depend on either 1) showing the old node throughout the page after a node_save or 2) showing the same version of the node in two places, between which a node_save is performed. However, if there are any they might be affected by this change. Either way, I believe it merits discussion. Also, if it is to be performed, it is a very simple fix: node_load(0, NULL, TRUE); but I am not very familiar with the rationale behind the node_save, node_save_revision, drupal_write_record etc functions in drupal 7, so perhaps there is a better place to put it than just in the node_save function somewhere. It could even be in an optional module that is called on nodeapi('update') with a very low weight. David Goode davidgoode(a)gmail.com

3 2

Future 6.x release schedule?
by Jim Li 10 Jul '08

10 Jul '08

Glad 6.3 is out, and I notice there are approximately more than 60 patches get into 6.3 release. Though I don't know how many of these fixed issues are critical, it raises the question to me that do we want to review release schedule for 6.x? I know it's been discussed before, but can we reconsider it, especially given that 7.x release is pushed out to maybe mid 2009? If my understanding is correct, current policy or practice on old rev release is not until a security bug surfaces. It works okay when release cycles are relatively short (I think 5.0 was release 10.5 months after 4.7). But sometimes, I still, guilty as it is, can't wait to see some security bugs are found, not only because drupal is safer but more to the fact that other critical patches get a chance to get into the official release. But even so, without a release schedule, it's sort of hard to plan my time or soliciting help on certain critical 6.x issues. So what do you think if we have some sort of flexible but known schedule for future 6.x release, by either set a tentative target date, like Nov 1th or every 4-6 months or when critical bug fixes have accumulated to a certain number, then 6.4 will be released?

5 4

new maintainer wanted for module linktocontent
by Stefan Borchert 10 Jul '08

10 Jul '08

Hi. After trying several weeks to find some time to implement all the ideas [1] I've got in mind for the next release of linktocontent [2] (or even start porting the module to 6.x) I must admit: I don't have some. If someone feels strong enough (:-)) to take the module and give it the love and attention it needs, please contact me. I will try to give as many assistance you need to push development of linktocontent. thanks, Stefan [1] http://drupal.org/project/issues?projects=74128&states=1,16,8,13,14,15,2,4&… [2] http://drupal.org/project/linktocontent

1 0

update node_example.module to use schema api
by Jon Saints 10 Jul '08

10 Jul '08

I notice that the file node_example.module on http://api.drupal.org/api/file/developer/examples/node_example.module has not been upgraded to show how to use the schema api. I am interested in updating this page, which has been so helpful to me, to include a hook_schema implementation and some drupal_write_record calls. How and where is this documentation stored? What is the best way for me to make my proposed changes so they can be reviewed by the community and maintainer? Thanks Jon

2 1

Re: [development] Drupal could be 10x times faster with correct indexing
by David Timothy Strauss 08 Jul '08

08 Jul '08

When it comes to database capabilities, MySQL is quite a bit more than a glorified card catalog. When it comes to database architecture, Drupal developers are quite a bit more than rejected Microsoft Access programmers. ----- "Jean-Michel Pouré" <jm(a)poure.com> wrote: > Here is the issue with solutions: > http://drupal.org/node/276742 >From the issue, it seems like your indexes are missing or misconfigured. > When using MySQL, you don't really know how SQL queries are treated, > except execution times that may be monitored (?). Wrong. Use EXPLAIN. > This way, the database server is always faster than any kind of PHP cache. Wrong. Databases have higher latency for even simple queries compared to PHP static caching and memcache. > There is an extensive query debugging needed on Drupal: > [...] > 6) Add indexes everywhere. Wrong. Indexes add multiple forms of overhead. They should not be added gratuitously. Indexes should be added when they enhance performance more than they cost it or if they enhance data integrity (UNIQUE/PRIMARY keys). > [...] I consider this as a bug, [...] Wrong. Bugs are issues of correctness. Performance improvements are not issues of correctness.

7 11

paging module need to work out
by bharani kumar 05 Jul '08

05 Jul '08

Dear Am using paging for article content, in my table body field contains the all html tags my content looking like this manner <code> <table width="350" cellpadding="5" cellspacing="0" border="0" align="right"> <tr> <td><img src="/images/2002/November/tool_Fig1.gif" border="0" /></td> </tr> <tr> <td align="center"><font size="1">Figure 1. These examples show the application of die design guidelines.</font></td> </tr> </table> <i>Editor?s note: Chris Rauwendaal is a designer, consultant, and seminar instructor who has written extensively on process engineering and extrusion topics.</i><br /><br /> Die design for extrusion can be rather complicated, since the size and shape of the extruded product varies from that of the die flow channel. Multiple mechanisms affect the size and shape changes in the extruded product, and these can be controlled by die design.<br /><br /> </code> the above is my content, what happen u see, when the page break is inserted inside table tag, then the table content divided into two pages, Tell me solution for this????????? i want like this manner <code> <table width="350" cellpadding="5" cellspacing="0" border="0" align="right"> <tr> <td><img src="/images/2002/November/tool_Fig1.gif" border="0" /></td> </tr> <tr> <td align="center"><font size="1">Figure 1. These examples show the application of die design guidelines.</font></td> </tr> </table><--break--> <i>Editor?s note: Chris Rauwendaal is a designer, consultant, and seminar instructor who has written extensively on process engineering and extrusion topics.</i> <--break--> <br /><br /> Die design for extrusion can be rather complicated, since the size and shape of the extruded product varies from that of the die flow channel. Multiple mechanisms affect the size and shape changes in the extruded product, and these can be controlled by die design.<br /><br /> </code> anu support for this........ Thanks

1 0

Filter taxonomy
by Bertrand Mansion 04 Jul '08

04 Jul '08

Hi, In my configuration, I have users who belong to organic groups who can create "projects" nodes. Upon creation, these "projects" node automatically create taxonomy terms using the NAT module. Now, I would like to propose to the user only the "projects" terms he created (acctually, the ones created by people of his group as well, but if I can do one, I can do the other). Is there a module, a hook or a way to filter out some terms when a node is edited/added by a user that is not allowed to use these terms? At the moment, I have patched taxonomy.module but it would be nice to have something maybe like hook_taxonomy() with a "load" operation? -- Golgote Blog : http://golgote.freeflux.net

1 0

Re: [development] no date / time types in schema API
by Karen Stevenson 02 Jul '08

02 Jul '08

>> A solution based on timestamps is much more elegant: timestamps need >> no (database-specific) parsing whatsoever (both on reading and >> writing to the database), they play nice with arithmetic (and thus > >You obviously have never dealt with timestamps for dates... > >They are a most royal PITA, especially when dealing with timezones and >DST. Couldn't have said it better myself. The two people on this list who have probably spent more time than anyone else in Drupal trying to do things like proper timezone conversions on timestamps are in complete agreement that timestamps are a PITA. They also don't work at all well for historical dates, nor for incomplete dates -- years and months with unspecified days or dates without times. They imply a level of precision to the second when that may not be at all true. They have no knowledge of timezones nor any way of dealing with timezones. When you store a date in a database's native datetime format, the database can do timezone adjustments on the value, format the date values, and extract things like a month or year out of the date. If you store the date in a timestamp and need to do any of those things, you first have to come back and cast the timestamp as a datetime field, which is neither simple nor elegant, and works differently (and sometimes badly) in different databases. Dates are complicated beasts. Treating them as timestamps doesn't solve the problems, it just creates different ones. I'm looking forward to getting them out of Drupal core. Karen

4 3