Development
Threads by month
- ----- 2026 -----
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
September 2005
- 78 participants
- 615 discussions
Issue status update for
http://drupal.org/node/30727
Post a follow up:
http://drupal.org/project/comments/add/30727
Project: Drupal
Version: cvs
Component: user system
Category: feature requests
Priority: critical
Assigned to: chx
Reported by: chx
Updated by: chx
Status: patch (code needs review)
Attachment: http://drupal.org/files/issues/jabber.txt (4.59 KB)
Google (Talk) uses Jabber and that alone is enough reason to dust off
Jabber and put it back into core. If you are looking for a maintainer,
my hand is up.
The only significant code change is that I removed the global $jabber;
because I have not liked that.
I included an exception for gmail.com. If you do not like it, then do
not commit the module as there is almost no point.
chx
2
5
Issue status update for
http://drupal.org/node/17079
Post a follow up:
http://drupal.org/project/comments/add/17079
Project: Drupal
Version: cvs
Component: menu system
Category: bug reports
Priority: minor
Assigned to: Anonymous
Reported by: pz
Updated by: Robrecht Jacques
-Status: patch (code needs review)
+Status: patch (ready to be committed)
Still valid. Fixes a minor usability problem.
Robrecht Jacques
Previous comments:
------------------------------------------------------------------------
Wed, 09 Feb 2005 16:07:41 +0000 : pz
When creating a new menu the text "The name to display for this link."
appears as description for the title, but the menu name is never
linked. So either the menu-name should have a link or the text should
be changed.
------------------------------------------------------------------------
Sun, 13 Mar 2005 23:37:43 +0000 : killes(a)www.drop.org
I may be a bit sense, but I really don't get it. Can you please
elaborate?
------------------------------------------------------------------------
Mon, 14 Mar 2005 10:59:46 +0000 : pz
What I mean is that when creating a new menu (not a menuitem) the text
"The name to display for this link." appears as description for the
input field (same text as when creating a menutime). Problem is it is
not a link we are creating it is only the name of a menu, this name is
never linked to anything.
So either the description of the input field should change depending on
if we are creating a menitem or a new menu, or it should be possible to
add a link to the menuname.
------------------------------------------------------------------------
Mon, 22 Aug 2005 13:28:55 +0000 : Uwe Hermann
Attachment: http://drupal.org/files/issues/menu_20.patch (747 bytes)
Still valid in HEAD. Here's a patch.
1
0
[drupal-devel] [bug] Bugfix (?) to search_data function (hook_search_item not working)
by adixon 09 Sep '05
by adixon 09 Sep '05
09 Sep '05
Issue status update for
http://drupal.org/node/28767
Post a follow up:
http://drupal.org/project/comments/add/28767
Project: Drupal
Version: cvs
Component: search.module
Category: bug reports
Priority: normal
Assigned to: Anonymous
Reported by: adixon
Updated by: adixon
Status: patch (code needs review)
I think that line 678:
$output .= theme('search_item', $entry, $type);
should be
$output .= theme('search_item', $entry,
$entry['type']);
so that hook_search_item is in fact invoked for the particular entry's
module type.
adixon
2
1
Issue status update for
http://drupal.org/node/25685
Post a follow up:
http://drupal.org/project/comments/add/25685
Project: Drupal
Version: cvs
Component: base system
Category: feature requests
Priority: normal
Assigned to: walkah
Reported by: robertDouglass
Updated by: walkah
Status: patch (code needs work)
so here's the thing... robrecthj has been working on some image.module
enhancements in his sandbox (one of them being splitting image.module &
imagegallery) ... it's still being worked on... but that might be the
best place to look for moving stuff into core.
as in - he's already working on it and i'm watching that :)
walkah
Previous comments:
------------------------------------------------------------------------
Fri, 24 Jun 2005 14:02:38 +0000 : robertDouglass
How do people feel about moving image.module to core? My personal view
is that it is the right thing to do. We will have had the entire 4.6
cycle to evaluate image.module and image.inc, and I think that they are
both on the same level of quality as Drupal as a whole. Furthermore,
image.module is essential to most known uses of Drupal, including
drupal.org. The amount of work needed for making this move is
relatively small. There is no new database schema. The biggest issue
would be the image.module specific upgrade script and the documentation
that would need to be written to warn and instruct people who might be
upgrading from the previous image module.
-Robert
------------------------------------------------------------------------
Sun, 26 Jun 2005 01:03:14 +0000 : kbahey
According to this http://drupal.org/node/25704, it is one of the most
downloaded modules on Drupal.org.
Also, part of it is already in core (image.inc).
So, for me, it makes sense to move it to core as well.
But: keep it minimalistic, with fancy addons as contribs.
------------------------------------------------------------------------
Mon, 27 Jun 2005 23:05:33 +0000 : shane
+1
But - I wouldn't want to lose site of the fact that the image.module is
WAY TOO BASIC and needs some more features to make it actually useful.
The initial discussion regarding img_assist.module in the top20 page is
a great example of the problems with the workflow of adding images.
------------------------------------------------------------------------
Tue, 28 Jun 2005 13:50:52 +0000 : Uwe Hermann
+1. The image module really belongs in core.
Uwe.
------------------------------------------------------------------------
Wed, 29 Jun 2005 13:09:56 +0000 : walkah
robert - i'm flattered that you think so highly of the code... Dries and
I talked about putting image in core when I was doing the rewrite ...
and decided against it. I can't totally remember why now...
I'm essentially +1 to this idea, and am fully willing to continue
maintaining a core image.module (and adding enhancements, etc).
One thing I think we need to figure out though is ... what do folks
want most out of a core image.module? (i.e. do we want galleries? just
easy inclusion in blog posts? bulk uploading? etc...)
------------------------------------------------------------------------
Wed, 29 Jun 2005 14:04:40 +0000 : pegmonkey
+1 HOWEVER.... it wasn't ready and yet released for 4.6. I'd say it's
a good consideration, but I advise caution. The upgrade to 4.6 just
about destroyed my working images. Derivatives were broken and though
fixed now, had some major issues that took a while to get sorted out.
Yes I backed it up.. so no big deal. But, still it was far from ready
to be released. I had actually considered solutions other than drupal
for my sites during that time, but I stuck with it. Others might not
have been as persistant. Images are a very important part of most web
sites so it should go in eventually. I'd have given the initial 4.6
release an alpha rating at best. I would suggest that if it goes in,
it go in as a very basic module and then additional modules that add
features be created.
I think mass upload would be good to include. Galleries and various
other features could be external modules.
------------------------------------------------------------------------
Wed, 13 Jul 2005 04:45:49 +0000 : Zed Pobre
I'd volunteer a +1, if it meant that the breakage would be less likely
to occur in the future. I'm still running 4.5.2 because image.module
is too critical to my website, and I can't deal with it breaking. If
making it a core component meant tighter integration and upgrade
handling all around, I'd be much happier.
Bulk upload is a key feature for me, by the way, one of the other
reasons I haven't forged ahead. I make heavy use of the old
image.module galleries, but if additional modules will give me any
gallery ability, I'm not very particular about the features or the
exact form. The pictures just need to be accessible.
------------------------------------------------------------------------
Mon, 15 Aug 2005 20:22:01 +0000 : walkah
i'm gonna see what I can do on this front... assigning so i don't forget
:)
------------------------------------------------------------------------
Mon, 15 Aug 2005 21:45:01 +0000 : sepeck
+1 for me.
So far most/any issue's that people have experianced seem to have come
down to permissions issues specific to the server configuration that
they were on and whether the files/images directory existed or not..
------------------------------------------------------------------------
Mon, 15 Aug 2005 22:28:39 +0000 : robertDouglass
I'm glad that there is so much support for the idea. It will be
especially nice because the imagemagick.inc file can be in the includes
directory from the start (I always forget to move it). Are there any
reasons NOT to put this module in core? If there are tasks that still
need doing, please, let's talk about them so that we can get them done
before the code freeze.
------------------------------------------------------------------------
Tue, 23 Aug 2005 13:19:09 +0000 : neuraxon77
+1 core it. please.
With the galleries.
More work needs to be done, and could be at a later date. They way it
is now is functional as far as i'm concerned. The img_assist module
still needs work but again something like it IMHO should be in core
too.
There needs to be more modules like these essential to content creation
in core.
Quick! Get it in before the code freeze. :)
If it has Images, Galleries and the Free Tagging, 4.7 should be good.
------------------------------------------------------------------------
Thu, 08 Sep 2005 17:22:15 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/image_in_core.patch.txt (29.01 KB)
So here's a patch. It needs work - some of the update tasks for getting
this ready for 4.7 are quite obtuse. Somebody with intimate knowledge
of the image module and HEAD should take a good look, but at least
there is a patch. There is still time left before the freeze, and
neither Dries nore Steven have indicated that they are opposed to
including this, but it will take some work. The next round is for
someone else.
------------------------------------------------------------------------
Thu, 08 Sep 2005 21:12:26 +0000 : robertDouglass
Ok, ignore the patch. Chx just pointed out to me that my CVS repository
wasn't up to date when I started working on the module, thus I wasted
my time. I do still hope that this can be moved to core.
1
0
[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Souvent22 08 Sep '05
by Souvent22 08 Sep '05
08 Sep '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: Souvent22
Status: patch (ready to be committed)
+1. I like the new patch, makes things easier to patch. Very slick. I
like the break down of years, to months, to days. Very nice. Ready to
go I say.
Souvent22
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.
------------------------------------------------------------------------
Wed, 31 Aug 2005 00:02:06 +0000 : Morbus Iff
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.
------------------------------------------------------------------------
Wed, 31 Aug 2005 05:53:51 +0000 : Junyor
Since that is also a problem with the old archive.module, I don't see
why it should stop this from getting into core.
------------------------------------------------------------------------
Wed, 31 Aug 2005 06:37:28 +0000 : stefan nagtegaal
"Since that is also a problem with the old archive.module, I don't see
why it should stop this from getting into core.
"
Well, I think it's better to only accept the best code rather than
accepting bugs getting in core.
------------------------------------------------------------------------
Wed, 31 Aug 2005 07:05:51 +0000 : Kobus
I am with Junyor on this. If this can be fixed, great, but if not, it's
not a train smash, as the old one exhibits the same problem.
I say add the new archive module, if there are no other ciritical bugs
with it. It is much more robust and usable than the old one. We
desperately need a new archive module.
I couldn't find any other bugs while testing with the links Morbus
posted. I don't have a HEAD installation anywhere, so can't test it
locally at this moment.
Regards,
Kobus
------------------------------------------------------------------------
Wed, 31 Aug 2005 07:07:49 +0000 : Kobus
BTW, code freeze means no new code added, right?
Can't this module put in Core as is for the code freeze and the bug
sorted out before the official release? Or is that just mean of me to
suggest that?
Kobus
------------------------------------------------------------------------
Wed, 31 Aug 2005 07:13:09 +0000 : Junyor
Stefan: The bug is already in core, since node.module is in core.
Archive.module (old and new!) just shows that bug.
------------------------------------------------------------------------
Wed, 31 Aug 2005 07:20:35 +0000 : Tobias Maier
I want to have it in core for 4.7, too!!!
------------------------------------------------------------------------
Wed, 31 Aug 2005 07:25:24 +0000 : stefan nagtegaal
Junyor: I know that.. Though I think it's not good to accept code which
we are aware of that it has bugs in it..
Offcourse this is very double, because drupal contains (probably) a lot
of bugs, only they weren't spotted yet..
But, accepting code which has bugs in unacceptable imo..
For example, the node revisions patch had almost 40 reviews/rewritings
from Gerhard and several others before it was accepted to be in core..
If we do not allow bugs to go into core, we don't have to bughunt and
fix later which is a good thing..
So, imo we should first sort out the problem, then discuss what the
best way is to fix the problem, and after that Squeeze that moron! ;-)
------------------------------------------------------------------------
Wed, 31 Aug 2005 09:11:06 +0000 : adrian
I vote we include this module, and open up a new issue for the bug.
It's not archive's fault that this occurs, it is just showing the data
it has access to. The bug already exists in core too.
------------------------------------------------------------------------
Wed, 31 Aug 2005 13:50:59 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive_2.module (10.63 KB)
Attached is a new, and most likely final, version of the archive.module.
I've removed all user->timezone references - all date determinations are
based on server time, which is also the time used in the "created"
column of the node table. This is "more accurate" than what the core
archive.module currently does (which'll always be wrong because it's
treating server time as GMT, which isn't always the case). When
node.module does start saving times as GMT properly, archive.module
will have be to be tweaked with timezones and blah blah blah. I did
fiddle around with determining the server offset in an attempt to get
to a GMT base, but I didn't have much luck with that. The NHPR.org URLs
above are still valid for testing.
I need testers and reviewers.
------------------------------------------------------------------------
Wed, 31 Aug 2005 14:55:16 +0000 : m3avrck
I get these two PHP errors when I have *no* content in my Drupal install
(just did a clean install to test it):
warning: mktime() [<a href='function.mktime'>function.mktime</a>]:
Windows does not support negative values for this function in
websites\drupal_cvs\drupal\modules\archive.module on line 274.
warning: date() [<a href='function.date'>function.date</a>]: Windows
does not support dates prior to midnight (00:00:00), January 1, 1970 in
websites\drupal_cvs\drupal\modules\archive.module on line 274.
Once I add content, these go away. Need some better checks to make sure
if there is *no* content you don't get weird errors and what not :)
------------------------------------------------------------------------
Wed, 31 Aug 2005 14:55:45 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/_p_29676_archive_css_0.patch (1.56 KB)
Updated drupal.css patch for HEAD.
------------------------------------------------------------------------
Wed, 31 Aug 2005 15:26:01 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive_3.module (10.75 KB)
Attached is the complete module, fixed for m3avrck's #31.
------------------------------------------------------------------------
Wed, 31 Aug 2005 17:30:36 +0000 : m3avrck
Reviewed patch and further test, running great over here! Definetly +1
for this one!
------------------------------------------------------------------------
Wed, 31 Aug 2005 20:03:36 +0000 : Morbus Iff
Note: The NHPR folks preferred their archives to be sorted from earliest
to latest (SQL ASC vs. DESC) for month/day listings, so no longer use
the NHPR.org URLs above as representative of the module itself.
------------------------------------------------------------------------
Wed, 31 Aug 2005 21:26:37 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/drupal.css (10.35 KB)
CVS updated for HEAD again.
------------------------------------------------------------------------
Wed, 31 Aug 2005 21:27:00 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/_p_29676_archive_css_1.patch (1.56 KB)
GRRR.
------------------------------------------------------------------------
Thu, 08 Sep 2005 20:18:48 +0000 : m3avrck
Attachment: http://drupal.org/files/issues/archive_0.patch (20.72 KB)
Rerolled patch against head. Also created one patch that fixes both
archive.module and drupal.css so it's a clean and simple process now :)
------------------------------------------------------------------------
Thu, 08 Sep 2005 20:23:55 +0000 : m3avrck
Just retested with the latest patch I made, applies cleanly against HEAD
and *everything* works great and looks great too. No errors of any kind,
even works on PHP 5.0.5 with no call by reference errors, :D Let's get
this baby in!
1
0
Issue status update for
http://drupal.org/node/25685
Post a follow up:
http://drupal.org/project/comments/add/25685
Project: Drupal
Version: cvs
Component: base system
Category: feature requests
Priority: normal
Assigned to: walkah
Reported by: robertDouglass
Updated by: robertDouglass
Status: patch (code needs work)
Ok, ignore the patch. Chx just pointed out to me that my CVS repository
wasn't up to date when I started working on the module, thus I wasted
my time. I do still hope that this can be moved to core.
robertDouglass
Previous comments:
------------------------------------------------------------------------
Fri, 24 Jun 2005 14:02:38 +0000 : robertDouglass
How do people feel about moving image.module to core? My personal view
is that it is the right thing to do. We will have had the entire 4.6
cycle to evaluate image.module and image.inc, and I think that they are
both on the same level of quality as Drupal as a whole. Furthermore,
image.module is essential to most known uses of Drupal, including
drupal.org. The amount of work needed for making this move is
relatively small. There is no new database schema. The biggest issue
would be the image.module specific upgrade script and the documentation
that would need to be written to warn and instruct people who might be
upgrading from the previous image module.
-Robert
------------------------------------------------------------------------
Sun, 26 Jun 2005 01:03:14 +0000 : kbahey
According to this http://drupal.org/node/25704, it is one of the most
downloaded modules on Drupal.org.
Also, part of it is already in core (image.inc).
So, for me, it makes sense to move it to core as well.
But: keep it minimalistic, with fancy addons as contribs.
------------------------------------------------------------------------
Mon, 27 Jun 2005 23:05:33 +0000 : shane
+1
But - I wouldn't want to lose site of the fact that the image.module is
WAY TOO BASIC and needs some more features to make it actually useful.
The initial discussion regarding img_assist.module in the top20 page is
a great example of the problems with the workflow of adding images.
------------------------------------------------------------------------
Tue, 28 Jun 2005 13:50:52 +0000 : Uwe Hermann
+1. The image module really belongs in core.
Uwe.
------------------------------------------------------------------------
Wed, 29 Jun 2005 13:09:56 +0000 : walkah
robert - i'm flattered that you think so highly of the code... Dries and
I talked about putting image in core when I was doing the rewrite ...
and decided against it. I can't totally remember why now...
I'm essentially +1 to this idea, and am fully willing to continue
maintaining a core image.module (and adding enhancements, etc).
One thing I think we need to figure out though is ... what do folks
want most out of a core image.module? (i.e. do we want galleries? just
easy inclusion in blog posts? bulk uploading? etc...)
------------------------------------------------------------------------
Wed, 29 Jun 2005 14:04:40 +0000 : pegmonkey
+1 HOWEVER.... it wasn't ready and yet released for 4.6. I'd say it's
a good consideration, but I advise caution. The upgrade to 4.6 just
about destroyed my working images. Derivatives were broken and though
fixed now, had some major issues that took a while to get sorted out.
Yes I backed it up.. so no big deal. But, still it was far from ready
to be released. I had actually considered solutions other than drupal
for my sites during that time, but I stuck with it. Others might not
have been as persistant. Images are a very important part of most web
sites so it should go in eventually. I'd have given the initial 4.6
release an alpha rating at best. I would suggest that if it goes in,
it go in as a very basic module and then additional modules that add
features be created.
I think mass upload would be good to include. Galleries and various
other features could be external modules.
------------------------------------------------------------------------
Wed, 13 Jul 2005 04:45:49 +0000 : Zed Pobre
I'd volunteer a +1, if it meant that the breakage would be less likely
to occur in the future. I'm still running 4.5.2 because image.module
is too critical to my website, and I can't deal with it breaking. If
making it a core component meant tighter integration and upgrade
handling all around, I'd be much happier.
Bulk upload is a key feature for me, by the way, one of the other
reasons I haven't forged ahead. I make heavy use of the old
image.module galleries, but if additional modules will give me any
gallery ability, I'm not very particular about the features or the
exact form. The pictures just need to be accessible.
------------------------------------------------------------------------
Mon, 15 Aug 2005 20:22:01 +0000 : walkah
i'm gonna see what I can do on this front... assigning so i don't forget
:)
------------------------------------------------------------------------
Mon, 15 Aug 2005 21:45:01 +0000 : sepeck
+1 for me.
So far most/any issue's that people have experianced seem to have come
down to permissions issues specific to the server configuration that
they were on and whether the files/images directory existed or not..
------------------------------------------------------------------------
Mon, 15 Aug 2005 22:28:39 +0000 : robertDouglass
I'm glad that there is so much support for the idea. It will be
especially nice because the imagemagick.inc file can be in the includes
directory from the start (I always forget to move it). Are there any
reasons NOT to put this module in core? If there are tasks that still
need doing, please, let's talk about them so that we can get them done
before the code freeze.
------------------------------------------------------------------------
Tue, 23 Aug 2005 13:19:09 +0000 : neuraxon77
+1 core it. please.
With the galleries.
More work needs to be done, and could be at a later date. They way it
is now is functional as far as i'm concerned. The img_assist module
still needs work but again something like it IMHO should be in core
too.
There needs to be more modules like these essential to content creation
in core.
Quick! Get it in before the code freeze. :)
If it has Images, Galleries and the Free Tagging, 4.7 should be good.
------------------------------------------------------------------------
Thu, 08 Sep 2005 17:22:15 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/image_in_core.patch.txt (29.01 KB)
So here's a patch. It needs work - some of the update tasks for getting
this ready for 4.7 are quite obtuse. Somebody with intimate knowledge
of the image module and HEAD should take a good look, but at least
there is a patch. There is still time left before the freeze, and
neither Dries nore Steven have indicated that they are opposed to
including this, but it will take some work. The next round is for
someone else.
1
0
Issue status update for
http://drupal.org/node/10888
Post a follow up:
http://drupal.org/project/comments/add/10888
Project: Drupal
Version: cvs
Component: base system
Category: bug reports
Priority: normal
Assigned to: Bèr Kessels
Reported by: jhriggs
Updated by: robertDouglass
Status: patch (code needs work)
Good - that needs to be removed too, but is there anything that doesn't
work right if we don't remove them? Lots of the $output = '<a href....'
instances in the code use url() for href and these are not broken. They
can't be seen as a reason not to commit this particular patch. If
anyone point out things that break with the patch I made, I'll fix
them. I can't go through and clean up anchor tags on idealistic grounds
at the moment (as much as I would otherwise like to).
robertDouglass
Previous comments:
------------------------------------------------------------------------
Thu, 16 Sep 2004 15:01:24 +0000 : jhriggs
Attachment: http://drupal.org/files/issues/full_url.patch (1.97 KB)
This little patch allows full URLs to be used for the url() and l()
functions, giving modules a single interface for creating links.
Currently, modules must use l() for drupal links and raw HTML for
external links. This patch changes url() to handle -- basically pass
through -- full URLs while still doing the proper handling of internal
paths and works with clean URLs enabled or disabled. It also shortens
(and hopefully simplifies) the url() code a bit.
Some examples of calls that now work:
<?php
l('a link', 'some/path'); // same as before
l('an external link', 'http://drupal.org/');
l('full with query', 'http://google.com/search?q=define:foo');
l('full with separate query', 'http://google.com/search', array(), 'q=define:foo'); // same link as above
l('full with fragment', 'http://drupal.org/node/5942#comment-12374');
l('full with separate fragment', 'http://drupal.org/node/5942', array(), NULL, 'comment-12374'); // same link as above
?>
------------------------------------------------------------------------
Thu, 30 Sep 2004 11:09:30 +0000 : moshe weitzman
+1. less HTML in code is a good thing for readability, if nothing else.
------------------------------------------------------------------------
Mon, 24 Jan 2005 20:06:26 +0000 : mathias
Attachment: http://drupal.org/files/issues/external_urls.patch (838 bytes)
Revisiting this issue one year later shows we're almost there. The only
thing that's left is the ability to handle external urls when
clean_urls is disabled. Once implemented, menu.module can happily
accept external urls and not just Drupal paths, making the menu system
much more attractive to end users.
I'll update the menu.module docs if this patch (or an alternative
solution) is accepted.
------------------------------------------------------------------------
Sun, 13 Mar 2005 22:36:34 +0000 : killes(a)www.drop.org
Attachment: http://drupal.org/files/issues/external_urls_0.patch (909 bytes)
Updated from Drupal root directory.
------------------------------------------------------------------------
Mon, 14 Mar 2005 00:05:17 +0000 : gordon
+1 This is a good thing for people who can't using clean urls.
------------------------------------------------------------------------
Sat, 02 Apr 2005 06:23:10 +0000 : TDobes
This patch seems like a good idea, but does not apply anymore. Also,
shouldn't the comments for l() and url() be updated to indicate that
the functions will work with both internal and external URL's?
------------------------------------------------------------------------
Sat, 02 Apr 2005 07:25:13 +0000 : asimmonds
Attachment: http://drupal.org/files/issues/external_urls_1.patch (897 bytes)
The &'s had been changed to & amp; , here's a valid patch
------------------------------------------------------------------------
Thu, 12 May 2005 14:57:07 +0000 : adrian
This is a new patch against cvs that allows url() to create external
links, with the side-effect that menu can now be used to make external
links.
Also closes http://drupal.org/node/10177
This will be even more important with the primary links menu
integration. (This patch already cleans up a special case in
phptemplate for that).
Killes benchmarked this, and it turns out the difference is negligible.
Requests per second: 1.33 [#/sec] (mean) = with patch
Requests per second: 1.31 [#/sec] (mean) = without patch.
------------------------------------------------------------------------
Thu, 12 May 2005 14:59:57 +0000 : killes(a)www.drop.org
I had benchmarked /node as anon user without cache.
------------------------------------------------------------------------
Wed, 25 May 2005 04:50:08 +0000 : Steven
+1 on the idea of this patch. It allows people to use l() for external
links.
However, I don't like the implementation. Running that complicated
regexp for every url() call is simply wasteful. 95% or more of url()
calls have a fixed string as parameter and point to Drupal's own paths.
I suggest we create an url_external() wrapper around url() which allows
external URLs. Any path which we want to allow external URLs in can use
url_external() instead. The places where we use it will not be many
anyway.
------------------------------------------------------------------------
Wed, 25 May 2005 05:05:55 +0000 : gordon
splitting into url() url_external is not a good idea. The main reason
for this patch that I see is for putting external urls into the
navigation menu using the menu.module, and if all goes to plan, the
primary and secondary menus.
------------------------------------------------------------------------
Wed, 25 May 2005 06:00:01 +0000 : Steven
gordon: I still think this is a bit excessive. Perhaps instead of
valid_url() we could use a simpler regexp !^[a-z]://!i or even
strpos('://').
------------------------------------------------------------------------
Wed, 25 May 2005 06:15:36 +0000 : gordon
I am not says that it is or is not excessive. I was just saying that
this is where it is going to be used, so creating url() and
url_external() is not really an option
------------------------------------------------------------------------
Wed, 25 May 2005 06:57:53 +0000 : Bèr Kessels
we /do/ need an external_url() thing.
The links bundle (handling weblinks and the likes) willprovide this
/and/ need this.
People will get all sorts of tools to do /stuff/ with external links,
like add permissions, track clicks etc. depending on the modules they
have and the settings. All outgoing weblinks, should somehow respect
those. Patches for core are coming, though.
On top of that, a external_l() finction is simple. And if people want
them in primary links they can do the regexping /before/ the function,
not /in/ the function. The calling code can decide whether to call l()
or external_l(), instead of putting logic in l() that is unneded 95% of
the times.
But i hereby promise to introduce such a function tbefore the end of
this week :)
------------------------------------------------------------------------
Wed, 25 May 2005 07:17:47 +0000 : gordon
The only thing I do not see in this plan is how with this work with the
menu module and the navigation menu.
------------------------------------------------------------------------
Wed, 25 May 2005 10:04:12 +0000 : adrian
Attachment: http://drupal.org/files/issues/url_external_links.patch (1.75 KB)
What happened to the patch i uploaded ?
It doesn't use a complex regexp, but uses strpos($url, '://') < 5.
------------------------------------------------------------------------
Thu, 26 May 2005 06:19:32 +0000 : Bèr Kessels
Allthough this works, is clean AND does what it should do, I still am in
favour of a better nitegrated solution. So please do not yet commit
this, untill I upload my patch. We can then discuss what solution to
take. It will not differ a big lot though.
------------------------------------------------------------------------
Thu, 26 May 2005 08:39:32 +0000 : adrian
is this the patch where you want to introduce an el() to allow for
counting of external links ?
That's a different patch altogether. This is primarily about stopping
url() from not handling external links when there is no good reason for
it to do so. Your el() has a very specific use in the weblinks api, and
should probably be included with it.
------------------------------------------------------------------------
Thu, 26 May 2005 16:18:31 +0000 : Bèr Kessels
Yes, that el()
But let me explain why i am anxious for my solution: el(), by default
will not do much, in fact it will just be an URL()-clone but one that
allows outgoing links. But it has a hook-caller. Again: by default it
does nothing much, for there will not be any hooks around in core.
It will allow, for example, weblinks, to track clicks, or to look up a
permission and allow or disallow users to follow a link.
Now, the whole issue, IMO is, that we should *not* provide two ways for
handling external URLS, but rather a single one, that is weblink-safe.
If we would introduce URL() with outgoing links-capabilities, we can no
longer track any outgoing URLs trough them. We will then have two ways
for handling outgoing URLs, resulting in inconsistencies, and confused
users. (hey, my anonymous users can follow link foo, while i have
"follow outgig links" permission disabled for them).
(BTW weblink will soon be renamed into links, just for reference)
------------------------------------------------------------------------
Thu, 30 Jun 2005 11:06:11 +0000 : adrian
Attachment: http://drupal.org/files/issues/url_external_links_0.patch (824 bytes)
I've updated the patch.
------------------------------------------------------------------------
Mon, 18 Jul 2005 14:12:36 +0000 : adrian
spoke to dries about this patch, and apart from the incomplete patch I
uploaded, there are about a dozen instances where in-line html is used
were l() would suffice.
I will be cleaning them up and submitting a new patch soon.
------------------------------------------------------------------------
Fri, 05 Aug 2005 18:44:03 +0000 : moshe weitzman
hopefully adrian or someone else will chase down the remaining urls
which should use this function.
------------------------------------------------------------------------
Fri, 05 Aug 2005 19:25:08 +0000 : jsloan
I've come to this party late but would like to see a patch soon... I've
used the patch from Adrian (#15) but this did not work correctly in my
setup (IIS 5.0 / no clean urls) I applied it against 4.6.2 and cvs.
Where is the latest patch that I can test ... I'll throw some time at
this because I need it for a module used within our Intranet.
------------------------------------------------------------------------
Mon, 08 Aug 2005 20:06:03 +0000 : jsloan
Attachment: http://drupal.org/files/issues/external_urls_2.patch (3.67 KB)
I'm not sure what the final plans are for this in the CVS so I have
developed a patch for use on 4.6.2
I decided to add a parameter named $external that is passed to url()
function. The default is FALSE so this should not break any existing
calls to either l() or url(). I have also refactored url() so that it
is much easier to understand and extend --- I'm thinking of Bèr
Kessels intention to
"allow, for example, weblinks, to track clicks, or to look up a
permission and allow or disallow users to follow a link"
"
Since the parameter is passed to activate the external url there is no
need for regex or strpos, this should be handled by the calling
function and then set the $external parameter to TRUE
For example I have patched the theme_menu_item_link() function in
menu.inc to accept external urls:
<?php
function theme_menu_item_link($item, $link_item) {
// this next line was added so that a menu item could point to the default home
$link_item['path'] = preg_replace('/^\/$/','',$link_item['path']);
// this next line was added so that a menu item could point to an external url
$external = (preg_match('<^[a-z]+://>', $link_item['path'])) ? TRUE : FALSE ;
return l($item['title'], $link_item['path'], array_key_exists('description', $item) ? array('title' => $items['description']) : array(),NULL,NULL,FALSE,FALSE,$external);
}
?>
I hope that this patch will spur some solutions - I'm using this now in
production but have not tested extensively across every scenario.
thanks
jim sloan
------------------------------------------------------------------------
Fri, 19 Aug 2005 12:10:50 +0000 : jsloan
... are there any thoughts on this? What is the status of the final
patch?
------------------------------------------------------------------------
Sun, 28 Aug 2005 15:48:08 +0000 : adrian
The problem with this patch is that we still need to fix all the inline
occurrences of the <a href tag.
I don't think we should confuse the issue and implement a hook at this
point, as url() breaking with external links is a bug, pure and simple.
------------------------------------------------------------------------
Thu, 08 Sep 2005 15:24:16 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/theme.inc.patch.txt (1.16 KB)
Adrian, your second patch for theme.inc looks wrong to me. Don't you
still need the line
$settings[$type .'_links'][] = l($text, $link, $attributes); ?
I also got rid of unset($attributes); Where was that supposed to come
from that it needed unsetting?
------------------------------------------------------------------------
Thu, 08 Sep 2005 15:48:02 +0000 : robertDouglass
Attachment: http://drupal.org/files/issues/theme.common.inc.patch.txt (1.83 KB)
Here is a unified patch that I updated to fix a bug in Adrian's
common.inc code (everything was being handled as absolute), plus the
update to theme.inc that I questioned in the previous post.
In my initial testing, this works perfectly. I can put absolute URLs in
for the paths in menu items and it handles them fine, and changes no
other behavior. I searched core for all uses of url() and http:// and
found no more violating code such as that in theme.inc.
Net change in core with this patch: 0 lines of code.
Please review quickly, I'm writing in the upcoming book about this
functionality as if it is in. =)
------------------------------------------------------------------------
Thu, 08 Sep 2005 15:49:43 +0000 : robertDouglass
Correction: net change to core -1 line of code.
------------------------------------------------------------------------
Thu, 08 Sep 2005 18:58:01 +0000 : adrian
What needs to be removed from core are not uses of url() and l(), but
all occurences of the anchor tag.
The anchor tag was mostly used because l() didn't do external links.
Also, in the case of phptemplate , that is the line that creates the
array that is passed to the template.
1
0
Issue status update for
http://drupal.org/node/27364
Post a follow up:
http://drupal.org/project/comments/add/27364
Project: Drupal
Version: cvs
Component: filter.module
Category: tasks
Priority: normal
Assigned to: Bèr Kessels
Reported by: Bèr Kessels
Updated by: m3avrck
Status: patch (code needs work)
Found a few more issues:
If I go into 'Configure' for 'PHP Code' and click the 'Configure' tab
at the top and then click 'list filters' link in the text, I get this
warning with PHP5 warning: Missing argument 1 for filter_admin_format()
in \drupal\modules\filter.module on line 378.
Also, it is sort of confusing as to what the 'List' tab implies. For
example, if I click on 'input formats' in the admin menu, I get a list
of the current filters. When I click 'configure' for one of those, I
see the options for that filter. However, it says 'list' in one of the
tab, which doesn't really mean much. I thought that was the list of
filters, not the options for that filter. That should be cleaned up.
Also, there is no way to get back to the full list of filters unless
you click on 'input formats' in the admin menu. A setting/link to fix
this would be great.
Also, where is the link to add filters???
I think the options/layout/tabs should mimic of that of admin > users.
So on admin > input formats, it has the tabs 'list', 'add format' ...
very clear and consistent.
On a configure page for a filter, it should have 'list', 'view',
'configure', 'rearrange' ... this would make it easier to navigate and
get back to the original list of filters.
Make sense? I think this and Dries' comments put this patch over the
top :)
m3avrck
Previous comments:
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:30:54 +0000 : Bèr Kessels
This is a mockup for the Filter UI. Currently it is soo complex, that I
dare to call it broken.
Please comment on this, for I will not ake any patches, when the
general idea is disliked.
The idea is t split filters and input formats better. Filters are
filters, defined in modules. Input formats are bundles of filters. This
is how we have it ATM, but the interface fails to communicate that. I
tried to develop a consistent (with the rest of Drupal) interfce that
makes it clearer what is what.
The menu is as follows:
* administer
** ....
** settings
*** input formats
*** filters
** ...
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:37:10 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_list1.png (16.34 KB)
* administer
** ....
** settings
*** input formats >> see attachement 1
*** filters
**
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:39:02 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_add.png (23.42 KB)
* administer
** ....
** settings
*** input formats >> see attachement 2, tab 2
*** filters
**
Note: The default checkbox lmay seem a bit odd. But checking it will
remove the "default status" from the current "default" one and make
this one "default". The help text, and a drupal_set_message should
explain this.
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:40:08 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit_format.png (22.17 KB)
* administer
** ....
** settings
*** input formats >> clicking a 'configure' link in the table of
attachement 1
*** filters
**
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:40:55 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-filters_list.png (36.24 KB)
* administer
** ....
** settings
*** input formats
*** filters >> see attachement 4
**
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:41:40 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit.png (22.63 KB)
* administer
** ....
** settings
*** input formats
*** filters >> clicking a 'configure' link in the table of attachement
4
**
------------------------------------------------------------------------
Mon, 25 Jul 2005 14:46:27 +0000 : Bèr Kessels
IMO this makes the interface easier. But other disagree. And because it
also removes one feature: (being able to use E.g. HTML in different
input formats, with different settings)
I'll simply wont fix this :(
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:36:12 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy.patch (10.28 KB)
I decided to go for it anyway. Be it in a slightly different way then my
initial mockups. The difference is that I left the filters where they
are, hidden beneath the formats.
So, here is the patch that makes the filter UI more consistent with
screens like blocs, menus, vocabularies et al
also nice to note is that:
93 lines are added, 104 are removed. So netto we have less code :)
(cvs diff filter.module | grep ^+ | wc -l)
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:37:02 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_list_html.png (44.64 KB)
Here is how the listing now looks.
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:37:57 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit_format_html.png (113.71 KB)
And the "configure" screen.
The 'add' screen looks exactly the same, only with the default values
pre-filled.
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:39:19 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit_format_too_long.png (121.82 KB)
Oh, And here is a really nice example of why the current screen is no
good.
And here I "only" have four roles. I run a site with 12 roles, imagine
this screen then!
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:48:35 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_HEAD.patch (10.24 KB)
And here is a pathc for HEAD (I forgot that I developed this on a 4.6.2
codebase. Sorry)
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:55:25 +0000 : stefan nagtegaal
I like this very, very much!
This is - indeed - much better than the current UI. This always fits,
and makes the life of people who use a fixed width theme much nicer..
Ber, FYI (you probably know this too), 'admin/access' does also break
fixed width themes due to the fact that it expands the width of the
table when more roles are being added..
Good catch! I like it much more this way..
+1 from me...
------------------------------------------------------------------------
Fri, 29 Jul 2005 07:27:34 +0000 : Dries
The code style needs work (spaces, tabs, 'as' -> 'AS'), the code
comments need work, and debug statements should be removed.
Screenshots look good to me. db_query('UPDATE {filter_formats} SET
cache = %d, name = \'%s\', roles = \'%s\' WHERE format = %d',
(int)$cache, $name, $roles, $format); can be written better/shorter
quote-wise.
------------------------------------------------------------------------
Fri, 29 Jul 2005 09:04:16 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_HEAD_0.patch (10.37 KB)
Dries, thanks a lot for the review. OI fixed your comments. Or so I
hope. code-style.pl was of no use (can that *please* be removed from
core?) because it chokes on the help texts. It also pointed out a lot
of old formatting isues, whic, when fixed wuold flood this patch with
unrelated fixes. I tried to narow my style-searching to the areas I
touched. And I made the comments more verbous.
The query is fixed. it saves no characters, but looks better now.
Thanks for the tip.
The print_r..... blush. thats what I get for not running my default
grep -r print_r on my code after finishing up...
I could not find a lot of spaces and tabs. So it lmight be that i
missed one. I triple checked it though.
------------------------------------------------------------------------
Fri, 29 Jul 2005 09:32:21 +0000 : Steven
Moving the role settings inward does fix the wide-table problem, but it
makes the filter configuration much more opaque. We could perhaps fix
this by showing the roles as a comma-separate list in the input formats
table. Such a list can wrap and will not stretch the table.
Other than that:
* Having the instructions for the Roles and Filters form_group() at the
bottom is a bit weird. The distance is too big.
* The table that was used for toggling filters on/off was much more
compact before, and IMO a lot clearer. Why change to a flat list with
the description staggered below each item?
------------------------------------------------------------------------
Fri, 29 Jul 2005 10:31:30 +0000 : Bèr Kessels
consistancy, consistancy and more consistancy.
There really is nothing worse that having a different 'concept' of UI
for every thing in Drupal. We are going in the right direction, with
the blocks being editable objects, menus acting like that, taxonomy,
users, etc..
I wanted to make this act similar. I am not at all happy with the fact
tah the list is still a form. But we need this, for setting the
default.
A big -1 for a comma-separate list. That is extremely hackish, even
worse useabilitywise and just silly
* we should avoid typing when not needed.
* we should avoid errors on input, when they can be avoided (a typo
is made very easy, I know all about it) Form set errors won't fix that
usability -wise.
I agree that you sort-of loose the overview. But IMO that is a minor
loss comared to what we gain, usability-wise.
The wtoo-wide was onlywhat triggered me. But do not think that I am
noly making this patch to fix that issue. This patch is there to
improve usability, through consistancy. o make drupal behave the same
in most places in admin. If you know one screen, you know most of them.
We really should move away from custom-hacks for every page, because
that is useability rule #1: consistancy. Stadardisation, even if
sometimes a custom hack might make things easier in that single case,
it will reduce your overall usability so much that nearly ever it is
worth that hack.
That select-boxes instead of the table issue: consistancy. As well that
it completely broke fluid CSS layouts, my solution is more consistant,
and uses forms the way they are meant. If we cannot use $descritption
in checkboxes they should be removed. but IMO it feels much more
consistant. Tables are for tabular data, and this is simply a list of
items, with additional data.
And i do not really get what you mean with "too far down". Do you mean
that you would like to see the order of the groups different?
------------------------------------------------------------------------
Fri, 29 Jul 2005 13:31:24 +0000 : Dries
I haven't tested Ber's patch yet but looking at the screenshots, it like
what I see. I remember being confused by the current filter UI, and
often, I still am.
------------------------------------------------------------------------
Fri, 29 Jul 2005 19:53:26 +0000 : moshe weitzman
I dislike the recent movement away from overview pages. I think we can
still provide and overview while allowing editing to happen in a
dedicated form. An example in the wrong direction is 'content types'
admin. It is impossible to get an overview, and the listing page is
worthless. I agree with Steven on this one.
It is true that consistency is desirable. But consistent crap is not.
------------------------------------------------------------------------
Fri, 29 Jul 2005 20:02:39 +0000 : killes(a)www.drop.org
I agree with Moshe. Getting a quick overview about what is set how is
essential for an admin.
------------------------------------------------------------------------
Sat, 30 Jul 2005 00:27:15 +0000 : Robrecht Jacques
Overall I like the screenshots. Did not test the patch.
Bèr, what I think Steven (#15) meant by "showing the roles as a
comma-separate list in the input formats table" is that as an overview
page it would be better if you added a list (not an input box!) to
screenshot "input-formats_list1.png" (comment #1). Add a column that
reads "Roles" (or "Enabled for") and then for each row a comma
seperated list of the roles that can use this input format (or maybe
even better a HTML list). You would still need to click "configure" to
_change_ the roles.
The "Default" text (not a radio button) you already show in the
"Options" column is something similar: it immediately shows that this
input format is the default without you having to go to the "configure"
page. Why not do the same for "roles"?
If this is what Steven meant, then I tend to agree with him.
And to help moshe and killes: maybe you could even add a column that
_lists_ the used input filters. Again, only a list, not a way to change
it. That's what the "operations" column is for.
A table like that will "fluid" better than what we have now, still it
is a _complete_ overview of the settings.
I could have misunderstand someone... I have the tendency to do that...
------------------------------------------------------------------------
Mon, 22 Aug 2005 08:21:32 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_interface_improvements.patch (14.52 KB)
by popular demand: a comma separated list.
------------------------------------------------------------------------
Mon, 22 Aug 2005 08:24:31 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/format_now_contains_roles.png (22.09 KB)
and a screenshot
------------------------------------------------------------------------
Mon, 22 Aug 2005 18:39:44 +0000 : Dries
Please check your use of print theme('page', $output). Normally, you
just return $output.
------------------------------------------------------------------------
Mon, 29 Aug 2005 18:54:28 +0000 : Bèr Kessels
All instances of theme('page',...) in filter.module are now changed to
return ... ;
furthermore, the patch is the same.
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:04:02 +0000 : Uwe Hermann
Bèr, I think you forgot to attach your updated patch.
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:27:39 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_interface_improvements_2.patch (13.52 KB)
my email client has this nice warning system for attachements. Maybe
drupal should search for the word attachement too, and when no att.
found give an error ;). Or maybe i should just learn to pay attention.
Guess that is easier.
Anyway, here it is.
------------------------------------------------------------------------
Thu, 08 Sep 2005 20:22:54 +0000 : Dries
I wanted to apply this patch but:
1. I can't change the default input format. 'Save'-button doesn't
work.
2. I got confused by the fact I can't change the roles of the default
filter. I think the form group description should explain this.
3. form_group(t(filter)) should be form_group(t('filter'), ...).
1
0
[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by m3avrck 08 Sep '05
by m3avrck 08 Sep '05
08 Sep '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: m3avrck
Status: patch (ready to be committed)
Just retested with the latest patch I made, applies cleanly against HEAD
and *everything* works great and looks great too. No errors of any kind,
even works on PHP 5.0.5 with no call by reference errors, :D Let's get
this baby in!
m3avrck
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.
------------------------------------------------------------------------
Wed, 31 Aug 2005 00:02:06 +0000 : Morbus Iff
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.
------------------------------------------------------------------------
Wed, 31 Aug 2005 05:53:51 +0000 : Junyor
Since that is also a problem with the old archive.module, I don't see
why it should stop this from getting into core.
------------------------------------------------------------------------
Wed, 31 Aug 2005 06:37:28 +0000 : stefan nagtegaal
"Since that is also a problem with the old archive.module, I don't see
why it should stop this from getting into core.
"
Well, I think it's better to only accept the best code rather than
accepting bugs getting in core.
------------------------------------------------------------------------
Wed, 31 Aug 2005 07:05:51 +0000 : Kobus
I am with Junyor on this. If this can be fixed, great, but if not, it's
not a train smash, as the old one exhibits the same problem.
I say add the new archive module, if there are no other ciritical bugs
with it. It is much more robust and usable than the old one. We
desperately need a new archive module.
I couldn't find any other bugs while testing with the links Morbus
posted. I don't have a HEAD installation anywhere, so can't test it
locally at this moment.
Regards,
Kobus
------------------------------------------------------------------------
Wed, 31 Aug 2005 07:07:49 +0000 : Kobus
BTW, code freeze means no new code added, right?
Can't this module put in Core as is for the code freeze and the bug
sorted out before the official release? Or is that just mean of me to
suggest that?
Kobus
------------------------------------------------------------------------
Wed, 31 Aug 2005 07:13:09 +0000 : Junyor
Stefan: The bug is already in core, since node.module is in core.
Archive.module (old and new!) just shows that bug.
------------------------------------------------------------------------
Wed, 31 Aug 2005 07:20:35 +0000 : Tobias Maier
I want to have it in core for 4.7, too!!!
------------------------------------------------------------------------
Wed, 31 Aug 2005 07:25:24 +0000 : stefan nagtegaal
Junyor: I know that.. Though I think it's not good to accept code which
we are aware of that it has bugs in it..
Offcourse this is very double, because drupal contains (probably) a lot
of bugs, only they weren't spotted yet..
But, accepting code which has bugs in unacceptable imo..
For example, the node revisions patch had almost 40 reviews/rewritings
from Gerhard and several others before it was accepted to be in core..
If we do not allow bugs to go into core, we don't have to bughunt and
fix later which is a good thing..
So, imo we should first sort out the problem, then discuss what the
best way is to fix the problem, and after that Squeeze that moron! ;-)
------------------------------------------------------------------------
Wed, 31 Aug 2005 09:11:06 +0000 : adrian
I vote we include this module, and open up a new issue for the bug.
It's not archive's fault that this occurs, it is just showing the data
it has access to. The bug already exists in core too.
------------------------------------------------------------------------
Wed, 31 Aug 2005 13:50:59 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive_2.module (10.63 KB)
Attached is a new, and most likely final, version of the archive.module.
I've removed all user->timezone references - all date determinations are
based on server time, which is also the time used in the "created"
column of the node table. This is "more accurate" than what the core
archive.module currently does (which'll always be wrong because it's
treating server time as GMT, which isn't always the case). When
node.module does start saving times as GMT properly, archive.module
will have be to be tweaked with timezones and blah blah blah. I did
fiddle around with determining the server offset in an attempt to get
to a GMT base, but I didn't have much luck with that. The NHPR.org URLs
above are still valid for testing.
I need testers and reviewers.
------------------------------------------------------------------------
Wed, 31 Aug 2005 14:55:16 +0000 : m3avrck
I get these two PHP errors when I have *no* content in my Drupal install
(just did a clean install to test it):
warning: mktime() [<a href='function.mktime'>function.mktime</a>]:
Windows does not support negative values for this function in
websites\drupal_cvs\drupal\modules\archive.module on line 274.
warning: date() [<a href='function.date'>function.date</a>]: Windows
does not support dates prior to midnight (00:00:00), January 1, 1970 in
websites\drupal_cvs\drupal\modules\archive.module on line 274.
Once I add content, these go away. Need some better checks to make sure
if there is *no* content you don't get weird errors and what not :)
------------------------------------------------------------------------
Wed, 31 Aug 2005 14:55:45 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/_p_29676_archive_css_0.patch (1.56 KB)
Updated drupal.css patch for HEAD.
------------------------------------------------------------------------
Wed, 31 Aug 2005 15:26:01 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive_3.module (10.75 KB)
Attached is the complete module, fixed for m3avrck's #31.
------------------------------------------------------------------------
Wed, 31 Aug 2005 17:30:36 +0000 : m3avrck
Reviewed patch and further test, running great over here! Definetly +1
for this one!
------------------------------------------------------------------------
Wed, 31 Aug 2005 20:03:36 +0000 : Morbus Iff
Note: The NHPR folks preferred their archives to be sorted from earliest
to latest (SQL ASC vs. DESC) for month/day listings, so no longer use
the NHPR.org URLs above as representative of the module itself.
------------------------------------------------------------------------
Wed, 31 Aug 2005 21:26:37 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/drupal.css (10.35 KB)
CVS updated for HEAD again.
------------------------------------------------------------------------
Wed, 31 Aug 2005 21:27:00 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/_p_29676_archive_css_1.patch (1.56 KB)
GRRR.
------------------------------------------------------------------------
Thu, 08 Sep 2005 20:18:48 +0000 : m3avrck
Attachment: http://drupal.org/files/issues/archive_0.patch (20.72 KB)
Rerolled patch against head. Also created one patch that fixes both
archive.module and drupal.css so it's a clean and simple process now :)
1
0
Issue status update for
http://drupal.org/node/27364
Post a follow up:
http://drupal.org/project/comments/add/27364
Project: Drupal
Version: cvs
Component: filter.module
Category: tasks
Priority: normal
Assigned to: Bèr Kessels
Reported by: Bèr Kessels
Updated by: Dries
-Status: patch (code needs review)
+Status: patch (code needs work)
I wanted to apply this patch but:
1. I can't change the default input format. 'Save'-button doesn't
work.
2. I got confused by the fact I can't change the roles of the default
filter. I think the form group description should explain this.
3. form_group(t(filter)) should be form_group(t('filter'), ...).
Dries
Previous comments:
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:30:54 +0000 : Bèr Kessels
This is a mockup for the Filter UI. Currently it is soo complex, that I
dare to call it broken.
Please comment on this, for I will not ake any patches, when the
general idea is disliked.
The idea is t split filters and input formats better. Filters are
filters, defined in modules. Input formats are bundles of filters. This
is how we have it ATM, but the interface fails to communicate that. I
tried to develop a consistent (with the rest of Drupal) interfce that
makes it clearer what is what.
The menu is as follows:
* administer
** ....
** settings
*** input formats
*** filters
** ...
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:37:10 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_list1.png (16.34 KB)
* administer
** ....
** settings
*** input formats >> see attachement 1
*** filters
**
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:39:02 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_add.png (23.42 KB)
* administer
** ....
** settings
*** input formats >> see attachement 2, tab 2
*** filters
**
Note: The default checkbox lmay seem a bit odd. But checking it will
remove the "default status" from the current "default" one and make
this one "default". The help text, and a drupal_set_message should
explain this.
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:40:08 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit_format.png (22.17 KB)
* administer
** ....
** settings
*** input formats >> clicking a 'configure' link in the table of
attachement 1
*** filters
**
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:40:55 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-filters_list.png (36.24 KB)
* administer
** ....
** settings
*** input formats
*** filters >> see attachement 4
**
------------------------------------------------------------------------
Sun, 24 Jul 2005 09:41:40 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit.png (22.63 KB)
* administer
** ....
** settings
*** input formats
*** filters >> clicking a 'configure' link in the table of attachement
4
**
------------------------------------------------------------------------
Mon, 25 Jul 2005 14:46:27 +0000 : Bèr Kessels
IMO this makes the interface easier. But other disagree. And because it
also removes one feature: (being able to use E.g. HTML in different
input formats, with different settings)
I'll simply wont fix this :(
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:36:12 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy.patch (10.28 KB)
I decided to go for it anyway. Be it in a slightly different way then my
initial mockups. The difference is that I left the filters where they
are, hidden beneath the formats.
So, here is the patch that makes the filter UI more consistent with
screens like blocs, menus, vocabularies et al
also nice to note is that:
93 lines are added, 104 are removed. So netto we have less code :)
(cvs diff filter.module | grep ^+ | wc -l)
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:37:02 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_list_html.png (44.64 KB)
Here is how the listing now looks.
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:37:57 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit_format_html.png (113.71 KB)
And the "configure" screen.
The 'add' screen looks exactly the same, only with the default values
pre-filled.
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:39:19 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/input-formats_edit_format_too_long.png (121.82 KB)
Oh, And here is a really nice example of why the current screen is no
good.
And here I "only" have four roles. I run a site with 12 roles, imagine
this screen then!
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:48:35 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_HEAD.patch (10.24 KB)
And here is a pathc for HEAD (I forgot that I developed this on a 4.6.2
codebase. Sorry)
------------------------------------------------------------------------
Thu, 28 Jul 2005 13:55:25 +0000 : stefan nagtegaal
I like this very, very much!
This is - indeed - much better than the current UI. This always fits,
and makes the life of people who use a fixed width theme much nicer..
Ber, FYI (you probably know this too), 'admin/access' does also break
fixed width themes due to the fact that it expands the width of the
table when more roles are being added..
Good catch! I like it much more this way..
+1 from me...
------------------------------------------------------------------------
Fri, 29 Jul 2005 07:27:34 +0000 : Dries
The code style needs work (spaces, tabs, 'as' -> 'AS'), the code
comments need work, and debug statements should be removed.
Screenshots look good to me. db_query('UPDATE {filter_formats} SET
cache = %d, name = \'%s\', roles = \'%s\' WHERE format = %d',
(int)$cache, $name, $roles, $format); can be written better/shorter
quote-wise.
------------------------------------------------------------------------
Fri, 29 Jul 2005 09:04:16 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_module_UI_consistancy_HEAD_0.patch (10.37 KB)
Dries, thanks a lot for the review. OI fixed your comments. Or so I
hope. code-style.pl was of no use (can that *please* be removed from
core?) because it chokes on the help texts. It also pointed out a lot
of old formatting isues, whic, when fixed wuold flood this patch with
unrelated fixes. I tried to narow my style-searching to the areas I
touched. And I made the comments more verbous.
The query is fixed. it saves no characters, but looks better now.
Thanks for the tip.
The print_r..... blush. thats what I get for not running my default
grep -r print_r on my code after finishing up...
I could not find a lot of spaces and tabs. So it lmight be that i
missed one. I triple checked it though.
------------------------------------------------------------------------
Fri, 29 Jul 2005 09:32:21 +0000 : Steven
Moving the role settings inward does fix the wide-table problem, but it
makes the filter configuration much more opaque. We could perhaps fix
this by showing the roles as a comma-separate list in the input formats
table. Such a list can wrap and will not stretch the table.
Other than that:
* Having the instructions for the Roles and Filters form_group() at the
bottom is a bit weird. The distance is too big.
* The table that was used for toggling filters on/off was much more
compact before, and IMO a lot clearer. Why change to a flat list with
the description staggered below each item?
------------------------------------------------------------------------
Fri, 29 Jul 2005 10:31:30 +0000 : Bèr Kessels
consistancy, consistancy and more consistancy.
There really is nothing worse that having a different 'concept' of UI
for every thing in Drupal. We are going in the right direction, with
the blocks being editable objects, menus acting like that, taxonomy,
users, etc..
I wanted to make this act similar. I am not at all happy with the fact
tah the list is still a form. But we need this, for setting the
default.
A big -1 for a comma-separate list. That is extremely hackish, even
worse useabilitywise and just silly
* we should avoid typing when not needed.
* we should avoid errors on input, when they can be avoided (a typo
is made very easy, I know all about it) Form set errors won't fix that
usability -wise.
I agree that you sort-of loose the overview. But IMO that is a minor
loss comared to what we gain, usability-wise.
The wtoo-wide was onlywhat triggered me. But do not think that I am
noly making this patch to fix that issue. This patch is there to
improve usability, through consistancy. o make drupal behave the same
in most places in admin. If you know one screen, you know most of them.
We really should move away from custom-hacks for every page, because
that is useability rule #1: consistancy. Stadardisation, even if
sometimes a custom hack might make things easier in that single case,
it will reduce your overall usability so much that nearly ever it is
worth that hack.
That select-boxes instead of the table issue: consistancy. As well that
it completely broke fluid CSS layouts, my solution is more consistant,
and uses forms the way they are meant. If we cannot use $descritption
in checkboxes they should be removed. but IMO it feels much more
consistant. Tables are for tabular data, and this is simply a list of
items, with additional data.
And i do not really get what you mean with "too far down". Do you mean
that you would like to see the order of the groups different?
------------------------------------------------------------------------
Fri, 29 Jul 2005 13:31:24 +0000 : Dries
I haven't tested Ber's patch yet but looking at the screenshots, it like
what I see. I remember being confused by the current filter UI, and
often, I still am.
------------------------------------------------------------------------
Fri, 29 Jul 2005 19:53:26 +0000 : moshe weitzman
I dislike the recent movement away from overview pages. I think we can
still provide and overview while allowing editing to happen in a
dedicated form. An example in the wrong direction is 'content types'
admin. It is impossible to get an overview, and the listing page is
worthless. I agree with Steven on this one.
It is true that consistency is desirable. But consistent crap is not.
------------------------------------------------------------------------
Fri, 29 Jul 2005 20:02:39 +0000 : killes(a)www.drop.org
I agree with Moshe. Getting a quick overview about what is set how is
essential for an admin.
------------------------------------------------------------------------
Sat, 30 Jul 2005 00:27:15 +0000 : Robrecht Jacques
Overall I like the screenshots. Did not test the patch.
Bèr, what I think Steven (#15) meant by "showing the roles as a
comma-separate list in the input formats table" is that as an overview
page it would be better if you added a list (not an input box!) to
screenshot "input-formats_list1.png" (comment #1). Add a column that
reads "Roles" (or "Enabled for") and then for each row a comma
seperated list of the roles that can use this input format (or maybe
even better a HTML list). You would still need to click "configure" to
_change_ the roles.
The "Default" text (not a radio button) you already show in the
"Options" column is something similar: it immediately shows that this
input format is the default without you having to go to the "configure"
page. Why not do the same for "roles"?
If this is what Steven meant, then I tend to agree with him.
And to help moshe and killes: maybe you could even add a column that
_lists_ the used input filters. Again, only a list, not a way to change
it. That's what the "operations" column is for.
A table like that will "fluid" better than what we have now, still it
is a _complete_ overview of the settings.
I could have misunderstand someone... I have the tendency to do that...
------------------------------------------------------------------------
Mon, 22 Aug 2005 08:21:32 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_interface_improvements.patch (14.52 KB)
by popular demand: a comma separated list.
------------------------------------------------------------------------
Mon, 22 Aug 2005 08:24:31 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/format_now_contains_roles.png (22.09 KB)
and a screenshot
------------------------------------------------------------------------
Mon, 22 Aug 2005 18:39:44 +0000 : Dries
Please check your use of print theme('page', $output). Normally, you
just return $output.
------------------------------------------------------------------------
Mon, 29 Aug 2005 18:54:28 +0000 : Bèr Kessels
All instances of theme('page',...) in filter.module are now changed to
return ... ;
furthermore, the patch is the same.
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:04:02 +0000 : Uwe Hermann
Bèr, I think you forgot to attach your updated patch.
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:27:39 +0000 : Bèr Kessels
Attachment: http://drupal.org/files/issues/filter_interface_improvements_2.patch (13.52 KB)
my email client has this nice warning system for attachements. Maybe
drupal should search for the word attachement too, and when no att.
found give an error ;). Or maybe i should just learn to pay attention.
Guess that is easier.
Anyway, here it is.
1
0