March 2007 - Development - lists.drupal.org

Re: [development] What's going on with this person's commits?
by Ken Rickard 10 Mar '07

10 Mar '07

I've seen this behavior as well, but only from the cvs end-user side. I only have cvs access to one project (MySite) but have 3 commits filed for the Content Recommendation Engine. http://drupal.org/user/20975 http://drupal.org/project/cre http://drupal.org/project/mysite I don't even checkout modules outside of the MySite directory path, so I know that I didn't commit to CRE. I mentioned it to Scott Reynolds (the CRE maintainer) via email and assumed he would file a bug report. -- Ken Rickard agentrickard

3 2

Installation profile projects now hosted on drupal.org
by Derek Wright 10 Mar '07

10 Mar '07

hello world, drupal.org infrastructure can now be used to host installation profiles: 1) there's a "/contributions/profiles" directory in the contrib repo. http://cvs.drupal.org/viewcvs/drupal/contributions/profiles/ README.txt?view=markup 2) there's a new Project type, called "Installation profiles": http://drupal.org/project/Installation+profiles two critical points i wrote in the README.txt: a) "At this time, only files ending in .profile or .txt are allowed to be committed, since installation profile maintainers should *NOT* include the code of the modules that are enabled by their profiles." b) "In the future, we will have a system where a file in each installation profile directory will define what versions of Drupal core and each contrib module should be packaged with the profile, and the packaging script will generate a single download-able tarball of all the code, and the installation profile. Until that time, the downloadable package for installation profile projects will just contain the .profile and .txt files." it's likely that somewhere at OSCMS '07 @ Yahoo, a discussion will break out about this topic, including: - what to name the "packaged collection of a profile, core, and all its contrib modules"? - how installation profile maintainers specify what modules (and versions!) to package with their profile - etc, etc. people who care about this debate are encouraged to participate here: http://groups.drupal.org/distributions for example: http://groups.drupal.org/node/2164 http://groups.drupal.org/node/2163 http://groups.drupal.org/node/3086 ... cheers, -derek (dww)

2 2

a roundup of web 2.0 environments for developers
by Kristjan Jansen 09 Mar '07

09 Mar '07

SolutionWatch is a site what does couple of good things: - they are not another web20-newsstream site like any other - the issue really detailed roundups of web 2.0 tools available on certain topics (tools for education, tools for small business, now tools for developers) http://www.solutionwatch.com/578/a-roundup-for-developers-developers-develo… have a look. if not more, you get some inspiration how drupal.org issue tracker should really look and behave, in DDH (1) Kristjan/Kika Jansen (1) Drupal Development Heaven

2 1

new editor at drupaldigest.com
by Moshe Weitzman 09 Mar '07

09 Mar '07

I am happy to let everyone know that the fine email digest service at http://drupaldigest.com has a new editor for the 'cvs commit messages' mailing list. Greg Knaddison replaces myself as the poor soul who reads all commit messages and hand picks the most important ones and puts them into a high quality rss feed. He reads the logs so you don't have to. You can subscribe to our feeds at http://drupaldigest.com. Angela Byron is editor for the documentation email list and I remain as editor of this development list.

4 3

Re: [development] Installation profile projects now hosted on drupal.org
by Matt Farina 08 Mar '07

08 Mar '07

1 0

is nodeapi hook a requirement or not?
by Peter Wolanin 08 Mar '07

08 Mar '07

In response to Moshe's suggestion, I'll just comment that while this is a good idea, there needs to be more consistency or guidelines about the way that nodes are loaded/saved for this to be sure to work with contrib modules. I've had experience with the Clone module where some node types expect to only be saved via the node form, and break if you do a direct node_save(): http://drupal.org/node/119140 http://drupal.org/node/92175 -Peter ---- From: Moshe Weitzman <weitzman(a)tejasa.com> To: Junyor <development(a)drupal.org> Date: Thu, 08 Mar 2007 00:06:24 -0500 Subject: [development] is nodeapi hook a requirement or not? i've bumped into a limitation in node.module that i makes me squirm. our bulk node operations on admin/content/node are very efficient because they perform single UPDATE statements like (make these nodes promoted): db_query('UPDATE {node} SET status = 1, promote = 1 WHERE nid IN(%s)', implode(',', $nodes)); the problem is that we don't let modules know about these changes via nodeapi. so modules which listen on nodeapi('update') never know about this change. oddly, the delete operation does do one by one deletion which is good because we aren't leaving behind cruft in ancillary node tables.

1 0

CCK development
by Dries Buytaert 08 Mar '07

08 Mar '07

Hello, for people that want to help with migrating some of CCK to core (haven't seen any patches yet), this great Lullabot article can help you get up to speed: http://www.lullabot.com/articles/ an_introduction_to_the_content_construction_kit -- Dries Buytaert :: http://www.buytaert.net/

1 0

is nodeapi hook a requirement or not?
by Moshe Weitzman 08 Mar '07

08 Mar '07

i've bumped into a limitation in node.module that i makes me squirm. our bulk node operations on admin/content/node are very efficient because they perform single UPDATE statements like (make these nodes promoted): db_query('UPDATE {node} SET status = 1, promote = 1 WHERE nid IN(%s)', implode(',', $nodes)); the problem is that we don't let modules know about these changes via nodeapi. so modules which listen on nodeapi('update') never know about this change. oddly, the delete operation does do one by one deletion which is good because we aren't leaving behind cruft in ancillary node tables. since this page only allows for changing 50 modes at a time, i think it wouldn't be too slow to call node_save() on each selected node. i think thats the best way to assure integrity for all those modules which expect to hear about node changes. this form doesn't have to be lightening fast. folks might also be interested in a Views powered version of this page which i've specced out at http://drupal.org/node/125810. conversation about this Views plugin should stay within that issue.

4 3

memcache
by Steve Rude 08 Mar '07

08 Mar '07

I don't want to hijack the file cache maintainer thread, so I am starting my own thread about this since I have some questions. I did talk to Robert about this in January, and I have done extensive testing with his code. His code patches core files all over the place in order to check memcache if there is a cached version available and then load that first. He has stated at http://drupal.org/project/memcache that "A set of patches that can be applied selectively to Drupal to cache various objects for high performance. The patches are necessary and this cannot be avoided." However, if we are doing object level caching for nodes than we can cache a complete loaded node without the need to hit the database until a node_save, until a new module is enabled or until the max life is hit. If the code in node_load hit the static variable $nodes first, then secondly hit cache_get then we would not need to have a set of patches, and this could be an option in the performance settings. You could then allow the pluggable cache.inc that I just realized has been merged into HEAD (As of January) to handle storage. This would only take a small change to the core modules in a few places. For example in node.module, if (is_numeric($param)) { if ($cachable && isset($nodes[$param])) { return is_object($nodes[$param]) ? drupal_clone($nodes[$param]) : $nodes[$param]; } $cond = 'n.nid = %d'; $arguments[] = $param; } could be changed into something like this: if (is_numeric($param)) { if($cachable) { if (isset($nodes[$param])) { return is_object($nodes[$param]) ? drupal_clone($nodes[$param]) : $nodes[$param]; } //Attempt to load from cache return false on cache miss $node = cache_get($param, 'cache_node'); if($node) { //Load into static $nodes $nodes[$param] = is_object($node) ? drupal_clone($node) : $node; return $node; } } $cond = 'n.nid = %d'; $arguments[] = $param; } I have time to work on this and offer performance testing. I am just not sure how far anyone has gone down these roads or is currently working on it. I have been working on custom module development for clients for about 7 months now and I have not really had time to contribute to the Drupal project personally other than by spreading the good word and having clients use Drupal. This is one area that I feel could be substantially improved upon in order for us to allow Drupal to scale beyond the current ability. According to Dries testing on his website, he has seen Drupal into the 80+ Requests per second area (ref. http://buytaert.net/drupal-webserver-configurations-compared) With some of the testing I have done with caching, I have seen it go as high as 500-700 Requests per second. In my testing out of the box I have seen Drupal do about 10 requests per second, with normal caching about 100 requests per second and with aggressive caching as high as 250 request per second. Thanks, Steve Rude On 3/6/07, Khalid Baheyeldin <kb(a)2bits.com> wrote: > > See this http://drupal.org/project/memcache > > Talk to Robert about it before you duplicate it. > > On 3/6/07, Steve Rude <steve(a)achieveinternet.com> wrote: > > > > I have done much testing with memory based object caching using > > memcached and I think it would be nice if there was the ability to choose > > what type of caching you wanted (memory/file/db) and have the cache.incfunctionality basically an abstraction layer that the storage mechanism can > > be taken care of by other include files ( e.g. cache-memcache.inc > > cache-file.inc. The same way that the database abstraction works. > > > > I would be willing to begin some work on this if anyone is interested. > > We are building a Drupal site now that will need to scale to >30m page views > > per month and I would like to work within an accepted method to help grow > > and scale Drupal. > > > > If anyone has any prior work or projects that can be looked at to help > > get this going down the correct path, please point me in the right > > direction. > > > > Thanks, > > > > Steve Rude > > > > On 3/6/07, Karoly Negyesi <karoly(a)negyesi.net> wrote: > > > > > > Hi, > > > > > > I might be mistaken but I thought file caching was something much > > > sought > > > after. I found posts relating to it as early as 2002. > > > > > > And yet, when the possibility has arisen for it to happen cleanly > > > (pluggable cache.inc), the code for it has been dumped into CVS on > > > August > > > 26, 2006 and not a single cvs commit since then. > > > > > > It's not used much according to the issues but that probably has > > > something > > > to do with not having a single release. > > > > > > Is the community truly interested? If yes, then please a maintainer > > > step > > > up. > > > > > > And yes, I have contacted the current maintainers three months ago to > > > no > > > avail. > > > > > > Regards, > > > > > > NK > > > > > > > > > > > -- > > > > Steve Rude > > Lead Web Developer > > > > 800-618-8777phone / 858-225-0479 fax > > www.achieveinternet.com > > steve(a)achieveinternet.com > > > > Achieve Internet is a Division of > > Web Page Maintenance, Inc. > > > > > -- > 2bits.com > http://2bits.com > Drupal development, customization and consulting. > -- Steve Rude Lead Web Developer 800-618-8777phone / 858-225-0479 fax www.achieveinternet.com steve(a)achieveinternet.com Achieve Internet is a Division of Web Page Maintenance, Inc.

8 19

Menu feature -- can we lose this, please?
by Karoly Negyesi 07 Mar '07

07 Mar '07

Hi, One of the biggest problems I am facing is a feature that happened somewhat accidentally in the old menu system. If you give administer comments right to someone and no other administer permission then you will see a 'Comments' link along with 'My account' and 'Logout'. This 'bubbling' just kills the new system. So, what about we get rid of it for good? admin, admin/by-task, admin/compact, admin/by-module, admin/logs, admin/help has access administration pages and their children have this permission, too. admin/settings, admin/content, admin/build and admin/user is currently set to administer site configuration . While it has logic in it, I would like to see a permission for the collection pages listed here which is not used anywhere else. Then you give your admin 'see admin pages' rights which in itself does not grant you any admin priviledges and also administer comments. However this comments admin user would see a very empty admin/build page, for example. With a nice message, probably. Is this acceptable? If not, then there are not one but two patches that are able to address this problem. However, the simpler one would slow down D6 to D5 speeds and the more complex one is, erm, a hell lot more complex and I have not yet benched it. See http://drupal.org/node/122876#comment-206669 #12 for the more complex approach, #15 for the simpler. If we find that a) the above is not acceptable b) the more complex one is needed then I will need help with explaining and commenting the code . Regards, NK

11 16