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
[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Morbus Iff 19 Sep '05
by Morbus Iff 19 Sep '05
19 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: Morbus Iff
Status: patch (code needs work)
Norrin - you'll also need the CSS patch in #36, but that wouldn't cause
what you're seeing. What HEAD are you running? A week old? Two weeks
old? Today? What's your PHP error log say (assuming some sort of error
reporting is enabled).
Morbus Iff
Previous comments:
------------------------------------------------------------------------
Thu, 25 Aug 2005 21:08:49 +0000 : Morbus Iff
Over at http://drupal.org/node/8287, Berkes mentions that the core
archive.module was considered being removed, per a discussion at the
Drupal Sprint. Kjartan also mentions he would "love to have the archive
module improved in general." In chatting with chx about this, he
mentioned codemonkeyx's rewrite sitting in contrib/modules/archive/.
I'll be doing some work with the archive.module over the next few days,
and will be basing my changes around codemonkeyx's version, and making
it compatible with HEAD. This general Issue is to move codemonkeyx's
version into HEAD as a replacement to the existing archive.module. An
unknown version of his replacement can be seen at
http://www.codemonkeyx.net/archive. I'll be running a live HEAD version
soon as well.
These patches were made during the customization of Drupal by
http://www.NHPR.org. In loving support of open source software,
http://www.NHPR.org will continue to contribute patches they feel the
community will benefit from. Questions about this patch should be
directed to morbus(a)disobey.com.
------------------------------------------------------------------------
Fri, 26 Aug 2005 19:45:59 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues_2 (9.56 KB)
As an example of a very early revision, see the attached, with the
following changes from the current contrib CVS:
* removed the year offset from theme_archive_navigation_years, which
controlled how many year links to show at once in the top nav. For
those with sites with more than five years, they'll WANT people to
notice that they have five years, not to have to click on the earliest
date and then have their expectations changed.
* made the "created > $date" in archive_buildQuery "created >= $date"
instead, to allow posts that were created at exactly midnight that day
(like me, by design).
* since there's no block, I made the menu item visible upon first load.
this menu item is given "access content" permissions.
More to come, including doxygen and gmt considerations.
------------------------------------------------------------------------
Fri, 26 Aug 2005 19:47:41 +0000 : Morbus Iff
Might as well start getting a review of it so I can fix 'em as they come
in.
------------------------------------------------------------------------
Fri, 26 Aug 2005 19:56:49 +0000 : Tobias Maier
cant you provide a patch file?
thanks for your work
------------------------------------------------------------------------
Fri, 26 Aug 2005 20:04:01 +0000 : Morbus Iff
The codemonkeyx version is a complete rewrite of the core
archive.module. If I were to create a patch file against core, every
line would be deleted, and every line would be new. Once I finish my
revisions to codemonkey's version, I'll post the final version here, as
well as a patch against his current CVS.
------------------------------------------------------------------------
Fri, 26 Aug 2005 20:09:13 +0000 : Tobias Maier
ok, thanks again :D
------------------------------------------------------------------------
Mon, 29 Aug 2005 13:41:43 +0000 : Junyor
+1 for this change. The archive.module in core is dead.
------------------------------------------------------------------------
Mon, 29 Aug 2005 16:14:30 +0000 : adrian
What is the progress on this morbus ?
------------------------------------------------------------------------
Mon, 29 Aug 2005 16:29:13 +0000 : Morbus Iff
Adrian - I'll be attaching a new version either later today or tomorrow,
with a CHANGELOG. I'll also be running a live version of it over on
NHPR.org for people to play with. The three major things I'm worried
about right now are a) doxygen, b) variable/function naming, c) GMT
considerations. After those, I'll be exploring a patch for my own
needs: the ability to get archives for particular term.
------------------------------------------------------------------------
Mon, 29 Aug 2005 18:53:34 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive.module (9.93 KB)
Here's the latest, with the following changelog:
* reordered some routines to be a little more workflowish.
* renamed archive_buildQuery to archive_build_query.
* general whitespace and formatting cleanup.
* HEADish update: returning $output, not page templating it.
* removed the reference of &$ad in archive_build_query.
* test for the existence of arg(#)'s before validating them.
* archive_validSomething changed to archive_valid_something.
* removed unused vars: cur_date, cur_date_end.
* renamed archive_buildURL to archive_build_url.
* removed the HTML whitespace from the theming.
* twiddled a lot of quotes and apostraphes.
* removed 'future' CSS class. ill-defined.
* reordered/renamed the CSS classes.
------------------------------------------------------------------------
Mon, 29 Aug 2005 18:54:08 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/_p_29676_archive_css.patch (1.56 KB)
And the drupal.css patch.
------------------------------------------------------------------------
Mon, 29 Aug 2005 18:56:29 +0000 : Morbus Iff
This version of the module is currently running live at
http://www.nhpr.org/archive/.
------------------------------------------------------------------------
Mon, 29 Aug 2005 19:59:57 +0000 : Tobias Maier
if i click for example on 2003 it would be good if this would go to
january or december
and marks them that this one will be shown now
as you can see it if you click on january 2003.
it has to select
* on the first:
the first month of writing
* on the last:
the last month of writing
* on every else:
january
I hope you can understand what I mean...
greets tobias
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:17:40 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive_0.module (11.28 KB)
Alright. I've attached another new version that adds a new feature that
wasn't part of the original codemonkeyx CVS, but was chatted about on
the devel list back in April. If this particular feature has bad code
or needs heavy refactoring, certainly consider ONLY the version in
comment #9 (and the matching drupal.css patch in #10).
This new version supports dated archives based on taxonomy tids. It was
a quick addition which NHPR.org needed (for the date nav; the normal tid
archive pager wasn't strong enough for our needs). Since it was a quick
addition, it supports only ONE tid at a time - the 'and/or' syntax for
the taxonomy.module was not brought over. If that syntax was desired,
it'd make more sense to create some sort of API for archive.module so
that other nodes can take advantage of the dated nav in their normal
pages (like node types, users, forums, etc.)
The added code supports term matches at any granularity:
# all node types that match tid 15000 ('The Front Porch')
http://www.nhpr.org/archive/term/15000
# all 2005 node types that match tid 20 ('Health')
http://www.nhpr.org/archive/2005/term/20
# all March, 2003 node types that match tid 9 ('Education')
http://www.nhpr.org/archive/2003/3/term/9
# all July 11, 2003 node types that match tid 49 ('Economy')
http://morbus.totalnetnh.net/nhpr/archive/2002/7/11/term/49
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:27:26 +0000 : Tobias Maier
what does this mean?
"Story Archives of 'archives'
"
on http://www.nhpr.org/archive/term/15000
should this maybe named?
"Archive of 'The Front Porch'"
if I go to http://www.nhpr.org/archive/term/20
I can only read "archives"...
why is there a difference?
- I never tested this module on my test site, because I'm not at home
-
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:29:34 +0000 : Morbus Iff
Tobias: that wouldn't be possible, at least not accurately. The new
archive.module supports browsing by year, month, and day, as you know.
archive/2005 loads up all the data from a particular year and starts
creating a pager out of it. Consider if you have 3 posts in December,
and 15 posts in November. It wouldn't be "right" to highlight December
because the pager display for the entire year would also include some
of November's entries (since 3 is less than the pager increment).
Likewise, if we ONLY showed the items from December, then we wouldn't
have a "pager by year" feature, only a "pager by month (defaulting to
December when none is selected)" feature.
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:30:41 +0000 : Morbus Iff
Tobias: regarding #14, that's an artifact of the templates that I'm
using for NHPR, and has nothing to do with archive.module itself (in
fact, once the anonymous cache expires, you'll see that little oopsie
go away).
------------------------------------------------------------------------
Mon, 29 Aug 2005 20:31:47 +0000 : Tobias Maier
I can see your right :)
I hope it comes in HEAD before tomorrow :D
------------------------------------------------------------------------
Tue, 30 Aug 2005 00:20:12 +0000 : dtan
I apologize if this is already a known issue.
http://www.nhpr.org/archive/2005/9 does not create a link for september
1st, even though there are 2 nodes listed
(http://www.nhpr.org/archive/2005/9/1)
------------------------------------------------------------------------
Tue, 30 Aug 2005 17:11:21 +0000 : Morbus Iff
dtan: I'm pretty sure I know what this is - I'll address it either later
today or tomorrow.
------------------------------------------------------------------------
Tue, 30 Aug 2005 20:49:58 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive_1.module (11.53 KB)
Alright, I've attached a new archive.module - this is the version WITH
term filtering enabled. I can make one without terms if necessary -
otherwise, I'll just work from this one for now. This version fixes the
bug that dtan saw, as a well as a bunch of other off-by-one errors. Of
primary importance, however, is that all mktime's that mattered have
been switched to gmmktime, which was one of the oft-reported Issues
with the old archive.module. I want to eyeball them all again and make
sure they're right though.
The URLs from #13 are still operational and the CSS from #10 is still
required.
------------------------------------------------------------------------
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!
------------------------------------------------------------------------
Thu, 08 Sep 2005 21:26:06 +0000 : Souvent22
+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.
------------------------------------------------------------------------
Mon, 12 Sep 2005 18:55:56 +0000 : m3avrck
Bump to the top, freeze coming soon!!!
------------------------------------------------------------------------
Tue, 13 Sep 2005 18:05:21 +0000 : Cvbge
So, pgsql does not have FROM_UNIXTIME nor MONTH functions...
I'd prefer, if it is possibile, to change the query to not use this
mysql-specific functions, then writing pgsql specific equivalents...
------------------------------------------------------------------------
Tue, 13 Sep 2005 18:39:20 +0000 : Dries
It might be me, but visually, I like the little calendar block better.
Though, this new (slightly ugly) widget is easier to navigate.
I'd like to postpone this patch until after 4.7. While nice, I'm not
convinced this is the right approach. Like, adding the term-magic to
the archive module is more of a hack than anything else. What's next,
adding a uid-check so you can filter by user ID? Or a type check so
you can filter by node type? Ultimately this should be merged into the
tracker module, or better yet, into a generic "query string to node
query"-mechanism. (I've outlined this elsewhere in the issues.)
There is also a bunch of very minor code issues that need to be looked
at.
------------------------------------------------------------------------
Tue, 13 Sep 2005 19:06:57 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive_4.module (11.18 KB)
I've attached an updated version, which includes gmmktime +
user->timezones, as well as changing all date()'s to format_date()'s.
As for nodetypes/users, actually, yeah, NHPR.org is interested in those
filter functionalities too (and actually wanted them a few weeks ago).
Haven't yet addressed the PSQL stuff from Cvbge.
------------------------------------------------------------------------
Tue, 13 Sep 2005 19:09:46 +0000 : Morbus Iff
I'm not entirely convinced that this should be part of tracker.module -
the tracker module is to "track changes" or to "track updates". That's
an entire different problem than archived data, which probably hasn't
been changed for months or even years. I'd hate to see the tracker view
applied to an archive system - I could care less about the titles of a
blog post (which are usually piss-poor), especially when most *entire*
blog posts are small enough to fit into the teaser that the
archive.module shows.
------------------------------------------------------------------------
Wed, 14 Sep 2005 05:45:57 +0000 : Boris Mann
Dries, I agree with Morbus.
I can see what you're thinking with tracker (I think) -- have it handle
read/unread for all sorts of stuff, in which case you'll want all sorts
of filters.
Archive is the place where all content can be navigated primarily by
date. Let's commit this rather than live with the current completely
useless archive.module for another entire release cycle.
------------------------------------------------------------------------
Wed, 14 Sep 2005 06:45:23 +0000 : Bèr Kessels
Dries, I can see your point.
The navigation interfce feels odd. But after some time I found this UI
to be VERY good. it just feels odd because you are used to a calendar,
yet this really is a better interface for browsing dates. It requires
less clicks, offers all possible options in one glance etc.
If we don't go for this archive module. Then please pretty please,
remove at least the other one from core. It is completely useless as
Boris states Better that people must use contribs than something that
makes us look like we code crappy modules for core.
------------------------------------------------------------------------
Wed, 14 Sep 2005 08:14:06 +0000 : Kobus
It would be very sad indeed if this is not included in 4.7! I will
definately replace it on all my local sites though.
I understand the concern that the new widget is not as pretty as the
old one, but in my opinion it is the "resistance to change" that speaks
here. We're so used to think that an archive is square-ish, that this
wide rectangle is a bit awkward at first.
The gain in usefulness and easier navigation is totally making up for
that. It also gives a clearer overview of a time-frame than is
currently the case, so all in all, I am +1 for this.
Regards,
Kobus
------------------------------------------------------------------------
Wed, 14 Sep 2005 08:17:51 +0000 : stefan nagtegaal
Because I would like to to see this hit trunk as much as you all, I'll
volunteer that _after_ this is in, I'll have a look if we can
refactor/spice up the default looking of the new archive.module..
So Dries, any other concerns you have left? ;-)
------------------------------------------------------------------------
Wed, 14 Sep 2005 13:44:14 +0000 : m3avrck
I agree with said points, this module really cleans things up and works
so much better. Let's get this in now and we still have a few weeks
before 4.7 ships. We can deal with any outstanding bugs then... not
that these are really any *new* bugs since they already exist in CVS.
Not to mention this also fixes a slew of bugs with the current
archive.module, so based on that, I think this one should be included.
------------------------------------------------------------------------
Wed, 14 Sep 2005 14:18:05 +0000 : Morbus Iff
Very minor changes in this version: slightly different comments and a "
to ' conversion.
------------------------------------------------------------------------
Wed, 14 Sep 2005 14:19:12 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive_5.module (11.18 KB)
Grr.
------------------------------------------------------------------------
Mon, 19 Sep 2005 19:02:38 +0000 : Norrin
What do I do wrong? I installed the 'archive_5.module' from the post
before. But when I call 'http://www.examplesite.com/archive' all I get
is a blank page.
1
0
19 Sep '05
Issue status update for
http://drupal.org/node/10056
Post a follow up:
http://drupal.org/project/comments/add/10056
Project: Drupal
Version: cvs
Component: node system
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: Anonymous
Updated by: killes(a)www.drop.org
-Status: fixed
+Status: patch (code needs work)
fixing status
killes(a)www.drop.org
Previous comments:
------------------------------------------------------------------------
Sat, 14 Aug 2004 18:17:11 +0000 : Anonymous
Attachment: http://drupal.org/files/issues/node.set-title-field.patch (2.02 KB)
The default "title" field in a node object is useful but not always
appropriate. For some node types it would be preferable to rename the
field for display to users (e.g., from "title" to "name" for a record
of an organization or business), while in others the title might be
best drawn from a combination of other fields (e.g., first_name and
last_name fields,
for a record of an individual).
This patch enables two new alternatives for node titles:
renamingThe title field can be renamed, e.g., from "title" to "name".
substutingOther fields can be substituted for the title field.
The functionality is implemented through a new proposed node hook,
_title_field($op). There are two possible values for $op: "action"
(either "rename" or "substitute") and "names" (a list of field names to
be used in the title field).
Sample uses:
[?PHP
function example_title_field($node, $op) {
switch ($op) {
case 'action':
$return = 'rename';
break;
case 'names':
$return = array('Name');
}
return $return;
}
?]
In this case, since the requested action is "rename", the title field
would be labelled "Name" (instead of "Title") in node add and edit
forms for nodes of type "example".
[?PHP
function example_title_field($node, $op) {
switch ($op) {
case 'action':
$return = 'substitute';
break;
case 'names':
$return = array('first_name', 'last_name');
}
return $return;
}
?]
In this case, no "Title" field would be displayed in node add or node
edit forms of node type "example". Instead, the fields "first_name"
and "last_name" would be concatenated to form a title.
Implementing this patch would significantly increase the flexibility of
the node system, making it feasible to store information of many types
not currently supported because they don't have a "title" attribute.
------------------------------------------------------------------------
Sun, 15 Aug 2004 16:39:37 +0000 : Dries
This is best accomplished through the existing nodeapi hook, using a
separate module.
------------------------------------------------------------------------
Sun, 15 Aug 2004 23:02:13 +0000 : nedjo
Thanks for the suggestion. I did look for a way to accomplish this
through _nodeapi (and other existing hooks), but couldn't see how. The
"title" field is hard-coded into node.module. The _nodeapi hook allows
various types of manipulations, but not, so far as I could see, changes
to elements that have been generated by, e.g., form_textfield() calls.
Are there possibilities I'm missing? Other approaches? Any specific
suggestions as to means we could use to change the hard-coded "title"
field?
------------------------------------------------------------------------
Thu, 19 Aug 2004 18:27:15 +0000 : nedjo
Attachment: http://drupal.org/files/issues/node.set-title-field_0.patch (741 bytes)
Drawing on Dries's suggestion, I've substantially revised this patch to
enable node title field customization with only three additional lines
of code in node.module.
In place of the existing line in function node_form()
<?php
$output .= form_textfield(t('Title'), 'title', $edit->title, 60, 128, NULL, NULL, TRUE);
?>
the patch substitutes a the following:
<?php
$title = variable_get('node_titlefield_'. $edit->type, 'Title');
if(!($title == 'none')) {
$output .= form_textfield(t($title), 'title', $edit->title, 60, 128, NULL, NULL, TRUE);
}
?>
With this change in place, node modules will be able to override the
standard node title label by setting a variable,
node_titlefield_nodetype, where nodetype is the type of node. This
could be done, e.g., in a _settings hook, so that the first time
settings were accessed the module would set the variable:
<?php
if (variable_get('node_titlefield_example', '') == '') {
// since none is already set, set this variable
variable_set('node_titlefield_example', 'Name');
drupal_set_message('Example module initialization completed.');
}
?>
The special value 'none' would suppress the title field altogether in
node forms, used as follows:
<?php
if (variable_get('node_titlefield_example', '') == '') {
// since none is already set, set this variable
variable_set('node_titlefield_example', 'none');
drupal_set_message('Example module initialization completed.');
}
?>
In this case, a _validate hook would be used to set the title field
value. Assuming a module where a first name-last name combination was
to be used for a title:
<?php
function example_validate(&$node) {
if(!(isset($node->title))) {
$node->title = $node->first_name . ' ' . node->last_name;
}
}
?>
In short, this three-line addition to the node.module would
significantly increase the flexibility of the node system by removing
the hard-coded 'Title' field in node add and edit forms and instead
enabling custom labelling or concatenation of the field from other
sources.
------------------------------------------------------------------------
Thu, 19 Aug 2004 18:50:42 +0000 : moshe weitzman
I like this functionality. But the implementation still seems unclean. I
would prefer to simply remove the 'title' form field from node_form()
and require that modules present this field in whatever way they
please. in some cases, they will use a hidden form field because no
customer interaction is required. This causes a break with backward
compatibility, but cleanliness is facored over compatibilityness (when
you must choose).
I'm moving this back to 'Active', since I don't think this patch is
committable as is.
------------------------------------------------------------------------
Fri, 27 Aug 2004 23:46:45 +0000 : nedjo
Attachment: http://drupal.org/files/issues/node.set-title-field_1.patch (830 bytes)
Thanks for looking at this. The suggestion - dropping the title field
altogether and leaving this for module authors - has the advantage of
simplicity. However, this change would imply significant new work as it
would would require all or nearly all existing modules - core and
contributed - be modified. While I think enabling title field
customization is important for Drupal as a whole, and while this is a
change I need for two modules I'm working on, I'm not immediately
convinced that the benefits of this change justify this cost. Also, in
most cases, the present title field works fine, so keeping it as a
default option would I feel be desirable.
Hence the following patch. In place of my (poorly conceived) initial
hook proposals, above, this patch introduces a single very
straightforward new node hook, _title_field. By setting this hook to
return FALSE, node modules authors will suppress the default title
field, and be free therefore to substitute what they wish or need.
Returning TRUE, or not using the hook, will result in the default title
field being used.
Sample usage:
<?php
function example_title_field() {
return FALSE;
}
?>
This is, I feel, a much better solution than the previous two I
suggested--proof, if it's true, that the Drupal issue system works!
------------------------------------------------------------------------
Mon, 06 Sep 2004 15:50:38 +0000 : nedjo
Are there any objections to or issues raised by this small patch
(introducing a new hook to make the title field optional in node
forms)? If not, can it be applied?
------------------------------------------------------------------------
Tue, 07 Sep 2004 13:46:29 +0000 : Anonymous
I think I agree with Moshe's opinion that this should be accomplished by
having node modules display the title field. In any event, this is a new
feature and shouldn't go in during the feature freeze for 4.5.
------------------------------------------------------------------------
Tue, 07 Sep 2004 13:58:34 +0000 : ccourtne
+1 for just moving the title field to be a responsibility of the
implementing module instead of node_form. There is already to some
extent "hook overload", in addition there may be several modules which
don't want to even display a title module. Why add that only fixes
some of the problems just to have to remove it later when you make a
fix that address the whole problem.
------------------------------------------------------------------------
Tue, 07 Sep 2004 21:09:53 +0000 : nedjo
Attachment: http://drupal.org/files/issues/node.remove-title-field.patch (636 bytes)
Thanks for comments. As per feedback, the attached patch removes the
title field from node forms, leaving this instead to node modules.
Understood that possible approval of this patch this will need to wait
until code unfrozen.
------------------------------------------------------------------------
Sun, 24 Oct 2004 12:06:46 +0000 : moshe weitzman
please patch all core node modules as well.
------------------------------------------------------------------------
Sun, 28 Nov 2004 01:00:31 +0000 : nedjo
Attachment: http://drupal.org/files/issues/node-move-form-title-field.patch (4.29 KB)
Good point Moshe. This patch of node.module plus all core node modules
simply moves the title field out of node.module and into the node
modules, enabling (if desired) customization of the title field by a
module. Patches to contributed modules will in most cases be as simple
as adding the line
<?php
$output = form_textfield(t('Subject'), 'title', $node->title, 60, 128, NULL, NULL, TRUE);
?>
at the beginning of a typename_form() function (and, if necessary
changing an existing $output = to $output .=). In the attached patch,
I've customized the title field for only one of the node types, calling
the title of a forum topic the "Subject". We could consider calling the
title of a blog a "Subject" or "Topic" as well.
I feel this is a good solution (thanks for the feedback and discussion)
and, for minimal work (minor updates to contributed modules), will have
the significant benefit of enabling flexibility in content types beyond
those that have "title" attributes.
------------------------------------------------------------------------
Sun, 28 Nov 2004 17:45:35 +0000 : nedjo
Ability to customize title as provided in this patch was requested here
[1]:
"When adding/editing, the 'title' field is manditory, which is fine.
Except that its label is hardcoded to 'title'. A custom node modelling,
say, a 'Company' would much rather this field be presented to the user
as 'Company Name'.
"
[1] http://drupal.org/node/13596
------------------------------------------------------------------------
Fri, 04 Mar 2005 03:44:55 +0000 : nedjo
Here's another patch that's sat for months without being either applied
or turned down, although there was expressed support and, after several
iterations, it addressed all issues that had been raised. The point is
to remove the hard-coded "Title" field - inapprioriate for many node
types, e.g., companies - from node forms, instead allowing node modules
to treat this as appropriate (e.g., a "Subject", "Name" or "Topic", or
nothing at all).
Are there problems with this approach that were not raised? Is there a
reason this wasn't accepted?
------------------------------------------------------------------------
Fri, 04 Mar 2005 03:54:02 +0000 : Steven
nedjo: if you read the backlog you can see that this feature was delayed
for after the 4.6 release.
"I've customized the title field for only one of the node types,
calling the title of a forum topic the "Subject".
"
This is really inconsistent, as what you call the title of a blog,
story or forum node is purely subjective. "Subject" "Topic" and "Title"
are pretty much interchageable and any subtle differences will surely be
eroded by translation. The only thing I can agree on so far is naming a
polls' title "Question".
------------------------------------------------------------------------
Fri, 04 Mar 2005 05:15:03 +0000 : nedjo
Thanks for the note. I'm not sure what you mean by the "backlog".
Where would I find this? I agree that a "Question" field would make
sense for polls.
------------------------------------------------------------------------
Fri, 04 Mar 2005 14:12:56 +0000 : JonBob
Actually UnConeD, it was postponed until after the 4.5 release, not 4.6,
and looks like everyone forgot about it when the release happened. And
no, Nedjo, I don't take this as proof that Drupal needs more
bureaucracy. :-)
Marking this active again; I'm sure the patch will have to be updated
once the code branches. We had rolled this function into the needs for
CCK, but in our discussions split it off again.
------------------------------------------------------------------------
Sun, 03 Apr 2005 05:28:08 +0000 : chx
Attachment: http://drupal.org/files/issues/node-move-form-title-field_0.patch (4.59 KB)
The patch applies to ucrrent HEAD with some offset. I have rerolled it
so it applies cleanly.
------------------------------------------------------------------------
Fri, 20 May 2005 10:09:50 +0000 : chx
Patch still applies (yes, with some offset, but applies). ANd yes, we
need this very badly.
------------------------------------------------------------------------
Fri, 20 May 2005 10:18:49 +0000 : Thox
I'd benefit greatly from having a feature like this. The example already
given is one of the cases I need it: I'd like the title field to be a
concatenation of two fields: "First name" and "Last name".
------------------------------------------------------------------------
Tue, 24 May 2005 03:39:40 +0000 : gsperk
I wonder if someone could help me with the following problem.
After applying the patch I made the output for 'title' in my
own_node.module this:
$output .= form_hidden('title', $node->firstname . ' ' .
$node->surname);
When the form is first submitted I get the error 'You have to specify a
title'. When I submit again the firstname/surname variables are
obviously in $node, and the form submits with the desired title.
So, I suppose my question is, how can get the values for firstname and
surname into $node without submitting twice? (If it's not obvious I can
confirm that I dont have much experience with this kind of stuff. Any
suggestions would be a big help.)
------------------------------------------------------------------------
Wed, 25 May 2005 04:23:41 +0000 : Steven
To make this patch work you also need to move the title validation out
of node.module and into the node modules. I don't think this is that
much of a problem, it is code that is not going to be touched much.
Also, in light of the upcoming CCK it makes sense to do it like this.
------------------------------------------------------------------------
Sat, 02 Jul 2005 17:02:26 +0000 : hanoii
Nice thread.
I have come up with a slightly different approach I think that would
need less patching/updating of other modules.
Drupal 4.6.2
node.module:1275
<?php
// Get the node-specific bits.
// We can't use node_invoke() because $param must be passed by reference.
$function = node_get_module_name($edit) .'_form';
$param = array();
if (function_exists($function)) {
$form .= $function($edit, $param, $title);
}
?>
Notice the $title param on the hook_form invoke. This was what I added.
As that hook is called like this an not with the node_invoke() I can
define on my custom node module, or patch any module I need to modify
the title description with the following hook:
<?php
function budget_form(&$node, &$params, &$title) {
?>
and modify the $title argument there, as it is by reference, It will me
modified on node.module.
Then again on
node.module:1319
I added/changed the following:
<?php
if ( ! $title ) {
$title = t('Title') ;
}
$output .= form_textfield($title, 'title', $edit->title, 60, 128, NULL, NULL, TRUE);
?>
So, if the module modify the title var, it uses that, if not, it uses
the default one.
Worked for me so far, nice to post on drupal.
Greetings,
a.=
------------------------------------------------------------------------
Sat, 02 Jul 2005 18:10:28 +0000 : hanoii
I posted too soon the thing before... :)
I did further patches because of the validation keep telling that I
have tu put a "title".
I was happy with the previous patch, not so much with this one, but I
let you know what I did...
on the node.module, node_validate() function I move the title
validation block just after the
<?php
// Do node-type-specific validation checks.
node_invoke($node, 'validate');
node_invoke_nodeapi($node, 'validate');
?>
and added another parameter to the form_set_error()
<?php
// Validate the title field.
if (isset($node->title)) {
if (trim($node->title) == '') {
form_set_error('title', t('You have to specify a title.'), TRUE);
}
}
?>
then, on the form_set_error function in common.inc I did the following:
<?php
/**
* File an error against the form element with the specified name.
*/
function form_set_error($name, $message, $checkexistance = FALSE ) {
if ( !$checkexistance || $checkexistance && !isset($GLOBALS['form'][$name]) ) {
$GLOBALS['form'][$name] = $message;
drupal_set_message($message, 'error');
}
}
?>
So now, if any previous title error was added, and the $checkexistance
flag is TRUE, no error will be added to the message queue.
The moving place of the validation block was to let the modules
validate first than the node module.
Errrr.. I don't like it, but again, it worked :)
a.=
------------------------------------------------------------------------
Mon, 01 Aug 2005 00:54:22 +0000 : killes(a)www.drop.org
Attachment: http://drupal.org/files/issues/title_0.patch (4.56 KB)
I've updated the patch to apply to current cvs. As progress on the CCK
has been rather slow, I'd appreciate if somebody could address Steven's
concerns and the patch could be applied.
------------------------------------------------------------------------
Tue, 16 Aug 2005 19:19:23 +0000 : Thox
Attached is a patch with an attempt to move the title validation code
into the node modules (from node.module).
------------------------------------------------------------------------
Tue, 16 Aug 2005 19:20:21 +0000 : Thox
Attachment: http://drupal.org/files/issues/title-validation.patch (6.22 KB)
attached again (issue preview seems busted?)
------------------------------------------------------------------------
Wed, 24 Aug 2005 18:57:26 +0000 : nedjo
Thanks chx, killes, and Thox for updates and fixes on the patch.
I've applied and tested it and Thox's changes seem to address the title
validation issue.
It's a couple of releases later--it would be great to see this fix
applied!
------------------------------------------------------------------------
Wed, 24 Aug 2005 23:17:25 +0000 : matt westgate
Attachment: http://drupal.org/files/issues/title-validation_0.patch (6.04 KB)
+1
I've needed to change the name of the title field or even altogether
hide it for custom modules.
Issue preview was working for me.
We should document for module developers the implications title-less
nodes (e.g., less informative watchdog entries, harder to edit nodes,
node title lists become buggy, etc).
I couldn't get the patch to apply cleanly to HEAD so here's a new one.
------------------------------------------------------------------------
Mon, 12 Sep 2005 15:42:30 +0000 : Robrecht Jacques
Attachment: http://drupal.org/files/issues/title-validation_1.patch (6.23 KB)
+1 I need this too: I want to be able to set the title of a node
automatically.
Patch still applies with offset (rerolled patch attached).
------------------------------------------------------------------------
Tue, 13 Sep 2005 13:59:39 +0000 : fago
+1 for this functionality
i've tested the patch and it looks nice, however node_validate_title()
produces an validation error, where the field is called title, which
isn't suitable if the modules changes the name, as the forum.module
does.
------------------------------------------------------------------------
Tue, 13 Sep 2005 15:50:15 +0000 : Thox
Perhaps node_validate_title() should be passed the name of the field?
'Title' by default.
------------------------------------------------------------------------
Fri, 16 Sep 2005 13:22:24 +0000 : fago
Attachment: http://drupal.org/files/issues/nodetitle-updated.patch (7.05 KB)
i've updated node_validate_title() as thox suggested and added a title
"question" to the poll.module, as there was no title field for it.
------------------------------------------------------------------------
Fri, 16 Sep 2005 14:01:17 +0000 : fago
Attachment: http://drupal.org/files/issues/nodetitle-updated2.patch (7.13 KB)
updated the patch again.
now node_validate_title() takes the whole error message as optional
second parameter as this allows more customization by modules.
------------------------------------------------------------------------
Mon, 19 Sep 2005 18:49:25 +0000 : Dries
I'm cool with this patch but don't like node_validate_title(). Can't we
simply this function? 3 nested ifs are somewhat hairy. Can we beautify
this a little?
1
0
[drupal-devel] [feature] Replace core archive.module w/ codemonkeyx archive.module
by Norrin 19 Sep '05
by Norrin 19 Sep '05
19 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: Norrin
Status: patch (code needs work)
What do I do wrong? I installed the 'archive_5.module' from the post
before. But when I call 'http://www.examplesite.com/archive' all I get
is a blank page.
Norrin
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!
------------------------------------------------------------------------
Thu, 08 Sep 2005 21:26:06 +0000 : Souvent22
+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.
------------------------------------------------------------------------
Mon, 12 Sep 2005 18:55:56 +0000 : m3avrck
Bump to the top, freeze coming soon!!!
------------------------------------------------------------------------
Tue, 13 Sep 2005 18:05:21 +0000 : Cvbge
So, pgsql does not have FROM_UNIXTIME nor MONTH functions...
I'd prefer, if it is possibile, to change the query to not use this
mysql-specific functions, then writing pgsql specific equivalents...
------------------------------------------------------------------------
Tue, 13 Sep 2005 18:39:20 +0000 : Dries
It might be me, but visually, I like the little calendar block better.
Though, this new (slightly ugly) widget is easier to navigate.
I'd like to postpone this patch until after 4.7. While nice, I'm not
convinced this is the right approach. Like, adding the term-magic to
the archive module is more of a hack than anything else. What's next,
adding a uid-check so you can filter by user ID? Or a type check so
you can filter by node type? Ultimately this should be merged into the
tracker module, or better yet, into a generic "query string to node
query"-mechanism. (I've outlined this elsewhere in the issues.)
There is also a bunch of very minor code issues that need to be looked
at.
------------------------------------------------------------------------
Tue, 13 Sep 2005 19:06:57 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive_4.module (11.18 KB)
I've attached an updated version, which includes gmmktime +
user->timezones, as well as changing all date()'s to format_date()'s.
As for nodetypes/users, actually, yeah, NHPR.org is interested in those
filter functionalities too (and actually wanted them a few weeks ago).
Haven't yet addressed the PSQL stuff from Cvbge.
------------------------------------------------------------------------
Tue, 13 Sep 2005 19:09:46 +0000 : Morbus Iff
I'm not entirely convinced that this should be part of tracker.module -
the tracker module is to "track changes" or to "track updates". That's
an entire different problem than archived data, which probably hasn't
been changed for months or even years. I'd hate to see the tracker view
applied to an archive system - I could care less about the titles of a
blog post (which are usually piss-poor), especially when most *entire*
blog posts are small enough to fit into the teaser that the
archive.module shows.
------------------------------------------------------------------------
Wed, 14 Sep 2005 05:45:57 +0000 : Boris Mann
Dries, I agree with Morbus.
I can see what you're thinking with tracker (I think) -- have it handle
read/unread for all sorts of stuff, in which case you'll want all sorts
of filters.
Archive is the place where all content can be navigated primarily by
date. Let's commit this rather than live with the current completely
useless archive.module for another entire release cycle.
------------------------------------------------------------------------
Wed, 14 Sep 2005 06:45:23 +0000 : Bèr Kessels
Dries, I can see your point.
The navigation interfce feels odd. But after some time I found this UI
to be VERY good. it just feels odd because you are used to a calendar,
yet this really is a better interface for browsing dates. It requires
less clicks, offers all possible options in one glance etc.
If we don't go for this archive module. Then please pretty please,
remove at least the other one from core. It is completely useless as
Boris states Better that people must use contribs than something that
makes us look like we code crappy modules for core.
------------------------------------------------------------------------
Wed, 14 Sep 2005 08:14:06 +0000 : Kobus
It would be very sad indeed if this is not included in 4.7! I will
definately replace it on all my local sites though.
I understand the concern that the new widget is not as pretty as the
old one, but in my opinion it is the "resistance to change" that speaks
here. We're so used to think that an archive is square-ish, that this
wide rectangle is a bit awkward at first.
The gain in usefulness and easier navigation is totally making up for
that. It also gives a clearer overview of a time-frame than is
currently the case, so all in all, I am +1 for this.
Regards,
Kobus
------------------------------------------------------------------------
Wed, 14 Sep 2005 08:17:51 +0000 : stefan nagtegaal
Because I would like to to see this hit trunk as much as you all, I'll
volunteer that _after_ this is in, I'll have a look if we can
refactor/spice up the default looking of the new archive.module..
So Dries, any other concerns you have left? ;-)
------------------------------------------------------------------------
Wed, 14 Sep 2005 13:44:14 +0000 : m3avrck
I agree with said points, this module really cleans things up and works
so much better. Let's get this in now and we still have a few weeks
before 4.7 ships. We can deal with any outstanding bugs then... not
that these are really any *new* bugs since they already exist in CVS.
Not to mention this also fixes a slew of bugs with the current
archive.module, so based on that, I think this one should be included.
------------------------------------------------------------------------
Wed, 14 Sep 2005 14:18:05 +0000 : Morbus Iff
Very minor changes in this version: slightly different comments and a "
to ' conversion.
------------------------------------------------------------------------
Wed, 14 Sep 2005 14:19:12 +0000 : Morbus Iff
Attachment: http://drupal.org/files/issues/archive_5.module (11.18 KB)
Grr.
1
0
Issue status update for
http://drupal.org/node/27958
Post a follow up:
http://drupal.org/project/comments/add/27958
Project: Drupal
Version: cvs
Component: user.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: kubaZygmunt
Updated by: kubaZygmunt
Status: patch (code needs review)
Attachment: http://drupal.org/files/issues/unique.roles.patch.txt (1.61 KB)
I've added code which prevents user from submiting 2 roles with the same
name.
kubaZygmunt
4
4
I had a vivid hallucination that someone was working on importing
Docbook XML as "book" content types. Please tell me that it wasn't a
dream :-)
Robert
3
2
Issue status update for
http://drupal.org/node/28604
Post a follow up:
http://drupal.org/project/comments/add/28604
Project: Drupal
Version: cvs
Component: base system
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: Dries
Updated by: m3avrck
Status: patch (code needs review)
Well first off, just wanted to say I'm currently evaluating this and
been sending regular feedback to killes for improvements. So far so
good on PHP5 machines :-)
But in terms of where should this code go, I think mail.module should
be eliminated and those functions should be put in mail.inc which
*should* be seperate from common.inc. This way, as Drupal grows and
more and more modules depend upon mail functions, they will be in their
unqiue spot which can easily be patched and extended instead of
rummaging through the common.inc mess ;-)
As a result, the mail.module settings should be moved to Admin >
Settings with the mail setup there, since the basic Drupal "request new
password" etc framework requires mail functionality and having these
settings there makes the most sense, usability wise.
I think with this setup the code could be organized in the cleanest and
most straightforward method and would be an elegant refinement in mail
handling for 4.7... no new features, just cleaned up and seperate for
other modules to make use of, instead of duplicating code and time.
This also has the benefit of bringing in more patches to the Drupal
core and how it handles mail and making it rock solid.
Just my 2 cents.
m3avrck
Previous comments:
------------------------------------------------------------------------
Wed, 10 Aug 2005 12:35:37 +0000 : Dries
It was suggested that we separate the mail backend from the front-end.
We might want to include the mail backend in core as includes/mail.inc.
Then, other modules like massmailer, subscriptions, notify, pm (private
messages), project (project issues), contact, etc. could reuse this
component. The mail.inc file would implement some kind of mail queue
functionality, and modules just add a mail to the mail queue using a
simple /mail API/. In future, the mail backend could deal with bounces
and report back proper status codes. Moreover, mail.inc would be
pluggable so it could be replaced by a more powerful one, or one that
is build specifically for the underlying mail transport (SMTP server).
Furthermore, this would solve issues with how many mails get send
within a specified interval. Like, when more than one module sends out
e-mails it is hard to enforce limitations/restrictions imposed by the
hosting company.
I'm posting this here so you can keep this in mind when working on
simplenews, and to solicit for feedback. Chances are we'll setup an
IRC meeting to discuss this further. Details to follow.
------------------------------------------------------------------------
Wed, 10 Aug 2005 16:15:16 +0000 : Amazon
A good place to start would be to look at existing Mail API's
Pear Mail: http://pear.php.net/package/Mail
Pear Mail tutorial:
http://www.zend.com/pear/tutorials/Mail.php#Heading2
------------------------------------------------------------------------
Wed, 10 Aug 2005 20:21:57 +0000 : walkah
um. +1 and then some. I think this is good... and some good references
from Amazon. I'll throw in one other :
http://phpmailer.sf.net/ - has great mime handling (i've run into
issues with PEAR::Mail's mime handilng in the past, but that was around
2 years ago, and things may have gotten better since then).
Oh - and you don't mention it - but support for multipart / mime
messages would be lovely :)
I'd be interested in / happy to sit in on any IRC discussion as well.
------------------------------------------------------------------------
Wed, 10 Aug 2005 21:40:34 +0000 : robertDouglass
phpmailer++
I've used it and like how easy it is to send both text and html mail.
Did I say html mail? You bet! It's time that we had the option.
------------------------------------------------------------------------
Thu, 11 Aug 2005 05:47:01 +0000 : cyberchucktx
I'm definitely interested.
Hopefully by adding a post to this I'll get notified on new postings
(?)
If not I may miss the IRC ..
I've been doing a lot of work with safe_mode PHPLIST (have posted to
the drupal site somewhee, can dig out the reference if anyone is
interested).
Charlie in TX
------------------------------------------------------------------------
Wed, 17 Aug 2005 08:42:34 +0000 : Dries
It was suggested that mail.inc also provides a HTML to text services.
Lots of modules (newsletter, notify, project) try converting HTML to
text. Having a reusable function makes sense, and will lead to better
conversion routines. XSLT anyone?
------------------------------------------------------------------------
Wed, 17 Aug 2005 12:31:27 +0000 : Grugnog2
+1 for phpmailer
I found it very easy to use - and most importantly for me - it supports
SMTP authentication. As many ISP's will not let you send mail without
using SMTP-auth nowadays it may be worth this feature is incorporated
into the mail.inc API.
- Grug
------------------------------------------------------------------------
Wed, 17 Aug 2005 15:08:43 +0000 : Robert Castelo
For about a year now I've been working on an email newsletter and
announcement module [1]. There's a version in my sandbox commited about
2 months ago which works fairly well. Dan Robinson and Varr Willis at
CivicActions, Moshe Weitzman plus a few others have been testing it,
and I've had lots of positive feedback and feature and bug reports from
them.
A few months ago a realised that there's not much point in putting so
much effort into creating all this functionality, only for it to be
locked away in my module. Better to
Better to create discreet component modules which provide a particular
service, such as bounced email handling, but which can be used by any
other module that also needs that service.
For the last two months I've been working to split functionality into
component services modules and make these services available to all
modules.
One of the biggest challenges was to make these component modules
independent of each other. The only area where I haven't managed this
is some of the database calls - but thanks to a chat with chx I
realised that db_rewrite_sql could be used to handle this very nicely.
This is what I have:
* bounced_email.module - process bounced emails
* html2text.module - convert HTML to plain text equivalent (e.g. list
item becomes "* item")
* identity_hash.module - manages full and partial loggin based on hash
which can be used in email links
* publication.module - defines and packages content of publication,
which could be any kind of publication
* schedule.module - defines and manages schedules, e.g. email sending
schedule
* subscribed.module - manages subscriptions to publications
* templates.module - manage and define templates
What's great is that the component modules are not limited to email,
they could be used to quickly create RSS newsletters, PDF newsletters,
text message newsletters, or even personalised/filtered website
sections.
I haven't made the new component modules available anywhere yet, but
I'll be happy to upload them to contrib and let others get involved.
What would be the best way to commit them - as a single directory? or
each component module in it's own directory?
[1]
http://www.cortextcommunications.com/development/newsletter/features
------------------------------------------------------------------------
Thu, 15 Sep 2005 02:05:18 +0000 : vwX
Attachment: http://drupal.org/files/issues/mailqueue.tar.gz (3.71 KB)
This is a very basic mail queue system I would like to contribute.
There are some changes to other modules that will have to be made such
as changing user.module to use this instead of directly calling the php
mail function and moving mime_header_encoding to mail.inc.
------------------------------------------------------------------------
Thu, 15 Sep 2005 15:25:11 +0000 : killes(a)www.drop.org
Note: I am moving this to the main project.
VwX: What I see looks very nice for a start. Some polishing is
certainly needed, but I'd like to try this. If I only had the time...
------------------------------------------------------------------------
Fri, 16 Sep 2005 22:10:19 +0000 : killes(a)www.drop.org
Ok, I've been doing some clean-up on this one and made contact.module
use it. The module and the .inc file work.
I've put the files into my sandbox for now. I plan to work on them over
the weekend (unless Dries tells me they are too late for 4.7).
http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/killes/mail/
But I could use some input:
- the sql file defines a column to store the module that generated the
mail. Do we want this? If yes, we need to fix it.
- Do we need a throttle for only sending x mails per cron run?
- can somebody try the files with php5?
- what else do we need?
Please give input, links and what not.
------------------------------------------------------------------------
Sat, 17 Sep 2005 20:34:04 +0000 : Dries
Some of my comments might be false. If so, sorry. I only looked at it
for 5 minutes:
* I wonder why we need per-module settings. I can't think of concrete
use cases.
* For consistency, mailid needs to be mid.
* I don't see an option to send mails immediately?
* I don't see any "messages per hour" accounting?
* I don't understand why mail.inc should be node system aware?
* mailid = '%s' should be mailid = %d.
* Incorrect use of t(): don't translate user input.
* The coding style needs work; inconsistent variable names,
inconsistent spacing, etc.
* Some PHPDoc is rather cryptic: /Updates table mail queue address
table sets sent flag to 1 for a queued msg./.
------------------------------------------------------------------------
Sun, 18 Sep 2005 04:28:11 +0000 : killes(a)www.drop.org
I've fixed a number of things. needs testing.
------------------------------------------------------------------------
Mon, 19 Sep 2005 02:28:25 +0000 : killes(a)www.drop.org
Ok, changed and tested.
Some more changes, taken some concepts from massmailer.module.
Included hacked copies of simplenews and contact module for testing
purposes.
We need to discuss if this should be a module or a part od
system.module.
depending on the outcome we need to put the functions in mail.module
and mail.inc into different files.
Testers welcome.
------------------------------------------------------------------------
Mon, 19 Sep 2005 06:31:04 +0000 : Peter Apockotos
Dries,
Are you talking about something like I request here
http://drupal.org/node/28079 ?
1
0
Issue status update for
http://drupal.org/node/31326
Post a follow up:
http://drupal.org/project/comments/add/31326
Project: Drupal
Version: cvs
Component: system.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: der
Updated by: der
Status: patch (code needs review)
Attachment: http://drupal.org/files/issues/control_panel_1.patch (5.64 KB)
Sorry for the excessive number of patches. I just realized that my
previous patch had an issue with icon image file names if there were
admin and admin/settings menu items that were the same (eg admin/user
and admin/settings/user).
New patch attached to address.
der
Previous comments:
------------------------------------------------------------------------
Thu, 15 Sep 2005 17:50:52 +0000 : der
Attachment: http://drupal.org/files/issues/system_9.patch (4.27 KB)
New feature suggestion:
I would like to suggest a couple of enhancments to administration
pages.
First, add a new general settings option to allow the user to specify
the admin home page. Currently the watchdog log view is the default
home page.
Second, add a new control panel page that can be used as the default
admin start page.
I've attached a suggested patch to the CVS head version of the
system.module that implements these two enhancements. The patch does
the following.
Adds a new "default admin page" text field to the general settings
group (just after the "default front page"). It also changes the admin
menu entry to call a new function that examines the default "admin page"
variable and redirects to the appropriate path. For the control panel,
the patch adds a new function (system_admin_controlpanel). This
function basically looks for the admin entry in the menu structure and
then iterates through the child menu items and builds a control panel
page using the path and title information returned from the menu
structure. For the control panel icons it looks for an icon file in the
misc directory that matches the name of the menu item (e.g. user.png,
access.png etc) If it doesn't find an icon it uses a default. I've
also included some 48/48 icons that I borrowed from my
usr/share/icon/gnome directory of my local Linux box. I believe these
are gnome GPL'ed icons but any 48/48 icons could be used.
This patch allows users who prefer the current functionality to keep it
as their default. It provides the option for others to make any admin
page they want to be their admin "home page" including using a
graphical control panel. Module developers that add new admin menu
options can add their own custom icons for the control panel but they
are not "required" to do so as a default will be used if they don't
provide one.
------------------------------------------------------------------------
Thu, 15 Sep 2005 17:52:15 +0000 : der
Attachment: http://drupal.org/files/issues/drupal_controlpanel_icons.zip (39.09 KB)
48x48 icons attached
------------------------------------------------------------------------
Fri, 16 Sep 2005 14:30:16 +0000 : der
Attachment: http://drupal.org/files/issues/system_2_0.patch (4.5 KB)
updated patch. slightly changed the formatting of the control panel
page
------------------------------------------------------------------------
Sat, 17 Sep 2005 00:37:24 +0000 : moggy
I quite like this. It certainly goes some way to making Drupal easier on
the eyes for first time users.
I noticed there's a lot of hard coded style. Would this not be better
in a stylesheet and the code just containing classes and ids?
Also would a dropdown box of possible admin pages be better than trying
to remember how to spell controlpanel (something I'm having trouble with
tonight ;-) )
------------------------------------------------------------------------
Sat, 17 Sep 2005 13:02:08 +0000 : syllance
Nice job :)
the default admin page is a nice feature, and the controlpanel is a
very good idea. This goes in the good direction to make Drupal more
user friendly.
i agree with the dropdown menu and stylesheet additions, but i already
really appreciate the current version.
hope this will go into core soon, as it really makes the first admin
pages contact better :)
i don't mind scrolling through the nav menu and i rarely goes into
admin without checking the logs, but that definitely will help me
converting my wife's site to drupal :p
thanks !
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:09:43 +0000 : der
I'll move the styles off to a style sheet but I'm uncertain about
whether or not make make the default admin page a dropdown. It's an
easy change and it eliminates any typos by the user but it also
restricts the user to a current visible admin menu item. If by chance
someone wanted to write their own admin start page (ie their own control
panel) they would have to hack the core system.module to do it.
Anyone else want to weigh in with their preference?
Also, anyone up for creating drupalized versions of the control panel
icons?
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:16:15 +0000 : chx
Maybe just because I created it, I like my control panel module better.
------------------------------------------------------------------------
Sat, 17 Sep 2005 16:25:30 +0000 : der
If I would have known there was a module I wouldn't have written this
patch although I do think this would be good for core Drupal as the
default.
Is your modules a recent creation? I don't see it on drupal.org nor
could I find in the contribs section of CVS (either the modules or
sandbox sections). I'm I missing something? Is it called something
different?
------------------------------------------------------------------------
Sat, 17 Sep 2005 18:20:15 +0000 : syllance
chx control panel is located in his sandbox (cp.module), and thanks to
him for letting us know there's one :)
it's working fine (tested on HEAD) and provide interesting concept for
navigating through the admin, instead of just add a frontend. the
settings part is the better one, listing all elements in the page makes
quickly forget the standard menu.
der's one looks nice and provide a more immediate access to admin
pages, but the standard menu is still mandatory to access some elements
(dba or store settings for example, still needs to be accessed via left
menu).
to be honest, i like them both :)
being able to change the default admin page is very nice, and icons
make admin looks a lot better, raising the Woman Acceptance Factor by a
huge amount (my wife loves it :). but i also really like the more in
depth admin navigation offered by chx module.
mixing both on my head setup gives a nice result, so may be it would be
a good idea to join forces and mix the 2 panels.
chx, is your module somewhat official and scheduled to hit the core ?
------------------------------------------------------------------------
Sat, 17 Sep 2005 19:24:11 +0000 : Amazon
Hi, I asked Karoly to create the control panel module. It important
that the control panel be tied into the navigation menu block so that
it does not create inconsistent navigation.
The goal is to start a user experience grouping exercise to help the
community categorize administration tasks. The first thing that has
to happen is that administration must be considered a seperate
situation from creating personal content in Drupal. To support this
seperation of personal tasks and administration tasks we broke out
administration to have a separate theme in the CivicSpace theme.
Through research interviews into Drupal administration we need to
discover what the goals and tasks of administrators are. Some early
feedback is that site developers need modules to be evaluated on
Drupal.org. They have also indicated they need better and consistent
administration help ,with incontext list, which we have been adding.
We have also heard administrators want a quick overview. Any change to
provide a control panel like overview must have a dashboard like
overview. You should assume that we will identify a list of 5-7 top
goals for administrators.
Once those those 5-7 top goals are identified we need to ensure
administrators can acommplish tasks to achieve those goals. Some of
those tasks will completed by clicking through to icons or admin
interface links. Sub-goals will be accomplished by providing
effective navigation. We need to consider 4 types of navigation to be
added to the control panel: Global navigation, local navigation,
contextual navigation, and situational navigation. Some of this
navigation can be accomplished through a theme or blocks. Some will
need to be in the page and some need to be added in otherways, such as
interaction techniques.
Keep all this in mind when creating a control panel solution. It also
must respond to the fact that every site will have different
permissions set and different modules. This is a complex problem and
it's going to research and experimentation to get it right. But this
is a big step in the right direction.
Cheers,
Kieran
------------------------------------------------------------------------
Sat, 17 Sep 2005 19:47:55 +0000 : der
Attachment: http://drupal.org/files/issues/system.module_11.patch (5.61 KB)
This has sparked a lot of good discussion. I've taken a look at
cp.module and I think it really is complimentary with my proposed
patch. I've taken my patch one step further and provided the settings
icons in a collapsable group below the main control panel. This would
allow access to all admin functions without referring to the
traditional menu.
Syllance, do you think this addresses the gap you saw in my solution?
------------------------------------------------------------------------
Sat, 17 Sep 2005 20:33:10 +0000 : der
Kieran, I'm glad to see some serious thought going into the user
experience for site administrators. I think separating the user and
admin sections of the site is critical. It will not only allow
extensive usability work to be done for site admins it will also make
it much easier for theme creators as they will be able to focus on the
end user experience. I like the admin theme for civicspace. My only
dislike about the approach is that it's template driven which causes a
sites template to be larger and more complex due to handling all the
logic for user and admin themes. I think a better approach may be to
use a module such as the sections module. This allows you to have
smaller templates focused on user or admin themes.
I agree with your point about making sure the control panel ties into
them menu system. My approach uses the existing menu structure so
modules are added dynamically and all permissions are enforced.
------------------------------------------------------------------------
Sat, 17 Sep 2005 22:21:05 +0000 : chx
<?php
function _system_adminpage () {
drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL);
}
?>
no way. Use menu !$may_cache and set the path based on the variable.
Adding in-line style elements is also a no-go.
The code style is not kept. Never a space between full stop and
apostrophe, always otherwise.
It's not $menuvisible but $menu_visible
I must be blind (it's 0:17am) but // Build the settings section of the
control panel does not seem to differ from the previous section. A
function may be appropriate.
------------------------------------------------------------------------
Sat, 17 Sep 2005 22:39:40 +0000 : der
Thanks for the code feedback. I'm assuming the extracted style info
would get patched to drupal.css?
Your right about the duplicate code. A function would make more sense,
I'll make the change.
I'm not sure about the comment to use "$may_cache" I've never used it
before. What's it's purpose? How should I use it in this situation.
I'll dig around and see if I can figure it out but I thought you might
be able to give me a little insight.
Thanks!
------------------------------------------------------------------------
Sun, 18 Sep 2005 10:41:00 +0000 : syllance
der, i've checked the new version of your control panel, and it does
simplify access to the settings menu (although with a complex setup,
the site config collapsable menu goes a lot more down than the menu,
but this a page and not a small menu so its still better)
however, there other case settings like, such as the ecommerce modules,
which provides a more complex menu tree (ex :
store->settings->payment->adjustments, each with their own admin
pages). these are not taken into account by your panel, leaving the
menu mandatory.
chx control panel handles this nicely with page navigation. going
through the store menu with chx panel is a real pleasure while its a
real pain with the menu. So i think the best would be to mix the two
panels, chx one handling page navigation, and yours providing a
frontend for basic admin pages, and collapsable site config items.
instead of linking to the standard admin pages, icons might link to chx
nav pages where there are sub entries.
i'm running both today, and this already makes the admin really better,
but i'm often switching from der panel to chx one (for store), so mixing
both would be, for me, a very nice solution :p
thanks for the good work :)
------------------------------------------------------------------------
Sun, 18 Sep 2005 12:54:55 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel.patch (5.61 KB)
Here's a new patch with the code reworked per chx's comments with the
exception of his objection to my use of drupal_goto function. chx, I'm
probably missing something really obvious but I'm not understanding your
suggestion. Are you suggesting I use some menu function to do the
redirect? If so, I could not find one that suits my needs. Or are you
suggesting to use the drupal_goto function in a different manner than I
am using it. Like I said, I'm probably missing something really
obvious here but for the life of me I don't know what it is. Any
further advice would be greatly appreciated. The offending code below:
<?php
function _system_adminpage () {
drupal_goto($path = variable_get('site_adminpage', 'admin/controlpanel'), $query = NULL, $fragment = NULL);
}
?>
------------------------------------------------------------------------
Mon, 19 Sep 2005 13:42:57 +0000 : syllance
i think there's a problem with your latest patch. it seems to display
all icons as a vertical list. it may be a problem with my setup, but
i'm using basic themes that comes with head. the administer page is
thus very long, and this is not very useful. previous version was
better, imho :)
thanks
------------------------------------------------------------------------
Mon, 19 Sep 2005 14:10:03 +0000 : der
which theme and which browser are you using?
------------------------------------------------------------------------
Mon, 19 Sep 2005 15:59:16 +0000 : der
Attachment: http://drupal.org/files/issues/control_panel_0.patch (5.32 KB)
I've tested this with IE and FireFox with each of the Drupal shipped
HEAD themes and I'm not seeing the issue you described. Are you sure
the patch applied correctly to drupal.css?
Here's a slightly revised patch. It make the control panel icon group
collapsable but open by default.
1
0
Hello,
I was wondering if any of you had experiences with a multisite environment on
apache, where apache runs in a chrooted vhost environment.
We want to give all hosted sites full UID1 permissions on drupal, meaning that
they are allowed (for example) to make PHP pages and blocks.
One day there will be a user that abuses that, or tries to root the server
with that. So we need to limit the abilities of the user running PHP/drupal.
Each multisite will run on a single drupal multisite installation, but with
apache as a separate user.
It seems to work out fine, but I wonder if any of you people has more
experience with this, and knows if there are any oddities and quirks to be
expected.
-- Ber
3
4
[drupal-devel] [feature] XML-RPC Engine setting in blogapi module is superfluous and anti-usability
by robertDouglass 19 Sep '05
by robertDouglass 19 Sep '05
19 Sep '05
Issue status update for
http://drupal.org/node/31650
Post a follow up:
http://drupal.org/project/comments/add/31650
Project: Drupal
Version: cvs
Component: blogapi.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: robertDouglass
Updated by: robertDouglass
Status: patch (code needs review)
Attachment: http://drupal.org/files/issues/blogapi.patch.txt (2.51 KB)
Here is something I wrote recently:
"The other field on the blogAPI settings page, XML-RPC Engine,
determines which is the preferred set of functions that should be used
if the publishing client supports more than one API. The options
include Blogger, MetaWeblog and Moveabletype and the recommended
default is Blogger, simply due to the larger number of functions it
supports. *There is no reason to change this setting, even if you wish
to use the MetaWeblog or Moveabletype APIs, as the setting is only
responsible for publishing the preferred API, and doesn't turn anything
on or off*.
"
(emphasis added)
Upon reviewing this, Morbus correctly asks
"If there is no reason to change the setting, because it seemingly
doesn't do anything important, why is it there?
"
Therefore this patch takes away the configurability and just defaults
to Blogger. Since it is, after all, only a preference for some form of
mostly non-existent auto-discovery, and even in the worst case doesn't
restrict the functionality, why should we bother people with it?
robertDouglass
3
2
Issue status update for
http://drupal.org/node/26031
Post a follow up:
http://drupal.org/project/comments/add/26031
Project: Drupal
Version: cvs
Component: comment.module
Category: bug reports
Priority: critical
Assigned to: leafish_dylan
Reported by: leafish_dylan
Updated by: tostinni
Status: patch (code needs review)
I also posted a patch there [1].
But there's still some major bug with comments...
[1] http://drupal.org/node/26966#comment-41012
tostinni
Previous comments:
------------------------------------------------------------------------
Wed, 29 Jun 2005 23:43:10 +0000 : leafish_dylan
I've just upgraded a 4.6.1 site to CVS and there's no comment pager on
nodes with more than $comments_per_page. Is this a bug, or it it one of
my modules? I've tested the site with various other themes, including
the defaults.
------------------------------------------------------------------------
Mon, 04 Jul 2005 23:41:03 +0000 : leafish_dylan
Can anybody confirm this? I can't find the problem.
------------------------------------------------------------------------
Fri, 15 Jul 2005 12:35:14 +0000 : leafish_dylan
Hello?
------------------------------------------------------------------------
Tue, 23 Aug 2005 14:12:16 +0000 : Uwe Hermann
Confirmed in HEAD. The problem is here (comment.module,
comment_render()):
if ($pager = theme('pager', NULL, $comments_per_page, 0,
array('comments_per_page' => $comments_per_page))) {
$output .= $pager;
}
The $pager variable is empty (for whatever reason), hence no pager is
generated. I didn't debug this any further...
------------------------------------------------------------------------
Fri, 09 Sep 2005 21:11:26 +0000 : leafish_paul
Confirmed here too - can any one take a look at this?
------------------------------------------------------------------------
Mon, 19 Sep 2005 15:52:20 +0000 : leafish_dylan
Attachment: http://drupal.org/files/issues/comment.module_30.patch (1.02 KB)
Comment paging has been broken in CVS for at least 3 months, yet only
one other person has noticed this?
Here's a patch to fix the bug...
1
0