February 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Content type options editing broken
by Goba 10 Feb '05

10 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-fix-node-options-settings.patch (1.38 KB) The node options settings implemented through the nodeapi 'settings' op is incorrectly invoked. Only the type is passed on as a string, while the nodeapi hook expects a node object. Therefore the type property of the object is not possible to use in the hook, and it is impossible to set and content type options. One way to fix it is to use $node as a typename inside the nodeapi settings op implementation, and the other way is to really pass an object. A patch for the second option is attached. Goba -- View: http://drupal.org/node/16960 Edit: http://drupal.org/project/comments/add/16960

3 5

[drupal-devel] [feature] Add support for generating an RSS 0.92 feed of news aggregator items
by Boris Mann 10 Feb '05

10 Feb '05

Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: blake7 Updated by: Boris Mann Status: patch This patch is not about "feed unification", it adds RSS feeds for category bundles...which have been asked about (and coded for, here in this patch) since 4.4. Boris Mann Previous comments: ------------------------------------------------------------------------ July 8, 2004 - 20:11 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_0.patch (2.96 KB) The attached patch adds support for generating an RSS 0.92 feed of the default news aggregator page (the output of aggregator_page_last()). This allows re-use of the Drupal aggregator in other RSS readers like Trillian. The patch consists of the aggregator_page_rss() function which builds the XML output needed. It uses the existing RSS building functions already present to construct the feed. Note the comment about how many items are in the feed. In Drupal 4.4.x, there was a variable "aggregator_page_limit" which represented how many items were returned for both the HTML and RSS versions. It defaulted to 75 items. In Drupal CVS, all the HTML output is now paged through a hard-coded limit of 20 items per page. A limit of 20 seems small for the RSS feed, so I reverted to the old limit of 75. Would it be better to add a new variable like "aggregator_rss_limit"? Also, there are 2 places that the callback to aggregator_page_rss are installed. One is in _aggregator_page_list right before the pager output and shows up as the XML icon (like how the OPML feeds are linked now). The other is in aggregator_menu where I try and install a menu itme called "RSS feed". For some reason, the menu itme is not displaying itself though I believe I am inserting it properly. Feel free to contact me if there are any questions. Thanks! ------------------------------------------------------------------------ July 9, 2004 - 09:29 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_1.patch (2.54 KB) Fixed the navigation menu problems mentioned above. Please consider this patch instead of the first one. ------------------------------------------------------------------------ July 9, 2004 - 10:09 : drumm When this functionality is added it should be able to generate feeds for each aggregator category as well. ------------------------------------------------------------------------ July 9, 2004 - 17:22 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_2.patch (3.25 KB) Done. The attached patch supports RSS feeds of each aggregator category through the XML icon at the bottom exactly like the main aggregator page. ------------------------------------------------------------------------ July 10, 2004 - 04:01 : Dries 1. $base_url . "/aggregator" . $url is incorrect. All URLs must be constructed using url() as it is aware of clean URLs and path aliasing. 2. Emitting 75 RSS items is quite much (uncommon) and can easily turn into a bandwidth bottleneck. Can we add one global setting that controls how many entries our feed should have (not just the newly introduced feeds)? To 'export' your content in case you wish to migrate to another tool, a special value 'all' (say '1000000') might be handy. ------------------------------------------------------------------------ September 17, 2004 - 00:19 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_3.patch (4.47 KB) 1. Using url() now. 2. Added the presistent variable aggregator_rss_limit which controls how many RSS items are generated. A form_select edit control to control the new variable, with all defined as 1000000, was added to the configure tab. I am not sure what you mean by "our feeds" versus "newly introduced feeds" in your comment. Also, even though the code-freeze has taken place, do you think it would be possible to get this into Drupal 4.5? The code change is very minimal and I believe the ability to share aggregated feeds is a great feature. ------------------------------------------------------------------------ September 17, 2004 - 10:07 : Boris Mann +1 I actually assumed (there was much discussion?) that the re-exporting of aggregator items on a per-bundle basis was going to be enabled for 4.5. Let's get this in before the code freeze -- this would be a major feature announcement for 4.5, and could perform the basis for other great functionality for 4.6 (e.g. per category OPML file generation). ------------------------------------------------------------------------ October 22, 2004 - 10:20 : blake7 Now that 4.5 has released. Can this go into CVS/HEAD? Is there any other changes to the patch that need to be made by me to make that happen? Thanks. ------------------------------------------------------------------------ October 23, 2004 - 10:05 : Dries I'll look at it again. Does the patch add XML-icons or how do people find out about the RSS feeds? Can't we make the URLs a bit more intuitive? For example by making it so that you merely have to append '/rss.xml' to the aggregator module's URLs: foo.com/aggregator/rss.xml foo.com/aggregator/categories/1/rss.xml It is certainly not a requirement, just a thought that might be worth considering. ------------------------------------------------------------------------ October 23, 2004 - 10:15 : Dries I'll look at it again. Does the patch add XML-icons or how do people find out about the RSS feeds? Can't we make the URLs a bit more intuitive? For example by making it so that you merely have to append '/rss.xml' to the aggregator module's URLs: foo.com/aggregator/rss.xml foo.com/aggregator/categories/1/rss.xml It is certainly not a requirement, just a thought that might be worth considering. ------------------------------------------------------------------------ October 25, 2004 - 02:50 : Bèr Kessels cross linking to a [feature] that talks about such a unified rss link: http://drupal.org/node/11937 ------------------------------------------------------------------------ February 9, 2005 - 12:17 : sethcohn Bump. Neat feature, would be nice for 4.6 What's the progress on making it happen? ------------------------------------------------------------------------ February 9, 2005 - 12:43 : Boris Mann Here's another bump to this. I would say since it missed 4.5 (and was ready at the time) we get this in to 4.6. Should mesh nicely with walkah's RSS updates. Dries: there is an XML icon at the bottom of each category page, plus the HTML header can include an alternate link to the feed. I vote against any sort of "rss.xml", people can alias if they wish. (ideally we could get per-category OPML links as well, but I'll leave that for another feature request) ------------------------------------------------------------------------ February 10, 2005 - 06:58 : Bèr Kessels A request for unification of feeds [1] is waiting in the queue already. [1] http://drupal.org/node/11937 -- View: http://drupal.org/node/9167 Edit: http://drupal.org/project/comments/add/9167

1 0

[drupal-devel] [feature] Add support for generating an RSS 0.92 feed of news aggregator items
by Bèr Kessels 10 Feb '05

10 Feb '05

Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: blake7 Updated by: Bèr Kessels Status: patch A request for unification of feeds [1] is waiting in the queue already. [1] http://drupal.org/node/11937 Bèr Kessels Previous comments: ------------------------------------------------------------------------ July 9, 2004 - 05:11 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_0.patch (2.96 KB) The attached patch adds support for generating an RSS 0.92 feed of the default news aggregator page (the output of aggregator_page_last()). This allows re-use of the Drupal aggregator in other RSS readers like Trillian. The patch consists of the aggregator_page_rss() function which builds the XML output needed. It uses the existing RSS building functions already present to construct the feed. Note the comment about how many items are in the feed. In Drupal 4.4.x, there was a variable "aggregator_page_limit" which represented how many items were returned for both the HTML and RSS versions. It defaulted to 75 items. In Drupal CVS, all the HTML output is now paged through a hard-coded limit of 20 items per page. A limit of 20 seems small for the RSS feed, so I reverted to the old limit of 75. Would it be better to add a new variable like "aggregator_rss_limit"? Also, there are 2 places that the callback to aggregator_page_rss are installed. One is in _aggregator_page_list right before the pager output and shows up as the XML icon (like how the OPML feeds are linked now). The other is in aggregator_menu where I try and install a menu itme called "RSS feed". For some reason, the menu itme is not displaying itself though I believe I am inserting it properly. Feel free to contact me if there are any questions. Thanks! ------------------------------------------------------------------------ July 9, 2004 - 18:29 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_1.patch (2.54 KB) Fixed the navigation menu problems mentioned above. Please consider this patch instead of the first one. ------------------------------------------------------------------------ July 9, 2004 - 19:09 : drumm When this functionality is added it should be able to generate feeds for each aggregator category as well. ------------------------------------------------------------------------ July 10, 2004 - 02:22 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_2.patch (3.25 KB) Done. The attached patch supports RSS feeds of each aggregator category through the XML icon at the bottom exactly like the main aggregator page. ------------------------------------------------------------------------ July 10, 2004 - 13:01 : Dries 1. $base_url . "/aggregator" . $url is incorrect. All URLs must be constructed using url() as it is aware of clean URLs and path aliasing. 2. Emitting 75 RSS items is quite much (uncommon) and can easily turn into a bandwidth bottleneck. Can we add one global setting that controls how many entries our feed should have (not just the newly introduced feeds)? To 'export' your content in case you wish to migrate to another tool, a special value 'all' (say '1000000') might be handy. ------------------------------------------------------------------------ September 17, 2004 - 09:19 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_3.patch (4.47 KB) 1. Using url() now. 2. Added the presistent variable aggregator_rss_limit which controls how many RSS items are generated. A form_select edit control to control the new variable, with all defined as 1000000, was added to the configure tab. I am not sure what you mean by "our feeds" versus "newly introduced feeds" in your comment. Also, even though the code-freeze has taken place, do you think it would be possible to get this into Drupal 4.5? The code change is very minimal and I believe the ability to share aggregated feeds is a great feature. ------------------------------------------------------------------------ September 17, 2004 - 19:07 : Boris Mann +1 I actually assumed (there was much discussion?) that the re-exporting of aggregator items on a per-bundle basis was going to be enabled for 4.5. Let's get this in before the code freeze -- this would be a major feature announcement for 4.5, and could perform the basis for other great functionality for 4.6 (e.g. per category OPML file generation). ------------------------------------------------------------------------ October 22, 2004 - 19:20 : blake7 Now that 4.5 has released. Can this go into CVS/HEAD? Is there any other changes to the patch that need to be made by me to make that happen? Thanks. ------------------------------------------------------------------------ October 23, 2004 - 19:05 : Dries I'll look at it again. Does the patch add XML-icons or how do people find out about the RSS feeds? Can't we make the URLs a bit more intuitive? For example by making it so that you merely have to append '/rss.xml' to the aggregator module's URLs: foo.com/aggregator/rss.xml foo.com/aggregator/categories/1/rss.xml It is certainly not a requirement, just a thought that might be worth considering. ------------------------------------------------------------------------ October 23, 2004 - 19:15 : Dries I'll look at it again. Does the patch add XML-icons or how do people find out about the RSS feeds? Can't we make the URLs a bit more intuitive? For example by making it so that you merely have to append '/rss.xml' to the aggregator module's URLs: foo.com/aggregator/rss.xml foo.com/aggregator/categories/1/rss.xml It is certainly not a requirement, just a thought that might be worth considering. ------------------------------------------------------------------------ October 25, 2004 - 11:50 : Bèr Kessels cross linking to a [feature] that talks about such a unified rss link: http://drupal.org/node/11937 ------------------------------------------------------------------------ February 9, 2005 - 21:17 : sethcohn Bump. Neat feature, would be nice for 4.6 What's the progress on making it happen? ------------------------------------------------------------------------ February 9, 2005 - 21:43 : Boris Mann Here's another bump to this. I would say since it missed 4.5 (and was ready at the time) we get this in to 4.6. Should mesh nicely with walkah's RSS updates. Dries: there is an XML icon at the bottom of each category page, plus the HTML header can include an alternate link to the feed. I vote against any sort of "rss.xml", people can alias if they wish. (ideally we could get per-category OPML links as well, but I'll leave that for another feature request) -- View: http://drupal.org/node/9167 Edit: http://drupal.org/project/comments/add/9167

1 0

[drupal-devel] [feature] New options for forum block
by kbahey 10 Feb '05

10 Feb '05

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: kbahey Reported by: kbahey Updated by: kbahey Status: patch Attachment: http://drupal.org/files/issues/forum.module-block.patch (2.72 KB) I have implemented a patch that adds two new features for the forum module block. The options provide more granularity for the forum block, when the admin can select to show only active topics, or new topics, or both. Patch is attached. kbahey -- View: http://drupal.org/node/16829 Edit: http://drupal.org/project/comments/add/16829

9 17

[drupal-devel] Should we make project issue status more nuanced?
by Nedjo Rogers 10 Feb '05

10 Feb '05

Following up on recent discussions on drupal decision-making and structure (thanks for the many comments, particularly Steven's recent succinct summary, http://drupal.org/node/15916#comment-26377) I'd like to look at some practical improvements to the system we use for evaluating patches, see my reply to Steven's comment at http://drupal.org/node/15916#comment-26627. I know I could suggest this as a patch on the project module, but I'd like to start with a more general testing of the waters. And, if your eyes are glazing over as you mutter "not him again with his structure babble", please bear with me, I think we might be on to something. The basic issue is that too much is put on the single status, "patch". To see the problem in action, we only have to do a search on Drupal project issues with status=patch. I currently get a total of 124 matches, some ranging up to 33 weeks old. I'm not suggesting the CVS review team is doing anything but excellent work. I know that for my part I can't properly keep up even with the issues for the modules I maintain. I have nothing but appreciation for the work Dries, Steven, and Kjartan do. But they're not able on their own to work through everything. When I go through the outstanding patches, I find quite a few that look (to my not wholly qualified eye) ready to apply--that is, they received discussion, support was evinced, issues raised were to all appearances addressed. Some proposals were very small, but useful. Often the only obvious missing factor is that the patch is now outdated, having sat for so long. Others don't meet these criteria (e.g., lack demonstrated support). What happens currently is that an issue jumps straight from "patch" to "applied"--that is, the status change comes *after* the decision-maker (most often, Dries) has made the change. What's missing is a way for Drupal contributors - more specifically, the subset of developers who are qualified to do so - to pre-filter the patches--basically, to put them in a queue for approval, indicating that, in their view, the patch meets our approval criteria (set out in the Handbook at http://drupal.org/node/10262) Concretely, I'm thinking of an additional status category after "patch": * "reviewed" or "tentatively approved" This would be set when a qualified Drupal member (e.g., a maintainer, or other recognized core contributor) judged the patch meets our criteria. To help even further to increase the community role in decision-making (and thereby relieve the pressure or bottleneck on the CVS review team), we could also consider a time factor. I'm thinking that, when a given amount of time has passed after a patch was deemed "tentatively approved" and no further issues have been raised, the patch would (likely, automatically) move to a second additional category: * "pending application" providing a further indication of readiness. Of course, the actual decision would remain with the CVS review team, who could still raise issues (downgrade the status, deny the proposal, etc.). As an additional step, we could create a new drupal.org role, and limit the ability to set these new status categories to users in this role (i.e., recognized core contributors/developers). Thus we could make sure this judgement was made by qualified members (and would be roughly equivalent to what I think we do e.g. for documentation--a role with permissions to edit the Handbook). What to people think of these suggestions? Would they help improve our code review system? Thanks, Nedjo Rogers

7 9

[drupal-devel] [bug] "TYPES" is not a legal field name table "BLOCKS"
by andremolnar 09 Feb '05

09 Feb '05

Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: Philippe Updated by: andremolnar Status: patch I remembered seeing it here: http://drupal.org/node/2497 If this is incorrect, then the documentation needs to be changed. But all in all, nodes isn't a bad idea - I can submit a patch along with the upgrade path if 'types' is indeed a reserved word in either mySQL or pgSQL. andre andremolnar Previous comments: ------------------------------------------------------------------------ February 5, 2005 - 13:31 : Philippe There was a "TYPES" field added to the BLOCKS table. MySQL does not like this; "types" is considered a reserved word. (MySQL-server-4.1.0-0) The field name needs to be changed to something else. ------------------------------------------------------------------------ February 5, 2005 - 13:37 : Philippe Attachment: http://drupal.org/files/issues/types.diff (3.51 KB) here's a patch ------------------------------------------------------------------------ February 9, 2005 - 21:35 : andremolnar Changing Status to patch. I guess we didn't catch this - the field wasn't orginally called types. Good eye. andre ------------------------------------------------------------------------ February 9, 2005 - 21:39 : Dries I suggest we name this field 'nodes'. Also, we'll need an upgrade path for those who are running CVS HEAD. ------------------------------------------------------------------------ February 9, 2005 - 21:54 : JonBob I'm a bit confused by this. The word "types" doesn't show up here: http://dev.mysql.com/doc/mysql/en/reserved-words.html -- View: http://drupal.org/node/16817 Edit: http://drupal.org/project/comments/add/16817

1 0

[drupal-devel] [bug] "TYPES" is not a legal field name table "BLOCKS"
by JonBob 09 Feb '05

09 Feb '05

Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: Philippe Updated by: JonBob Status: patch I'm a bit confused by this. The word "types" doesn't show up here: http://dev.mysql.com/doc/mysql/en/reserved-words.html JonBob Previous comments: ------------------------------------------------------------------------ February 5, 2005 - 08:31 : Philippe There was a "TYPES" field added to the BLOCKS table. MySQL does not like this; "types" is considered a reserved word. (MySQL-server-4.1.0-0) The field name needs to be changed to something else. ------------------------------------------------------------------------ February 5, 2005 - 08:37 : Philippe Attachment: http://drupal.org/files/issues/types.diff (3.51 KB) here's a patch ------------------------------------------------------------------------ February 9, 2005 - 16:35 : andremolnar Changing Status to patch. I guess we didn't catch this - the field wasn't orginally called types. Good eye. andre ------------------------------------------------------------------------ February 9, 2005 - 16:39 : Dries I suggest we name this field 'nodes'. Also, we'll need an upgrade path for those who are running CVS HEAD. -- View: http://drupal.org/node/16817 Edit: http://drupal.org/project/comments/add/16817

1 0

[drupal-devel] [bug] "TYPES" is not a legal field name table "BLOCKS"
by Dries 09 Feb '05

09 Feb '05

Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: Philippe Updated by: Dries Status: patch I suggest we name this field 'nodes'. Also, we'll need an upgrade path for those who are running CVS HEAD. Dries Previous comments: ------------------------------------------------------------------------ February 5, 2005 - 15:31 : Philippe There was a "TYPES" field added to the BLOCKS table. MySQL does not like this; "types" is considered a reserved word. (MySQL-server-4.1.0-0) The field name needs to be changed to something else. ------------------------------------------------------------------------ February 5, 2005 - 15:37 : Philippe Attachment: http://drupal.org/files/issues/types.diff (3.51 KB) here's a patch ------------------------------------------------------------------------ February 9, 2005 - 23:35 : andremolnar Changing Status to patch. I guess we didn't catch this - the field wasn't orginally called types. Good eye. andre -- View: http://drupal.org/node/16817 Edit: http://drupal.org/project/comments/add/16817

1 0

[drupal-devel] [bug] "TYPES" is not a legal field name table "BLOCKS"
by andremolnar 09 Feb '05

09 Feb '05

Project: Drupal Version: cvs Component: block.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: Philippe Updated by: andremolnar -Status: active +Status: patch Changing Status to patch. I guess we didn't catch this - the field wasn't orginally called types. Good eye. andre andremolnar Previous comments: ------------------------------------------------------------------------ February 5, 2005 - 13:31 : Philippe There was a "TYPES" field added to the BLOCKS table. MySQL does not like this; "types" is considered a reserved word. (MySQL-server-4.1.0-0) The field name needs to be changed to something else. ------------------------------------------------------------------------ February 5, 2005 - 13:37 : Philippe Attachment: http://drupal.org/files/issues/types.diff (3.51 KB) here's a patch -- View: http://drupal.org/node/16817 Edit: http://drupal.org/project/comments/add/16817

1 0

[drupal-devel] settings inconsistencies
by Gabor Hojtsy 09 Feb '05

09 Feb '05

Hi, I have just seen while reviewing my Drupal HEAD update diff, that the profile admin pages have been moved from the user admin area to the general module admin area. What is the rationale behind this? Content settings are under the content menu item, comments similarly. Why are profiles moved to the general module admin? Goba

10 31