February 2005 - Development - lists.drupal.org

[drupal-devel] [feature] RSS Feeds behind Firewall
by Anonymous 04 Feb '05

04 Feb '05

Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jhefmv24 Updated by: Anonymous Status: patch Here's the error I get... warning: fsockopen(): unable to connect to :8080 in ....\includes\common.inc on line 228. Anonymous Previous comments: ------------------------------------------------------------------------ May 19, 2004 - 05:01 : jhefmv24 Attachment: http://drupal.org/files/issues/common.inc (37.11 KB) I think the RSS feeds don't work if there is proxy server running. The request/connection is somehow being blocked. The connection should be made first to the proxy and once it is established, then request can made. I think the core function drupal_http_request() under /includes/common.inc doesn't support this. One workaround is change the code from: <?php switch ($uri['scheme']) { case 'http': //$fp = @fsockopen($uri['host'], ($uri['port'] ? $uri['port'] : 80), $errno, $errstr, 15); ?> into: <?php //use proxy settings $fp = @fsockopen('proxy2', '8080'); ?> And then create the request by change from: <?php $request = "$method $path HTTP/1.0\r\n"; ?> Into: <?php $request = "$method ".$uri['scheme']."://".$uri['host'].$path." HTTP/1.1\r\n"; ?> And comment out the lines: <?php $request .= implode("\r\n", $defaults); ?> ------------------------------------------------------------------------ February 1, 2005 - 23:38 : Anonymous Did this ever get taken care of in 4.5.2. I can't seem to get any feed to work from behind a firewall. Getting error.... Failed to parse RSS feed Microsoft Security Info: 10060 A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.. At home this same feed works fine, so I know it's not the feed. Thanks, SlackNet ------------------------------------------------------------------------ February 4, 2005 - 04:24 : jhefmv24 Attachment: http://drupal.org/files/issues/common.inc_4.patch (1.37 KB) +1 on having a facility to modify proxy settings... here's a patch of /includes/common.inc for drupal-4.4.2 version ------------------------------------------------------------------------ February 4, 2005 - 04:25 : jhefmv24 Attachment: http://drupal.org/files/issues/system.module_2.patch (956 bytes) +1 on having a facility to modify proxy settings... here's a patch of /modules/system.module for drupal-4.4.2 version ------------------------------------------------------------------------ February 4, 2005 - 04:31 : jhefmv24 Attachment: http://drupal.org/files/issues/common.inc_5.patch (1.35 KB) patch for /includes/common.inc 4.5.2 version to facilitate rss feeds behind firewall ------------------------------------------------------------------------ February 4, 2005 - 04:32 : jhefmv24 Attachment: http://drupal.org/files/issues/system.module_3.patch (1.03 KB) patch of /modules/system.module 4.5.2 version to set proxy settings ------------------------------------------------------------------------ February 4, 2005 - 08:23 : Bèr Kessels hi, tso small issues. one is described at: http://drupal.org/node/9706 The other is that the code is not "drupal compliant". Drupal developrs are (luckily) very picky about spaces, indentation, etc. ------------------------------------------------------------------------ February 4, 2005 - 08:51 : jhefmv24 Attachment: http://drupal.org/files/issues/common.inc_6.patch (1.37 KB) i forgot to remove my hardcoded proxy name.. sorry Ber, which is not drupal compliant? ------------------------------------------------------------------------ February 4, 2005 - 21:22 : Anonymous Is there any way to hardcode my proxy server name? I can't seem to get the patches to work. I just get a blank page after I try to update the news feeds. -- View: http://drupal.org/node/7881 Edit: http://drupal.org/project/comments/add/7881

1 0

[drupal-devel] [feature] RSS Feeds behind Firewall
by Anonymous 04 Feb '05

04 Feb '05

Project: Drupal Version: 4.5.2 Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jhefmv24 Updated by: Anonymous Status: patch Is there any way to hardcode my proxy server name? I can't seem to get the patches to work. I just get a blank page after I try to update the news feeds. Anonymous Previous comments: ------------------------------------------------------------------------ May 19, 2004 - 05:01 : jhefmv24 Attachment: http://drupal.org/files/issues/common.inc (37.11 KB) I think the RSS feeds don't work if there is proxy server running. The request/connection is somehow being blocked. The connection should be made first to the proxy and once it is established, then request can made. I think the core function drupal_http_request() under /includes/common.inc doesn't support this. One workaround is change the code from: <?php switch ($uri['scheme']) { case 'http': //$fp = @fsockopen($uri['host'], ($uri['port'] ? $uri['port'] : 80), $errno, $errstr, 15); ?> into: <?php //use proxy settings $fp = @fsockopen('proxy2', '8080'); ?> And then create the request by change from: <?php $request = "$method $path HTTP/1.0\r\n"; ?> Into: <?php $request = "$method ".$uri['scheme']."://".$uri['host'].$path." HTTP/1.1\r\n"; ?> And comment out the lines: <?php $request .= implode("\r\n", $defaults); ?> ------------------------------------------------------------------------ February 1, 2005 - 23:38 : Anonymous Did this ever get taken care of in 4.5.2. I can't seem to get any feed to work from behind a firewall. Getting error.... Failed to parse RSS feed Microsoft Security Info: 10060 A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.. At home this same feed works fine, so I know it's not the feed. Thanks, SlackNet ------------------------------------------------------------------------ February 4, 2005 - 04:24 : jhefmv24 Attachment: http://drupal.org/files/issues/common.inc_4.patch (1.37 KB) +1 on having a facility to modify proxy settings... here's a patch of /includes/common.inc for drupal-4.4.2 version ------------------------------------------------------------------------ February 4, 2005 - 04:25 : jhefmv24 Attachment: http://drupal.org/files/issues/system.module_2.patch (956 bytes) +1 on having a facility to modify proxy settings... here's a patch of /modules/system.module for drupal-4.4.2 version ------------------------------------------------------------------------ February 4, 2005 - 04:31 : jhefmv24 Attachment: http://drupal.org/files/issues/common.inc_5.patch (1.35 KB) patch for /includes/common.inc 4.5.2 version to facilitate rss feeds behind firewall ------------------------------------------------------------------------ February 4, 2005 - 04:32 : jhefmv24 Attachment: http://drupal.org/files/issues/system.module_3.patch (1.03 KB) patch of /modules/system.module 4.5.2 version to set proxy settings ------------------------------------------------------------------------ February 4, 2005 - 08:23 : Bèr Kessels hi, tso small issues. one is described at: http://drupal.org/node/9706 The other is that the code is not "drupal compliant". Drupal developrs are (luckily) very picky about spaces, indentation, etc. ------------------------------------------------------------------------ February 4, 2005 - 08:51 : jhefmv24 Attachment: http://drupal.org/files/issues/common.inc_6.patch (1.37 KB) i forgot to remove my hardcoded proxy name.. sorry Ber, which is not drupal compliant? -- View: http://drupal.org/node/7881 Edit: http://drupal.org/project/comments/add/7881

1 0

[drupal-devel] [task] Put revisions in their own table
by killes 04 Feb '05

04 Feb '05

Project: Drupal Version: cvs Component: node system Category: tasks Priority: normal Assigned to: killes(a)www.drop.org Reported by: killes(a)www.drop.org Updated by: killes(a)www.drop.org Status: patch @dmjossel: thanks. @all. The strange problem I reported was apparently php 5 related. After applying Steven's php 5 patch it went away. One error is remaining: If I create a new forum topic it will be shown as part of the book on preview. Hmm, that was due to a db that got corrupted during testing so that is fixed too. Please poke around at the test site and look if you find more errors. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ May 5, 2004 - 17:25 : killes(a)www.drop.org Currently all node revisions are stored in a serialized field in node.table and retrieved for _each_ page view although they are rarely needed. However, we have agreed that serializing data is bad and that we should try to keep the memory foot print pf Drupal small. Therefore I propose to create a separate revisions table which would be in principle identical to the node table, only that it could have several old copies of the same node. Extra data added by other modules could be added in a serialized field unless we find a better solution. ------------------------------------------------------------------------ May 5, 2004 - 18:06 : jhriggs I too think the serialized approach is less than desirable, but here's an alternative. This would likely take some considerable rework in core and contrib, but the following is how we handle similar types of situations in our databases at work. It is more elegant that a separate table, and avoids the (almost exact) duplication of a table. Instead of separate tables, keep all revisions of nodes in the node table as follows: * add field: active (0/1 or Y/N) * add field: revision * every revision of a node is stored in the node table; however, only one revision can be active at any given time * nid can no longer be unique -- primary/unique key becomes (nid, active) * any time a node is loaded, updated (without revision), etc., the active version is used. Thoughts? ------------------------------------------------------------------------ May 5, 2004 - 18:57 : killes(a)www.drop.org I am not opposed to your scheme, but I want to stress the following: * Duplicating a table's structure is not bad (IMHO) as long as the content is different. * having two tables will allow us to have a rather small node table. This is (maybe) a performance gain. ------------------------------------------------------------------------ May 5, 2004 - 19:37 : jhriggs I don't necessarily think that duplicating a table's structure is _bad_. It just seems to be wasteful and a pain to maintain. (Every change to the node table is made twice...easy to do, but also easy to miss perhaps.) As for performance, as long as nid and the active indicator are indexed, there shouldn't be any performance loss. Also, archiving an old version when making a new revision will be much simpler: just change the active indicator rather than copying an entire node to another table (and ensuring everything gets copied...again a potential maintainance issue). To be honest, I would just like to see the serialized data go away, regarless of what approach is taken. ------------------------------------------------------------------------ July 30, 2004 - 20:49 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_07-30-2004.p… (10.47 KB) I'm interested in using Drupal for a large scale wiki-type project. In order to do this, I need revisions to be in their own table. Attached is a patch to do just that. Most of the changes are pretty self explanatory. Spreading out node data across two tables meant that I had to add database functions to do locking/transactions. Without this, race conditions in which the database becomes corrupted are possible. ------------------------------------------------------------------------ July 30, 2004 - 20:54 : Nick Nassar Oh yeah... The patch is a diff against Drupal CVS ------------------------------------------------------------------------ July 31, 2004 - 01:00 : Anonymous Gerhard speaking. Nick, thanks a lot for your nice patch! It saves me a great deal of labour. I looked through it and immediately liked it. You not only put the old revisions into a new table but also the current one. Do you have an estimate how much more expensive the additional join is? Besides a few minor coding style issues I found a major one: Just a few hours before you uploaded your patch JonBob's node access patch hit core. That means your patch won't apply anymore as all the queries you change have been changed. Can I bug you to update your patch? ------------------------------------------------------------------------ July 31, 2004 - 02:11 : Anonymous Also I think that your upgrade path loses existing revisions. ------------------------------------------------------------------------ July 31, 2004 - 03:39 : drumm I think this is the proper way to do things. No columns are duplicated, there is no serialized data, and only the fields that are logically revised are stored. Nothing jumped out at me as a way to have my node modules be able to keep a table of revisions of additional fields. I'm guessing this could be done within the confines of _insert and _update. Assuming the upgrade path works and modules can extend it I give it a +1. ------------------------------------------------------------------------ July 31, 2004 - 15:40 : Nick Nassar It figures that just as I finish a big patch, another patch comes along and breaks it. Oh well, it should be a pretty easy to fix. I'll work on it. Fixing the upgrade path to keep revisions should be fairly painless. I found another issue that needs to be fixed before this patch gets merged. There format of a node needs to be stored for each revision. Otherwise, for modules that store a format for the nodes, such as page and book, if you write one revision in PHP and the next in HTML, the PHP revision will be displayed as HTML. This is part of a larger issue of how node modules should store revisions of additional fields. I think each module that wants to do this should create another table with (nid, revid) as the primary key. Just as when they want to add fields to a node they create another table with nid as the primary key. As far as performance goes, for sites that make heavy use of revisions, an extra join on primary keys is going to be a lot faster than grabbing all of the revisions from that database everytime. We would need to run benchmarks to determine is the overall difference in speed is for an average site is a gain or a loss. I'm guessing it's very minor either way. ------------------------------------------------------------------------ August 23, 2004 - 14:55 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_08-23-2004.p… (10.92 KB) Here's an updated patch against CVS that puts revisions in their own table, provides an upgrade path, and fixes the format related bugs in the last patch. Hopefully, this can make it into CVS as soon as the freeze is over. ------------------------------------------------------------------------ August 23, 2004 - 15:10 : moshe weitzman Interesting patch ... drumm's question is still outstanding. how do modules store revisions of their fields? Are they expected to manage this on their own? Thats not how it works today. As an aside, i am seeing profile_ fields in my node.revisions column. One could argue that those need not be saved. They pertain to the node author, not to the node itself. ------------------------------------------------------------------------ August 23, 2004 - 17:14 : Nick Nassar Having modules be responsible for storing revisions of their own fields is a side-effect of storing revision data in tables. There's really no way around it. However, revisions generally don't make sense for node types that don't have PHP/HTML content, such as polls. I think it's going to be a pretty rare scenario for a new node type to want another field to change per-revision, so it's a pretty good trade-off. Storing fields that shouldn't be part of revisions, such as the profile_ fields, is a side-effect of storing revisions as serialized objects. Applying this patch will free up that wasted space. :) ------------------------------------------------------------------------ August 23, 2004 - 18:20 : Anonymous There should be a hook that let's the module choose whether it supports history. This way a module author can prevent the user from doing something that may break his module or just cause undefined behavior. If the module doesn't support history then don't let the user/admin choose to add history to nodes of that type. Craig ------------------------------------------------------------------------ August 23, 2004 - 20:23 : Nick Nassar I agree, there should be an API change to make specifying support for revisions easier. In the interests of keeping patches small and keeping to one change per patch, I think the API change should be a separate issue. A sort of ad-hoc API to decide whether or not a module supports revisions by default already exists. Instead of having a hook, modules set the default value of the "Create new revision" field in the edit form. The admin can change this option in admin/node/configure/defaults. This patch doesn't change that. Revisions are broken for node types that have their own database structure, like polls, even when storing them as serialized objects. This patch doesn't change that, either. ------------------------------------------------------------------------ October 26, 2004 - 03:35 : moshe weitzman I'm guessing that someone is going to have to demonstrate that this patch performs as well as current drupal before it gets comitted. i think this patch is a few benchmarks from being comitted. ------------------------------------------------------------------------ October 27, 2004 - 02:04 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004.p… (11 KB) I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ October 27, 2004 - 02:05 : Nick Nassar I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ October 27, 2004 - 02:05 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004.p… (11 KB) I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ November 15, 2004 - 06:05 : elias1884 please overthink the revision system default workflow as well. don't look at the revision system as an isolated system but as a part of the whole workflow system! if you combine revisions with the moderation queue the most logic default workflow would be like that: auth user creates node (revision #0) admin approves the node (status = 1, moderation = 0) => node publicly available auth user finds typo and changes node (revision #1, status = 0, moderation = 1) ------- what happens at that point at the moment is, that the node is not accessible anymore at all until the new revision is approved by admin. of course the new revision should not go online until reviewed and approved, this is absolutely correct, but there is no reason to not take the old revision offline, since it was already approved and should therefore be online until the new revision is approved. it is not practical if a node disappears only because the author corrected a typo. ------- admin approves the node (status = 1, moderation = 0) eventhough I first thought a plain boolean active field would not be capable of providing that functionality if finally came to the conclusion, that it can. The only thing to do is to not set that bit, when a new revision is created, but when it is approved (in case moderation is activated under default workflow). Every revision should have its own moderation, status and active field and on approval they are set like this (status=1, moderation=0, active=Y). When you wanna rollback to an old revision, you can chose between all revisions that already have the moderation bit set back to 0 again and the published to 1. There should be an extra permission for rollback! another concern that I have about the default workflow is, that users can't see the content, they have just created, when moderation is enabled. Eventhough, there is a big fat "submission accepted" presented after submissions, unexperienced users tend to question the information those stupid tincans give them, if they can't find their content afterwards. Many users are really lazy bastards and they don't even read the status messages. The best feedback about whether his story was submitted successfully or not of course is, if he can find the story somewhere on the site, maybe with a status message on top of it, mentioning, that the content is currently not publicly available since it has not been approved yet. there should be a my content section under my account, like somebody is trying to do with the workspace module I guess. so my suggestion is to make (status=0, moderation=1) still available for the creator under a my content section somewhere! ------------------------------------------------------------------------ November 24, 2004 - 05:21 : Nick Nassar I agree. The current workflow for moderation queues and revisions needs to change, but this patch isn't the place for it. The patch is already too big, and it only does the backend stuff. Instead of adding more to this patch and making it take even longer to get into core, would you mind creating a new issue for your UI suggestions, so the those changes can be added as a separate patch? Thanks, Nick ------------------------------------------------------------------------ December 11, 2004 - 13:26 : Dries This patch is _much_ needed so I'd love to see someone revive it. In order for this patch to be accepted, the following needs to be done: Update this patch to CVS HEAD. Rename revid to vid. Rename node_rev to node_revisions. Rename node_rev.changed to node_revisions.timestamp. Rename $rnode to $revision. Fix the coding style to match Drupal's: proper spacing, single quotes where possible, proper variable names. Benchmark this patch with a large database with enough revisions. I'd be happy to benchmark this on my local copy of the drupal.org database. The book.log field should probably move to the node_revisions table. This can be done in a separate patch. Investigate whether transactions are well-supported. ------------------------------------------------------------------------ December 13, 2004 - 01:25 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004-r… (11.02 KB) I've worked a bit on the patch (coding style issues as mentioned by Dries). One thing I noticed is that the patch uses REPLACE. IIRC this needs to be chagned to "UPDATE, if fail INSERT" for pgsql compatibility. Nick, are you still interested in working on that patch? I'd like to know how it works on your site and work on getting it into core. ------------------------------------------------------------------------ December 13, 2004 - 13:33 : Dries Gerhard: your patch does not apply. ------------------------------------------------------------------------ December 13, 2004 - 18:10 : killes(a)www.drop.org Yes, I know, that was the same version as I mailed to you earlier. ------------------------------------------------------------------------ December 13, 2004 - 22:02 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions.patch (52.96 KB) Ok, upüdated the patch to cvs. ------------------------------------------------------------------------ December 14, 2004 - 09:58 : Dries Some more comments: db_begin_transaction() and db_end_transaction() do not belong in database.inc, but in database.mysql.inc and database.pgsql.inc respectively. The node module calls node_revisionsision_list() which is not defined. (Fxed that on my local copy.) Do db_begin_transaction() and db_end_transaction() deprecate Jeremy's table locking patch? The upgrade path assigns the wrong user ID to each revision. The upgrade path assigns the wrong date to each revision (that or a node's revision page shows the wrong usernames/dates). The coding style needs a bit of work, but we can worry about that later. ------------------------------------------------------------------------ December 14, 2004 - 18:34 : Nick Nassar If you need any help getting those things fixed, just let me know. ------------------------------------------------------------------------ December 14, 2004 - 18:50 : Nick Nassar How this relates to Jeremy's node locking patch: There was lots of discussion, and node locking was decided against because from an end user point of view you never want a node to be locked. He's now advocating for a much simpler patch that warns users if their changes will overwrite someone elses. That patch still has a race condition, which might be fixed using db_begin_transaction(). http://drupal.org/node/6025 ------------------------------------------------------------------------ December 14, 2004 - 23:26 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_0.patch (55.96 KB) Here is an updated patch that tries to address Dries concerns. ------------------------------------------------------------------------ December 15, 2004 - 09:32 : Dries Attachment: http://drupal.org/files/issues/revisions-bug.png (76.06 KB) It didn't fix the aforementioned bugs. See attached screenshot. ------------------------------------------------------------------------ January 6, 2005 - 21:15 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_1.patch (51.77 KB) Ok, here is a new version. Dries and myself worked hart at it, so please have a look. what is still missing - database upgrades for the core modules with an own table - contrib modules need an upgrade too. - do we need nid and vid in both the node and the node_revisions table? - the amount of sql queries means a good stress testing for large databases. ------------------------------------------------------------------------ January 19, 2005 - 22:43 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_2.patch (49.49 KB) Here is an updated patch. We discussed to keep the current title in node module and also in the revisiosn table. This is content duplication but will save many joins as many queries only need the title of a node. Discussion is welcome. ------------------------------------------------------------------------ January 20, 2005 - 00:33 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_3.patch (29.93 KB) I've implemented the aforementioned solution. This makes the patch much smaller. The patch now also removes taxonomy_node_has_term() which wasn't used anywhere. I'd really apprciate if some people could test drive the patch. It will be another huge improvement for 4.6. ------------------------------------------------------------------------ January 20, 2005 - 01:05 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_4.patch (30 KB) Another revision. Steven didn't like my literal $node->vid in queries. ------------------------------------------------------------------------ January 20, 2005 - 02:10 : killes(a)www.drop.org - database upgrades for the core modules with an own table - contrib modules need an upgrade too. - do we need nid and vid in both the node and the node_revisions table? - the amount of sql queries means a good stress testing for large databases. These issues are still open, btw. Especially the first one needs to be tackled. ------------------------------------------------------------------------ January 25, 2005 - 21:11 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_5.patch (51.13 KB) Here is a patch that has the database tables updated for forum, book, and page module. ------------------------------------------------------------------------ January 29, 2005 - 23:55 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_6.patch (49.18 KB) Yet another update to keep it working with head. The patch now also removes the table definitons for the page table. ------------------------------------------------------------------------ January 29, 2005 - 23:57 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_7.patch (55.69 KB) Sorry, that was the old version, this is the right one. ------------------------------------------------------------------------ January 31, 2005 - 20:55 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_8.patch (55.71 KB) Updated once more. ------------------------------------------------------------------------ January 31, 2005 - 21:52 : Dries Anyone to help review/test this? ------------------------------------------------------------------------ January 31, 2005 - 22:22 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_9.patch (49.29 KB) Updated again, the update functions occurred twice. Thanks Bart. ------------------------------------------------------------------------ February 2, 2005 - 01:27 : killes(a)www.drop.org Don't know if the db I am using is corrupted or what. I still do have some didficulties. The latest patch is attached. ------------------------------------------------------------------------ February 2, 2005 - 01:27 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_10.patch (49.67 KB) I am probably slowly going mad ... ------------------------------------------------------------------------ February 2, 2005 - 02:54 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_11.patch (48.95 KB) The update issue still needs investigating. This patch is updated for cvs. ------------------------------------------------------------------------ February 2, 2005 - 21:20 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_12.patch (49.83 KB) Ok, here is a new version. I've solved my troubles with book.module. There are still some issues with forum module. Possibly due to inconsistent database. ------------------------------------------------------------------------ February 2, 2005 - 22:31 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_13.patch (49.83 KB) Turns out the drupal.org database had indeed some quirks. Please run this query in your oldest db and tell me the result: select nid,type from node where type like '%/%'; If you get a non-zero result we might need to add another security update. The patch could use still more testing, though. ------------------------------------------------------------------------ February 3, 2005 - 02:16 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_14.patch (49 KB) Ok, we are getting somewhere. At a first glance the update is working. There is a problem remaining: the revisions tab will be shown whether the node has revisions or not. Not sure we can/need to fix this. People with a drupal.org account can log in at http://killes.drupaldevs.org/revision/ and poke around. Your permissions will be the same as on drupal.org. Feel free to vreak everything but don't forget to file complaints here. (Note: this is only a pruned version of the drupal.org database with all project nodes and nodes with nids > 7000 dropped). ------------------------------------------------------------------------ February 3, 2005 - 05:19 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_15.patch (52.39 KB) There was some error in node_save and also the patches to the database.inc files got lost... ------------------------------------------------------------------------ February 3, 2005 - 08:07 : robertDouglass Submitting book pages doesn't work on your test site. It puts the entire content of the preview inside the body textarea. I wrote a sentence in the body and the log, and pressing preview put several lines of HTML containing both sentences in the body textarea on the preview page, plus the book page wouldn't submit. -R ------------------------------------------------------------------------ February 3, 2005 - 08:50 : Junyor 0 results here. I started using Drupal with version 4.4, though. ------------------------------------------------------------------------ February 4, 2005 - 00:56 : killes(a)www.drop.org @Junyor: Thanks, that's a good sign. Maybe somebody else has an older db to try. @robertDouglass: The first effect you describe is due to drupaldevs running on PHP 5. I am unsure why the second thing does not work. In node_save() the node object has a nid although there is none in the form. Very strange. I've enabled display of db queries on the testsite. ------------------------------------------------------------------------ February 4, 2005 - 20:17 : dmjossel No results here on the query: select nid,type from node where type like '%/%'; On a database that was put in place prior to Drupal 4 and is now running on 4.5.2. -- View: http://drupal.org/node/7582 Edit: http://drupal.org/project/comments/add/7582

1 0

[drupal-devel] [task] Put revisions in their own table
by dmjossel 04 Feb '05

04 Feb '05

Project: Drupal Version: cvs Component: node system Category: tasks Priority: normal Assigned to: killes(a)www.drop.org Reported by: killes(a)www.drop.org Updated by: dmjossel Status: patch No results here on the query: select nid,type from node where type like '%/%'; On a database that was put in place prior to Drupal 4 and is now running on 4.5.2. dmjossel Previous comments: ------------------------------------------------------------------------ May 5, 2004 - 23:25 : killes(a)www.drop.org Currently all node revisions are stored in a serialized field in node.table and retrieved for _each_ page view although they are rarely needed. However, we have agreed that serializing data is bad and that we should try to keep the memory foot print pf Drupal small. Therefore I propose to create a separate revisions table which would be in principle identical to the node table, only that it could have several old copies of the same node. Extra data added by other modules could be added in a serialized field unless we find a better solution. ------------------------------------------------------------------------ May 6, 2004 - 00:06 : jhriggs I too think the serialized approach is less than desirable, but here's an alternative. This would likely take some considerable rework in core and contrib, but the following is how we handle similar types of situations in our databases at work. It is more elegant that a separate table, and avoids the (almost exact) duplication of a table. Instead of separate tables, keep all revisions of nodes in the node table as follows: * add field: active (0/1 or Y/N) * add field: revision * every revision of a node is stored in the node table; however, only one revision can be active at any given time * nid can no longer be unique -- primary/unique key becomes (nid, active) * any time a node is loaded, updated (without revision), etc., the active version is used. Thoughts? ------------------------------------------------------------------------ May 6, 2004 - 00:57 : killes(a)www.drop.org I am not opposed to your scheme, but I want to stress the following: * Duplicating a table's structure is not bad (IMHO) as long as the content is different. * having two tables will allow us to have a rather small node table. This is (maybe) a performance gain. ------------------------------------------------------------------------ May 6, 2004 - 01:37 : jhriggs I don't necessarily think that duplicating a table's structure is _bad_. It just seems to be wasteful and a pain to maintain. (Every change to the node table is made twice...easy to do, but also easy to miss perhaps.) As for performance, as long as nid and the active indicator are indexed, there shouldn't be any performance loss. Also, archiving an old version when making a new revision will be much simpler: just change the active indicator rather than copying an entire node to another table (and ensuring everything gets copied...again a potential maintainance issue). To be honest, I would just like to see the serialized data go away, regarless of what approach is taken. ------------------------------------------------------------------------ July 31, 2004 - 02:49 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_07-30-2004.p… (10.47 KB) I'm interested in using Drupal for a large scale wiki-type project. In order to do this, I need revisions to be in their own table. Attached is a patch to do just that. Most of the changes are pretty self explanatory. Spreading out node data across two tables meant that I had to add database functions to do locking/transactions. Without this, race conditions in which the database becomes corrupted are possible. ------------------------------------------------------------------------ July 31, 2004 - 02:54 : Nick Nassar Oh yeah... The patch is a diff against Drupal CVS ------------------------------------------------------------------------ July 31, 2004 - 07:00 : Anonymous Gerhard speaking. Nick, thanks a lot for your nice patch! It saves me a great deal of labour. I looked through it and immediately liked it. You not only put the old revisions into a new table but also the current one. Do you have an estimate how much more expensive the additional join is? Besides a few minor coding style issues I found a major one: Just a few hours before you uploaded your patch JonBob's node access patch hit core. That means your patch won't apply anymore as all the queries you change have been changed. Can I bug you to update your patch? ------------------------------------------------------------------------ July 31, 2004 - 08:11 : Anonymous Also I think that your upgrade path loses existing revisions. ------------------------------------------------------------------------ July 31, 2004 - 09:39 : drumm I think this is the proper way to do things. No columns are duplicated, there is no serialized data, and only the fields that are logically revised are stored. Nothing jumped out at me as a way to have my node modules be able to keep a table of revisions of additional fields. I'm guessing this could be done within the confines of _insert and _update. Assuming the upgrade path works and modules can extend it I give it a +1. ------------------------------------------------------------------------ July 31, 2004 - 21:40 : Nick Nassar It figures that just as I finish a big patch, another patch comes along and breaks it. Oh well, it should be a pretty easy to fix. I'll work on it. Fixing the upgrade path to keep revisions should be fairly painless. I found another issue that needs to be fixed before this patch gets merged. There format of a node needs to be stored for each revision. Otherwise, for modules that store a format for the nodes, such as page and book, if you write one revision in PHP and the next in HTML, the PHP revision will be displayed as HTML. This is part of a larger issue of how node modules should store revisions of additional fields. I think each module that wants to do this should create another table with (nid, revid) as the primary key. Just as when they want to add fields to a node they create another table with nid as the primary key. As far as performance goes, for sites that make heavy use of revisions, an extra join on primary keys is going to be a lot faster than grabbing all of the revisions from that database everytime. We would need to run benchmarks to determine is the overall difference in speed is for an average site is a gain or a loss. I'm guessing it's very minor either way. ------------------------------------------------------------------------ August 23, 2004 - 20:55 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_08-23-2004.p… (10.92 KB) Here's an updated patch against CVS that puts revisions in their own table, provides an upgrade path, and fixes the format related bugs in the last patch. Hopefully, this can make it into CVS as soon as the freeze is over. ------------------------------------------------------------------------ August 23, 2004 - 21:10 : moshe weitzman Interesting patch ... drumm's question is still outstanding. how do modules store revisions of their fields? Are they expected to manage this on their own? Thats not how it works today. As an aside, i am seeing profile_ fields in my node.revisions column. One could argue that those need not be saved. They pertain to the node author, not to the node itself. ------------------------------------------------------------------------ August 23, 2004 - 23:14 : Nick Nassar Having modules be responsible for storing revisions of their own fields is a side-effect of storing revision data in tables. There's really no way around it. However, revisions generally don't make sense for node types that don't have PHP/HTML content, such as polls. I think it's going to be a pretty rare scenario for a new node type to want another field to change per-revision, so it's a pretty good trade-off. Storing fields that shouldn't be part of revisions, such as the profile_ fields, is a side-effect of storing revisions as serialized objects. Applying this patch will free up that wasted space. :) ------------------------------------------------------------------------ August 24, 2004 - 00:20 : Anonymous There should be a hook that let's the module choose whether it supports history. This way a module author can prevent the user from doing something that may break his module or just cause undefined behavior. If the module doesn't support history then don't let the user/admin choose to add history to nodes of that type. Craig ------------------------------------------------------------------------ August 24, 2004 - 02:23 : Nick Nassar I agree, there should be an API change to make specifying support for revisions easier. In the interests of keeping patches small and keeping to one change per patch, I think the API change should be a separate issue. A sort of ad-hoc API to decide whether or not a module supports revisions by default already exists. Instead of having a hook, modules set the default value of the "Create new revision" field in the edit form. The admin can change this option in admin/node/configure/defaults. This patch doesn't change that. Revisions are broken for node types that have their own database structure, like polls, even when storing them as serialized objects. This patch doesn't change that, either. ------------------------------------------------------------------------ October 26, 2004 - 09:35 : moshe weitzman I'm guessing that someone is going to have to demonstrate that this patch performs as well as current drupal before it gets comitted. i think this patch is a few benchmarks from being comitted. ------------------------------------------------------------------------ October 27, 2004 - 08:04 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004.p… (11 KB) I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ October 27, 2004 - 08:05 : Nick Nassar I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ October 27, 2004 - 08:05 : Nick Nassar Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004.p… (11 KB) I ran some really unscientific benchmarks, and it looks like this patch has a negligible affect on performance. I used apache bench and the database from theregular.org, which doesn't contain any revisions (worst case scenario for this patch) and contains several hundred nodes. Both the patched and unpatched versions hovered between 2.36 and 2.38 requests per second. The command I used was: ab -n50 -C 'PHPSESSID=b01a9f92880ef215b0ed6f1314a5eba2' http://192.168.0.100/ An updated patch that should apply to CVS is attached. ------------------------------------------------------------------------ November 15, 2004 - 12:05 : elias1884 please overthink the revision system default workflow as well. don't look at the revision system as an isolated system but as a part of the whole workflow system! if you combine revisions with the moderation queue the most logic default workflow would be like that: auth user creates node (revision #0) admin approves the node (status = 1, moderation = 0) => node publicly available auth user finds typo and changes node (revision #1, status = 0, moderation = 1) ------- what happens at that point at the moment is, that the node is not accessible anymore at all until the new revision is approved by admin. of course the new revision should not go online until reviewed and approved, this is absolutely correct, but there is no reason to not take the old revision offline, since it was already approved and should therefore be online until the new revision is approved. it is not practical if a node disappears only because the author corrected a typo. ------- admin approves the node (status = 1, moderation = 0) eventhough I first thought a plain boolean active field would not be capable of providing that functionality if finally came to the conclusion, that it can. The only thing to do is to not set that bit, when a new revision is created, but when it is approved (in case moderation is activated under default workflow). Every revision should have its own moderation, status and active field and on approval they are set like this (status=1, moderation=0, active=Y). When you wanna rollback to an old revision, you can chose between all revisions that already have the moderation bit set back to 0 again and the published to 1. There should be an extra permission for rollback! another concern that I have about the default workflow is, that users can't see the content, they have just created, when moderation is enabled. Eventhough, there is a big fat "submission accepted" presented after submissions, unexperienced users tend to question the information those stupid tincans give them, if they can't find their content afterwards. Many users are really lazy bastards and they don't even read the status messages. The best feedback about whether his story was submitted successfully or not of course is, if he can find the story somewhere on the site, maybe with a status message on top of it, mentioning, that the content is currently not publicly available since it has not been approved yet. there should be a my content section under my account, like somebody is trying to do with the workspace module I guess. so my suggestion is to make (status=0, moderation=1) still available for the creator under a my content section somewhere! ------------------------------------------------------------------------ November 24, 2004 - 11:21 : Nick Nassar I agree. The current workflow for moderation queues and revisions needs to change, but this patch isn't the place for it. The patch is already too big, and it only does the backend stuff. Instead of adding more to this patch and making it take even longer to get into core, would you mind creating a new issue for your UI suggestions, so the those changes can be added as a separate patch? Thanks, Nick ------------------------------------------------------------------------ December 11, 2004 - 19:26 : Dries This patch is _much_ needed so I'd love to see someone revive it. In order for this patch to be accepted, the following needs to be done: Update this patch to CVS HEAD. Rename revid to vid. Rename node_rev to node_revisions. Rename node_rev.changed to node_revisions.timestamp. Rename $rnode to $revision. Fix the coding style to match Drupal's: proper spacing, single quotes where possible, proper variable names. Benchmark this patch with a large database with enough revisions. I'd be happy to benchmark this on my local copy of the drupal.org database. The book.log field should probably move to the node_revisions table. This can be done in a separate patch. Investigate whether transactions are well-supported. ------------------------------------------------------------------------ December 13, 2004 - 07:25 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/Drupal-Improved_Revision_Schema_10-26-2004-r… (11.02 KB) I've worked a bit on the patch (coding style issues as mentioned by Dries). One thing I noticed is that the patch uses REPLACE. IIRC this needs to be chagned to "UPDATE, if fail INSERT" for pgsql compatibility. Nick, are you still interested in working on that patch? I'd like to know how it works on your site and work on getting it into core. ------------------------------------------------------------------------ December 13, 2004 - 19:33 : Dries Gerhard: your patch does not apply. ------------------------------------------------------------------------ December 14, 2004 - 00:10 : killes(a)www.drop.org Yes, I know, that was the same version as I mailed to you earlier. ------------------------------------------------------------------------ December 14, 2004 - 04:02 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions.patch (52.96 KB) Ok, upüdated the patch to cvs. ------------------------------------------------------------------------ December 14, 2004 - 15:58 : Dries Some more comments: db_begin_transaction() and db_end_transaction() do not belong in database.inc, but in database.mysql.inc and database.pgsql.inc respectively. The node module calls node_revisionsision_list() which is not defined. (Fxed that on my local copy.) Do db_begin_transaction() and db_end_transaction() deprecate Jeremy's table locking patch? The upgrade path assigns the wrong user ID to each revision. The upgrade path assigns the wrong date to each revision (that or a node's revision page shows the wrong usernames/dates). The coding style needs a bit of work, but we can worry about that later. ------------------------------------------------------------------------ December 15, 2004 - 00:34 : Nick Nassar If you need any help getting those things fixed, just let me know. ------------------------------------------------------------------------ December 15, 2004 - 00:50 : Nick Nassar How this relates to Jeremy's node locking patch: There was lots of discussion, and node locking was decided against because from an end user point of view you never want a node to be locked. He's now advocating for a much simpler patch that warns users if their changes will overwrite someone elses. That patch still has a race condition, which might be fixed using db_begin_transaction(). http://drupal.org/node/6025 ------------------------------------------------------------------------ December 15, 2004 - 05:26 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_0.patch (55.96 KB) Here is an updated patch that tries to address Dries concerns. ------------------------------------------------------------------------ December 15, 2004 - 15:32 : Dries Attachment: http://drupal.org/files/issues/revisions-bug.png (76.06 KB) It didn't fix the aforementioned bugs. See attached screenshot. ------------------------------------------------------------------------ January 7, 2005 - 03:15 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_1.patch (51.77 KB) Ok, here is a new version. Dries and myself worked hart at it, so please have a look. what is still missing - database upgrades for the core modules with an own table - contrib modules need an upgrade too. - do we need nid and vid in both the node and the node_revisions table? - the amount of sql queries means a good stress testing for large databases. ------------------------------------------------------------------------ January 20, 2005 - 04:43 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_2.patch (49.49 KB) Here is an updated patch. We discussed to keep the current title in node module and also in the revisiosn table. This is content duplication but will save many joins as many queries only need the title of a node. Discussion is welcome. ------------------------------------------------------------------------ January 20, 2005 - 06:33 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_3.patch (29.93 KB) I've implemented the aforementioned solution. This makes the patch much smaller. The patch now also removes taxonomy_node_has_term() which wasn't used anywhere. I'd really apprciate if some people could test drive the patch. It will be another huge improvement for 4.6. ------------------------------------------------------------------------ January 20, 2005 - 07:05 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_4.patch (30 KB) Another revision. Steven didn't like my literal $node->vid in queries. ------------------------------------------------------------------------ January 20, 2005 - 08:10 : killes(a)www.drop.org - database upgrades for the core modules with an own table - contrib modules need an upgrade too. - do we need nid and vid in both the node and the node_revisions table? - the amount of sql queries means a good stress testing for large databases. These issues are still open, btw. Especially the first one needs to be tackled. ------------------------------------------------------------------------ January 26, 2005 - 03:11 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_5.patch (51.13 KB) Here is a patch that has the database tables updated for forum, book, and page module. ------------------------------------------------------------------------ January 30, 2005 - 05:55 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_6.patch (49.18 KB) Yet another update to keep it working with head. The patch now also removes the table definitons for the page table. ------------------------------------------------------------------------ January 30, 2005 - 05:57 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_7.patch (55.69 KB) Sorry, that was the old version, this is the right one. ------------------------------------------------------------------------ February 1, 2005 - 02:55 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_8.patch (55.71 KB) Updated once more. ------------------------------------------------------------------------ February 1, 2005 - 03:52 : Dries Anyone to help review/test this? ------------------------------------------------------------------------ February 1, 2005 - 04:22 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_9.patch (49.29 KB) Updated again, the update functions occurred twice. Thanks Bart. ------------------------------------------------------------------------ February 2, 2005 - 07:27 : killes(a)www.drop.org Don't know if the db I am using is corrupted or what. I still do have some didficulties. The latest patch is attached. ------------------------------------------------------------------------ February 2, 2005 - 07:27 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_10.patch (49.67 KB) I am probably slowly going mad ... ------------------------------------------------------------------------ February 2, 2005 - 08:54 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_11.patch (48.95 KB) The update issue still needs investigating. This patch is updated for cvs. ------------------------------------------------------------------------ February 3, 2005 - 03:20 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_12.patch (49.83 KB) Ok, here is a new version. I've solved my troubles with book.module. There are still some issues with forum module. Possibly due to inconsistent database. ------------------------------------------------------------------------ February 3, 2005 - 04:31 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_13.patch (49.83 KB) Turns out the drupal.org database had indeed some quirks. Please run this query in your oldest db and tell me the result: select nid,type from node where type like '%/%'; If you get a non-zero result we might need to add another security update. The patch could use still more testing, though. ------------------------------------------------------------------------ February 3, 2005 - 08:16 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_14.patch (49 KB) Ok, we are getting somewhere. At a first glance the update is working. There is a problem remaining: the revisions tab will be shown whether the node has revisions or not. Not sure we can/need to fix this. People with a drupal.org account can log in at http://killes.drupaldevs.org/revision/ and poke around. Your permissions will be the same as on drupal.org. Feel free to vreak everything but don't forget to file complaints here. (Note: this is only a pruned version of the drupal.org database with all project nodes and nodes with nids > 7000 dropped). ------------------------------------------------------------------------ February 3, 2005 - 11:19 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/revisions_15.patch (52.39 KB) There was some error in node_save and also the patches to the database.inc files got lost... ------------------------------------------------------------------------ February 3, 2005 - 14:07 : robertDouglass Submitting book pages doesn't work on your test site. It puts the entire content of the preview inside the body textarea. I wrote a sentence in the body and the log, and pressing preview put several lines of HTML containing both sentences in the body textarea on the preview page, plus the book page wouldn't submit. -R ------------------------------------------------------------------------ February 3, 2005 - 14:50 : Junyor 0 results here. I started using Drupal with version 4.4, though. ------------------------------------------------------------------------ February 4, 2005 - 06:56 : killes(a)www.drop.org @Junyor: Thanks, that's a good sign. Maybe somebody else has an older db to try. @robertDouglass: The first effect you describe is due to drupaldevs running on PHP 5. I am unsure why the second thing does not work. In node_save() the node object has a nid although there is none in the form. Very strange. I've enabled display of db queries on the testsite. -- View: http://drupal.org/node/7582 Edit: http://drupal.org/project/comments/add/7582

1 0

[drupal-devel] [Fwd: [droppies] Digital communities - Prix Ars Electronica 2005]
by Dries Buytaert 04 Feb '05

04 Feb '05

-------- Original Message -------- Subject: Digital communities - Prix Ars Electronica 2005 Date: Fri, 4 Feb 2005 09:36:35 +0100 From: AEC Communities <communities(a)prixars.aec.at> To: <info(a)drupal.org> Dear Drupal Team, The category "Digital Communities", which met with great interest and participation in 2004, will be awarded again by Prix Ars Electronica in 2005. As you had been participating last year, we would kindly like to invite you and your team to submit your project "http://drupal.org/" - or a new project - in the category "Digital Communities" of this year's Prix Ars Electronica. The Digital Communities category of Prix Ars Electronica encompasses digital community projects as well as developments in the field of social software, mobile communications or wireless networks. For a detailed description of the category and about Prix Ars Electronica in general, please see our website: <http://www.aec.at/en/prix/communities/communities.asp> Prizes One Golden Nica with 10,000 Euro and two Awards of Distinction with 5,000 Euro each will be awarded and up to 12 Honorary Mentions made by the jury. The registration starts January 10, 2005. The deadline for submissions is March 11, 2005. Please use <http://www.aec.at/en/prix/registration/index.asp> for your submission and to obtain further details. If you need any further information or help, please do not hesitate to contact us. Looking forward to your participation! Sincerely yours, > Ingrid Fischer-Schreiber > Prix Ars Electronica 2005 > > AEC Ars Electronica Center Linz > Museumsgesellschaft mbH > Hauptstraße 2 > A-4040 Linz > > Tel. ++43.664.8126230 > Fax ++43.732.7272-674 > communities(a)prixars.aec.at > http://prixars.aec.at > > -- Dries Buytaert :: http://www.buytaert.net/ _______________________________________________ droppies mailing list droppies(a)drupal.org http://lists.drupal.org/listinfo/droppies

1 0

[drupal-devel] [feature] Enclosure Support for Aggregator
by sulleleven 04 Feb '05

04 Feb '05

Project: Drupal Version: 4.5.2 Component: aggregator.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: geeknews Updated by: sulleleven Status: patch antipasto- this doesnt change the aggragator's ability to parse enclosures... which this request is about. I am going to look at aggregator.module and see what needs to be done. sulleleven Previous comments: ------------------------------------------------------------------------ January 31, 2005 - 15:32 : geeknews The aggregator should be able to parse the enclosure information out of RSS 2.0 feeds. It should be implemented to recognize and display the links to enclosures. If you want to 1 up the competition add the code to determine standard file types mp3, wma, ogg, etc and place a download Icon within the aggregated content. I have donated and would be willing to help out more to see something like this implemented. ------------------------------------------------------------------------ February 4, 2005 - 00:21 : antipasto Attachment: http://drupal.org/files/issues/drupal_452_rss20.tar.gz (35.63 KB) Here's a patch for 4.5.2, but this will be implemented way better in 4.6: http://writtorrent.sourceforge.net/2005/02/rss-20-feeds-with-enclosures-for… -- View: http://drupal.org/node/16485 Edit: http://drupal.org/project/comments/add/16485

1 0

[drupal-devel] [bug] Signature "interrupts" typing comments due to existence in text field
by irwin 04 Feb '05

04 Feb '05

Project: Drupal Version: cvs Component: comment.module Category: bug reports Priority: minor Assigned to: Anonymous Reported by: irwin Updated by: irwin Status: patch I realised as I was going to bed last night that the extra query was extraneous. :) As for adding the comment to the comment body, the reason I would want to do that is for the signature to "appear" to be a part of the... well, comment body. That will avoid potential issues with some themes that aren't designed to handle signatures at all - for instance, a theme might put a border around the "body" part of the signature, and if it doesn't explicitly handle the signature, things can look very ugly and strange. But I can see what you mean about Input Filtering. Do you have suggestions on how to improve that? I had one idea, and that was to add the signature as an argument to the theme, but that would require theme modifications fir signatures to be displayed. If this patch is of interest I'll keep working on it and posting updates. irwin Previous comments: ------------------------------------------------------------------------ February 3, 2005 - 23:47 : irwin In the Drupal comments/ signature system, there is a usability problem with the signature. The main problem is that, when adding a comment, the signature appears in the same line as the textarea that you are writing the content of your post. When you begin typing, your new text actually appears AFTER the signature (at least in Konqueror 3.2). This makes it incredibly annoying for users because you have to go to the beginning of the textarea before you can type your data. A corrolary to this problem is that, when quoting (using the quote module), the signature is included by default in the quote, which should not be the default behaviour. It appears that the signature is being added to the actual body text of the comment, as opposed to being retrieved from the user's profile when the page is rendered. -- >From an engineering/design perspective, one possible way to fix this is instead of adding the signature text to the comment, instead retrieve the signature dynamically from the user's profile when the page is rendered. If you do this, not only do you avoid the above problems, but you also improve the flexibility of signatures (for example, changing it once will cause the signature to change in every comment you make). You can also use this design change to give the users a choice of when to display their signature (for example, by using a checkbox on the node that says, "Display your signature with this post"). -- Thank you. ------------------------------------------------------------------------ February 4, 2005 - 00:49 : irwin Attachment: http://drupal.org/files/issues/signature_load_on_render-20050204.patch (1.62 KB) Included: patch. Changes explanation: "theme_comment_form": the code to autoinsert the signature into the textarea is removed. "theme_comment_view": code added to insert signature at the end of the $comment->comment data structure. I encase the comment in [p class="signature"] [/p] (with the correct brackets of course) so that a CSS theme can change the appearance of signatures. Caveat: the sig still appears in the [div class="body"] of the comment theme. Added function _comment_get_signature($uid), which gets a signature, given a user ID. Caveat: this requires an additional query to the "users" table with every user comment. Tested with: - User without signature - User with signature - Anonymous poster - Previewing - Positng - Editing a signature: expected result is that all signatures are changed to reflect the new signature. Please let me know of any problems. ------------------------------------------------------------------------ February 4, 2005 - 00:50 : irwin Reducing severity to "minor" because that's what it is. ------------------------------------------------------------------------ February 4, 2005 - 04:15 : Bart Jansens The extra queries aren't necessary, the queries that are used to retrieve the comments already join the users table, just add u.signature to the select clause there. I'm not sure if adding the signature to the comment body is the best approach, if you just keep it in a different field, themes can decide where to place it. Note that usually admins will want to be able to use a different filter for signatures. Eg, allow bbcode in the comment body, but not in the signature. I am using a similar patch on my own site (although it really needs to be updated), it never made it into core because it is difficult or almost impossible to create an upgrade path. I hope this can be discussed again, or at least made into an option for new sites, i'm surprised there haven't been more complaints about this ;) -- View: http://drupal.org/node/16726 Edit: http://drupal.org/project/comments/add/16726

1 0

[drupal-devel] [bug] QUICKFIX: node titles invalidate XHTML
by Goba 04 Feb '05

04 Feb '05

Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: Goba Reported by: Goba Updated by: Goba Status: patch Attachment: http://drupal.org/files/issues/Drupal-nodetitle-validity-fix.patch (839 bytes) The node titles printed by node_title_list() are not filtered through drupal_specialchars(), so titles, like bead&breakfast break XHTML validity... The attached patch fixes this. Goba -- View: http://drupal.org/node/16753 Edit: http://drupal.org/project/comments/add/16753

1 0

[drupal-devel] [bug] Signature "interrupts" typing comments due to existence in text field
by Bart Jansens 04 Feb '05

04 Feb '05

Project: Drupal Version: cvs Component: comment.module Category: bug reports Priority: minor Assigned to: Anonymous Reported by: irwin Updated by: Bart Jansens Status: patch The extra queries aren't necessary, the queries that are used to retrieve the comments already join the users table, just add u.signature to the select clause there. I'm not sure if adding the signature to the comment body is the best approach, if you just keep it in a different field, themes can decide where to place it. Note that usually admins will want to be able to use a different filter for signatures. Eg, allow bbcode in the comment body, but not in the signature. I am using a similar patch on my own site (although it really needs to be updated), it never made it into core because it is difficult or almost impossible to create an upgrade path. I hope this can be discussed again, or at least made into an option for new sites, i'm surprised there haven't been more complaints about this ;) Bart Jansens Previous comments: ------------------------------------------------------------------------ February 4, 2005 - 05:47 : irwin In the Drupal comments/ signature system, there is a usability problem with the signature. The main problem is that, when adding a comment, the signature appears in the same line as the textarea that you are writing the content of your post. When you begin typing, your new text actually appears AFTER the signature (at least in Konqueror 3.2). This makes it incredibly annoying for users because you have to go to the beginning of the textarea before you can type your data. A corrolary to this problem is that, when quoting (using the quote module), the signature is included by default in the quote, which should not be the default behaviour. It appears that the signature is being added to the actual body text of the comment, as opposed to being retrieved from the user's profile when the page is rendered. -- >From an engineering/design perspective, one possible way to fix this is instead of adding the signature text to the comment, instead retrieve the signature dynamically from the user's profile when the page is rendered. If you do this, not only do you avoid the above problems, but you also improve the flexibility of signatures (for example, changing it once will cause the signature to change in every comment you make). You can also use this design change to give the users a choice of when to display their signature (for example, by using a checkbox on the node that says, "Display your signature with this post"). -- Thank you. ------------------------------------------------------------------------ February 4, 2005 - 06:49 : irwin Attachment: http://drupal.org/files/issues/signature_load_on_render-20050204.patch (1.62 KB) Included: patch. Changes explanation: "theme_comment_form": the code to autoinsert the signature into the textarea is removed. "theme_comment_view": code added to insert signature at the end of the $comment->comment data structure. I encase the comment in [p class="signature"] [/p] (with the correct brackets of course) so that a CSS theme can change the appearance of signatures. Caveat: the sig still appears in the [div class="body"] of the comment theme. Added function _comment_get_signature($uid), which gets a signature, given a user ID. Caveat: this requires an additional query to the "users" table with every user comment. Tested with: - User without signature - User with signature - Anonymous poster - Previewing - Positng - Editing a signature: expected result is that all signatures are changed to reflect the new signature. Please let me know of any problems. ------------------------------------------------------------------------ February 4, 2005 - 06:50 : irwin Reducing severity to "minor" because that's what it is. -- View: http://drupal.org/node/16726 Edit: http://drupal.org/project/comments/add/16726

1 0

[drupal-devel] [feature] http proxy support patch
by jhefmv24 04 Feb '05

04 Feb '05

Project: Drupal Version: 4.4.2 Component: base system Category: feature requests Priority: minor Assigned to: Anonymous Reported by: liquidx Updated by: jhefmv24 Status: patch see this for complete patches: http://drupal.org/node/7881 jhefmv24 Previous comments: ------------------------------------------------------------------------ August 3, 2004 - 11:39 : liquidx Attachment: http://drupal.org/files/issues/drupal-cvs-20040802-proxy.diff (1.96 KB) My drupal site is behind a firewall which doesn't allow outgoing port 80 connections except if they go through an http proxy. normally that doesn't really harm anything, except when i start using XML-RPC or try to get RSS/Atom feed from other blogs. So I've written a quick patch to add http_proxy support in conf.php. I'm not sure whether that is the best place to put it, but if you think people might want a UI to change that, I could do that. But I suspect that proxy settings don't change much (its not like you migrate a drupal web site to different isps everyday :), so conf.php seems like a good choice. Cheers, Alastair Tse ------------------------------------------------------------------------ August 3, 2004 - 11:42 : liquidx Attachment: http://drupal.org/files/issues/drupal-cvs-20040802-proxy-v2.diff (1.96 KB) slight typo in the comment, i never get things right the first time round :( ------------------------------------------------------------------------ August 3, 2004 - 12:13 : Anonymous HOW TO MAKE 1000'S FROM 6$! READ PLEASE! How to afford anything you want, no joke! Read, it cant hurt! READING THIS COULD CHANGE YOUR LIFE! AND RICH! I found this on a bulletin board and decided to try it. A little while back, I was browsing through newsgroups and came across an article similar to this that said you could make thousands of dollars within weeks with only an initial investment of $6.00! So I thought, "Yeah right, this must be a scam", but like most of us, I was curious, so I kept reading. Anyway, it said that you send $1.00 to each of the 6 names and addresses stated in the article. You then place your name and address in the bottom of the list at #6, and post the article in at least 200 newsgroups. (There are thousands) No catch, that was it. So after thinking it over, and talking to a few people first, I thought about trying it. I figured: "what have I got to lose except 6 stamps and $6.00, right?" Then I invested the measly $6.00. Well GUESS WHAT!!... within 7 days, I started getting money in the mail! I was shocked? I figured it would end soon, but the money just kept coming in. In my first week, I made about $25.00. By the end of the second week I had made a total of over $1,000.00! In the third week I had over $10,000.00 and it's still growing. This is now my fourth week and I have made a total of just over $42,000.00 and it's still coming in rapidly. It's certainly worth $6.00, and 6 stamps, I have spent more than that on the lottery!! Let me tell you how this works and most importantly, why it works... Also, make sure you print a copy of this article NOW, so you can get the information off of it as you need it. I promise you that if you follow the directions exactly, that you will start making more money that you thought possible by doing something so easy! Suggestion: Read this entire message carefully! (print it out or download it.) Follow the simple directions and watch the money come in! It's easy. It's legal. And, your investment is only $6.00 (plus postage). IMPORTANT: This is not a rip-off; it is not indecent; it is not illegal; and it is virtually no risk - it really works!!! IMPORTANT2: The $1.00 for each person on the list is for keeping you up to date and for putting you in all our newsgroups. So you will make just as much as we do!!! If all of the following instructions are adhered to, you will receive extraordinary dividends. PLEASE NOTE: Please follow these directions EXACTLY, and $50,000 or more can be yours in 20 to 60 days. This program remains successful because of the honesty and integrity of the participants. Please continue its success by carefully adhering to the instructions. You will now become part of the Mail Order business. In this business your product is not solid and tangible, it's a service. You are in the business of developing Mailing Lists. Many large corporations are happy to pay big bucks for quality lists. However, the money made from the mailing lists is secondary to the income which is made from people like you and me asking to be included in that list. Here are the 4 easy steps to success: STEP 1: Get 6 separate pieces of paper and write the following on each piece of paper "PLEASE PUT ME ON YOUR MAILING LIST." Now get 6 US $1.00 bills and place ONE inside EACH of the 6 pieces of paper so the bill will not be seen through the envelope (to prevent thievery). Next, place one paper in each of the 6 envelopes and seal them. You should now have 6 sealed envelopes, each with a piece of paper stating the above phrase, your name and address, and a $1.00 bill. What you are doing is creating a service. This is absolutely legal? You are requesting a legitimate service and you are paying for it! Like most of us I was a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161) and they confirmed that it is indeed legal! Mail the 6 envelopes to the following addresses: 1.) GLEN RAY CAMPBELL Jr. 919 Virginia Ct. Panama City,Fl 32404,usa 2.)Heather Angel 4244 46th St. San Diego, Ca. 92115 3.) Alexander Dolstra Frederik Hendrik straat 37 3143 LB Maassluis the Netherlands 4.) J. Kirk 2360 Forbes Ave. Santa Clara, CA 95050 5.) N. Hernandez PO Box 712 Crystal Beach, Fl. 34681, usa 6.)D.Herela 849 La Fayette apt.6-D El Paso, TX. 79907, usa STEP 2: Now take the #1 name off the list that you see above, move the other names up (6 becomes 5, 5 becomes 4, etc. ...) and add YOUR name as number 6 on the list. STEP 3: Change anything you need to, but try to keep this article as close to the original as possible. Now, post your amended article to at least 200 newsgroups. (I think there are close to 24,000 groups.) All you need is 200, but remember, the more you post, the more money you make! This is perfectly legal! If you have any doubts, refer to Title 18 Sec. 1302 & 1241 of the Postal lottery laws. Keep a copy of these steps for yourself and, whenever you need money, you can use it again, and again. PLEASE REMEMBER that this program remains successful because of the honesty and integrity of the participants and by their carefully adhering to the directions. Look at it this way, if you are of integrity, the program will continue and the money that so many others have received will come your way, too. NOTE: You may want to retain every name and address sent to you, either on a computer or hard copy and keep the notes people send you. This VERIFIES that you are truly providing a service. (Also, it might be a good idea to wrap the $1 bill in dark paper to reduce the risk of mail theft.) So, as each post is downloaded and the directions carefully followed, six members will be reimbursed for their participation as a List Developer with one dollar each. Your name will move up the list geometrically so that when your name reached the #1 position you will be receiving thousands of dollars in CASH!!! What an opportunity for only $6.00 ($1.00 for each of the first six people listed above). Send it now, add your own name to the list and you're in business! ---DIRECTIONS----FOR HOW TO POST TO NEWSGROUPS------------------ STEP 1: You do not need to re-type letter to your own posting. Simply put your cursor at the beginning of this letter and drag your cursor to the bottom of this document, and select 'copy' from the edit menu. This will copy the entire letter into the computer's memory. STEP 2: Open a blank 'notepad' file and place your cursor at the top of the blank page. From the 'edit' menu select 'PASTE'. This will paste a copy of the letter into notepad so that you can add your name to the bottom of the list and to change the numbers of the list. STEP 3: Save your new notepad file as a '.txt' file. If you want to do your postings in different settings, you'll always have this file to go back to. STEP 4: Use Netscape or Internet Explorer and try search for various newsgroups (on-line forums, message boards, chat sites, discussions). STEP 5: Visit these message boards and post this article as a new message by highlighting the text of this letter and selecting 'PASTE' from the edit menu. Fill in the Subject, this will be the header that everyone sees as they scroll through the list of postings in a particular group, click the post message button. You're done with your first one! Congratulations... That is it! All you have to do is jump to different newsgroups and post away, after you get the hang of it, it will take about 30 seconds for each newsgroup! ** REMEMBER, THE MORE NEWSGROUPS YOU POST IN, THE MORE MONEY YOU WILL MAKE!! BUT YOU HAVE TO POST A MINIMUM OF 200** That is it! You will begin receiving money form around the world within days! You may eventually want to rent a P.O. Box due to the large amount of mail you will receive. If you wish to stay anonymous, you can invent a name to use, as long as the postman will deliver it. **JUST MAKE SURE ALL THE ADDRESSES ARE CORRECT.** Now the WHY part: Out of 200 postings, say I receive only 5 replies (a very low example). So then I made $5.00 with my name at #6 on the letter. Now, each of the 5 persons who just sent me $1.00 make the MINIMUM 200 postings, each with my name at #5 and only 5 persons respond to each of the original 5, this is an additional $25.00 for me. Now those 25 each make 200 MININUM posts with my name at #4 and only 5 replies each. This brings in an additional $125.00. Now, those 125 persons turn around and post the MINIMUM 200 with my name at #3 and receive 5 replies each, I will make an additional $625.00. Ok, now here is the fun part, each of those 625 people post a MINIMUM 200 letters with my name at #2 and they receive 5 replies each. That just made me $3,125.00!!! Those 3,125 persons will all deliver this message to 200 newsgroups with my name at #1 and if still 5 persons per 200 react, I will receive an additional $15,625.00!! With an investment of only $6.00! AMAZING! When your name is no longer on the list, you just take the latest posting in the newsgroups, and send out another $6.00 to names on the list, putting your name at number 6 again. And start posting again. The thing to remeber is: do you realize that thousands of people all over the world are joining the internet and reading these articles everyday? JUST LIKE YOU are now!! So, can you afford $6.00 and see if it really works?? I think so... People have said, "what if the plan is played out and no one sends you the money? So what! What are the chances of that Happening when there are tons of new honest users and new honest people who are joining the internet and newsgroups everyday and are willing to give it a try? Anyway, it is only $6.00 for a chance at thousands. Estimates are at 20,000 to 50,000 new users, every day, with thousands of those joining the actual internet. Remember, play FAIRLY and HONESTLY and this will really work. You wouldn't want someone to cheat you the same way you may be cheating! HOW TO MAKE 1000'S FROM 6$! READ PLEASE! ------------------------------------------------------------------------ August 4, 2004 - 16:54 : TDobes This seems like a possibly useful patch for those stuck in an environment where they must use a proxy. (intranets?) I have no proxy set up at the moment with which to test, but +1 to the functionality. ------------------------------------------------------------------------ December 3, 2004 - 19:47 : Steven If we use HTTP/1.1 (using the Host header), I think we can send exactly the same request to both a proxy and the real server. It might make the code a bit cleaner. ------------------------------------------------------------------------ January 26, 2005 - 12:01 : Steve Stock That's correct, HTTP/1.1 explicitly requires servers to accept an absolute URI in the request-line (which of course proxies already require). See http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1.2 for details. Note: a host header is still required. The drawback is all HTTP/1.1 applications must be able to accept the chunked transfer coding, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4 (third paragraph above section 4.5). I don't know if Drupal supports this (doesn't look like it). While not as nice, for now it appears simpler to implement a proxy along the lines of this patch. My only suggestion would be to add a proxy section to the settings page instead of hardcoding the proxy host/port. ------------------------------------------------------------------------ February 4, 2005 - 12:23 : jhefmv24 Attachment: http://drupal.org/files/issues/common.inc_3.patch (1.37 KB) +1 on having a facility to modify proxy settings... here's a patch of /includes/common.inc for drupal-4.4.2 version ------------------------------------------------------------------------ February 4, 2005 - 16:18 : Bèr Kessels Hi, you use variable_get('proxy_name', '') , but that is not defined anywhere. I would plead against another config option, or conf.php options. I am no proxy guru, so the following suggestion might be impossible: * add the proxy port to the $base_url and try to re-arrange your logic in such a way ,that it will detect the port from the $base_url. If found the variabale will be set, and userd. * or use the default system, but add some logic to the fsockopen, that, if it fails, it will try again, with proxy, if that was sucessfull, set the variable. Bèr -- View: http://drupal.org/node/9706 Edit: http://drupal.org/project/comments/add/9706

1 0