- Development - lists.drupal.org

[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

[drupal-devel] How to take up development of a module
by NSK 28 May '05

28 May '05

Hi I would like to take up development of the Amazon Items module. The owner doesn't seem to respond: http://drupal.org/node/23397 What do I need to do? I would like my version to appear in drupal.org. Should I rename my version? -- NSK http://portal.wikinerds.org

2 2

[drupal-devel] Drupal 4.6.1 release sechedule
by Dries Buytaert 28 May '05

28 May '05

Hello world, I'd like to release the first Drupal 4.6 maintenance release, Drupal 4.6.1, early next week. Please help us test the DRUPAL-4-6 branch to ensure that this release is stable, and that the upgrade path works. Thanks. -- Dries Buytaert :: http://www.buytaert.net/

1 0

[drupal-devel] upload should support open formats by default
by Bèr Kessels 28 May '05

28 May '05

Call me a purist, or whatever you want, but i do not like the fact that an OS product -Drupal- by default allows uploads of all sorts of MS office files, but not those from OO.o or koffice, etc. So would you people mind if i change the array of default allowed foile extensions into something else? Please give me your favorite extensions too. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

2 1

[drupal-devel] [bug] New pager code broken taxonomy pagers
by Dries 27 May '05

27 May '05

Issue status update for http://drupal.org/node/23687 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Dries Status: patch Morbus: the funky comment thread stuff rocks. We should do the same for book pages and taxonomy terms if it can be done effectively. This doens't mean we should remove the traditional pid-columns. Dries Previous comments: ------------------------------------------------------------------------ May 26, 2005 - 21:44 : Morbus Iff I've not yet looked into it, but I doubt I'll be able to fix it (the original taxonomy/term pager code was a hack that moshe taught me about). In a nutshell, though, the recent pager cleanup in head has broken the term pagers for vocabularies. ------------------------------------------------------------------------ May 26, 2005 - 22:21 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_23687_taxopager.patch (1.88 KB) Patch attached. ------------------------------------------------------------------------ May 27, 2005 - 09:05 : Steven Why can't this code use pager_query() and query the database directly? If free tagging vocabularies can get so big, it seems a very inefficient thing to fetch the entire list. ------------------------------------------------------------------------ May 27, 2005 - 09:05 : Steven Note: if you need to fetch a list of tags ordered by hierarchy in one query, you should look at how comment.module does it. ------------------------------------------------------------------------ May 27, 2005 - 13:17 : Morbus Iff Which part of comment.module? I hope you don't think the crazy "thread 1.1.2/, 1.2" stuff is /better/. ------------------------------------------------------------------------ May 27, 2005 - 15:19 : Steven Maybe it's crazy, but it has a single, pagable query and an unambigous sorting both ways. It works well for what it needs to do. In fact, the only problem is the assignment of numbers because we cannot do a "natural order" sort in SQL. Right now it uses a rather inefficient coding that scales O(n) with size and adds another digit every 10 values. This prompted me to experiment with better codings. First I generalized the current scheme a bit, then tweaked it to get near O(log n) scaling and on average only 20-30% more digits than an equivalent decimal notation, while still retaining the string sorting property. Quite fun actually. I don't see the problem with the approach though... all it does is store a compact ordering key per row. Compare this to the convoluted tree logic in taxonomy_get_tree() and I know which one I prefer. Of course, I'm not at all sure if the comment.module approach can be implemented here, but I can't believe you'd do something like this after talking about mega-taxonomies for so long. Loading in 8000 tags just to show 50 is nowhere near optimal. ------------------------------------------------------------------------ May 27, 2005 - 15:28 : Morbus Iff Fair enough. I don't have the time right now to code this though - my deadline for the full NHPR conversion is fast approaching, and the patch attached merely brings us back to the "working" behavior prior to the pager changes, not "better" behavior, which you're proposing. However, I'm a little .. .. .. cautious about the idea of using a comment.thread-like equivalent (something I immediately knee-jerked disliked the first time I saw it) for a regular parent/child relationship just to get a hierarchal sort based on a LIMIT. This can't be how other database apps are doing it, is it?

1 0