- Development - lists.drupal.org

[drupal-devel] DRUPAL-4-6 branch created, HEAD opened up
by Dries Buytaert 08 Apr '05

08 Apr '05

Hello world, I created the DRUPAL-4-6 branch, meaning that CVS HEAD is opened up for development! Furthermore, I modified the package script to package the DRUPAL-4-6 branch as Drupal 4.6.0 RC. The Drupal 4.6.0 RC now lives at http://www.drupal.org/files/projects/drupal-4.6.0-rc.tar.gz. I'll follow up with a short status report on drupal.org. Let's rock and roll, -- Dries Buytaert :: http://www.buytaert.net/

2 1

[drupal-devel] [bug] Run view nodeapi action on *teaser* in feed generation (quickfix)
by Goba 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/20188 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: Goba Reported by: Goba Updated by: Goba Status: patch Attachment: http://drupal.org/files/issues/Drupal-fix-feed-nodeapi-view.patch (718 bytes) Node_feed() instructs the nodeapi view call it invokes to deal with the body of the node, but afterwards it only uses the teaser to generate the feed. So the nodeapi hook should be called with teaser processing in mind. This simple patch fixes that. Patch is against DRUPAL-4-6 (but it is not possible to categorize this bug as such), and it probably also applies to HEAD. Goba

1 0

[drupal-devel] [bug] User info should not be visible without permission
by killes 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/4166 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: mic Updated by: killes(a)www.drop.org Status: patch Attachment: http://drupal.org/files/issues/user_access_bug_2.patch (11.26 KB) Further testing revealed a bug in the older parts of the patch... killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ November 17, 2003 - 06:23 : mic When anonymous visitors do not have "Access userlist" permission, they can still view all the public info in user profiles. Drupal sites that are created for a group of friends or for an organization want to protect their e-mail addresses, telephone numbers and so on, while making these accessible to fellow members. This could be a critical feature request, but since I think it's an error, I'm sending you this as bug. (I don't have CVS, so I'm hoping someone else will make the simple correction needed to the user module) ------------------------------------------------------------------------ February 3, 2004 - 05:41 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission.patch (1.54 KB) I made a patch that fixed this by adding a new permission, "access users". This is everything this patch does: Add new permission, "access users" If a user does not have the "access users" permission, s/he cannot read another user's profile at all, and instead gets an "access denied" page. I hope I did this in the proper way. ------------------------------------------------------------------------ April 21, 2004 - 20:25 : Dries I think we should not introduce a new permission but merge with the existing 'access user list' permission (or rename it to 'access users'). Marking this "won't fix" until the patch has been udpated. ------------------------------------------------------------------------ May 28, 2004 - 02:26 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission_0.patch (1.88 KB) Another patch, this time renaming the permission "access user list" to "access users", and adding a check in the user viewing function to only allow users with this permission to view the user information. ------------------------------------------------------------------------ July 5, 2004 - 15:31 : Anonymous Attachment: http://drupal.org/files/issues/user-module-add-view-permission_1.patch (1.86 KB) Here is a patch again, now for CVS. Does the same thing as above. It is a very simple patch. If it seems proper, I hope that can be included before it goes stale. ------------------------------------------------------------------------ July 9, 2004 - 02:08 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission_2.patch (1.33 KB) The previous patch was accepted, but then for some reason reversed as part of another CVS commit. So, here is a new patch that brings back the "access users" permission. It controls whether or not a user may view other users info. ------------------------------------------------------------------------ September 22, 2004 - 16:53 : Bèr Kessels Attachment: http://drupal.org/files/issues/access_users_perm.patch (6.46 KB) A new and revised patch. It adds an "access users" permission ------------------------------------------------------------------------ September 22, 2004 - 18:02 : killes(a)www.drop.org I'd like to see this patch applied to cvs before the 4.5 release. Now that we can protect our nodes from unauthorized access it just makes sense to protect our user data as well. In the future I'd like to see scheme where the user (as in end-user) is able to selet which of his data gets published. ------------------------------------------------------------------------ September 23, 2004 - 01:52 : rkendall I would like this too ------------------------------------------------------------------------ October 14, 2004 - 23:46 : drumm Can the name be changed to 'view user profiles'? ------------------------------------------------------------------------ October 18, 2004 - 09:19 : Bèr Kessels It can, but I used "access" for consistancy. we have "access newsfeeds", "access comments", "access etc". This patch is critical for corporate sites btw. A corporate site that has its customers information lying on the streets (so to say) is not-done. Ber ------------------------------------------------------------------------ November 27, 2004 - 13:49 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-access.patch (5.96 KB) Updated for CVS. I assumed that "admin users" implies "access users" in user_admin. ------------------------------------------------------------------------ March 1, 2005 - 17:30 : killes(a)www.drop.org Does not apply anymore, Ber can you have a look at it? ------------------------------------------------------------------------ March 7, 2005 - 09:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/user_access_0.patch (9.74 KB) New patch. Should apply to HEAD. ------------------------------------------------------------------------ April 7, 2005 - 21:29 : killes(a)www.drop.org It's a patch (which still applies and wants into core). ------------------------------------------------------------------------ April 8, 2005 - 18:10 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user_access_bug_1.patch (11.45 KB) Ok, updated patch. Includes changes to format_name to only display unlinked username for non-privileddged users. 'acccess users' is now 'access user profiles'. The search users tab won't get displayed either if you are not allowed to seee user profiles. The patch got even tested.

1 0

[drupal-devel] [bug] User info should not be visible without permission
by killes 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/4166 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: mic Updated by: killes(a)www.drop.org Status: patch Attachment: http://drupal.org/files/issues/user_access_bug_1.patch (11.45 KB) Ok, updated patch. Includes changes to format_name to only display unlinked username for non-privileddged users. 'acccess users' is now 'access user profiles'. The search users tab won't get displayed either if you are not allowed to seee user profiles. The patch got even tested. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ November 17, 2003 - 06:23 : mic When anonymous visitors do not have "Access userlist" permission, they can still view all the public info in user profiles. Drupal sites that are created for a group of friends or for an organization want to protect their e-mail addresses, telephone numbers and so on, while making these accessible to fellow members. This could be a critical feature request, but since I think it's an error, I'm sending you this as bug. (I don't have CVS, so I'm hoping someone else will make the simple correction needed to the user module) ------------------------------------------------------------------------ February 3, 2004 - 05:41 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission.patch (1.54 KB) I made a patch that fixed this by adding a new permission, "access users". This is everything this patch does: Add new permission, "access users" If a user does not have the "access users" permission, s/he cannot read another user's profile at all, and instead gets an "access denied" page. I hope I did this in the proper way. ------------------------------------------------------------------------ April 21, 2004 - 20:25 : Dries I think we should not introduce a new permission but merge with the existing 'access user list' permission (or rename it to 'access users'). Marking this "won't fix" until the patch has been udpated. ------------------------------------------------------------------------ May 28, 2004 - 02:26 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission_0.patch (1.88 KB) Another patch, this time renaming the permission "access user list" to "access users", and adding a check in the user viewing function to only allow users with this permission to view the user information. ------------------------------------------------------------------------ July 5, 2004 - 15:31 : Anonymous Attachment: http://drupal.org/files/issues/user-module-add-view-permission_1.patch (1.86 KB) Here is a patch again, now for CVS. Does the same thing as above. It is a very simple patch. If it seems proper, I hope that can be included before it goes stale. ------------------------------------------------------------------------ July 9, 2004 - 02:08 : daBrado Attachment: http://drupal.org/files/issues/user-module-add-view-permission_2.patch (1.33 KB) The previous patch was accepted, but then for some reason reversed as part of another CVS commit. So, here is a new patch that brings back the "access users" permission. It controls whether or not a user may view other users info. ------------------------------------------------------------------------ September 22, 2004 - 16:53 : Bèr Kessels Attachment: http://drupal.org/files/issues/access_users_perm.patch (6.46 KB) A new and revised patch. It adds an "access users" permission ------------------------------------------------------------------------ September 22, 2004 - 18:02 : killes(a)www.drop.org I'd like to see this patch applied to cvs before the 4.5 release. Now that we can protect our nodes from unauthorized access it just makes sense to protect our user data as well. In the future I'd like to see scheme where the user (as in end-user) is able to selet which of his data gets published. ------------------------------------------------------------------------ September 23, 2004 - 01:52 : rkendall I would like this too ------------------------------------------------------------------------ October 14, 2004 - 23:46 : drumm Can the name be changed to 'view user profiles'? ------------------------------------------------------------------------ October 18, 2004 - 09:19 : Bèr Kessels It can, but I used "access" for consistancy. we have "access newsfeeds", "access comments", "access etc". This patch is critical for corporate sites btw. A corporate site that has its customers information lying on the streets (so to say) is not-done. Ber ------------------------------------------------------------------------ November 27, 2004 - 13:49 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-access.patch (5.96 KB) Updated for CVS. I assumed that "admin users" implies "access users" in user_admin. ------------------------------------------------------------------------ March 1, 2005 - 17:30 : killes(a)www.drop.org Does not apply anymore, Ber can you have a look at it? ------------------------------------------------------------------------ March 7, 2005 - 09:19 : Bèr Kessels Attachment: http://drupal.org/files/issues/user_access_0.patch (9.74 KB) New patch. Should apply to HEAD. ------------------------------------------------------------------------ April 7, 2005 - 21:29 : killes(a)www.drop.org It's a patch (which still applies and wants into core).

1 0

[drupal-devel] [bug] Remove message_access function and introduce better worded situation aware messages
by killes 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/17592 Project: Drupal Version: cvs Component: other Category: bug reports Priority: normal Assigned to: killes(a)www.drop.org Reported by: Carl McDade Updated by: killes(a)www.drop.org Status: patch Dries said, he will look at it again after 4.6 got released. killes(a)www.drop.org 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? ------------------------------------------------------------------------ February 20, 2005 - 03:47 : Steven Can someone point out to me how this is related to i18n, at all? ------------------------------------------------------------------------ March 23, 2005 - 23:01 : Dries As discussued, this is not going to work as is. ------------------------------------------------------------------------ March 23, 2005 - 23:06 : killes(a)www.drop.org My patch still applies just fine and I am not aware of any discussion.

1 0

[drupal-devel] hi, etc
by Daniel Convissor 08 Apr '05

08 Apr '05

Hi: I'm new to Drupal, but have long involvement in the PHP community. For instance, I'm the lead maintainer of PEAR's DB package and am involved with the PEAR documentation and website teams. A client of mine needs a CMS and I'm very impressed with how well the Drupal website is organized. I'm also enjoying Drupal's code itself. I submitted two code maintenance patches: http://drupal.org/node/19609 http://drupal.org/node/19474 One more thing I would like to do is make multi-site installations easier by providing scripts for performing the table name prefix substitutions. As I move forward with helping this client, I'm sure I'll come across more ways to improve Drupal. To these ends, I'm interested in obtaining the ability to make commits to the repository, please. Hmm, now that I'm looking at http://drupal.org/node/19474 I see people have commented on it. That's great. I'm used to bug systems sending an email when someone comments. I didn't receive such emails in response to these people's comments. Does Drupal's system not do that or am I missing something? My email address is correct, since I got the initial confirmation when setting up my account. Sincerely, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

9 24

[drupal-devel] [bug] race condition in variable_set in bootstrap.inc
by jhriggs 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/20114 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: Ricetons Reported by: Ricetons Updated by: jhriggs Status: patch 1. Assuming that all we are talking about is variable_set() calls, DELETE is not an issue, because the patch removes deletes. It only does updates and inserts. Now if you throw in variable_del() calls, that's another story, but it's also outside the scope of this issue. It would likely be much more rare than the delete/insert problems we see now. 2. Your second example is the only lingering downfall. As I mentioned in my post: "...they may both see that the row does not exist and both attempt to do an INSERT. This will only happen the first time a variable is created, though, which may be more acceptable than what we are seeing now." 3. This doesn't add any queries. Right now it does DELETE and INSERT. With the patch it does SELECT and UPDATE/INSERT. Two queries either way. As I alluded, this may not be a true fix -- I don't think there is one for race conditions like this, even with table-locking -- but it addresses the problem in a way that makes sense and eliminates an error in the majority of cases. jhriggs Previous comments: ------------------------------------------------------------------------ April 6, 2005 - 21:53 : Ricetons This bug was exposed by the poormancron module. We can see that the module itself contains no bug. But in the function variable_get(), the function just execute SQL like this: DELETE bar WHERE key="foo" INSERT INTO bar VALUES(foo, bar2ooo) but suppose this: thread A and thread B has executed the DELETE sentence. And they do INSERT at the same time. then an SQL error like this occured: duplicated key 'foo' in table "variables" It's a critical bug. It should be fixed before the time that drupal 4.6.0 released. ------------------------------------------------------------------------ April 8, 2005 - 02:01 : robertDouglass I also experience this on a site that has many different cron cycles ranging from 2 minutes to 6 hours. The query errors which arise (as noted above) are impossible to reproduce through normal testing yet occur fairly (surprisingly) often in the logs. This doesn't just apply to cron jobs but rather to all code that calls variable_set. Setting to CVS since this hasn't been addressed since the issue was opened. ------------------------------------------------------------------------ April 8, 2005 - 07:10 : jhriggs Attachment: http://drupal.org/files/issues/variable_set_update.patch (922 bytes) I'm not sure that there is a "right" way to fix this. In mysql, we could use a REPLACE rather than DELETE/INSERT, but that wouldn't work for pgsql. And, if we are really seeing this type of race, there is no telling which REPLACE would actually make it last and be saved. Instead, we could do a check to see if the row exists and do an UPDATE if it does and an INSERT otherwise; however, this would be prone to the same problem if we are seeing such a race. That is, they may both see that the row does not exist and both attempt to do an INSERT. This will only happen the first time a variable is created, though, which may be more acceptable than what we are seeing now. If the row does already exist, they would both do UPDATES and would "succeed" in the sense that there is no duplicate key error. There is still no telling which one actually sticks, though. The attached patch takes the second approach. ------------------------------------------------------------------------ April 8, 2005 - 07:37 : Jeremy(a)kerneltrap.org What keeps another session from doing a DELETE after your session does its SELECT COUNT but before it does its UPDATE? Or, what keeps another session from doing an INSERT after your session does its SELECT COUNT but before it does its INSERT? All you've done is add another query... I think you'll need to use locking to fix this right.

1 0

[drupal-devel] [feature] settings.php: better instructions for $db_url and $db_prefix
by danielc 08 Apr '05

08 Apr '05

Issue status update for http://drupal.org/node/19474 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: danielc Updated by: danielc Status: patch Attachment: http://drupal.org/files/issues/settings.diff (2.49 KB) Improves instructions in /drupal/sites/default/settings.php: * How to escape URL characters in $db_url. * How to use the array format of $db_prefix. danielc

5 7

[drupal-devel] 4.6 + PostgreSQL
by Marc Poris 08 Apr '05

08 Apr '05

Hi, For the last couple days I have been using 4.6 with PostgreSQL on windows with Apache 2 and PHP5. I've gotten a bunch of pg_query() errors and am wondering if this stuff is supposed to be working yet with PostgreSQL. Some of the errors: 1. Attempting to add a new role: INSERT INTO role (name) VALUES ('superduper') in C:\...\includes\database.pgsql.inc on line 62. pg_query() [function.pg-query <http://www.footballfantasywizard.com/function.pg-query>]: Query failed: ERROR: duplicate key violates unique constraint "role_pkey" in C:\...\includes\database.pgsql.inc on line 45. I fixed this by incrementing the role_rid_seq Current Value, but looking at the code in user.module, it seems that we would want to change the following (add a call to db_next_id): db_query("INSERT INTO {role} (name) VALUES ('%s')", $edit['name']); 2. Under logs, top users (and top pages) this error happens: SELECT COUNT(a.uid) AS hits, a.uid, u.name FROM accesslog a LEFT JOIN users u ON a.uid = u.uid GROUP BY a.uid ORDER BY hits DESC LIMIT 30 OFFSET 0 in C:\...\includes\database.pgsql.inc on line 63. pg_query() [function.pg-query <http://www.footballfantasywizard.com/function.pg-query>]: Query failed: ERROR: column "u.name" must appear in the GROUP BY clause... 3. First time I went to the forums (can't reproduce this one, but will do so on a clean install): INSERT INTO vocabulary (name, description, help, multiple, required, hierarchy, relations, weight, module, vid) VALUES ('Forums', '', '', 0, 1, 1, 0, '', 'forum', '1') pg_query() [function.pg-query <http://www.footballfantasywizard.com/function.pg-query>]: Query failed: ERROR: invalid input syntax for integer: "" --- I guess my questions are: 1. Is there a main contact for Drupal/PostgreSQL issues (I emailed James Arthur whose name is at the top of database.pgsql and he gave me some great starting points but said he's been out of the loop for a number of years)? 2. When 4.6 is released, what does that mean as far as PostgreSQL stability? And I'm volunteering to help out -- I've got some time on my hands, but I am not a PostgreSQL expert. Doesn't look like one is really needed, but there appears to be a need for someone to be banging on it. Please feel free to flame away. Hope I haven't put this out in the wrong venue. Marc

5 6

[drupal-devel] Taxonomy Similar: Very Early First Draft
by Morbus Iff 08 Apr '05

08 Apr '05

Hey all. Anyone interested in my tagging patch has probably seen: http://disobey.com/detergent/2005/similar_keywords.jpg which is/was a homebrew UI to select similar tags to the ones entered during content creation. I've just finished an early draft for Drupal: http://disobey.com/detergent/2005/drupal_taxonomy_similar.jpg cvs.drupal.org/viewcvs/drupal/contributions/modules/taxonomy_similar/ Some notes: * the low match count is because I've only imported 8000 terms, and not all the node content that exists at NHPR.org. I'll be populating term_node soon so I can get an idea of the hit on tag->node counting. * the module works best when you already have a large tagging vocabulary. It'll probably be pretty useless if you have less than, say, 500 terms. * there's no help, README, blah - hell, there's not much of anything in the way of documentation besides that screenshot. Still, the code DOES work (and the next version will redirect you to node/$nid instead of itself after submission). * it will ONLY kick in on free-tagging vocabularies. there is no configuration necessary. install it, enable it, insert/update a node that uses free tagging. I got into some small discussion about the UI today, and I wanted to rationalize why I've done it the way I've done it. The current UI supports ALL these possibilities, and I've yet to find a compact or intuitive alternative based on other folks suggestions. * don't change a thing (close the window, or "submit"). * re-assign tags (uncheck your original, check new one). * add tags (keep your original checked, check new one). * delete tags (uncheck your original, don't check new one). I have plans on the following explorations: * Explore "merging" of tags, such that two similar tags can be merged into one combined tag. this would be an 'administer taxonomy' access. * Explore playing with term_relation so that similar tags are related to one another when a user makes that explicit choice. * Explore a 'view nodes' sorta screen or block, which would just link off to similar keywords. this seems evilly dangerous, since the similarity code is prohibitive to run on a large vocab (8000+ tested). * Currently, there's a bit of confusion when it comes to "your tags" that are also "similar tags" for another one. So, say you choose "Death Penalty". A similar tag is "Juvenile Death Penalty", so you also choose that one. The NEXT time you go back to that screen, should "Juvenile Death Penalty" (now one of "your tags") still be shown as a similar tag under "Death Penalty"? From a clutter standpoint, no. From a comprehension/expectation standpoint, I'm not sure. Anyways. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus

3 9