January 2007 - Development - lists.drupal.org

Drupal 4.7 - Question regarding Comments module.
by Ignacio G. Dupont 03 Jan '07

03 Jan '07

Hi, I have had a problem with the comments module (administer->comments) and I have a couple of questions on it. I'm currently using Drupal 4.7.4 with PHP 4.4.3 and MySQL 4.1.21 When entering the configure tab I was getting this warnings. warning: array_keys() [function.array-keys]: The first argument should be an array in /home/server/public_html/modules/user.module on line 352.warning: implode() [function.implode]: Bad arguments. in /home/server/public_html/modules/user.module on line 352.user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 1 query: SELECT DISTINCT(p.perm) FROM role r INNER JOIN permission p ON p.rid = r.rid WHERE r.rid IN () in /home/server/public_html/includes/database.mysql.inc on line 121.After debugging it a bit I found that when looking for the 'post comments' permissions it was hard sending a user with uid = 0. I have recently had to recover my database and row with uid = 0 on users table was missing. As my Administrator user has uid = 1 I tried to replace the hardcoded value to 1: --- a/comment.module 2006-10-18 15:14:42.000000000 -0500 +++ b/comment.module 2007-01-03 03:17:09.000000000 -0600 @@ -402,7 +402,7 @@ COMMENT_ANONYMOUS_MUST_CONTACT => t('Anonymous posters must leave their contact information')), '#description' => t('This option is enabled when anonymous users have permission to post comments on the <a href="%url">permissions page</a>.', array('%url' => url('admin/access'))), ); - if (!user_access('post comments', user_load(array('uid' => 0)))) { + if (!user_access('post comments', user_load(array('uid' => 1)))) { $form['posting_settings']['comment_anonymous']['#attributes'] = array('disabled' => 'disabled'); } It seemed to work ok. I have performed a grep over all module sources and it seems that is the only place where the seccond parameter is hardcoded when calling user_access function: user@server [~/public_html/modules]$ grep "user_access([^,)]*," * blog.module: if ($type == 'view' && user_access('edit own blog', $user)) { blogapi.module: if (user_access('edit own blog', $user)) { comment.module: if (!user_access('post comments', user_load(array('uid' => 0)))) { user.module:function user_access($string, $account = NULL) { I then decided to undo the change in the comment.module and go on with an insert into the users table with uid = 0 and the rest of the columns with their default values and it seems to work ok. What I don't understand is why do you pass the second argument instead of having the default value (NULL) to be assigned to the $account parameter in the user_access functiont of the user.module: function user_access($string, $account = NULL) { global $user; static $perm = array(); ... Regards. Ignacio. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.es

1 0

Re: [development] OT: Future of Transactional Engine with MySQL
by Steven Peck 03 Jan '07

03 Jan '07

> -----Original Message----- > From: development-bounces(a)drupal.org [mailto:development- > bounces(a)drupal.org] On Behalf Of Dries Buytaert > > > I've talked to some MySQL employees and it seems that Falcon is going > to be the new InnoDB -- so to speak. ;-) It's developed internally > at MySQL as a replacement for InnoDB. > > In general, it is expected that more and more storage engines will > emerge. There are even plans (jokes?) to create a mail storage > engine (with header parsing support) and/or an image storage engine > (with EXIF support). Imagine being able to query images based on the > embedded EXIF data -- sure sounds like fun. Actually there would need to be something like that developed to compete with Exchange which uses a highly optimized jet engine to accomplish that but that's a different list discussion ;).

1 0

Missing CVS branches in contrib -- peeve
by Chris Johnson 03 Jan '07

03 Jan '07

This is a pet peeve. Be forewarned. :-) Today, for the Nth time, I again wasted time looking for a module in the 4.7 branch of the contrib repository that was not there. Why? Because it was in the HEAD branch, even though it only works with 4.7 -- and not 5.0 or later. So this brings me to my pet peeve of the moment: module maintainers who do not branch their modules when appropriate. How can this be made easier for people, and more reliable for folks who want to download or checkout contrib code?

6 5

Re: [development] Missing CVS branches in contrib -- peeve
by Metzler, David 03 Jan '07

03 Jan '07

It seems to me that the docs conflict just a bit. I like the concept of using head for new feature module releases, creating releases when they're stable, and doing a branch when you need to cause the API's underneath change. Every time you branch, it seems to imply that you're going to maintain that branch for bug fixes, and I don't do that (don't have time). I will probably maintain head for the current stable version, and when I decide it's time to port, I'll create a branch to maintain bugfixes only in the prior stable release version, and continue new feature development in HEAD. Regardless as to how many branches I create (cause the docs tell me to) I'm trying to see if I'm missing something here. The only reason I bring this up, is that I've created a 5.0 branch on my code that I will "never alter any code in" because the doc's suggested I'd be irresponsible if I didn't. Shouldn't I have waited till 5.0 released before creating this branch? Is there a reason I shouldn't develop 5.x-0.1 in HEAD and then tag new releases from that?. (I've already created a DRUPAL-4-7 branch to maintain my 4.7 compatible code in and created new releases from it). Am I being "irresponsible"? What am I missing here? Decide for yourself whether you think this is in conflict: On the one hand...... http://drupal.org/handbook/cvs/branches-and-tags/contributions Once a contribution has been ported to a given version of the Drupal core API, the maintainer should create a branch that matches the branch name used by core. This is not technically required, but is definitely recommended for responsible project maintainers. These initial stable branches have the exact same format as Drupal core branches, for example DRUPAL-5 or DRUPAL-4-7. On the other..... http://drupal.org/node/17570#HEAD Eventually, you'll decide it is safe to update the module to the next version of core. At this point you should make a new branch for your previously developed features, before you start porting to the latest version of core. Once that branch was created, you would convert your module in HEAD, and when you consider it stable enough for an official release, you would create a new stable branch that was compatible with the new version of core. Thanks again Derek for the new release system... I am loving it! Dave

2 1

Not releasing for 5: remove HEAD alltogether?
by Bèr Kessels 03 Jan '07

03 Jan '07

Hi there. I maintain two projects that have better options alread in 4.7, I spent that cycle to phase them out and don't plan a release for 5. Should I remove the HEAD version from CVS? (cvs remove, so still accessible, for those interested) Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl

3 2

Evaluating Drupal 5.0
by Dries Buytaert 02 Jan '07

02 Jan '07

Hello, I plan to do a performance comparison of Drupal 5.0 with Drupal 4.7 similar to what I did at: http://buytaert.net/drupal-vs-joomla-performance http://buytaert.net/drupal-webserver-configurations-compared Along with upgrading Drupal.org to Drupal 5 that should give us some more confidence about Drupal 5's performance. Of course, there are other aspects of Drupal 5 that could do being evaluated. Two examples would be: XHTML compliance, accessibility and search engine optimalisation. For example, did anyone check whether Drupal 5 (Garland) is more or less accessible than Drupal 4.7 (Bluemarine)? -- Dries Buytaert :: http://www.buytaert.net/

7 8

Re: [development] Missing CVS branches in contrib -- peeve
by Ken Rickard 02 Jan '07

02 Jan '07

> We need a good concise document explaining step by step how to version code. http://drupal.org/handbook/cvs/quickstart I've made decent progress with CVS using that document (and the good documentation on release best practices http://drupal.org/handbook/cvs/releases) I find it easy to manage releases given the intstructions. My question is slightly naive and slightly different. I don't maintain HEAD as an active branch. That is, only 4-7--x and 5--x branches are actually working code. What I haven't found are any explicit instructions regarding the use of HEAD vs. the other branches. See the issue submitted here: http://drupal.org/node/101118, for example. I think I'm a good example of someone who uses CVS but doesn't understand it, so I'd like to know what the expectation is regarding HEAD. So, should I be committing all new changes to HEAD as well as 5--x? Or should HEAD only be used for code that complies with changes to Drupal HEAD? Or have I missed the point entirely. -- Ken Rickard agentrickard

2 1

4.7.5 (minor) API change, project_issue UI impacted: clear browser cache. ; )
by Derek Wright 02 Jan '07

02 Jan '07

hi folks. if anyone's been playing with core from the very tip of the DRUPAL-4-7 branch, you might have noticed a minor change in the API, regarding how FAPI renders #prefix elements from your form arrays. this can impact the UI of contrib modules, especially if you were trying to use css to modify the appearance of node forms. a) everyone who's messing with #prefix/#suffix around node forms should take a look at this: http://drupal.org/node/105960 b) the project_issue.css and project.css files had to change for 4.7.5 compatibility because of this. i just installed all of this on drupal.org, but you're going to have to clear your browser caches to get the new copy. ;) happy new years, -derek (dww)

8 11

Subscriptions module for Drupal.org (was Re: You know what would be really cool for d.o?)
by Boris Mann 02 Jan '07

02 Jan '07

On 12/27/06, Johan Forngren <johan(a)forngren.com> wrote: > > > On 12/27/06, Earnie Boyd <earnie(a)users.sourceforge.net> wrote: > > I know this really should be a feature request but I'm not sure which > > issue tracker to put it in. If someone could point I'll be happy to. > > > > 1) I would like to see a Subscribe button on a particular issue so that > > I can easily subscribe to an issue. This is a long requested feature in much more general terms -- i.e. subscribing to forum threads, etc. Generally, notification via email / RSS is desired. The meta issue is that we need someone to write a robust, lightweight, highly scaleable subscription framework capable of handling the volume on Drupal.org. There is the existing subscriptions module (http://drupal.org/project/subscriptions) that doesn't quite meet all of those needs yet. -- Boris

5 5

4.7 vs 5.0 UI and Workflow differences document
by Earnie Boyd 02 Jan '07

02 Jan '07

Is there a document for the general user describing the visual and workflow differences between 4.7 and 5.0? I didn't find one in my search and I've noticed that the Moderation Queue workflow is no longer provided and wanted to confirm that it was an intended difference. Earnie

1 0