- Development - lists.drupal.org

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Morbus Iff 31 Aug '05

31 Aug '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch (code needs review) In testing with a few people in #drupal, we've discovered a much bigger problem, which affects this rewritten module as well as the current core archive.module. In a nutshell, the node.created time is stored with time(). PHP's time() bases itself on the server time, NOT on GMT. Thus, for archive.module to work correctly, it must ALWAYS use mktime (relative to server time) and never consider the $user->timezone (relative to GMT). For archive.module, this would cause dates to always be considered via server time, which isn't good, but is better than the craziness going on now. Alternatively, we could try to convert server time to GMT first, and then work with that. The proper solution is to fix node.module to use gmmktime without any arguments for node.created, then have an update path that modifies all node .created and .modified values to GMT, not server time. Morbus Iff Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff Might as well start getting a review of it so I can fix 'em as they come in. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:56:49 +0000 : Tobias Maier cant you provide a patch file? thanks for your work ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:04:01 +0000 : Morbus Iff The codemonkeyx version is a complete rewrite of the core archive.module. If I were to create a patch file against core, every line would be deleted, and every line would be new. Once I finish my revisions to codemonkey's version, I'll post the final version here, as well as a patch against his current CVS. ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:09:13 +0000 : Tobias Maier ok, thanks again :D ------------------------------------------------------------------------ Mon, 29 Aug 2005 13:41:43 +0000 : Junyor +1 for this change. The archive.module in core is dead. ------------------------------------------------------------------------ Mon, 29 Aug 2005 16:14:30 +0000 : adrian What is the progress on this morbus ? ------------------------------------------------------------------------ Mon, 29 Aug 2005 16:29:13 +0000 : Morbus Iff Adrian - I'll be attaching a new version either later today or tomorrow, with a CHANGELOG. I'll also be running a live version of it over on NHPR.org for people to play with. The three major things I'm worried about right now are a) doxygen, b) variable/function naming, c) GMT considerations. After those, I'll be exploring a patch for my own needs: the ability to get archives for particular term. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:53:34 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive.module (9.93 KB) Here's the latest, with the following changelog: * reordered some routines to be a little more workflowish. * renamed archive_buildQuery to archive_build_query. * general whitespace and formatting cleanup. * HEADish update: returning $output, not page templating it. * removed the reference of &$ad in archive_build_query. * test for the existence of arg(#)'s before validating them. * archive_validSomething changed to archive_valid_something. * removed unused vars: cur_date, cur_date_end. * renamed archive_buildURL to archive_build_url. * removed the HTML whitespace from the theming. * twiddled a lot of quotes and apostraphes. * removed 'future' CSS class. ill-defined. * reordered/renamed the CSS classes. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:54:08 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_29676_archive_css.patch (1.56 KB) And the drupal.css patch. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:56:29 +0000 : Morbus Iff This version of the module is currently running live at http://www.nhpr.org/archive/. ------------------------------------------------------------------------ Mon, 29 Aug 2005 19:59:57 +0000 : Tobias Maier if i click for example on 2003 it would be good if this would go to january or december and marks them that this one will be shown now as you can see it if you click on january 2003. it has to select * on the first: the first month of writing * on the last: the last month of writing * on every else: january I hope you can understand what I mean... greets tobias ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:17:40 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive_0.module (11.28 KB) Alright. I've attached another new version that adds a new feature that wasn't part of the original codemonkeyx CVS, but was chatted about on the devel list back in April. If this particular feature has bad code or needs heavy refactoring, certainly consider ONLY the version in comment #9 (and the matching drupal.css patch in #10). This new version supports dated archives based on taxonomy tids. It was a quick addition which NHPR.org needed (for the date nav; the normal tid archive pager wasn't strong enough for our needs). Since it was a quick addition, it supports only ONE tid at a time - the 'and/or' syntax for the taxonomy.module was not brought over. If that syntax was desired, it'd make more sense to create some sort of API for archive.module so that other nodes can take advantage of the dated nav in their normal pages (like node types, users, forums, etc.) The added code supports term matches at any granularity: # all node types that match tid 15000 ('The Front Porch') http://www.nhpr.org/archive/term/15000 # all 2005 node types that match tid 20 ('Health') http://www.nhpr.org/archive/2005/term/20 # all March, 2003 node types that match tid 9 ('Education') http://www.nhpr.org/archive/2003/3/term/9 # all July 11, 2003 node types that match tid 49 ('Economy') http://morbus.totalnetnh.net/nhpr/archive/2002/7/11/term/49 ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:27:26 +0000 : Tobias Maier what does this mean? "Story Archives of 'archives' " on http://www.nhpr.org/archive/term/15000 should this maybe named? "Archive of 'The Front Porch'" if I go to http://www.nhpr.org/archive/term/20 I can only read "archives"... why is there a difference? - I never tested this module on my test site, because I'm not at home - ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:29:34 +0000 : Morbus Iff Tobias: that wouldn't be possible, at least not accurately. The new archive.module supports browsing by year, month, and day, as you know. archive/2005 loads up all the data from a particular year and starts creating a pager out of it. Consider if you have 3 posts in December, and 15 posts in November. It wouldn't be "right" to highlight December because the pager display for the entire year would also include some of November's entries (since 3 is less than the pager increment). Likewise, if we ONLY showed the items from December, then we wouldn't have a "pager by year" feature, only a "pager by month (defaulting to December when none is selected)" feature. ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:30:41 +0000 : Morbus Iff Tobias: regarding #14, that's an artifact of the templates that I'm using for NHPR, and has nothing to do with archive.module itself (in fact, once the anonymous cache expires, you'll see that little oopsie go away). ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:31:47 +0000 : Tobias Maier I can see your right :) I hope it comes in HEAD before tomorrow :D ------------------------------------------------------------------------ Tue, 30 Aug 2005 00:20:12 +0000 : dtan I apologize if this is already a known issue. http://www.nhpr.org/archive/2005/9 does not create a link for september 1st, even though there are 2 nodes listed (http://www.nhpr.org/archive/2005/9/1) ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:11:21 +0000 : Morbus Iff dtan: I'm pretty sure I know what this is - I'll address it either later today or tomorrow. ------------------------------------------------------------------------ Tue, 30 Aug 2005 20:49:58 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive_1.module (11.53 KB) Alright, I've attached a new archive.module - this is the version WITH term filtering enabled. I can make one without terms if necessary - otherwise, I'll just work from this one for now. This version fixes the bug that dtan saw, as a well as a bunch of other off-by-one errors. Of primary importance, however, is that all mktime's that mattered have been switched to gmmktime, which was one of the oft-reported Issues with the old archive.module. I want to eyeball them all again and make sure they're right though. The URLs from #13 are still operational and the CSS from #10 is still required.

1 0

[drupal-devel] [task] Collapsible settings for all settings pages?
by chx 30 Aug '05

30 Aug '05

Issue status update for http://drupal.org/node/30038 Post a follow up: http://drupal.org/project/comments/add/30038 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: chx Status: patch (code needs review) -1 and +1 at the same time. +1 but only after the forms API is in -- it'd be better if we won't break the fastly evolving patch. chx Previous comments: ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:37:22 +0000 : m3avrck Is there a reason collapsible fieldsets is used *only* on the main settings page? What about the users setting page? That is really long and would benefit. And the uploads setting page, as you add more roles, that page can get really long too. I think we should add this feature to all standard Drupal settings pages that are long like the settings page... it really helps and would make things look more consistent, instead of "why the heck is this on one page and not them all?". Need to get this into the next release as well to be consistent with the approach of this new feature. ------------------------------------------------------------------------ Tue, 30 Aug 2005 20:38:54 +0000 : m3avrck Attachment: http://drupal.org/files/issues/modules_0.patch (9.17 KB) I've gone through all of the settings pages for the included default Drupal modules and have applied the collapsible form fix. This really does make a *huge* difference... it makes the Settings interface more consistent and greatly improves readability. Let's get this one in! :) ------------------------------------------------------------------------ Tue, 30 Aug 2005 21:32:11 +0000 : Souvent22 Installed, and used the patched. Worked great. Much needed. :). +1

1 0

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Morbus Iff 30 Aug '05

30 Aug '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch (code needs review) Attachment: http://drupal.org/files/issues/archive_0.module (11.28 KB) Alright. I've attached another new version that adds a new feature that wasn't part of the original codemonkeyx CVS, but was chatted about on the devel list back in April. If this particular feature has bad code or needs heavy refactoring, certainly consider ONLY the version in comment #9 (and the matching drupal.css patch in #10). This new version supports dated archives based on taxonomy tids. It was a quick addition which NHPR.org needed (for the date nav; the normal tid archive pager wasn't strong enough for our needs). Since it was a quick addition, it supports only ONE tid at a time - the 'and/or' syntax for the taxonomy.module was not brought over. If that syntax was desired, it'd make more sense to create some sort of API for archive.module so that other nodes can take advantage of the dated nav in their normal pages (like node types, users, forums, etc.) The added code supports term matches at any granularity: # all node types that match tid 15000 ('The Front Porch') http://www.nhpr.org/archive/term/15000 # all 2005 node types that match tid 20 ('Health') http://www.nhpr.org/archive/2005/term/20 # all March, 2003 node types that match tid 9 ('Education') http://www.nhpr.org/archive/2003/3/term/9 # all July 11, 2003 node types that match tid 49 ('Economy') http://morbus.totalnetnh.net/nhpr/archive/2002/7/11/term/49 Morbus Iff Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff Might as well start getting a review of it so I can fix 'em as they come in. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:56:49 +0000 : Tobias Maier cant you provide a patch file? thanks for your work ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:04:01 +0000 : Morbus Iff The codemonkeyx version is a complete rewrite of the core archive.module. If I were to create a patch file against core, every line would be deleted, and every line would be new. Once I finish my revisions to codemonkey's version, I'll post the final version here, as well as a patch against his current CVS. ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:09:13 +0000 : Tobias Maier ok, thanks again :D ------------------------------------------------------------------------ Mon, 29 Aug 2005 13:41:43 +0000 : Junyor +1 for this change. The archive.module in core is dead. ------------------------------------------------------------------------ Mon, 29 Aug 2005 16:14:30 +0000 : adrian What is the progress on this morbus ? ------------------------------------------------------------------------ Mon, 29 Aug 2005 16:29:13 +0000 : Morbus Iff Adrian - I'll be attaching a new version either later today or tomorrow, with a CHANGELOG. I'll also be running a live version of it over on NHPR.org for people to play with. The three major things I'm worried about right now are a) doxygen, b) variable/function naming, c) GMT considerations. After those, I'll be exploring a patch for my own needs: the ability to get archives for particular term. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:53:34 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive.module (9.93 KB) Here's the latest, with the following changelog: * reordered some routines to be a little more workflowish. * renamed archive_buildQuery to archive_build_query. * general whitespace and formatting cleanup. * HEADish update: returning $output, not page templating it. * removed the reference of &$ad in archive_build_query. * test for the existence of arg(#)'s before validating them. * archive_validSomething changed to archive_valid_something. * removed unused vars: cur_date, cur_date_end. * renamed archive_buildURL to archive_build_url. * removed the HTML whitespace from the theming. * twiddled a lot of quotes and apostraphes. * removed 'future' CSS class. ill-defined. * reordered/renamed the CSS classes. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:54:08 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_29676_archive_css.patch (1.56 KB) And the drupal.css patch. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:56:29 +0000 : Morbus Iff This version of the module is currently running live at http://www.nhpr.org/archive/. ------------------------------------------------------------------------ Mon, 29 Aug 2005 19:59:57 +0000 : Tobias Maier if i click for example on 2003 it would be good if this would go to january or december and marks them that this one will be shown now as you can see it if you click on january 2003. it has to select * on the first: the first month of writing * on the last: the last month of writing * on every else: january I hope you can understand what I mean... greets tobias

2 2

[drupal-devel] [task] Collapsible settings for all settings pages?
by Souvent22 30 Aug '05

30 Aug '05

Issue status update for http://drupal.org/node/30038 Post a follow up: http://drupal.org/project/comments/add/30038 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: Souvent22 Status: patch (code needs review) Installed, and used the patched. Worked great. Much needed. :). +1 Souvent22 Previous comments: ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:37:22 +0000 : m3avrck Is there a reason collapsible fieldsets is used *only* on the main settings page? What about the users setting page? That is really long and would benefit. And the uploads setting page, as you add more roles, that page can get really long too. I think we should add this feature to all standard Drupal settings pages that are long like the settings page... it really helps and would make things look more consistent, instead of "why the heck is this on one page and not them all?". Need to get this into the next release as well to be consistent with the approach of this new feature. ------------------------------------------------------------------------ Tue, 30 Aug 2005 20:38:54 +0000 : m3avrck Attachment: http://drupal.org/files/issues/modules_0.patch (9.17 KB) I've gone through all of the settings pages for the included default Drupal modules and have applied the collapsible form fix. This really does make a *huge* difference... it makes the Settings interface more consistent and greatly improves readability. Let's get this one in! :)

1 0

[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Morbus Iff 30 Aug '05

30 Aug '05

Issue status update for http://drupal.org/node/29676 Post a follow up: http://drupal.org/project/comments/add/29676 Project: Drupal Version: cvs Component: archive.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch (code needs review) Attachment: http://drupal.org/files/issues/archive_1.module (11.53 KB) Alright, I've attached a new archive.module - this is the version WITH term filtering enabled. I can make one without terms if necessary - otherwise, I'll just work from this one for now. This version fixes the bug that dtan saw, as a well as a bunch of other off-by-one errors. Of primary importance, however, is that all mktime's that mattered have been switched to gmmktime, which was one of the oft-reported Issues with the old archive.module. I want to eyeball them all again and make sure they're right though. The URLs from #13 are still operational and the CSS from #10 is still required. Morbus Iff Previous comments: ------------------------------------------------------------------------ Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff Over at http://drupal.org/node/8287, Berkes mentions that the core archive.module was considered being removed, per a discussion at the Drupal Sprint. Kjartan also mentions he would "love to have the archive module improved in general." In chatting with chx about this, he mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/. I'll be doing some work with the archive.module over the next few days, and will be basing my changes around codemonkeyx's version, and making it compatible with HEAD. This general Issue is to move codemonkeyx's version into HEAD as a replacement to the existing archive.module. An unknown version of his replacement can be seen at http://www.codemonkeyx.net/archive. I'll be running a live HEAD version soon as well. These patches were made during the customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues_2 (9.56 KB) As an example of a very early revision, see the attached, with the following changes from the current contrib CVS: * removed the year offset from theme_archive_navigation_years, which controlled how many year links to show at once in the top nav. For those with sites with more than five years, they'll WANT people to notice that they have five years, not to have to click on the earliest date and then have their expectations changed. * made the "created > $date" in archive_buildQuery "created >= $date" instead, to allow posts that were created at exactly midnight that day (like me, by design). * since there's no block, I made the menu item visible upon first load. this menu item is given "access content" permissions. More to come, including doxygen and gmt considerations. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff Might as well start getting a review of it so I can fix 'em as they come in. ------------------------------------------------------------------------ Fri, 26 Aug 2005 19:56:49 +0000 : Tobias Maier cant you provide a patch file? thanks for your work ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:04:01 +0000 : Morbus Iff The codemonkeyx version is a complete rewrite of the core archive.module. If I were to create a patch file against core, every line would be deleted, and every line would be new. Once I finish my revisions to codemonkey's version, I'll post the final version here, as well as a patch against his current CVS. ------------------------------------------------------------------------ Fri, 26 Aug 2005 20:09:13 +0000 : Tobias Maier ok, thanks again :D ------------------------------------------------------------------------ Mon, 29 Aug 2005 13:41:43 +0000 : Junyor +1 for this change. The archive.module in core is dead. ------------------------------------------------------------------------ Mon, 29 Aug 2005 16:14:30 +0000 : adrian What is the progress on this morbus ? ------------------------------------------------------------------------ Mon, 29 Aug 2005 16:29:13 +0000 : Morbus Iff Adrian - I'll be attaching a new version either later today or tomorrow, with a CHANGELOG. I'll also be running a live version of it over on NHPR.org for people to play with. The three major things I'm worried about right now are a) doxygen, b) variable/function naming, c) GMT considerations. After those, I'll be exploring a patch for my own needs: the ability to get archives for particular term. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:53:34 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive.module (9.93 KB) Here's the latest, with the following changelog: * reordered some routines to be a little more workflowish. * renamed archive_buildQuery to archive_build_query. * general whitespace and formatting cleanup. * HEADish update: returning $output, not page templating it. * removed the reference of &$ad in archive_build_query. * test for the existence of arg(#)'s before validating them. * archive_validSomething changed to archive_valid_something. * removed unused vars: cur_date, cur_date_end. * renamed archive_buildURL to archive_build_url. * removed the HTML whitespace from the theming. * twiddled a lot of quotes and apostraphes. * removed 'future' CSS class. ill-defined. * reordered/renamed the CSS classes. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:54:08 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_29676_archive_css.patch (1.56 KB) And the drupal.css patch. ------------------------------------------------------------------------ Mon, 29 Aug 2005 18:56:29 +0000 : Morbus Iff This version of the module is currently running live at http://www.nhpr.org/archive/. ------------------------------------------------------------------------ Mon, 29 Aug 2005 19:59:57 +0000 : Tobias Maier if i click for example on 2003 it would be good if this would go to january or december and marks them that this one will be shown now as you can see it if you click on january 2003. it has to select * on the first: the first month of writing * on the last: the last month of writing * on every else: january I hope you can understand what I mean... greets tobias ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:17:40 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/archive_0.module (11.28 KB) Alright. I've attached another new version that adds a new feature that wasn't part of the original codemonkeyx CVS, but was chatted about on the devel list back in April. If this particular feature has bad code or needs heavy refactoring, certainly consider ONLY the version in comment #9 (and the matching drupal.css patch in #10). This new version supports dated archives based on taxonomy tids. It was a quick addition which NHPR.org needed (for the date nav; the normal tid archive pager wasn't strong enough for our needs). Since it was a quick addition, it supports only ONE tid at a time - the 'and/or' syntax for the taxonomy.module was not brought over. If that syntax was desired, it'd make more sense to create some sort of API for archive.module so that other nodes can take advantage of the dated nav in their normal pages (like node types, users, forums, etc.) The added code supports term matches at any granularity: # all node types that match tid 15000 ('The Front Porch') http://www.nhpr.org/archive/term/15000 # all 2005 node types that match tid 20 ('Health') http://www.nhpr.org/archive/2005/term/20 # all March, 2003 node types that match tid 9 ('Education') http://www.nhpr.org/archive/2003/3/term/9 # all July 11, 2003 node types that match tid 49 ('Economy') http://morbus.totalnetnh.net/nhpr/archive/2002/7/11/term/49 ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:27:26 +0000 : Tobias Maier what does this mean? "Story Archives of 'archives' " on http://www.nhpr.org/archive/term/15000 should this maybe named? "Archive of 'The Front Porch'" if I go to http://www.nhpr.org/archive/term/20 I can only read "archives"... why is there a difference? - I never tested this module on my test site, because I'm not at home - ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:29:34 +0000 : Morbus Iff Tobias: that wouldn't be possible, at least not accurately. The new archive.module supports browsing by year, month, and day, as you know. archive/2005 loads up all the data from a particular year and starts creating a pager out of it. Consider if you have 3 posts in December, and 15 posts in November. It wouldn't be "right" to highlight December because the pager display for the entire year would also include some of November's entries (since 3 is less than the pager increment). Likewise, if we ONLY showed the items from December, then we wouldn't have a "pager by year" feature, only a "pager by month (defaulting to December when none is selected)" feature. ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:30:41 +0000 : Morbus Iff Tobias: regarding #14, that's an artifact of the templates that I'm using for NHPR, and has nothing to do with archive.module itself (in fact, once the anonymous cache expires, you'll see that little oopsie go away). ------------------------------------------------------------------------ Mon, 29 Aug 2005 20:31:47 +0000 : Tobias Maier I can see your right :) I hope it comes in HEAD before tomorrow :D ------------------------------------------------------------------------ Tue, 30 Aug 2005 00:20:12 +0000 : dtan I apologize if this is already a known issue. http://www.nhpr.org/archive/2005/9 does not create a link for september 1st, even though there are 2 nodes listed (http://www.nhpr.org/archive/2005/9/1) ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:11:21 +0000 : Morbus Iff dtan: I'm pretty sure I know what this is - I'll address it either later today or tomorrow.

1 0

[drupal-devel] Bug#323347: Another XMLRPC issue in drupal
by Steve Langasek 30 Aug '05

30 Aug '05

On Tue, Aug 30, 2005 at 01:44:33PM +0200, Moritz Muehlenhoff wrote: > Moritz Muehlenhoff wrote: > > Package: drupal > > Severity: grave > > Tags: security > > Justification: user security hole > > [I'm pretty sure you are already aware of it; but here it is anyway] > > Another XMLRPC vulnerability has been detected that affects Drupal > > as well. Please see http://www.hardened-php.net/advisory_142005.66.html > > for information about the issue in general. > > The new upstream release 4.5.4 resolves this issue. > drupal's transition into testing doesn't take place, because the changelog > of the fixed package didn't contain bug closers and the two RC security bugs > prevent migration. > So, please, either close them manually or with the next upload. If the bugs are fixed in the current version then they should be closed *now*, not waiting until the next upload. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon(a)debian.org http://www.debian.org/

3 3

[drupal-devel] [task] Collapsible settings for all settings pages?
by m3avrck 30 Aug '05

30 Aug '05

Issue status update for http://drupal.org/node/30038 Post a follow up: http://drupal.org/project/comments/add/30038 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: m3avrck -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/modules_0.patch (9.17 KB) I've gone through all of the settings pages for the included default Drupal modules and have applied the collapsible form fix. This really does make a *huge* difference... it makes the Settings interface more consistent and greatly improves readability. Let's get this one in! :) m3avrck Previous comments: ------------------------------------------------------------------------ Tue, 30 Aug 2005 17:37:22 +0000 : m3avrck Is there a reason collapsible fieldsets is used *only* on the main settings page? What about the users setting page? That is really long and would benefit. And the uploads setting page, as you add more roles, that page can get really long too. I think we should add this feature to all standard Drupal settings pages that are long like the settings page... it really helps and would make things look more consistent, instead of "why the heck is this on one page and not them all?". Need to get this into the next release as well to be consistent with the approach of this new feature.

1 0

[drupal-devel] [task] Usability: Upload module needs a 'default' maxfile size setting
by Souvent22 30 Aug '05

30 Aug '05

Issue status update for http://drupal.org/node/30025 Post a follow up: http://drupal.org/project/comments/add/30025 Project: Drupal Version: cvs Component: upload.module Category: tasks Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: Souvent22 Status: patch (code needs review) Tried patch. Seems to work ok. +1 Souvent22 Previous comments: ------------------------------------------------------------------------ Tue, 30 Aug 2005 15:15:02 +0000 : m3avrck Problem: I've enabled upload.module I then later assign a few roles to be able to upload files. All of a sudden this new, hidden setting appears in Settings > Upload .. max file size and total file size for *each* role that has this capability. Hmm, good thing I decided to check back there! But where did those defaults come from, hmm. Fix: There should be a 'default' setting in Settings > Upload for max file size and total file size for *all* roles. Then, when I create a role and assign it upload permissions, it should inherit these defaults, which shouldn't be hardcode into Drupal anyways (as they are now). However, after I assign this permission, override settings should appear, as they currently do. Benefits: If I assign uploads to 20 different roles I can have default setting for them all instead of having to worry about changing them all. Also, this fixes the obviously usability problem and makes this module make more sense which is always a +1 :) ------------------------------------------------------------------------ Tue, 30 Aug 2005 15:20:59 +0000 : m3avrck Correction, there should also be a default setting for extensions as well. ------------------------------------------------------------------------ Tue, 30 Aug 2005 18:49:10 +0000 : m3avrck Attachment: http://drupal.org/files/issues/upload.module_3.patch (3.29 KB) Ok I've created a patch which fixes this problem. Thorougly test here, please test and let me know! This certainly does simplify the out-of-box experience with the upload.module. ------------------------------------------------------------------------ Tue, 30 Aug 2005 19:11:20 +0000 : m3avrck Attachment: http://drupal.org/files/issues/upload.module_4.patch (3.54 KB) Fixed a small bug caught by mozillman in IRC.

1 0

[drupal-devel] [task] Usability: Upload module needs a 'default' maxfile size setting
by m3avrck 30 Aug '05

30 Aug '05

Issue status update for http://drupal.org/node/30025 Post a follow up: http://drupal.org/project/comments/add/30025 Project: Drupal Version: cvs Component: upload.module Category: tasks Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: m3avrck Status: patch (code needs review) Attachment: http://drupal.org/files/issues/upload.module_4.patch (3.54 KB) Fixed a small bug caught by mozillman in IRC. m3avrck Previous comments: ------------------------------------------------------------------------ Tue, 30 Aug 2005 15:15:02 +0000 : m3avrck Problem: I've enabled upload.module I then later assign a few roles to be able to upload files. All of a sudden this new, hidden setting appears in Settings > Upload .. max file size and total file size for *each* role that has this capability. Hmm, good thing I decided to check back there! But where did those defaults come from, hmm. Fix: There should be a 'default' setting in Settings > Upload for max file size and total file size for *all* roles. Then, when I create a role and assign it upload permissions, it should inherit these defaults, which shouldn't be hardcode into Drupal anyways (as they are now). However, after I assign this permission, override settings should appear, as they currently do. Benefits: If I assign uploads to 20 different roles I can have default setting for them all instead of having to worry about changing them all. Also, this fixes the obviously usability problem and makes this module make more sense which is always a +1 :) ------------------------------------------------------------------------ Tue, 30 Aug 2005 15:20:59 +0000 : m3avrck Correction, there should also be a default setting for extensions as well. ------------------------------------------------------------------------ Tue, 30 Aug 2005 18:49:10 +0000 : m3avrck Attachment: http://drupal.org/files/issues/upload.module_3.patch (3.29 KB) Ok I've created a patch which fixes this problem. Thorougly test here, please test and let me know! This certainly does simplify the out-of-box experience with the upload.module.

1 0

[drupal-devel] [task] Usability: Upload module needs a 'default' maxfile size setting
by m3avrck 30 Aug '05

30 Aug '05

Issue status update for http://drupal.org/node/30025 Post a follow up: http://drupal.org/project/comments/add/30025 Project: Drupal Version: cvs Component: upload.module Category: tasks Priority: normal Assigned to: Anonymous Reported by: m3avrck Updated by: m3avrck -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/upload.module_3.patch (3.29 KB) Ok I've created a patch which fixes this problem. Thorougly test here, please test and let me know! This certainly does simplify the out-of-box experience with the upload.module. m3avrck Previous comments: ------------------------------------------------------------------------ Tue, 30 Aug 2005 15:15:02 +0000 : m3avrck Problem: I've enabled upload.module I then later assign a few roles to be able to upload files. All of a sudden this new, hidden setting appears in Settings > Upload .. max file size and total file size for *each* role that has this capability. Hmm, good thing I decided to check back there! But where did those defaults come from, hmm. Fix: There should be a 'default' setting in Settings > Upload for max file size and total file size for *all* roles. Then, when I create a role and assign it upload permissions, it should inherit these defaults, which shouldn't be hardcode into Drupal anyways (as they are now). However, after I assign this permission, override settings should appear, as they currently do. Benefits: If I assign uploads to 20 different roles I can have default setting for them all instead of having to worry about changing them all. Also, this fixes the obviously usability problem and makes this module make more sense which is always a +1 :) ------------------------------------------------------------------------ Tue, 30 Aug 2005 15:20:59 +0000 : m3avrck Correction, there should also be a default setting for extensions as well.

1 0