September 2005 - Development - lists.drupal.org

[drupal-devel] really really really really off-topic
by Adrian Rossouw 26 Sep '05

26 Sep '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 <itior> XML is like violence, if it doesn't solve the problem, just use more. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDN/FZgegMqdGlkasRAsbfAJ4wEEZ3hUfNJtXc7d+fVRXA+dZU+QCeNSiZ X6KH2X1v+2vPQbeff8KAi7U= =kXeZ -----END PGP SIGNATURE-----

1 0

Re: [drupal-devel] A collection of usability problems
by Kobus Myburgh 26 Sep '05

26 Sep '05

Ermmm... I meant /node/edit/* instead of /node/*/edit Kobus >>> ITBJDM(a)puknet.puk.ac.za 9/26/2005 12:58 PM >>> > I think it does help. Extending the regexp to also cover node/*/edit and > user/*/edit can't be that hard. Excuse the off topic post here, but I read this here and was wondering about that many times before. Why can't we do it /node/edit/4/* instead of /node/*/edit? Would make a lot of little nagging problems I have to code around all the time go away... :-) Regards, Kobus

1 0

[drupal-devel] Passing on Spread Firefox, Lincoln's Revenge, Democratica themes
by Chris Messina 26 Sep '05

26 Sep '05

Hey all, I'm looking for a new maintainer for Spread Firefox, Lincoln's Revenge, Democratica who can take those original styles and port them to the CivicSpace XHTML foundation (http://drupal.org/project/civicspace_theme) If you want details on this task, let me know. It's just become quite obvious that I don't have the time to maintain these themes and it's time for someone else to move them forward! Chris

1 0

Re: [drupal-devel] two minor usability issues, introduced recently
by Kobus Myburgh 25 Sep '05

25 Sep '05

> We don't have usability tests -- how do you envision this to be done? One hindrance in getting usability testing done is because the usability people are not necessarily technical people. When a new feature comes in as a patch, the usability expert has to patch his copy of Drupal, then get around to test it for usability. This is however not easily done, as I, for example, am a technical dufus with a little bit of coding skills. I am however majoring in usability, so, I can provide some usability testing but where and how? I have a possible solution for this issue. Before reading the proposed solution, keep in mind that it is only to stimulate thought, as I am not sure how technically feasible it is: 1. Set up a site based on HEAD. 2. Assign a technical person to update and maintain it. 3. When an update is applied (patch or other), simply add/update the a "changelog" or "issue" or something. 4. When a usability person analyzes the change, he documents it accordingly on the same issue. 5. Developers read the usability person's report and change the code if necessary. 6. Usability testers get access to test all new aspects of the page/page/feature/whatever. 7. Of course the database might need to be refreshed now and then. Regards, Kobus

3 2

RE: [drupal-devel] Admin theme
by Steven Peck 25 Sep '05

25 Sep '05

>From a usability stand point I can't stand a separate admin area. I tried really hard to like it and had four people whose sites I run try it. They all said that being pulled out of their site was a jolt. With the migration of more of the 'set once a forget it' settings to the admin settings link, stuff iis even easier to find then ever. With roles determining what can be seen, those with limited roles see what they can see within the context of the sites theme without the jolt of going to what seems to be a completely different site. -sp > -----Original Message----- > From: drupal-devel-bounces(a)drupal.org > [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Robert Douglass > Sent: Sunday, September 25, 2005 4:42 AM > To: drupal-devel(a)drupal.org > Subject: Re: [drupal-devel] Admin theme > > I think the CivicSpace admin theme is the model we ought to > be striving for. I love it. > > Bèr Kessels wrote: > > for me the admin theme has a few requirements: > > * it must be able to disable when someone feels he/she is > not helped with it. > > * it must be profilable (a forum site has a different > concept of what > > pages are admin then a personal blog) > > > > > * tackle this in a blocks/sections alike interface, where sets of > > regexps define what pages are admin and what pages not. > > A set of regexps is the way I'd like to see it implemented. > The two points above would be satisfied by having regexps. > > > * it must be overridable in a theme > > Wouldn't one just change the admin theme? What do you mean by > this last point, Bèr? > > -Robert > >

1 0

[drupal-devel] Help system redesign
by Larry Garfield 25 Sep '05

25 Sep '05

Last night there was a discussion in #drupal regarding the help system, and the need for an overhaul therein. Dries asked me to send a note to this list with what was discussed and the thoughts on where to go with it. This is a developer, documenter, and translator issue, so input from all three parties is welcome. Problems with the current help system, vis, hook_help() ----------------------------------------------------------------------- - Huge blocks o' text in the source code file. - Because the strings are large, translation of help files via PO is slooooow. - Synchronization with the online handbook is tedious and difficult, which means it sometimes doesn't get done. Proposed solution ----------------------- Replace hook_help() with a database-based help lookup system that incorporates translations directly in the database. The database table would look something like this: help ( hid, module, key, locale, helptext ); The key would be a short textual string that identifies the help text in question, serving the same function as $section in hook_help(). (Possibly with the same naming scheme, possibly not.) Then, hook_help() would be replaced with a function help_get(): /* Example function, missing lots of necessary error checks */ function help_get($module, $key, $locale='en') { $help = db_fetch_object(db_query("SELECT helptext FROM {help} WHERE module='%s' AND key='%s' AND locale='%s'", $module, $key, $locale)); return $help->helptext; } What gets returned, then, is an already-localized string, ready for printing/theming/whatevering. The help lookup is always a single database hit, no slow textual substr() matching needed. That also means that PO files are much smaller, and module source code doesn't have to have giant masses of text in it. Issues and solutions -------------------------- Links: I'd say the solution here is to have links flagged in the database for easy conversion by help_get() before they're returned. For example: ... Go to the <link url="admin/modules">modules page</link> to enable... help_get() would then, before returning the string, check for <link> tags, extract the data, and replace it with the output from an l() call. I'm not sure of the efficiency of the syntax above, but something along those lines should be easiest. (Good place for a regex?) Data loading: Of course, there needs to be some way to get helptext into the database in the first place. That would require an auxiliary file along with the .module file, say .help. See below for comments on the format of .help. When the module is enabled on admin/modules, the .help file is parsed into the help table once. When the module is disabled, the help table is cleared of any records for that module to avoid cruft. While this does make enabling and disabling a module a bit slower, that's not done often enough that it should make any practical difference. We would need to then make sure that the module's name and short description are available in the module itself, as those are needed on the admin/modules page. The simplest solution would be to have a hook_module_info() function, which returns an array of the form: array('name' => 'node', 'description' => 'Allows content to be submitted to the site and displayed on pages.'); Those text strings are small enough that they can be handled by the current translation system. admin/modules would then include every .module file (as now) and then call the _module_info() hooks to get the data to display. Data format, data entry, handbook sync -------------------------------------------------- These all dovetail together, so I'm going to discuss them all at once. - The Docs team wants to be able to write help text for core and contrib modules without futzing about with MySQL dumps or some other obscure format. A web-frontend is preferred. - Developers need to be able to enter their own help text without going through the drupal.org docs team. That's especially important for custom modules that need help text but don't end up on Drupal.org for whatever reason. (Custom for a client, commercial modules, etc.) - The Translation people don't want to have to deal with obscure file formats either. - Keeping the text in the online handbook in sync with the in-system text in the actual module should be sufficiently trivial that no one thinks to not do so. That's a tall order, and a problem that hasn't been solved yet. :-) My recommendation for the intermediary help files would be an XML format, one reasonably easy to import/export from the online handbook and reasonably easy to hand-edit. The Docs and Translations teams could then edit the text in the online handbook and export it to the necessary XML files, as can the translation team, while developers can write the XML file directly via their XML editing method of choice. The file needn't be complicated. For instance: <drupal:help module='node' locale='en'> <drupal:entry key="description">Some <b>HTML</b> here.</drupal:entry> <drupal:entry key="stuff">Some other text.</drupal:entry> </drupal:help> When the module is enabled, the XML file is parsed into the help table, as mentioned. It's a one-time event, so performance is a non-issue. There would be a separate file for each locale. So the node module, for instance, would have: node.module node.mysql node.help node.es.help node.de.help ... As now, English would be the default language. Besides being easier to edit, using XML files instead of an SQL dump keeps the help text database-independent. Otherwise, we'd need separate mysql and pgsql files for each locale. Other thoughts ------------------- I have not worked with the current help system that extensively, so I'm not sure how it handles context-sensitive help. By that I mean "What's this?" type help, or other "what do I do on this page" help text. One advantage to this method is that keys reserved for the main help system could be pre-defined, while a module author would be free to add additional help keys for his module. So on the foobar/4/edit page, the module author could write: $output .= theme('help_link', 'foobar', 'edit'); Which would return a formatted link to context-appropriate help, such as: <div class="help-link"><a href="help/foobar/edit">Help on this page</a></div> help/foobar/edit then would trigger the callback for 'help', which would dutifully display the theme('help') for module 'foobar', key 'edit'. Both of those could then be re-themed to allow pop-up help windows, javascript overLib (http://www.bosrup.com/web/overlib/) calls, or whatever else a theme-author felt like doing. Some more thought here is definitely needed, but I'd love to see more non-admin-user context sensitive help in Drupal. Conclusion -------------- I'm sure at least some of the above is insanely stupid, so please point out where gently. :-) Dries said he suspects this would be a 4.8-targeted improvement, which I think is likely given the amount of legacy code and how close we are to 4.7's release. Devs, Docs, and Trans, your input please! My thanks to Dries, Amazon, webcheck, killes, and everyone else who was in the channel last night for this discussion. *dons flame retardant suit* -- Larry Garfield AIM: LOLG42 larry(a)garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

10 19

[drupal-devel] Move pagers out of table
by Dries Buytaert 24 Sep '05

24 Sep '05

Hello world, I just committed a Neil Drumm production: "move pagers out of table". See http://drupal.org/node/28786. Moving the pagers out of the tables isn't strictly necessary but it makes for better XHTML and less code (for core: 31 insertions and 66 deletions). If you maintain a module in the contributions repository, you might want to update it for sake of consistency. A typical change looks like this: - if ($pager = theme('pager', NULL, 50, 0)) { - $rows[] = array(array('data' => $pager, 'colspan' => '7')); - } $output .= theme('table', $header, $rows); + $output .= theme('pager', NULL, 50, 0); The following modules could be updated for consistency with core: actions/actions.module akvaforum/akvaforum.module album/album.module asterisk/asterisk.module automail/am.module badbehavior/badbehavior.module banner/banner.module bookmarks/bookmarks.module bookreview/bookreview.module browscap/browscap.module checkout/checkout.module contact_dir/contact_dir.module dba/dba.module distantparent/distantparent.module eatlocal/foodmiles/foodmiles.module eatlocal/resource/resource.module ecommerce/contrib/submanage/submanage.module ecommerce/product/product.module ecommerce/store/store.module epublish/epublish.module evaluation/evaluation.module go/go.module groups/groups.module jobsearch/patches/node.module-4.6.2 jobsearch/patches/node.module-4.6.3 jobsearch/patches/tracker.module-4.6.2 links/links.module logsearch/logsearch.module mail_archive/mail_archive.module moviereview/moviereview.module netnews/netnews.module nmoderation/nmoderation.module og/og.module paypal_framework/paypal_framework.module paypal_subscription/paypal_subscription.module privatemsg/privatemsg.module project/issue.inc queue/queue.module scheduler/scheduler.module scouting/person.inc simplenews/simplenews.module spam/optional/comment.module.patch spam/spam.module survey/survey.module task/task.module taxonomy_assoc/taxonomy_assoc.module term_statistics/term_statistics.module trackback/trackback.module translation/translation.module troll/troll.module userpoints/userpoints.module volunteer/volunteer.module wireframe/wireframe.module workspace/workspace.module Thanks, -- Dries Buytaert :: http://www.buytaert.net/

1 0

Re: [drupal-devel] A collection of usability problems
by Kobus Myburgh 23 Sep '05

23 Sep '05

Ok, as promised: I have installed front_page module on one of my sites, generated some silly HTML to use as front page text, and set the settings for the module. These are my findings: (Please note - this is not a review of front_page.module, but rather a comparison of it with static nodes). 1. Frontpage module offers you several options for displaying: - For anonymous users: * themed - uses your current site's theme to dsplay your text/code * full - bypasses your sites theme, uses only your specified text/code * redirect - redirects you to another page/node/image/etc. - For logged in users: * same as for anonymous users * option to have it the same as for anonymous users 2. Static pages can offer you a lot of the above, but, it has a LOT more administration to do. For example, to implement these features with static pages, you'd have to: 1. Check whether the person is logged in. 2. Set all the blocks not to display on that particular page. 3. Must know some PHP to do #1 and to do redirects - can't use logic in HTML. 4. No way to disable the logo section of the theme for the page (e.g. I might just want an enlarged version of my logo with a few bullets of text on the main page - no other themable objects), without using another module (I think Gerhard had such a module where you can have a different logo for the front page). Basically, all in all, front_page module makes things MUCH simpler, and offers more choice than static pages. Static pages for front pages is too involved for newbies (and lazy admins...) and front_page module provides a great (and completely functional) alternative. HTH Kobus >>> ITBJDM(a)puknet.puk.ac.za 9/23/2005 10:39:23 AM >>> > Problem #6: quite some people use the front page module. I've never > used the front page module but I'd like to know how it is different > from a static page? The key difference I see is that you ca have a > different front page for anonymous users. If that is the only key > difference, why aren't people using static pages? Something is wrong > here, and I'd like to figure out what. I'll take care of this one - giving a complete overview of the front page module. I will highlight the differences between a static page and the front page module and then the developers can determine what to do with regards to this analysis. Regards, Kobus PS: Can we have a list drupal-usability? Or is that overkill?

2 1

[drupal-devel] Fwd: OpenUsability Project Approved
by Bèr Kessels 23 Sep '05

23 Sep '05

Hello, I hope we can form a usability team soon, nothing official, just a bunch of people evaluating and coding drupal, to improve usability, as opposed to adding features, optimisation, cutting edge technology etc. My first action was to register at openusability.org, to see if we can attract some more interested people and to to find out how well that sites tools may aid us. Ber ---------- Doorgestuurd bericht ---------- Subject: OpenUsability Project Approved Date: maandag 19 september 2005 18:15 From: noreply(a)openusability.org To: ber(a)webschuur.com Your project registration for OpenUsability has been approved. Project Full Name: Drupal Please keep in mind that this site is still under construction. If you find a bug, miss some functionality or would like to discuss usability issues, please use the forums at http://www.openusability.org/forum/?group_id=6 . If you visit your own project page in OpenUsability while logged in, you will find additional menu functions on a tab labeled 'Admin'. We highly suggest that you now visit OpenUsability and create a public description for your project. This can be done by visiting your project page while logged in, and selecting the 'Admin' tab (or by visiting http://www.openusability.org/project/admin/?group_id=139 after login). Your project will also not appear in the Project Tree (Trove Software Map, primary list of projects hosted on OpenUsability which offers great flexibility in browsing and search) until you categorize it in the project administration screens after login: http://www.openusability.org/project/admin/group_trove.php?group_id=139 By default, a newly registered project is looking for a usability expert to support it. If you want to refine your project's open jobs, you can add and edit them in the 'Admin' tab after login: http://www.openusability.org/people/createjob.php?group_id=139 http://www.openusability.org/people/?group_id=139 So that people can find your project, you should create a public description now and categorize your project in the Trove Map. Enjoy the system, and please tell others about OpenUsability. Let us know if there is anything we can do to help you. -- the OpenUsability crew ------------------------------------------------------- Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

3 8

[drupal-devel] Too early to report problems with flexinode?
by Steve Dondley 23 Sep '05

23 Sep '05

I tried using the CVS version of flexinode with the CVS version of Drupal. It's got some obvious problems. Should I bother reporting those or wait until the code freeze? -- Dondley Communications http://www.dondleycommunications.com Communicate or Die: American Labor Unions and the Internet http://www.communicateordie.com

2 1