- Development - lists.drupal.org

[drupal-devel] db_rewrite_sql handbook update
by Negyesi Karoly 21 Feb '05

21 Feb '05

If you have a module which queries the node table or implements a node type and holds the information in its own table with a nid field, then the following applies. The functions node_access_join_sql() and node_access_where_sql() should not be used any more but the SELECT-queries should be wrapped in a db_rewrite_sql() call. If you have used DISTINCT(nid) -- because of node_access_join_sql() -- you no longer need it, replace it simply with n.nid. If you have SELECT *, please replace it with SELECT n.nid, n.* -- this way the db_rewrite_sql() function can rewrite the query to use DISTINCT(nid) should there be a need for it. Always use table name before the field names, especially before nid because other tables may be JOINed during the rewrite process. Example: <?php // Drupal 4.5: $nodes = db_query_range('SELECT DISTINCT(n.nid) FROM {node} n '. node_access_join_sql() .' WHERE '. node_access_where_sql() .' AND n.promote = 1 AND n.status = 1 ORDER BY n.created DESC', 0, 15); // Drupal 4.6: $nodes = db_query_range(db_rewrite_sql('SELECT n.nid FROM {node} n WHERE n.promote = 1 AND n.status = 1 ORDER BY n.created DESC'), 0, 15); ?> If you are not using the node table, then you shall pass the table name from which you SELECTing the nodes. For example <?php $result = db_query(db_rewrite_sql("SELECT f.nid, f.* from {files} f WHERE filepath = '%s'", 'f'), $file); ?> note the 'f' parameter of db_rewrite_sql().

1 0

[drupal-devel] [task] usability: Group user related menu items more logically +fix help text links
by andremolnar 21 Feb '05

21 Feb '05

Project: Drupal Version: cvs Component: user system Category: tasks Priority: normal Assigned to: Anonymous Reported by: andremolnar Updated by: andremolnar Status: patch Attachment: http://drupal.org/files/issues/user_module_1.patch (10.64 KB) As per the discussion at: http://lists.drupal.org/archives/drupal-devel/2005-02/msg00302.html (settings inconsistencies) This patch implements the suggestions show in the screenshot (found in the link above). It also adjusts a few coding convention inconsistencies that I have noticed (e.g. unnecissary passing of form [edit] data between functions) Though more code could be cleaned in user module this was just a start to meet the primary goals of this patch. Finally the help text found in hook_help are now linked properly with their associated pages, and links within the text now take you to the proper pages. Dries: if you would like to test drive this on my demo site, contact me and I can set you up with an admin account. Other testers are welcome. andre andremolnar -- View: http://drupal.org/node/17025 Edit: http://drupal.org/project/comments/add/17025

2 2

[drupal-devel] [bug] Path module allows one to override existing (non-aliased) paths.
by adrian 21 Feb '05

21 Feb '05

Project: Drupal Version: cvs Component: path.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: adrian Updated by: adrian Status: patch Attachment: http://drupal.org/files/issues/path_menu_exists.diff (2.27 KB) One of our users recently tried to link to /admin , using the path module. And the link was allowed to be created. This meant his admin menu was disabled, which should not be able to happen. Attached is a function added to menu.inc that steps through all the menu items, and finds out if there is a callback registered for a specific path, unfortunately there still exists a few problems : Only explicitly registered callbacks are detected. For instance: 'node' will be picked up, but 'node/12' will be allowed. This is not as easy to test for, because of how pages default back to the top most callback, and pass the rest of the fields as paramaters. The only way to work around this is to explicitly define all callbacks that use parameters with a 'paramaters'=> true in the item. When an additional module gets enabled, any already specified links will take precedence over the new links created by it. adrian -- View: http://drupal.org/node/17386 Edit: http://drupal.org/project/comments/add/17386

8 10

[drupal-devel] Project management contribs: Bundles: grouped modules.
by Bèr Kessels 20 Feb '05

20 Feb '05

Hi, Starting with the thesis: "The way contributions are managed now is not suitable anymore. Esp. modules are growing out of hand, not only the amount of modules, but mostly the way modules conflic,t overlap and even completely duplicate one-another is a problem." We can only fix that with some effort and rearranging the way we handle contribs. I do not beleive we can solve this with code, or extra features on drupal.org. Allthough that might /help/, the real solution lies in management of this project. Note that I am /not/ (yet) addressing the part where users cannot find approporate modules for downloading: frankly I don't (yet) care about these users: they should just look better. Once we manage the contribs better, we can look into that. If it is still neccesary then. I see a couple of solutions, but I will only deal with one, here: bundles: definition: A bundle is a group of modules that have features in one area. A bundle is not a subcalssification of single modules, but a single entity. A bundle has only one project entry on drupal.org and it lives in one directory (+subdirs) in CVS. It is therefore downloadable as a complete tarball only. Modules in a bundle should be: * aware of oneanother. If A.module is anabled, B.module can hook into that, or use additional features, in addition to the features A.module already delivers. * reusing APIs. No duplication of code, re-use of optional .inc files. * never conflicting. enabling module A should never mean module B starts spitting errors. Module B should know that it must "shut off" certain parts, when module A is enabled. * Reusing databse tables. Currently most modules have private tables, tables that even often confilct with others. Weblinks, for example, should be stored in a single (set of) table(s), where all weblinks-realted modules (in the weblink bundle) will store and get their info. It makes no sense if relatedlinks.module stores weblinks in tableA, weblinks.module in tableB, blogmarks in tableC, flexinodes url.inc in tableD etcetc. The e-commerce modules are a good example of this. For 4.6 we hope to have weblinks into a bundle too, this would Project management-wise a bundle would imply collaboration of a few developers. These developers must communicate amoungs eachother, they should use a separate directory in the sandbox CVS area as well as devide issues and features amoungst eachother. Pro: modules within same range of features can be managed in a central place. Pro: modules within same range of features can be found in one central place PRo: modules within same range of features will work together. Together they make a single and *complete* set of functions. separate managed modules (what we have now) often have a lot of simil;ar features. Take for example amazon_serach.module and amazon_items.module both offer some way to add amazon ads to your site, both allow some amazon content to be published on your site, but features differ slightly. Also, they use some moduified 3rd party .incs, which are not shared, buyboth modules. Ideally we would split them up and have: * one module that handles all ad-serving from amazon. * one module that handles content serving. so thogether they make a complete system, instead of having to conflicting modules. Con: Contributions of custommade modules is impossible/hard. If a module was developed for yoursite.com only, it will most likely not fit within one of the bundles. Question of course is, if we should host these modules at all. Con: Second-level discussions need to take place. So some small mailinglists, or even simply a list of CC-ed mailadresses are needed for each bundle. I beleive this is no real problem as yet, in future some module on Drupal.org could take care of this. Con: It is hard to manage. esp because of the open nature of the contribs. WE cannot dissallow people to contribute their custommade.module ATM, and we will not be able to implement such a thing soon. Thus the bundle systems would require common sense and good agreemenents between contributors. Con: a user will have to download a complete bundle (lets assumne weblink bundle) even if she only wants to have relatedlinks.module (which is part of the weblink bundle). So, please tell me what you think of this idea, and if it is worth discussion on drupalCON, or even on the lists only. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

15 36

[drupal-devel] [Fwd: Feedback from two usability sessions on CivicSpace 0.8.0.3]
by Dries Buytaert 20 Feb '05

20 Feb '05

Good read, valuable feedback. -------- Original Message -------- Subject: Feedback from two usability sessions on CivicSpace 0.8.0.3 Date: Fri, 18 Feb 2005 07:40:30 -0800 From: Kieran Lal <kieran(a)civicspacelabs.org> To: civicspace-community(a)civicspacelabs.org Hello, I managed to squeeze in two usability sessions yesterday to test the 0.8.0.3 release. I'll try to be brief, and when I get connected I'll file usability issues at CivicSpaceLabs.orb/project. First test: Scenario: Community organizer wants blogs, policies(Book), and contact information online. Their site has been professionally customized to do only those three things using 0.8.0.x Democratica theme Feedback: -After user logged on they didn't know what to do because there were no action words inviting them to do something. i.e. blogs instead of create a blog. -User did not know how to create content because the user doesn't think of the site as a content management site. They think of it as a site that has blogs, contact info,etc. Therefore, Create Content does not provide the cues to open the menu. -Messages on the create content page are too small to be read. "Might as well be in Swahili" -User is overwhelmed by the three boxes of options and twelve options altogether. The user does not know what a path alias is. The user has to scroll down the screen because content dropping of the options boxes pushes the preview button off the screen. Previewing is an unnecessary step. Second Test: Video capture installation of CivicSpace 0.8.0.3 and configuration of contacts, users, and an attempt to send an invitation email. Users were started at a firefox window with install.php screen in front of them. -Users found messages on first page overwhelmingly confusing. They just clicked ok and moved to the next screen. -Users had two errors. Both were write permissions to conf.php, and files directory. They were successful in getting to help pages. User had no command line experience. Did not know how to get into the includes directory on a unix host. i.e. (cd includes). User's proceeded to type what was in bold at the command line: localhost% chmod blah blah. I had to step in and tell them not to type localhost%. -Next they had to set permissions on the files directory. They thought they had to be in the files directory to set the permissions. But first they didn't know how to get out of the includes directory at the command line. -I didn't give them the database name and password, so I had to come in and give the wrong user name, database name, and wrong prefix. Eventually, firefox suggested the right answers from the last install I did using that browser. I'll have to clear the firefox browser cache for the next test. -Once the site was configured and running they added several users. They wanted to know where to add people so they could send them an invitation email. They tried to add email addresses. I ended up explaining that contacts is where they could add email addresses. I explained that contacts was like the address book in hotmail, and users was like the people who have email accounts at hotmail. -Once users were added, they went to contacts to try and send invitations. They were surprised that users information they just entered was not in contacts. -Next they tried to send out invitation emails. It was very clear that there were no cues as to where to configure mail. The entire interface is clearly functional in nature and not at all self-explanatory, or able to provide any useful cues. I directed them to mass mailer which left them with a large number of options. There was confusion about where to go to configure it. I directed them to admin and settings and there were so many options it was confusing. I directed them to set mail to work off a cron job to try and activate it by going to cron.php. Cron.php gave a completely blank page. At this point, the entire experience had plummeted into chaos. -Two notable additional experiences were watching two very well educated intelligent people stare and mouse hover at the "Queue message" button for a what felt like an eternity. Also, in an effort to customize the invite message, the users change the user% and added their name hoping that this would send the message. Whew! Deep breaths, deep breaths, breath directly into the paper bag. 3 days of usability training are just what the doctor ordered. Kieran --------------------------------------------------------------------- To unsubscribe, e-mail: civicspace-community-unsubscribe(a)civicspacelabs.org For additional commands, e-mail: civicspace-community-help(a)civicspacelabs.org -- Dries Buytaert :: http://www.buytaert.net/

4 3

[drupal-devel] Storing arbitrary data for a user
by Dan Robinson 20 Feb '05

20 Feb '05

I have a small amount of persistant data I would like to associate with a user and would like to avoid creating a new table to store it in. I have come across variable_get and variable_set - which is great - but probably not appropriate for what I'm doing. I've also seen user->categories, but can't find any doco or info on what this is. Thanks, Dan

4 7

[drupal-devel] Ecommerce module problems with current CVS
by Ross Kendall 20 Feb '05

20 Feb '05

Just a warning really. Ecommerce module(s) seem broken on current CVS (HEAD). I was upgrading a development install (earlier CVS) to current CVS, and spent a while trying to sort out my 'upgrade' problems, until I tried a clean install only to find the same problems. Errors look like this: *when viewing a product user error: 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 'AND n.nid = 3 AND n.type != 'product'' at line 1 query: SELECT COUNT(n.nid) FROM node n WHERE AND n.nid = 3 AND n.type != 'product' in /home/rosskend/public_html/drupal-test/includes/database.mysql.inc on line 66. * when creating a 'product' Fatal error: Call to undefined function: check_query() in /home/rosskend/public_html/drupal-test/modules/ecommerce/product/product.module on line 590 If/when I work out what the issue is I will file a bug.

3 2

[drupal-devel] [bug] Internationalization: Create user-defined string variable whenever possible
by Steven 20 Feb '05

20 Feb '05

Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: Carl McDade Updated by: Steven Status: patch Can someone point out to me how this is related to i18n, at all? Steven Previous comments: ------------------------------------------------------------------------ February 19, 2005 - 18:50 : Carl McDade Attachment: http://drupal.org/files/issues/common_11.patch (503 bytes) There should be an effort to externalize all english text into default variables. It makes a great step towards true internatiolization. Does not cost anything in terms of performance or matainance. What it does do is make the code that uses hard coded strings open and more resuable. It adds the flexibility in phrasology that is necessary in internationalizing Drupal. It creates more usability in that better text instructions can be delivered to the user based on the situation of the process. I have made this slight change in my install which allows me to give a descriptive message based on the url tried. This can be done in both english and swedish without me having to use gettext and the like. <?php --- common_1.inc 2005-02-19 17:33:21.451910400 +0100 +++ common_2.inc 2005-02-19 17:34:40.876116800 +0100 @@ -427,8 +427,8 @@ function object2array($object) { * Always consider whether to use drupal_access_denied() instead to return a * proper (and customizable) 403 error. */ -function message_access() { - return t('You are not authorized to access this page.'); +function message_access($message = 'You are not authorized to access this page.') { + return t($message); } *Warning*: Unterminated comment starting line 13 in */home/www/drupal.org/modules/codefilter/codefilter.module* on line *28* ------------------------------------------------------------------------ February 19, 2005 - 20:47 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/message-access.patch (2.99 KB) The original description is a bit unclear, but the underlying concern seems to be that the error messages are not specific to the situation they occur in. I share this concern. The attached patch removes the function message_access() (which hails from 2001) and replaces the six calls to it by hopefully better chosen strings. Since I do not use blogapi.module I welcome suggestions for better phrases. Since this is actually a usability bug fix i hope this can get into 4.6. ------------------------------------------------------------------------ February 20, 2005 - 00:35 : chx Attachment: http://drupal.org/files/issues/message-access_0.patch (3.2 KB) While we are at it, we could open up drupal_access_denied so that the title can be changed per call. It costs almost nothing, breaks nothing, so why not? -- View: http://drupal.org/node/17592 Edit: http://drupal.org/project/comments/add/17592

2 1

[drupal-devel] Web Spam Summit - can anyone make it to this?
by Boris Mann 20 Feb '05

20 Feb '05

Hi: I direct your attention to this: http://jeremy.zawodny.com/blog/archives/004256.html It's right in the middle of DrupalCon, but it would be fantastic if someone from the community could attend. Chris Messina? Zack? Anyone? -- Boris Mann http://www.bryght.com

7 16

[drupal-devel] [bug] Internationalization: Create user-defined string variable whenever possible
by chx 20 Feb '05

20 Feb '05

Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: Carl McDade Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/message-access_0.patch (3.2 KB) While we are at it, we could open up drupal_access_denied so that the title can be changed per call. It costs almost nothing, breaks nothing, so why not? chx Previous comments: ------------------------------------------------------------------------ February 19, 2005 - 18:50 : Carl McDade Attachment: http://drupal.org/files/issues/common_11.patch (503 bytes) There should be an effort to externalize all english text into default variables. It makes a great step towards true internatiolization. Does not cost anything in terms of performance or matainance. What it does do is make the code that uses hard coded strings open and more resuable. It adds the flexibility in phrasology that is necessary in internationalizing Drupal. It creates more usability in that better text instructions can be delivered to the user based on the situation of the process. I have made this slight change in my install which allows me to give a descriptive message based on the url tried. This can be done in both english and swedish without me having to use gettext and the like. <?php --- common_1.inc 2005-02-19 17:33:21.451910400 +0100 +++ common_2.inc 2005-02-19 17:34:40.876116800 +0100 @@ -427,8 +427,8 @@ function object2array($object) { * Always consider whether to use drupal_access_denied() instead to return a * proper (and customizable) 403 error. */ -function message_access() { - return t('You are not authorized to access this page.'); +function message_access($message = 'You are not authorized to access this page.') { + return t($message); } *Warning*: Unterminated comment starting line 13 in */home/www/drupal.org/modules/codefilter/codefilter.module* on line *28* ------------------------------------------------------------------------ February 19, 2005 - 20:47 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/message-access.patch (2.99 KB) The original description is a bit unclear, but the underlying concern seems to be that the error messages are not specific to the situation they occur in. I share this concern. The attached patch removes the function message_access() (which hails from 2001) and replaces the six calls to it by hopefully better chosen strings. Since I do not use blogapi.module I welcome suggestions for better phrases. Since this is actually a usability bug fix i hope this can get into 4.6. -- View: http://drupal.org/node/17592 Edit: http://drupal.org/project/comments/add/17592

1 0