May 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Don't promote forum topics by default
by Steven 31 May '05

31 May '05

Issue status update for http://drupal.org/node/24003 Project: Drupal Version: cvs Component: forum.module Category: feature requests Priority: normal Assigned to: Steven Reported by: Steven Updated by: Steven Status: patch Attachment: http://drupal.org/files/issues/forumpromote.patch (1.14 KB) One side effect of the node system is that all the default node flags (promote, revisions, etc) have only one default setting for all node types. The most meaningless result of that IMO is that forum topics are promoted to the front page by default. This is probably one of the most confusing things people run into when setting up a Drupal forum. The attached patch adds a row to the variable table to force forum topics to not be promoted by default. This will only affect new installations. Patch is for CVS, but IMO it should go in 4.6 too. Steven

1 2

[drupal-devel] Seeking maintainer of webform.module
by Syscrusher 31 May '05

31 May '05

Greetings! I've tried contacting the person listed with the project, but never got any response, so I'll post more broadly here in case that person has moved on to other things. I need to reach the maintainer of the "webform" module as soon as possible, because I have some contributed patches to offer. My company needed to use this module internally, and needed some enhancements. So I got paid to write them, the company gets to use them, and per my company's wonderful Open Source policy, I get to contribute them back to the community under GPL. Everyone wins. What I have added to webform.module is: * Additional flexibility in setting the "Subject" line for emails of submitted forms, including a template-built subject line that can optionally include values of one or more fields from the submitted form. * Ability for the administrator to force the "From" address of generated emails to be the email address from the authenticated Drupal user, instead of an address the user enters into the form. * A new field type "select sql" that allows an arbitrary SQL query to return the list of options for list, checkbox, or radio fields. This allows, for example, a selection list that includes things like "all of the titles of the user's last N nodes" or similar site-defined queries. * A new field type "select php" that calls an arbitrary PHP function to get the list of options for list, checkbox, or radio fields. I'm using this feature to allow users to select a project number from a completely separate project tracking system The code is done, tested, and working with one exception: I need to add access checks so that editing the two new field types is restricted only to users who can create PHP-content nodes, to prevent a security hole. This isn't an issue at our company, because the "create webforms" access is already tightly restricted, but it is a potential issue in the broader community. The patches I have are against a very recent (< 1 week old) copy of the 4.6 branch for this module. So I just need to know whom to contact to submit the patch. Anyone care to step forward or offer the name and email of the current maintainer? Any assistance appreciated. Kind regards, Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher

1 0

[drupal-devel] [bug] menu error line 974 with MBstring
by mark.stephens 31 May '05

31 May '05

Issue status update for http://drupal.org/node/22026 Project: Drupal Version: cvs Component: menu system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: hendler Updated by: mark.stephens Status: patch I was having this problem with a clean install of drupal 4.6.0. I had mbstrings enabled in PHP. I turned it off, and the problem went away immediately. Within mbstrings, I had: mbstring.language = English mbstring.internal_encoding = UTF-8 mbstring.http_output = auto mbstring.func_overload = 7 PHP 4.3.11. Mark mark.stephens Previous comments: ------------------------------------------------------------------------ May 5, 2005 - 00:15 : hendler Menu.inc on line 974 the do {}while() causes an error if $parent is empty because strrpos, (I have mbstring enabled) may be null to fix my problem I have this if statement wrapping it, which I understand is logically equivlent to just doing a while loop. if ($parent){ do { $parent = substr($parent, 0, strrpos($parent, '/')); } while ($parent && !array_key_exists($parent, $_menu['path index'])); } This happens just after a new install. ------------------------------------------------------------------------ May 5, 2005 - 23:43 : Robin Monks Attachment: http://drupal.org/files/issues/menu.inc_0.patch (908 bytes) We apparently don't check if the object exists before we work on it. Robin ------------------------------------------------------------------------ May 6, 2005 - 09:43 : Dries I wonder how I can reproduce this problem. Maybe we are fixing the symptom, not the cause.

1 0

[drupal-devel] Legal Support
by Andre Molnar 31 May '05

31 May '05

Sorry for the cross post, Do we have any members in the community that are lawyers. Occasionally we have questions pop up regarding GPL and Licensing compatibilities - and there are bound to be questions about the legality of some of the documentation. I hope to continue to help coordinate the marketing documentation, but I'm sure there are times when legal questions will arise about making certain claims or citing names in marketing documents. Is there anybody that we have that we can turn to for these kinds of questions? For example, Joshuwa - who has been doing some amazing work on the print ad - asked: "Name-dropping is an excellent idea, especially big names like 'Yahoo!', but I am almost certain you'd need permission from Yahoo! before including their name/identity in an ad. I'm not 100% sure, but might be something to consider." I'm 99% sure that we wouldn't need permission - stating a fact is a fact and the fact is that Yahoo is using drupal internally - but then again I'm not a lawyer. andre

2 1

[drupal-devel] Coding style for admin help: please come to a consensus for the docs team
by Kieran Lal 31 May '05

31 May '05

Hello, In response to a user survey of documentation needs, the Drupal documentation team is working on writing consistent and usable admin help documentation for core and contributed modules. We are maintaining this documentation in the Drupal handbook, as a single source for built-in and on-line help documentation. Each core and contributed module will have an executive summary section in the handbook. This text will also be interpolated into the _help hook of each module as the admin help text. Current admin help text and older handbook module pages will be accessible from this executive summary. The benefits are: 1) consistent and usable documentation. 2) a single source for documentation, which will be the handbook. We are currently trying to automate the process of interpolating the admin help from the handbook on Drupal.org into the module code. Unfortunately, the coding style around the _help hook is quite inconsistent. It would be appreciated if the Drupal development community could come to some consensus so that the documentation team can easily create a large number of patches in a reasonably automated way. Improvements here will also likely help with extraction of text for translation, and with eventually removing hardcoded text from the code entirely. I have created a table of 61 modules and samples of the many different styles of coding (see below [1]). For example, in the core modules, node.module and user.module both use PHP to dynamically create content. Some but not all of the core modules use the second parameter to t() for formating URLs. He has extracted samples of the admin help from 30 contributed modules. The code is not exact but should give you a flavor of the inconsistency, including the use of theme calls, in location.module, and multitple t() calls for a single piece of text. There is also code in the the HTMLarea module admin help to check if needed modules are present. Djun / Kieran [1] Table of Admin help samples: http://civicspacelabs.org/home/node/ 12711 Useful links: Core modules: http://drupal.org/handbook/modules Contributed modules: http://drupal.org/handbook/modules/contributions Executive summaries of modules are now at: http://drupal.org/ handbook/modules/modulename

1 0

Re: [drupal-devel] Coding style for admin help: admin/help#modulename
by puregin 30 May '05

30 May '05

Hello, In response to a user survey of documentation needs, the Drupal documentation team is working on writing consistent and usable admin help documentation for core and contributed modules. We are maintaining this documentation in the Drupal handbook, as a single source for built-in and on-line help documentation. Each core and contributed module will have an executive summary section in the handbook. This text will also be interpolated into the _help hook of each module as the admin help text. Current admin help text and older handbook module pages will be accessible from this executive summary. The benefits are: 1) consistent and usable documentation. 2) a single source for documentation, which will be the handbook. We are currently trying to automate the process of interpolating the admin help from the handbook on Drupal.org into the module code. Unfortunately, the coding style around the _help hook is quite inconsistent. It would be appreciated if the Drupal development community could come to some consensus so that the documentation team can easily create a large number of patches in a reasonably automated way. Improvements here will also likely help with extraction of text for translation, and with eventually removing hardcoded text from the code entirely. Kieran has created a table of 61 modules and samples of the many different styles of coding (see below [1]). For example, in the core modules, node.module and user.module both use PHP to dynamically create content. Some but not all of the core modules use the second parameter to t() for formating URLs. He has extracted samples of the admin help from 30 contributed modules. The code is not exact but should give you a flavor of the inconsistency, including the use of theme calls, in location.module, and multitple t() calls for a single piece of text. Djun / Kieran [1] Table of Admin help samples: http://civicspacelabs.org/home/node/12711 Useful links: Core modules: http://drupal.org/handbook/modules Contributed modules: http://drupal.org/handbook/modules/contributions Executive summaries of modules are now at: http://drupal.org/handbook/modules/modulename -- Djun M. Kim, Director djun.kim(a)cielosystems.com Cielo Systems Inc. http://www.cielosystems.com Strategic Software Research Tel: (604) 739-3941 302 - 1298 10th Avenue West FAX: (604) 739-3943 Vancouver, BC, V6H 1J4 Mobile:(778) 895-1379

1 0

[drupal-devel] coding scrips in /scripts.
by Bèr Kessels 30 May '05

30 May '05

Hello Can we please move the two coding scrips in /scripts in core, to contributions/tricks/code-checker ? or contributions/tricks/code-style ? I am talking about code-clean.sh and code-style.pl I think these scripts -how handy they may be- are really misplaced in drupal core. Code is checked on drupal.org and developers should be able tofind them in the tricks directory just as easy. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

3 3

[drupal-devel] drupal.org stats and different users
by Nedjo Rogers 29 May '05

29 May '05

Two thoughts on drupal.org stats: 1. I suspect our relatively disappointing stats are not unrelated to recent discussions on what content we present to whom. I'm thinking in particular of the definable group "potential new drupal users", which will include most firt-time drupal.org visitors as well as some repeat visitors. Say we have fifteen pages that answer the needs of this main group. Their needs - and therefore their content, ideally - should need to change very little--every few weeks, I'd say. As things stand, pretty well every page contains content that changes hourly (the "active forum topics" block)--and that is of little interest to potential new users. True, we could address this partly by caching page parts--but it would be much better not to show those parts to uninterested users in the first place. Also, it's apparently the case that few visits are from authenticated users. But if authenticating gave you a whole new view of the site, catered to your interests and needs, likely more of our registered users would take the step of authenticating. In short--doing a better job of presenting focused content to user groups should have performance benefits as well as other payoffs. Coding to make this possible would start with user group specific filtering of content views (blocks, home page, etc.). 2. Do we do any automatic revisiting/recaching of recently viewed/newly added/popular content after cache flushes? Might doing so help to preempt many dynamic page loads?

1 0

Re: [drupal-devel] [drupal-infrastructure] Drupal.org cache statistics
by Karoly Negyesi 29 May '05

29 May '05

> page, but that would render the whole approach useless. Back to the > drawing board. Once again: block caching is being worked on. Stay tuned.

2 1

[drupal-devel] [feature] Automatic access keys
by Steven 28 May '05

28 May '05

Issue status update for http://drupal.org/node/23628 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Steven Reported by: Steven Updated by: Steven Status: patch Attachment: http://drupal.org/files/issues/accesskey.patch (5.83 KB) Access keys for forms are an important aspect of usability and accessibility. Especially with form buttons, they allow you to select the right button immediately (e.g. ALT-P preview, ALT-S Submit). To add access keys to Drupal, there are several problems: Due to the modularity, it is hard to ensure all access keys within a form are consistent. This puts a burden on the module author (who may not care about access keys). Also due to this, it is hard to ensure access keys for identical commands can have the same access key across Drupal. Drupal is localizable, so access keys need to be able to adapt to languages. If I translate "Preview" to "Voorbeeld", it doesn't make sense to assign it the accesskey P. This patch addresses these problems elegantly, by assigning access keys dynamically. It ensures access keys are unique, so no effort is required from the module author. It also contains some reserved commands which always receive their access key first. This ensures these labels always have the same access key, no matter which form they are in (e.g. Preview, Submit, Delete, ...). Once P is mapped to Preview, "Publish" will have to use U (or B, or L, ...). Localization is also handled, because the code for finding access keys is completely UTF-8 aware and works on the translated labels. On a russian site, russian characters will be mapped. The assumption is that the user can type in the site's character set, which is fair. Here's how it maps out in practice: Preview -> P (priority, this will always be P on any page) Publish -> U (handed out on a first-come basis) Translated: Voorbeeld -> V (priority, this will always be V on any page) Publiceer -> P (handed out on a first-come basis) Usually, access keys are displayed as underlined characters in the label. I implemented this, but made it themable so you have full liberty in it. The access key is marked with <span class="accesskey"></span> in a themable function theme_label_key and the class is styled with an underline in drupal.css. Steven

9 18