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
January 2005
- 54 participants
- 341 discussions
This post/discussion might be of interest regarding the recent
Watchdog changes. As an aside, it would be nice if there were a
dedicated module owner who operated in the realm of statistic analysis
in their waking life and could help us write some bang up analysis
tools (like Urchin maybe?)... ;)
http://superfluousbanter.org/archives/2005/01/poll_stat_track.php
Chris
1
0
17 Jan '05
Project: Drupal
Version: 4.5.2
Component: tracker.module
Category: bug reports
Priority: normal
Assigned to: Morbus Iff
Reported by: Morbus Iff
Updated by: Jeremy(a)kerneltrap.org
Status: patch
Agreed, the updated patch seems to be working perfectly for me. Now
these constant floods of spam don't render my tracker useless. Thanks!
:)
Jeremy(a)kerneltrap.org
Previous comments:
------------------------------------------------------------------------
January 12, 2005 - 11:02 : Morbus Iff
The automated unpublishing is great for stopping spam from being
displayed, but it doesn't stop spam from corrupting another feature: my
"recent posts" (tracker.module). I'll regularly get bursts of 200
auto-unpublished spams which make the "recent posts" page useless - an
unpublished spam still affects the modification date of a node, which
makes "recent posts" display craploads of updates, even though there
really isn't any. Thus, the feature request would be:
- treat an unpublished spam as a deleted spam
- when a spam is automatically unpublished, revert the node
modification date to its previous value.
I'm not entirely sure how easily possible this is, as you'd have to
make sure the date is properly set when someone says "nah, this
unpublished spam was actual ham", and then republishes it.
------------------------------------------------------------------------
January 12, 2005 - 14:41 : Jeremy(a)kerneltrap.org
This is a known and annoying bug. As it affects me too, I assure you
I'll get to fixing this eventually...
Any ideas on how to cleanly implement this are welcome.
------------------------------------------------------------------------
January 13, 2005 - 16:27 : Morbus Iff
Would it seem to you that this behavior should be part of core? Ignoring
spam.module entirely, if a node is updated at 11:00, and then updated
with a comment at 12:00, the 12:00 is saved in there as the node's
modification time. But if a comment is unpublished, shouldn't the node
also be reverted back to its previous state (being 11:00)? How is the
deletion of data (permanently hiding it) different from merely
temporarily hiding it (ie., unpublishing it)?
Perhaps I should move request to Drupal.
------------------------------------------------------------------------
January 13, 2005 - 16:32 : Jeremy(a)kerneltrap.org
Feel free to move it. If I come up with a clean solution (at least as
far as spam is concerned), I'll update the issue wherever it is.
------------------------------------------------------------------------
January 13, 2005 - 16:39 : Morbus Iff
Was talking about this with killes (who "frankly [doesn't] care too much
about comments"), and I'm now wondering if I'm going nutty with all this
talk about node and comment timestamps. We should investigate to see if
tracker.module looks at /unpublished/ comment timestamps instead of
just published ones. If it doesn't make a distinction, then it would
theoretically be a quickie patch to a SQL statement to only check
against published comment timestamps, not unpublished.
------------------------------------------------------------------------
January 13, 2005 - 16:42 : Morbus Iff
With a quick look, it looks like tracker_page() only checks node.status,
and not comment.status. We should be able to put a patch in for
comment.status = 1 (unpublished being 2), and that should solve our
problem, right?
------------------------------------------------------------------------
January 13, 2005 - 16:55 : Morbus Iff
Apologies... "AND c.status = 0". Modifying the two queries in
tracker_page() made things, seemingly, work as I desire. Can you
confirm?
------------------------------------------------------------------------
January 13, 2005 - 17:02 : Jeremy(a)kerneltrap.org
It didn't appear to help with regards to the spam module. I had a
recent spam flood, and with or without the 'AND c.status = 0' I saw the
same posts, including those with recently unpublished spam comments.
------------------------------------------------------------------------
January 13, 2005 - 17:08 : Morbus Iff
Odd - I had one unpublished piece of spam that I tested against (for
4.5.0, not CVS), and modifying tracker.module seemed to work as I
intended. So, the following bit of SQL still shows you erroneous nodes
with unpublished comments?
SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name,
MAX(GREATEST(n.changed, c.timestamp)) AS last_post FROM node n LEFT
JOIN comments c ON n.nid = c.nid INNER JOIN users u ON n.uid = u.uid
WHERE n.status = 1 AND c.status = 0 AND '1' GROUP BY n.nid, n.title,
n.type, n.changed, n.uid, u.name ORDER BY last_post DESC LIMIT 10;
The above is what is actually run against my database with the proposed
tracker.module change. (This code is currently active on gamegrene.com,
so we can test live if need be. Submit a comment as an anonymous user
with the words "poker" or "texas hold'em", and it should be a)
unpublished automatically via your module, and b) not shown in the
tracker.
------------------------------------------------------------------------
January 14, 2005 - 07:52 : Morbus Iff
For what it's worth, I just woke up to another flood of 150 spams, and
no corruption of my recent posts.
------------------------------------------------------------------------
January 14, 2005 - 08:05 : Jeremy(a)kerneltrap.org
Then it sounds like a patch is in order... For the tracker module.
------------------------------------------------------------------------
January 14, 2005 - 08:59 : Morbus Iff
Have you been able to confirm this though?
------------------------------------------------------------------------
January 14, 2005 - 09:46 : Morbus Iff
Attachment: http://drupal.org/files/issues/tracker_0.patch (2.59 KB)
Patch attached for 4.5.0. Haven't tried applying it to CVS, but it needs
to go there too.
------------------------------------------------------------------------
January 14, 2005 - 09:56 : killes(a)www.drop.org
I think it makes sense to only select published comments. I think this
bugfix should go in both 4.5 and cvs. +1
------------------------------------------------------------------------
January 14, 2005 - 10:43 : Dries
Committed to DRUPAL-4-5.
------------------------------------------------------------------------
January 15, 2005 - 13:55 : grohk
Reopening this issue. I just upgraded to 4.5.2 and noticed that this
patch did indeed filter out the nodes with unpublished comments, but it
also seems to be causing a new problem in the tracker. I have observed
that new posts do not show up in the tracker until they have been
commented on. I rolled back the tracker.module installed on my site to
revision 1.100 and the problem was resolved, but the phantom comments
(unpublished spam) were back. I am going to do some more
investigations, but I am rather inexperienced in this realm. Anyone
have an ideas?
------------------------------------------------------------------------
January 16, 2005 - 06:13 : Zed Pobre
Attachment: http://drupal.org/files/issues/tracker.diff (2.67 KB)
To fix this, instead of just checking c.status = 0, check (c.status = 0
OR c.status IS NULL). I've attached a patch to do this.
------------------------------------------------------------------------
January 16, 2005 - 10:45 : grohk
So far so good. This patch seems to have fixed my tracker. Thanks Zed,
I really appreciate it.
--
View: http://drupal.org/node/15500
Edit: http://drupal.org/project/comments/add/15500
1
0
17 Jan '05
Grant,
If your solution works for you on your site, by all means, use it! :)
My response to your patch was simply that it wouldn't be a wise one to
implement back into core Drupal. That said, I do think that more
themeability of form elements is needed and is actually something that
we're working on!
Have you seen the recent node creation redesign threads
(http://drupal.org/node/15506 and http://drupal.org/node/14886)?
Hopefully the issue that you're running into will be addressed through
the continuing work on improving both the default node creation
interface as well as the themeability of forms.
Chris
1
0
Project: Drupal
Version: cvs
Component: node.module
Category: feature requests
Priority: normal
Assigned to: Anonymous
Reported by: grantbow(a)civicspacelabs.org
Updated by: grantbow(a)civicspacelabs.org
Status: patch
Attachment: http://drupal.org/files/issues/node.module (60.79 KB)
On my site the preview and submit buttons appear to the right side of
the trackback block. Users who expect the buttons to be at the bottom
of the page have a (extremely small) hurdle to find the buttons.
Sometimes the buttons are rendered into the next column due to the
width of the trackback block. While I am not aware if this happens on
all sites, I wanted to offer a simple patch that works well on my own
site. If this fix not in the proper place I would appreciate
constructive feedback on where it does belong. Thanks.
Index: node.module
===================================================================
RCS file: /cvs/drupal/drupal/modules/node.module,v
retrieving revision 1.439
diff -u -F^fun -r1.439 node.module
--- node.module 11 Jan 2005 09:41:49 -0000 1.439
+++ node.module 16 Jan 2005 08:43:19 -0000
@@ -1220,6 +1220,7 @@ function node_form($edit) {
$output .= form_hidden('type', $edit->type);
// Add the buttons.
+ $output .= '';
$output .= form_submit(t('Preview'));
if (!form_get_errors()) {
grantbow(a)civicspacelabs.org
--
View: http://drupal.org/node/15679
Edit: http://drupal.org/project/comments/add/15679
5
7
Project: Drupal
Version: cvs
Component: node.module
Category: feature requests
Priority: normal
Assigned to: Steven
Reported by: Anonymous
Updated by: Steven
Status: patch
The widths are there to avoid IE pushing part of the form down. If you
remove them, make sure your modified setup doesn't suffer from the same
bugs.
In any case, I don't have the time now to work on this patch further
(exams), so if it needs further clean up, one of you guys will have to
do it...
Steven
Previous comments:
------------------------------------------------------------------------
August 23, 2004 - 17:09 : Anonymous
Attachment: http://drupal.org/files/issues/node_admin_filter.patch (3.8 KB)
Here's a patch for the current CVS version which adds the option to
filter nodes by type on the node admin page.
Having built a few sites recently which make heavy use of flexinodes,
the ability to filter out particular node types would have been
extremely useful, so I hope this makes it to 4.5.0.
------------------------------------------------------------------------
August 23, 2004 - 21:06 : leafish_dylan
This would be a great feature.
------------------------------------------------------------------------
August 23, 2004 - 21:06 : leafish_dylan
This would be a great feature.
------------------------------------------------------------------------
September 4, 2004 - 00:38 : Bèr Kessels
I think we should really come up with a good solution for this screen.
In the past, I went looking for such a solution and found that the
various MP3 library tools might come to help.
They deal with large amounts of metadata, some of wch are important,
other are not.
I summarise here what the UI could be like:
** The menu-based (tree) approach: Most mp3 collections use this idea.
In a tree like structure on the side, you can make selections. The list
in the main area will follow this selection. (Itunes:
http://www.apple.com/itunes/playlists.html , Juk:
http://developer.kde.org/~wheeler/images/juk-2.0/juk-2.png,
finf/freeamp: http://www.zinf.org/images/zinf_mymusic_shot.png)
In drupal that would mean a menu-based filtering method. I once made a
patch for that, but that was rejected:
http://drupal.org/node/view/7766
The good thing here, is that it is virtually endless scalable. So in
theory, flexinode coud add menu items to show only nodes where foo is
bar.
|
- nodetype
| |- blog
| |= Flexinode
| | |=foo
| | | |=bar
| |- page
** The multiple selectlist UI: Another moethod is a extended method of
what we have now: select items from select boxes and press submit.
Above the main area one will find some selection UI where one can in-
and exlude sertain criteria. (rhythmbox:
http://www.rhythmbox.org/screenshots/Screenshot-Rhythmbox.png, and
winamp http://www.winamp.com/player/walkthrough.php) Note that both
still show some form of tree navigation.
In drupal that would mean multiple selects in three columns (rhytmbox
and winamp show only two artist and album) For drupal we need three of
thos blocks: one for node-types, one for node-settings (promoted, etc)
and one for taxonomy terms. The node settings should be logical too: If
a criteria is selected it it true, if not: false. That way we can also
get rod of the annoying logic: "view posts that are not promoted" and
the likes.
In both solutions the "perform batch action" needs to move somewhere
else. I would plead for moving it to the bottom of the list. A lot of
webmail cleints do it that way. The reason being simple: the steps you
take to perform the update are:
1) select criteria (find nodes)
2) checkmark the chages (we need columns of checkboxes)
3) perform the update.
Logically the way you go through the UI is left->right, top-> down (not
taking into consideration japanese/hebrew/arabs etc)
So all in all: i think indeed the UI needs serious work. I am willing
to take this one me, bu I do need some consensus first. I am not
willing to spend hours on a new UI (like the menu-based approach) to
find the patch being rejected.Therefore I like some discussion up fron,
rather than the " code first see later" approach.
Regards, Ber
------------------------------------------------------------------------
September 5, 2004 - 23:42 : Bèr Kessels
Attachment: http://drupal.org/files/issues/new_UI_proposal.png (175.31 KB)
Here is a gimped mockup from what option 2) could look like.
WE could add a fouth box with users too, but I am not sure how that
would go with permissions and the like. I need to do some thinking
about selecatibility by users first.
------------------------------------------------------------------------
September 6, 2004 - 00:01 : Bèr Kessels
Sorry for the spam: but I forgot to mention that there are a few
issues:
The "perform action dropdown" should list stuff as: promote, demote,
etc. But that list needs to be generated with the selection above in
mind. So if you choose " published" the action list should not have
"publish these nodes"
Also the action list could contain "recategorise" wich would need
another screen after the one in the "ugly screendump-gimp-mockup", to
be able to choose the categories in wich the selection should be
placed.
And of course the delete these items with a confimation dialog.
(http://drupal.org/node/view/7743#comment-11624)
------------------------------------------------------------------------
September 6, 2004 - 14:32 : Bèr Kessels
Attachment: http://drupal.org/files/issues/node_admin.html (29.95 KB)
After a long discussion with Steven And gerhard, I designed the page in
HTML, to let you all try it in some way.
Beware: the html is an ugly mock, It is meant as scetch, not as valid
html.
Some notes on the page:
"View all nodes that are:" contains three differnet possibilities for
searching. The first two (above the blank line) are there for
simplicity, but they might confuse users, because they need a lot of
text. The second idea uses a checkbox to enable the select next to it.
The third one uses some ajvascript to improve useablity.
We should of course choose one of these three methods.
"View all nodes that are classified in:"
There are quite some people that have questions with whether or not we
should include this selection aat all. Here is why I think it should
definately go Because most sites have only one purpose and thus a lot
of nodes of one type in one state. For example a personal blog site:
99% of the nodes are blogs. 99% are promoted. Only 1 or 2 are not
promoted, not published or of type page.
Or take a photo-album-site. All posts will be images, the main
difference is the classification (the galleries) I placed them in.
"any/all" There must be a way to choose whether the sected options
should be an AND or an OR. I tried three different methods, each block
has one method. We should choose one.
Please give me feedback, for I still have to decide whether or not to
make this a contributed module or start lobby-ing to get it in core.
------------------------------------------------------------------------
September 13, 2004 - 11:50 : moshe weitzman
looking good, and really useful. a few small comments:
- consider upping the number of nodes that appear on this page. it is
nearly pointless to use paging on this sort of UI
- i like the second idea of an 'enabled' checkbox, without the
javascript. i think you can use 2 checkboxes, where the second one is
called 'publish', 'promote', and 'has comments'
- I prefer the horizontal configuration of the 'Require: all any' radio
buttons
- don't repeat 'the selected posts' in the choices for the bottom
dropdown. perhaps use a title for that form_select() instead.
- the last choice in that dropdown is 'reclassify'. i don't see how
this screen could support that. instead, use my
taxonomy_multi_edit.module from contrib :)
i suggest making this a contrib module at first. it can be a tab off of
the current page. thats how taxonomy_multi_edit.module appears.
------------------------------------------------------------------------
September 13, 2004 - 13:03 : Bèr Kessels
About that reclassify:
That was exactly my intention: using the taxonomy_muliti_edit module
for that. All I wanted to do is pass a list of nids to your module and
open a screen using that module with the previously selected nodes!
About the other comments: Yes upping the number of nodes might be a
good idea. Anyone any idea what number would still be usefull. 10.000
nodes (on drupal.org) in one list is not a good idea, IMO, so some
paging is needed.
indeed: repeatinf words in dropdowns is considered "bad UI design"
thank you for pointing it out.
Regards, Ber
------------------------------------------------------------------------
September 28, 2004 - 13:37 : eafarris
Attachment: http://drupal.org/files/issues/admin_node_filter_by_type.patch (1.96 KB)
here is an updated version of this patch, syncing it with CVS HEAD.
Also, i did change the functionality somewhat: previous versions of the
patch asked the modules what node types were out there (via
hook_node_name()). This version asks the node table what types are in
there (via SELECT DISTINCT type FROM {node}). I find this more useful,
because it's entirely possible that, over time, modules will be removed
from the system, yet they still have rows in the node table. This method
gives a more accurate view of the types of nodes on the system.
The new UI looks excellent, but this patch does not address it.
------------------------------------------------------------------------
September 28, 2004 - 19:05 : drumm
-1
I applied and tested and it did not work at all for me. The type
options selection only contains 's' and 'W', selecting one does not
work. The list of types seems to come from the DB which is probably an
unnecessary query.
------------------------------------------------------------------------
September 29, 2004 - 12:51 : eafarris
Attachment: http://drupal.org/files/issues/admin_node_filter_by_type_1.patch (2.31 KB)
Here's a version of that patch that should work. Sorry.
I think that getting the types from the node table is necessary. The
list of installed nodes is not the authority on what types of nodes are
in the db; we should ask the db directly. It's a small query on one
admin page; the result is that the dropdown has in it the most accurate
information available. That's worth it, imo.
------------------------------------------------------------------------
September 29, 2004 - 12:52 : eafarris
s/list of installed nodes/list of installed modules/ . sheesh. teach me
to post before my tea.
------------------------------------------------------------------------
October 21, 2004 - 18:15 : Bèr Kessels
Attachment: http://drupal.org/files/issues/node.html (29.33 KB)
I do not know where it weant, but my proposal had a HTML mockup.
Attaching it here to see what i meant.
------------------------------------------------------------------------
October 23, 2004 - 13:14 : com2
Nice filter options, but what I really miss it the possibility to select
all checkboxes. Really boring job when you have to click the whole list
one by one.
------------------------------------------------------------------------
October 24, 2004 - 10:41 : Bèr Kessels
I am not a big fan of those options in forms.
They more often break things than that thy fix them. Rahter use a
bookmarklet r so for that:
http://www.squarefree.com/bookmarklets/forms.html
Ber
------------------------------------------------------------------------
October 25, 2004 - 01:03 : Steven
Attachment: http://drupal.org/files/issues/node_admin_ucd.html (29.83 KB)
Based on some more IRC discussion, I came up with this (attachment). It
is based on an earlier mockup.
It does use Javascript and doesn't degrade without script (yet), but I
think it's worth considering. It can be implemented quite cleanly. The
idea would be to have a filter like this initially, and after clicking
'Go', to show the current filter as well as the form again, allowing
you to refine your search.
I haven't tested browser compatibility, but it should work on most
browsers. The only ones I know for sure won't work are IE4 and NS4,
which are old enough to ignore IMO: after all, this is admin only, and
we can put some stricter browser requirements on that. Recent versions
of other browsers should work (it only does a simple visibility
toggle).
I like it because it's not an airplane cockpit, but still offers
complex filtering options through refinement. It is also quite similar
to the search/filtering UI in e.g. mail applications.
The question is of course, how to degrade it for people without
Javascript. My suggestion would be to simply show all filter options,
and put a radiobutton in front of each:
( ) Where type is [ blog | v ]
( ) Where published status is ( ) published ( ) unpublished
( ) Where category is [ term1 | v ]
...
It has more visual clutter, but the same principle of use.
------------------------------------------------------------------------
October 25, 2004 - 01:13 : Steven
In fact, I just realized that the radio-button version can be coded to
send exactly the same form data as the scripted version, which makes it
more interesting.
------------------------------------------------------------------------
October 29, 2004 - 00:52 : Steven
If you guys approve of my idea, I'll start coding. Assigning to myself
for now.
------------------------------------------------------------------------
November 1, 2004 - 17:35 : Bèr Kessels
I like this idea much more than my previous approaches. Gave it some
thought and came with the follwing behaviour:
* I think we need to discuss or at least design the tabular data too:
It makes 0 sense to show the "types" column, if you chose "type =
image"
* I think we need to introduce a hook to add info to that tabulat view.
Images can output thumbnails, for example
* In tabular view, we should make: title a textfield, type and author a
select and satus a select too.
* I think we should introduce another range of options: "where content
contains" [ ] and "where title contains" [ ]
* I would like to get some feedback on how many drupal-using people are
firmly against javascript, with a reason why. I bet that this is < 1% !
Bèr
------------------------------------------------------------------------
November 1, 2004 - 17:42 : Steven
We don't have an anti-JS policy in Drupal. It's just that until
recently, doing cross browser JS was a chore and making it accessible
and degradable would be a disaster.
This form can be implemented cleanly and will degrade without problems.
Anyone who opposes it because it is JS can bugger off ;).
------------------------------------------------------------------------
November 3, 2004 - 19:24 : com2
There is a more radical way around JS. You could forget the table idea
alltogether and present the nodes in Listbox. Then selecting becomes
much easier with Ctrl-Click and Shift-Click
------------------------------------------------------------------------
November 4, 2004 - 00:02 : Bèr Kessels
Did you have a look at the previous applied UI improvements? Did you
consider the pre's and cons of those earlier posts?
It seams you are repeating passed issues here, please reply with miore
detailed issues here,
Bèr
------------------------------------------------------------------------
December 3, 2004 - 10:49 : Steven
Attachment: http://drupal.org/files/issues/node-admin.patch (13.1 KB)
Here's a patch which implements the JS approach of refining the
selection.
------------------------------------------------------------------------
December 3, 2004 - 10:50 : Steven
Attachment: http://drupal.org/files/issues/node_admin.png (34.38 KB)
And here's a screenshot of how it looks.
------------------------------------------------------------------------
December 3, 2004 - 19:23 : FactoryJoe(a)civicspacelabs.org
This is looking better and better. I'm going to do a UI review of this a
post any additional thoughts or comments.
Chris
------------------------------------------------------------------------
December 3, 2004 - 21:50 : Anonymous
Ack, I tested this using the bluebeach theme, but there's a small CSS
bug with bluemarine, where the header for the operations form is stuck
to the right of the filter form. I'll make an updated patch later. In
the meantime, comments are much appreciated.
------------------------------------------------------------------------
December 3, 2004 - 23:15 : killes(a)www.drop.org
I actually prefer the non-JS menu over the JS menu. Not (only) because
of the JS but because I prefer radiobuttons over pulldown menus. The
argument that the non-JS approach uses more vertical space can be
mitigated by redirecting to a #results anchor.
------------------------------------------------------------------------
January 15, 2005 - 06:32 : Steven
Attachment: http://drupal.org/files/issues/node.admin.patch (14.41 KB)
Here's an updated patch... I have exams in a week, so I don't have time
to finish up the Javascript version, so I removed it (it can be added
later easily). However, the non-JS version is still very usable.
Changes since last time:
- Uses semantic XHTML (definition list, and yes, they are for more than
just definitions, even w3c agrees).
- Merges the various node flags (promoted, published, ...) into one
"status" dropdown. This keeps the whole selector shorter, and is better
UI-wise IMO.
- Adds drupal_gotos, they were missing.
- Updates node admin watchog messages to properly display the type. The
code used t($node->type) which is a big no-no. hook_node_name() is now
invoked instead.
- Removes some dead code.
- I rolled Ber's node mass deletion patch in as it affects the same
piece of code. Updating either patch for the other separately would be
a waste of time. I also added some more improvements to Bèr's code,
such as removing the incorrect help from the confirmation page,
cleaning up the code style a bit, not loading every node just to
display its title and displaying a single drupal_set_message() after
the deleting rather than one per node.
The old issue is here: http://drupal.org/node/7743
------------------------------------------------------------------------
January 15, 2005 - 06:32 : Steven
Attachment: http://drupal.org/files/issues/node admin.png (30.19 KB)
------------------------------------------------------------------------
January 15, 2005 - 09:55 : Bèr Kessels
Thanks for integrating the batch delete patch, Steven!
------------------------------------------------------------------------
January 15, 2005 - 13:47 : Dries
Attachment: http://drupal.org/files/issues/node-filter-wrap.png (34.55 KB)
It looks good but:
1. It makes the UI looks cluttered. I suggest visually grouping the
varios form elements so it becomes easier for they eye to skip over
them.
2. It is too wide. Try using the Chameleon theme with a sidebar on the
right at 1024x768 (eg. my laptop's resolution) and you'll find that the
form elements wrap, and wrap in an awkward order. See screenshot.
Maybe we should group the form elements using from_group() and make
"Show only items where" the form_group()'s title. It would save space.
------------------------------------------------------------------------
January 15, 2005 - 16:14 : Bèr Kessels
Steven,
Is there a reason why you do not use theme_box, but hardcode HTML in
your forms? If there is none, I will spend some time monday to fix it.
Bèr
------------------------------------------------------------------------
January 15, 2005 - 17:48 : Steven
Simple. There aren't any guidelines on theme box usage :P. Plus, theming
the admin interface is probably not a big priority.
------------------------------------------------------------------------
January 15, 2005 - 19:44 : FactoryJoe(a)civicspacelabs.org
Attachment: http://drupal.org/files/issues/node-filter-wrap-v2.png (14.23 KB)
I simplified the layout and added some visual separation between
elements (the rounded boxes). I imagine that pretty much the same
markup as exists now could be used with some slight tweaks.
Probably the most significant change, horizontally, is moving the
filter button below the filters.
------------------------------------------------------------------------
January 15, 2005 - 20:13 : Steven
This way they take up even more space though. I'd like to at least have
the user see part of the results table without scrolling. Also, the
rounded boxes are definitely a theme thing and don't really belong in
core.
The markup would need some changes too, as right now the structure is
vertical nested inside horizontal, while yours is horizontal nested in
vertical.
I was also wondering about the wording... "Show items where A is B"
sounds a bit bumpy. Alternatives "... items whose A is B" "items with A
of B", etc.
------------------------------------------------------------------------
January 15, 2005 - 23:04 : Dries
Chris' mockup looks better but there is still room for improvement:
1. The titles of the two /form groups/ are not consistent.
2. Removing the (mostly) brain-death help text might help to reduce the
visual clutter. The help text is incorrect: clicking the username opens
the user's profile page as one would expect.
3. The indentation looks pretty random.
------------------------------------------------------------------------
January 16, 2005 - 20:33 : Dries
Attachment: http://drupal.org/files/issues/node-filter.png (27.38 KB)
Looked some more at this patch:
1. The hardcoded widths in drupal.css should be avoided. They don't
match my laptop's resolution and make for akward whitespace on higher
resolutions. When I remove some of the hardcoded constants in
drupal.css the forms look a whole lot better. Except for the buttons
that is, they still wrap but it might not be a problem. IMO, we can't
get this right unless we move the buttons under the form.
2. I played with the patch a little and came up with the attached
screenshot. It needs refinement but the CSS/markup make it bothersome
so this is nothing but of a proof-of-concept. As soon I try to change
something the layout freaks out. It took me 15 minutes to 'reverse
engineer' the markup/CSS. Personally, I'd rather have something that is
a bit easier to change/customize.
Any way, I simplified the help, wrapped the forms in a form_group() and
generally forced things to fit my resolution better.
3. The fact there is no Javascript involved makes things a whole lot
easier.
--
View: http://drupal.org/node/10296
Edit: http://drupal.org/project/comments/add/10296
1
0
Project: Drupal
Version: cvs
Component: story.module
Category: tasks
Priority: normal
Assigned to: Bèr Kessels
Reported by: Bèr Kessels
Updated by: Goba
Status: patch
But having a multisentence long text being present two times in the
code, and even one more time as a prefix makes translation a lot
harder. True, the two identical strings only need to be translated
once, but not the third one. Who will spot that the longer one actually
has the same prefix? Programs like kbabel provide no clue on what else
is in the file, they only concentrate on one string.
Also if one fixes a typo in your string, or starts to improve it, he
needs to do so in three places, and the translator also needs to fix it
in two places. I bet non-coders will not expect that a string they see
on the interface might be in the code three times, so if they fix one
instance, it might not be that one exact instance they expected to fix.
Non-coders have probably no idea on what the section identifiers mean...
Goba
Previous comments:
------------------------------------------------------------------------
January 7, 2005 - 14:19 : Bèr Kessels
Attachment: http://drupal.org/files/issues/story_help.patch (3.06 KB)
Because of historical reasons the story module help contained all sortts
of odd texts, that are partly even untrue.
This patch changes the help so that it:
* stresses that stories are nodes in their simplest form
* removes all the bloat about workflow. workflow can be configured for
any node type, why should nstories mention it?
* removes parts of voting, queues, promotion, comments etc. Any node
type can have this.
* adds a note that you can use stories for personal blogging, and as
general pages, pages with no specific purpose (I consider, for example,
a forum node a node with a special purpose)
* stresses that you should use other modules (taxonnomy, menu) to give
the node a place on your site.
set to CVS but will apply to 4.5 too.....
------------------------------------------------------------------------
January 10, 2005 - 17:41 : Bèr Kessels
Attachment: http://drupal.org/files/issues/story_help_0.patch (3.06 KB)
previous patch was the one before spellchecking. This one is without the
two spelling errors.
------------------------------------------------------------------------
January 10, 2005 - 20:29 : Dries
Can someone review this please?
------------------------------------------------------------------------
January 12, 2005 - 14:53 : Bèr Kessels
Attachment: http://drupal.org/files/issues/story_help_1.patch (3.01 KB)
After some discussion on the drupal-docs ML, i came up with the
following help-texts:
Short:
Stories are articles in their simplest form: they have a title, a
teaser and a body, but can be extended by other modules. The teaser is
part of the body too. Stories may be used as a personal blog or for
news
articles.
Longer:
Stories are articles in their simplest form: they have a title, a
teaser and a body, but can be extended by other modules. The teaser is
part of the body too. Stories may be used as a personal blog or for
news
articles. By default, no menu item, or navigation element is
created for a story. An extra feature of a
story is, that an administrator can specify a submission guideline and
enforce a minimum word count for user submitted stories
------------------------------------------------------------------------
January 13, 2005 - 20:42 : Dries
This patch doesn't apply against HEAD.
patching file modules/story.module
Hunk #1 FAILED at 14.
Hunk #2 FAILED at 26.
2 out of 2 hunks FAILED -- saving rejects to file
modules/story.module.rej
------------------------------------------------------------------------
January 14, 2005 - 23:55 : Bèr Kessels
AARHGH, such a simple patch, so much hassle. My mistake, uplaoded the
wrong one again.
This one should be right.
------------------------------------------------------------------------
January 15, 2005 - 00:05 : Bèr Kessels
Attachment: http://drupal.org/files/issues/story_improve_help.patch (3.19 KB)
**sigh**
------------------------------------------------------------------------
January 15, 2005 - 09:01 : Dries
Committed to HEAD.
------------------------------------------------------------------------
January 15, 2005 - 20:10 : Goba
Attachment: http://drupal.org/files/issues/Drupal.simplify.story.help.patch (2.18 KB)
Well, this was a bogus fix after all. The patch removed the paragraph
tags used in some help texts. These were introduced lately in most of
the help texts to improve consistency in displaying help texts. I am
unsure however, whether such paragraphs are going to be used on node
add pages...
What is worse, that the committed patch contained the exact same
sentence sequeces three times in the code, two times identical, one
time with an extension. Being in a switch() statement, it is quite
simple to overcome the duplicate, and it is also not hard to watch out
for the extended part. A patch attached to remedy this.
BUT this still does not restore the paragpraph wrapping around the help
text in the admin helps, since I am unsure, whether that would be
applicable to the 'node add' page descriptions.
------------------------------------------------------------------------
January 16, 2005 - 21:07 : Bèr Kessels
Allthough your patch cleans the code, I did purposedly not do it your
way. The reason being that i recall (but cannot refind some discussion
about this. AFAIKR it was decided we would keep help separate. The
reason being that non-codes would be able to chage the help of various
textx easier.
--
View: http://drupal.org/node/15264
Edit: http://drupal.org/project/comments/add/15264
1
0
Project: Drupal
Version: cvs
Component: story.module
Category: tasks
Priority: normal
Assigned to: Bèr Kessels
Reported by: Bèr Kessels
Updated by: Bèr Kessels
Status: patch
Allthough your patch cleans the code, I did purposedly not do it your
way. The reason being that i recall (but cannot refind some discussion
about this. AFAIKR it was decided we would keep help separate. The
reason being that non-codes would be able to chage the help of various
textx easier.
Bèr Kessels
Previous comments:
------------------------------------------------------------------------
January 7, 2005 - 14:19 : Bèr Kessels
Attachment: http://drupal.org/files/issues/story_help.patch (3.06 KB)
Because of historical reasons the story module help contained all sortts
of odd texts, that are partly even untrue.
This patch changes the help so that it:
* stresses that stories are nodes in their simplest form
* removes all the bloat about workflow. workflow can be configured for
any node type, why should nstories mention it?
* removes parts of voting, queues, promotion, comments etc. Any node
type can have this.
* adds a note that you can use stories for personal blogging, and as
general pages, pages with no specific purpose (I consider, for example,
a forum node a node with a special purpose)
* stresses that you should use other modules (taxonnomy, menu) to give
the node a place on your site.
set to CVS but will apply to 4.5 too.....
------------------------------------------------------------------------
January 10, 2005 - 17:41 : Bèr Kessels
Attachment: http://drupal.org/files/issues/story_help_0.patch (3.06 KB)
previous patch was the one before spellchecking. This one is without the
two spelling errors.
------------------------------------------------------------------------
January 10, 2005 - 20:29 : Dries
Can someone review this please?
------------------------------------------------------------------------
January 12, 2005 - 14:53 : Bèr Kessels
Attachment: http://drupal.org/files/issues/story_help_1.patch (3.01 KB)
After some discussion on the drupal-docs ML, i came up with the
following help-texts:
Short:
Stories are articles in their simplest form: they have a title, a
teaser and a body, but can be extended by other modules. The teaser is
part of the body too. Stories may be used as a personal blog or for
news
articles.
Longer:
Stories are articles in their simplest form: they have a title, a
teaser and a body, but can be extended by other modules. The teaser is
part of the body too. Stories may be used as a personal blog or for
news
articles. By default, no menu item, or navigation element is
created for a story. An extra feature of a
story is, that an administrator can specify a submission guideline and
enforce a minimum word count for user submitted stories
------------------------------------------------------------------------
January 13, 2005 - 20:42 : Dries
This patch doesn't apply against HEAD.
patching file modules/story.module
Hunk #1 FAILED at 14.
Hunk #2 FAILED at 26.
2 out of 2 hunks FAILED -- saving rejects to file
modules/story.module.rej
------------------------------------------------------------------------
January 14, 2005 - 23:55 : Bèr Kessels
AARHGH, such a simple patch, so much hassle. My mistake, uplaoded the
wrong one again.
This one should be right.
------------------------------------------------------------------------
January 15, 2005 - 00:05 : Bèr Kessels
Attachment: http://drupal.org/files/issues/story_improve_help.patch (3.19 KB)
**sigh**
------------------------------------------------------------------------
January 15, 2005 - 09:01 : Dries
Committed to HEAD.
------------------------------------------------------------------------
January 15, 2005 - 20:10 : Goba
Attachment: http://drupal.org/files/issues/Drupal.simplify.story.help.patch (2.18 KB)
Well, this was a bogus fix after all. The patch removed the paragraph
tags used in some help texts. These were introduced lately in most of
the help texts to improve consistency in displaying help texts. I am
unsure however, whether such paragraphs are going to be used on node
add pages...
What is worse, that the committed patch contained the exact same
sentence sequeces three times in the code, two times identical, one
time with an extension. Being in a switch() statement, it is quite
simple to overcome the duplicate, and it is also not hard to watch out
for the extended part. A patch attached to remedy this.
BUT this still does not restore the paragpraph wrapping around the help
text in the admin helps, since I am unsure, whether that would be
applicable to the 'node add' page descriptions.
--
View: http://drupal.org/node/15264
Edit: http://drupal.org/project/comments/add/15264
1
0
Project: Drupal
Version: cvs
Component: node.module
Category: feature requests
Priority: normal
Assigned to: Steven
Reported by: Anonymous
Updated by: Dries
Status: patch
Attachment: http://drupal.org/files/issues/node-filter.png (27.38 KB)
Looked some more at this patch:
1. The hardcoded widths in drupal.css should be avoided. They don't
match my laptop's resolution and make for akward whitespace on higher
resolutions. When I remove some of the hardcoded constants in
drupal.css the forms look a whole lot better. Except for the buttons
that is, they still wrap but it might not be a problem. IMO, we can't
get this right unless we move the buttons under the form.
2. I played with the patch a little and came up with the attached
screenshot. It needs refinement but the CSS/markup make it bothersome
so this is nothing but of a proof-of-concept. As soon I try to change
something the layout freaks out. It took me 15 minutes to 'reverse
engineer' the markup/CSS. Personally, I'd rather have something that is
a bit easier to change/customize.
Any way, I simplified the help, wrapped the forms in a form_group() and
generally forced things to fit my resolution better.
3. The fact there is no Javascript involved makes things a whole lot
easier.
Dries
Previous comments:
------------------------------------------------------------------------
August 23, 2004 - 18:09 : Anonymous
Attachment: http://drupal.org/files/issues/node_admin_filter.patch (3.8 KB)
Here's a patch for the current CVS version which adds the option to
filter nodes by type on the node admin page.
Having built a few sites recently which make heavy use of flexinodes,
the ability to filter out particular node types would have been
extremely useful, so I hope this makes it to 4.5.0.
------------------------------------------------------------------------
August 23, 2004 - 22:06 : leafish_dylan
This would be a great feature.
------------------------------------------------------------------------
August 23, 2004 - 22:06 : leafish_dylan
This would be a great feature.
------------------------------------------------------------------------
September 4, 2004 - 01:38 : Bèr Kessels
I think we should really come up with a good solution for this screen.
In the past, I went looking for such a solution and found that the
various MP3 library tools might come to help.
They deal with large amounts of metadata, some of wch are important,
other are not.
I summarise here what the UI could be like:
** The menu-based (tree) approach: Most mp3 collections use this idea.
In a tree like structure on the side, you can make selections. The list
in the main area will follow this selection. (Itunes:
http://www.apple.com/itunes/playlists.html , Juk:
http://developer.kde.org/~wheeler/images/juk-2.0/juk-2.png,
finf/freeamp: http://www.zinf.org/images/zinf_mymusic_shot.png)
In drupal that would mean a menu-based filtering method. I once made a
patch for that, but that was rejected:
http://drupal.org/node/view/7766
The good thing here, is that it is virtually endless scalable. So in
theory, flexinode coud add menu items to show only nodes where foo is
bar.
|
- nodetype
| |- blog
| |= Flexinode
| | |=foo
| | | |=bar
| |- page
** The multiple selectlist UI: Another moethod is a extended method of
what we have now: select items from select boxes and press submit.
Above the main area one will find some selection UI where one can in-
and exlude sertain criteria. (rhythmbox:
http://www.rhythmbox.org/screenshots/Screenshot-Rhythmbox.png, and
winamp http://www.winamp.com/player/walkthrough.php) Note that both
still show some form of tree navigation.
In drupal that would mean multiple selects in three columns (rhytmbox
and winamp show only two artist and album) For drupal we need three of
thos blocks: one for node-types, one for node-settings (promoted, etc)
and one for taxonomy terms. The node settings should be logical too: If
a criteria is selected it it true, if not: false. That way we can also
get rod of the annoying logic: "view posts that are not promoted" and
the likes.
In both solutions the "perform batch action" needs to move somewhere
else. I would plead for moving it to the bottom of the list. A lot of
webmail cleints do it that way. The reason being simple: the steps you
take to perform the update are:
1) select criteria (find nodes)
2) checkmark the chages (we need columns of checkboxes)
3) perform the update.
Logically the way you go through the UI is left->right, top-> down (not
taking into consideration japanese/hebrew/arabs etc)
So all in all: i think indeed the UI needs serious work. I am willing
to take this one me, bu I do need some consensus first. I am not
willing to spend hours on a new UI (like the menu-based approach) to
find the patch being rejected.Therefore I like some discussion up fron,
rather than the " code first see later" approach.
Regards, Ber
------------------------------------------------------------------------
September 6, 2004 - 00:42 : Bèr Kessels
Attachment: http://drupal.org/files/issues/new_UI_proposal.png (175.31 KB)
Here is a gimped mockup from what option 2) could look like.
WE could add a fouth box with users too, but I am not sure how that
would go with permissions and the like. I need to do some thinking
about selecatibility by users first.
------------------------------------------------------------------------
September 6, 2004 - 01:01 : Bèr Kessels
Sorry for the spam: but I forgot to mention that there are a few
issues:
The "perform action dropdown" should list stuff as: promote, demote,
etc. But that list needs to be generated with the selection above in
mind. So if you choose " published" the action list should not have
"publish these nodes"
Also the action list could contain "recategorise" wich would need
another screen after the one in the "ugly screendump-gimp-mockup", to
be able to choose the categories in wich the selection should be
placed.
And of course the delete these items with a confimation dialog.
(http://drupal.org/node/view/7743#comment-11624)
------------------------------------------------------------------------
September 6, 2004 - 15:32 : Bèr Kessels
Attachment: http://drupal.org/files/issues/node_admin.html (29.95 KB)
After a long discussion with Steven And gerhard, I designed the page in
HTML, to let you all try it in some way.
Beware: the html is an ugly mock, It is meant as scetch, not as valid
html.
Some notes on the page:
"View all nodes that are:" contains three differnet possibilities for
searching. The first two (above the blank line) are there for
simplicity, but they might confuse users, because they need a lot of
text. The second idea uses a checkbox to enable the select next to it.
The third one uses some ajvascript to improve useablity.
We should of course choose one of these three methods.
"View all nodes that are classified in:"
There are quite some people that have questions with whether or not we
should include this selection aat all. Here is why I think it should
definately go Because most sites have only one purpose and thus a lot
of nodes of one type in one state. For example a personal blog site:
99% of the nodes are blogs. 99% are promoted. Only 1 or 2 are not
promoted, not published or of type page.
Or take a photo-album-site. All posts will be images, the main
difference is the classification (the galleries) I placed them in.
"any/all" There must be a way to choose whether the sected options
should be an AND or an OR. I tried three different methods, each block
has one method. We should choose one.
Please give me feedback, for I still have to decide whether or not to
make this a contributed module or start lobby-ing to get it in core.
------------------------------------------------------------------------
September 13, 2004 - 12:50 : moshe weitzman
looking good, and really useful. a few small comments:
- consider upping the number of nodes that appear on this page. it is
nearly pointless to use paging on this sort of UI
- i like the second idea of an 'enabled' checkbox, without the
javascript. i think you can use 2 checkboxes, where the second one is
called 'publish', 'promote', and 'has comments'
- I prefer the horizontal configuration of the 'Require: all any' radio
buttons
- don't repeat 'the selected posts' in the choices for the bottom
dropdown. perhaps use a title for that form_select() instead.
- the last choice in that dropdown is 'reclassify'. i don't see how
this screen could support that. instead, use my
taxonomy_multi_edit.module from contrib :)
i suggest making this a contrib module at first. it can be a tab off of
the current page. thats how taxonomy_multi_edit.module appears.
------------------------------------------------------------------------
September 13, 2004 - 14:03 : Bèr Kessels
About that reclassify:
That was exactly my intention: using the taxonomy_muliti_edit module
for that. All I wanted to do is pass a list of nids to your module and
open a screen using that module with the previously selected nodes!
About the other comments: Yes upping the number of nodes might be a
good idea. Anyone any idea what number would still be usefull. 10.000
nodes (on drupal.org) in one list is not a good idea, IMO, so some
paging is needed.
indeed: repeatinf words in dropdowns is considered "bad UI design"
thank you for pointing it out.
Regards, Ber
------------------------------------------------------------------------
September 28, 2004 - 14:37 : eafarris
Attachment: http://drupal.org/files/issues/admin_node_filter_by_type.patch (1.96 KB)
here is an updated version of this patch, syncing it with CVS HEAD.
Also, i did change the functionality somewhat: previous versions of the
patch asked the modules what node types were out there (via
hook_node_name()). This version asks the node table what types are in
there (via SELECT DISTINCT type FROM {node}). I find this more useful,
because it's entirely possible that, over time, modules will be removed
from the system, yet they still have rows in the node table. This method
gives a more accurate view of the types of nodes on the system.
The new UI looks excellent, but this patch does not address it.
------------------------------------------------------------------------
September 28, 2004 - 20:05 : drumm
-1
I applied and tested and it did not work at all for me. The type
options selection only contains 's' and 'W', selecting one does not
work. The list of types seems to come from the DB which is probably an
unnecessary query.
------------------------------------------------------------------------
September 29, 2004 - 13:51 : eafarris
Attachment: http://drupal.org/files/issues/admin_node_filter_by_type_1.patch (2.31 KB)
Here's a version of that patch that should work. Sorry.
I think that getting the types from the node table is necessary. The
list of installed nodes is not the authority on what types of nodes are
in the db; we should ask the db directly. It's a small query on one
admin page; the result is that the dropdown has in it the most accurate
information available. That's worth it, imo.
------------------------------------------------------------------------
September 29, 2004 - 13:52 : eafarris
s/list of installed nodes/list of installed modules/ . sheesh. teach me
to post before my tea.
------------------------------------------------------------------------
October 21, 2004 - 19:15 : Bèr Kessels
Attachment: http://drupal.org/files/issues/node.html (29.33 KB)
I do not know where it weant, but my proposal had a HTML mockup.
Attaching it here to see what i meant.
------------------------------------------------------------------------
October 23, 2004 - 14:14 : com2
Nice filter options, but what I really miss it the possibility to select
all checkboxes. Really boring job when you have to click the whole list
one by one.
------------------------------------------------------------------------
October 24, 2004 - 11:41 : Bèr Kessels
I am not a big fan of those options in forms.
They more often break things than that thy fix them. Rahter use a
bookmarklet r so for that:
http://www.squarefree.com/bookmarklets/forms.html
Ber
------------------------------------------------------------------------
October 25, 2004 - 02:03 : Steven
Attachment: http://drupal.org/files/issues/node_admin_ucd.html (29.83 KB)
Based on some more IRC discussion, I came up with this (attachment). It
is based on an earlier mockup.
It does use Javascript and doesn't degrade without script (yet), but I
think it's worth considering. It can be implemented quite cleanly. The
idea would be to have a filter like this initially, and after clicking
'Go', to show the current filter as well as the form again, allowing
you to refine your search.
I haven't tested browser compatibility, but it should work on most
browsers. The only ones I know for sure won't work are IE4 and NS4,
which are old enough to ignore IMO: after all, this is admin only, and
we can put some stricter browser requirements on that. Recent versions
of other browsers should work (it only does a simple visibility
toggle).
I like it because it's not an airplane cockpit, but still offers
complex filtering options through refinement. It is also quite similar
to the search/filtering UI in e.g. mail applications.
The question is of course, how to degrade it for people without
Javascript. My suggestion would be to simply show all filter options,
and put a radiobutton in front of each:
( ) Where type is [ blog | v ]
( ) Where published status is ( ) published ( ) unpublished
( ) Where category is [ term1 | v ]
...
It has more visual clutter, but the same principle of use.
------------------------------------------------------------------------
October 25, 2004 - 02:13 : Steven
In fact, I just realized that the radio-button version can be coded to
send exactly the same form data as the scripted version, which makes it
more interesting.
------------------------------------------------------------------------
October 29, 2004 - 01:52 : Steven
If you guys approve of my idea, I'll start coding. Assigning to myself
for now.
------------------------------------------------------------------------
November 1, 2004 - 18:35 : Bèr Kessels
I like this idea much more than my previous approaches. Gave it some
thought and came with the follwing behaviour:
* I think we need to discuss or at least design the tabular data too:
It makes 0 sense to show the "types" column, if you chose "type =
image"
* I think we need to introduce a hook to add info to that tabulat view.
Images can output thumbnails, for example
* In tabular view, we should make: title a textfield, type and author a
select and satus a select too.
* I think we should introduce another range of options: "where content
contains" [ ] and "where title contains" [ ]
* I would like to get some feedback on how many drupal-using people are
firmly against javascript, with a reason why. I bet that this is < 1% !
Bèr
------------------------------------------------------------------------
November 1, 2004 - 18:42 : Steven
We don't have an anti-JS policy in Drupal. It's just that until
recently, doing cross browser JS was a chore and making it accessible
and degradable would be a disaster.
This form can be implemented cleanly and will degrade without problems.
Anyone who opposes it because it is JS can bugger off ;).
------------------------------------------------------------------------
November 3, 2004 - 20:24 : com2
There is a more radical way around JS. You could forget the table idea
alltogether and present the nodes in Listbox. Then selecting becomes
much easier with Ctrl-Click and Shift-Click
------------------------------------------------------------------------
November 4, 2004 - 01:02 : Bèr Kessels
Did you have a look at the previous applied UI improvements? Did you
consider the pre's and cons of those earlier posts?
It seams you are repeating passed issues here, please reply with miore
detailed issues here,
Bèr
------------------------------------------------------------------------
December 3, 2004 - 11:49 : Steven
Attachment: http://drupal.org/files/issues/node-admin.patch (13.1 KB)
Here's a patch which implements the JS approach of refining the
selection.
------------------------------------------------------------------------
December 3, 2004 - 11:50 : Steven
Attachment: http://drupal.org/files/issues/node_admin.png (34.38 KB)
And here's a screenshot of how it looks.
------------------------------------------------------------------------
December 3, 2004 - 20:23 : FactoryJoe(a)civicspacelabs.org
This is looking better and better. I'm going to do a UI review of this a
post any additional thoughts or comments.
Chris
------------------------------------------------------------------------
December 3, 2004 - 22:50 : Anonymous
Ack, I tested this using the bluebeach theme, but there's a small CSS
bug with bluemarine, where the header for the operations form is stuck
to the right of the filter form. I'll make an updated patch later. In
the meantime, comments are much appreciated.
------------------------------------------------------------------------
December 4, 2004 - 00:15 : killes(a)www.drop.org
I actually prefer the non-JS menu over the JS menu. Not (only) because
of the JS but because I prefer radiobuttons over pulldown menus. The
argument that the non-JS approach uses more vertical space can be
mitigated by redirecting to a #results anchor.
------------------------------------------------------------------------
January 15, 2005 - 07:32 : Steven
Attachment: http://drupal.org/files/issues/node.admin.patch (14.41 KB)
Here's an updated patch... I have exams in a week, so I don't have time
to finish up the Javascript version, so I removed it (it can be added
later easily). However, the non-JS version is still very usable.
Changes since last time:
- Uses semantic XHTML (definition list, and yes, they are for more than
just definitions, even w3c agrees).
- Merges the various node flags (promoted, published, ...) into one
"status" dropdown. This keeps the whole selector shorter, and is better
UI-wise IMO.
- Adds drupal_gotos, they were missing.
- Updates node admin watchog messages to properly display the type. The
code used t($node->type) which is a big no-no. hook_node_name() is now
invoked instead.
- Removes some dead code.
- I rolled Ber's node mass deletion patch in as it affects the same
piece of code. Updating either patch for the other separately would be
a waste of time. I also added some more improvements to Bèr's code,
such as removing the incorrect help from the confirmation page,
cleaning up the code style a bit, not loading every node just to
display its title and displaying a single drupal_set_message() after
the deleting rather than one per node.
The old issue is here: http://drupal.org/node/7743
------------------------------------------------------------------------
January 15, 2005 - 07:32 : Steven
Attachment: http://drupal.org/files/issues/node admin.png (30.19 KB)
------------------------------------------------------------------------
January 15, 2005 - 10:55 : Bèr Kessels
Thanks for integrating the batch delete patch, Steven!
------------------------------------------------------------------------
January 15, 2005 - 14:47 : Dries
Attachment: http://drupal.org/files/issues/node-filter-wrap.png (34.55 KB)
It looks good but:
1. It makes the UI looks cluttered. I suggest visually grouping the
varios form elements so it becomes easier for they eye to skip over
them.
2. It is too wide. Try using the Chameleon theme with a sidebar on the
right at 1024x768 (eg. my laptop's resolution) and you'll find that the
form elements wrap, and wrap in an awkward order. See screenshot.
Maybe we should group the form elements using from_group() and make
"Show only items where" the form_group()'s title. It would save space.
------------------------------------------------------------------------
January 15, 2005 - 17:14 : Bèr Kessels
Steven,
Is there a reason why you do not use theme_box, but hardcode HTML in
your forms? If there is none, I will spend some time monday to fix it.
Bèr
------------------------------------------------------------------------
January 15, 2005 - 18:48 : Steven
Simple. There aren't any guidelines on theme box usage :P. Plus, theming
the admin interface is probably not a big priority.
------------------------------------------------------------------------
January 15, 2005 - 20:44 : FactoryJoe(a)civicspacelabs.org
Attachment: http://drupal.org/files/issues/node-filter-wrap-v2.png (14.23 KB)
I simplified the layout and added some visual separation between
elements (the rounded boxes). I imagine that pretty much the same
markup as exists now could be used with some slight tweaks.
Probably the most significant change, horizontally, is moving the
filter button below the filters.
------------------------------------------------------------------------
January 15, 2005 - 21:13 : Steven
This way they take up even more space though. I'd like to at least have
the user see part of the results table without scrolling. Also, the
rounded boxes are definitely a theme thing and don't really belong in
core.
The markup would need some changes too, as right now the structure is
vertical nested inside horizontal, while yours is horizontal nested in
vertical.
I was also wondering about the wording... "Show items where A is B"
sounds a bit bumpy. Alternatives "... items whose A is B" "items with A
of B", etc.
------------------------------------------------------------------------
January 16, 2005 - 00:04 : Dries
Chris' mockup looks better but there is still room for improvement:
1. The titles of the two /form groups/ are not consistent.
2. Removing the (mostly) brain-death help text might help to reduce the
visual clutter. The help text is incorrect: clicking the username opens
the user's profile page as one would expect.
3. The indentation looks pretty random.
--
View: http://drupal.org/node/10296
Edit: http://drupal.org/project/comments/add/10296
1
0
[drupal-devel] Bug#290439: marked as done (drupal: Updated Japanese po-debconf template translation (ja.po))
by owner@bugs.debian.org 16 Jan '05
by owner@bugs.debian.org 16 Jan '05
16 Jan '05
Your message dated Sun, 16 Jan 2005 11:32:13 -0500
with message-id <E1CqDK1-0005G6-00(a)newraff.debian.org>
and subject line Bug#290439: fixed in drupal 4.5.2-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 14 Jan 2005 05:30:41 +0000
>From henrich(a)samba.gr.jp Thu Jan 13 21:30:41 2005
Return-path: <henrich(a)samba.gr.jp>
Received: from c201166.ppp.asahi-net.or.jp (grapefruit) [210.155.201.166]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CpK2d-0001Ll-00; Thu, 13 Jan 2005 21:30:36 -0800
Received: by grapefruit (Postfix, from userid 1000)
id 57AFB40A4; Fri, 14 Jan 2005 14:34:00 +0900 (JST)
Content-Type: multipart/mixed; boundary="===============1335817586=="
MIME-Version: 1.0
From: Hideki Yamane <henrich(a)samba.gr.jp>
To: Debian Bug Tracking System <submit(a)bugs.debian.org>
Subject: drupal: Updated Japanese po-debconf template translation (ja.po)
X-Mailer: reportbug 3.5
Date: Fri, 14 Jan 2005 14:34:00 +0900
Message-Id: <20050114053400.57AFB40A4@grapefruit>
Delivered-To: submit(a)bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-3.5 required=4.0 tests=BODY_8BITS,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
This is a multi-part MIME message sent by reportbug.
--===============1335817586==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Package: drupal
Severity: wishlist
Tags: l10n patch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear drupal maintainer,
Thank you for adding ja.po file to your package.
But, sorry, I fotgot to translate 1 message... now I translate
it completely. Please use attached one.
- --
Regards,
Hideki Yamane henrich @ samba.gr.jp/iijmio-mail.jp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFB51nHIu0hy8THJksRAn9bAJ9RODqBtvBiReSzld9usQtg3yz9sACfesvP
2WoVQlJSdDgboK6ec+bKMPs=
=56a7
-----END PGP SIGNATURE-----
--===============1335817586==
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: attachment; filename="ja.po"
Content-Transfer-Encoding: quoted-printable
#
# Translators, if you are not familiar with the PO format, gettext
# documentation is worth reading, especially sections dedicated to
# this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
# Some information specific to po-debconf are available at
# /usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
#
# Developers do not need to manually edit POT or PO files.
#
#
msgid ""
msgstr ""
"Project-Id-Version: drupal 4.5.1-1\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2004-03-13 19:13+0100\n"
"PO-Revision-Date: 2005-01-11 08:39+0900\n"
"Last-Translator: Hideki Yamane <henrich(a)samba.gr.jp>\n"
"Language-Team: Japanese <debian-japanese(a)lists.debian.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=3DEUC-JP\n"
"Content-Transfer-Encoding: 8bit\n"
#. Type: boolean
#. Description
#: ../templates.master:4
msgid "Automatically create Drupal database?"
msgstr "Drupal =A4=CE=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=F2=BC=AB=C6=B0=
=C5=AA=A4=CB=BA=EE=C0=AE=A4=B7=A4=DE=A4=B9=A4=AB?"
#. Type: boolean
#. Description
#: ../templates.master:4
msgid ""
"Drupal needs access to a database, along with initialized data structure=
s in "
"order to function properly. This can be created automatically by this "
"package, for MySQL or PostgreSQL databases."
msgstr ""
"=B5=A1=C7=BD=A4=AC=C0=B5=A4=B7=A4=AF=C6=B0=BA=EE=A4=B9=A4=EB=A4=BF=A4=E1=
=A4=CB=A4=CF=A1=A2Drupal =A4=CF=A5=C7=A1=BC=A5=BF=B9=BD=C2=A4=A4=AC=BD=E9=
=B4=FC=B2=BD=A4=B5=A4=EC=A4=BF=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=CB"
"=C0=DC=C2=B3=A4=B9=A4=EB=C9=AC=CD=D7=A4=AC=A4=A2=A4=EA=A4=DE=A4=B9=A1=A3=
=A4=B3=A4=EC=A4=CF=A1=A2=A4=B3=A4=CE=A5=D1=A5=C3=A5=B1=A1=BC=A5=B8=A4=CB=A4=
=E8=A4=C3=A4=C6=BC=AB=C6=B0=C5=AA=A4=CB=BA=EE=C0=AE=B2=C4=C7=BD=A4=C7=A1=A2=
"
"MySQL =A4=DE=A4=BF=A4=CF PostgreSQL =A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=
=A4=CE=A4=C9=A4=C1=A4=E9=A4=AB=A4=AC=CD=F8=CD=D1=A4=C7=A4=AD=A4=DE=A4=B9=A1=
=A3"
#. Type: boolean
#. Description
#: ../templates.master:4
msgid ""
"Automatically creating the database does not make sense if a Drupal data=
base "
"already exists or if no database server has been setup when Drupal is "
"installed."
msgstr ""
"Drupal =A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=AC=A4=B9=A4=C7=A4=CB=C2=B8=
=BA=DF=A4=B7=A4=C6=A4=A4=A4=EB=A1=A2=A4=DE=A4=BF=A4=CF Drupal =A4=CE=A5=A4=
=A5=F3=A5=B9=A5=C8=A1=BC=A5=EB=BB=FE=A4=CB=A5=C7=A1=BC"
"=A5=BF=A5=D9=A1=BC=A5=B9=A5=B5=A1=BC=A5=D0=A4=AC=C0=DF=C4=EA=A4=B5=A4=EC=
=A4=C6=A4=A4=A4=CA=A4=A4=A4=CA=A4=C9=A4=CE=BE=EC=B9=E7=A1=A2=A5=C7=A1=BC=A5=
=BF=A5=D9=A1=BC=A5=B9=A4=CE=BC=AB=C6=B0=BA=EE=C0=AE=A4=CF=B0=D5=CC=A3=A4=AC=
=A4=A2"
"=A4=EA=A4=DE=A4=BB=A4=F3=A1=A3"
#. Type: boolean
#. Description
#: ../templates.master:16
msgid "Run database update script?"
msgstr "=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=F2=B9=B9=BF=B7=A4=B9=A4=EB=
=A5=B9=A5=AF=A5=EA=A5=D7=A5=C8=A4=F2=BC=C2=B9=D4=A4=B7=A4=DE=A4=B9=A4=AB?=
"
#. Type: boolean
#. Description
#: ../templates.master:16
msgid ""
"If you are upgrading Drupal from an older upstream version, the database=
"
"structure needs to be updated. This package can perform this task "
"automatically."
msgstr ""
"Drupal =A4=F2=B8=C5=A4=A4=B3=AB=C8=AF=B8=B5=A4=CE=A5=D0=A1=BC=A5=B8=A5=E7=
=A5=F3=A4=AB=A4=E9=A5=A2=A5=C3=A5=D7=A5=B0=A5=EC=A1=BC=A5=C9=A4=B9=A4=EB=BE=
=EC=B9=E7=A1=A2=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=B9=BD=C2=A4=A4=E2"
"=B9=B9=BF=B7=A4=B9=A4=EB=C9=AC=CD=D7=A4=AC=A4=A2=A4=EA=A4=DE=A4=B9=A1=A3=
=A4=B3=A4=CE=A5=D1=A5=C3=A5=B1=A1=BC=A5=B8=A4=C7=A4=CF=A4=B3=A4=CE=BA=EE=B6=
=C8=A4=F2=BC=AB=C6=B0=C5=AA=A4=CB=BC=C2=B9=D4=A4=B7=A4=DE=A4=B9=A1=A3"
#. Type: boolean
#. Description
#: ../templates.master:16
msgid "The database will be backed up to prevent data loss."
msgstr "=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=CF=A5=C7=A1=BC=A5=BF=A4=CE=
=C2=BB=BC=BA=A4=F2=C8=F2=A4=B1=A4=EB=A4=BF=A4=E1=A4=CB=A5=D0=A5=C3=A5=AF=A5=
=A2=A5=C3=A5=D7=A4=B5=A4=EC=A4=DE=A4=B9=A1=A3"
#. Type: select
#. Description
#: ../templates.master:27
msgid "Database engine to be used with Drupal"
msgstr "Drupal =A4=C7=BB=C8=A4=EF=A4=EC=A4=EB=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=
=A5=B9=A5=A8=A5=F3=A5=B8=A5=F3"
#. Type: string
#. Description
#: ../templates.master:32
msgid "Database server for Drupal's database"
msgstr "Drupal =A4=CE=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=CD=D1=A4=CE=A5=C7=
=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A5=B5=A1=BC=A5=D0"
#. Type: string
#. Description
#: ../templates.master:37
msgid "Database server administrator user name on host ${host}"
msgstr "=A5=DB=A5=B9=A5=C8 ${host} =BE=E5=A4=CE=A5=C7=A1=BC=A5=BF=A5=D9=A1=
=BC=A5=B9=A5=B5=A1=BC=A5=D0=A4=CE=B4=C9=CD=FD=BC=D4=A5=E6=A1=BC=A5=B6"
#. Type: password
#. Description
#: ../templates.master:42
msgid "Password for database server administrator ${user} on host ${host}=
"
msgstr "=A5=DB=A5=B9=A5=C8 ${host} =BE=E5=A4=CE=A5=C7=A1=BC=A5=BF=A5=D9=A1=
=BC=A5=B9=A5=B5=A1=BC=A5=D0=A4=CE=B4=C9=CD=FD=BC=D4 ${user} =A4=CE=A5=D1=A5=
=B9=A5=EF=A1=BC=A5=C9"
#. Type: password
#. Description
#: ../templates.master:42
msgid "The answer will not be stored anywhere permanently."
msgstr "=B2=F3=C5=FA=A4=CF=A4=C9=A4=B3=A4=CB=A4=E2=B9=B1=B5=D7=C5=AA=A4=CB=
=A4=CF=CA=DD=C2=B8=A4=B5=A4=EC=A4=DE=A4=BB=A4=F3=A1=A3"
#. Type: string
#. Description
#: ../templates.master:48
msgid "Drupal database owner username"
msgstr "Drupal =A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=CE=BD=EA=CD=AD=BC=D4=
=A5=E6=A1=BC=A5=B6=CC=BE"
#. Type: string
#. Description
#: ../templates.master:48
msgid "This username will be used by Drupal to connect to the database se=
rver."
msgstr "=A4=B3=A4=CE=A5=E6=A1=BC=A5=B6=CC=BE=A4=AC=A5=C7=A1=BC=A5=BF=A5=D9=
=A1=BC=A5=B9=A4=CB=C0=DC=C2=B3=A4=B9=A4=EB=BA=DD=A1=A2Drupal =A4=CB=A4=E8=
=A4=C3=A4=C6=BB=C8=A4=EF=A4=EC=A4=DE=A4=B9"
#. Type: password
#. Description
#: ../templates.master:54
msgid "Drupal database owner password"
msgstr "Drupal =A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=CE=BD=EA=CD=AD=BC=D4=
=A5=D1=A5=B9=A5=EF=A1=BC=A5=C9"
#. Type: password
#. Description
#: ../templates.master:54
msgid "If no password is specified here, a random password will be genera=
ted."
msgstr ""
"=A4=B3=A4=B3=A4=C7=A5=D1=A5=B9=A5=EF=A1=BC=A5=C9=A4=AC=BB=D8=C4=EA=A4=B5=
=A4=EC=A4=CA=A4=AB=A4=C3=A4=BF=BE=EC=B9=E7=A1=A2=A5=E9=A5=F3=A5=C0=A5=E0=A4=
=C7=A5=D1=A5=B9=A5=EF=A1=BC=A5=C9=A4=AC=C0=B8=C0=AE=A4=B5=A4=EC=A4=DE=A4=B9=
=A1=A3"
#. Type: string
#. Description
#: ../templates.master:61
msgid "Drupal database name"
msgstr "Drupal =A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=CC=BE"
#. Type: boolean
#. Description
#: ../templates.master:66
msgid "Remove Drupal database when the package is removed?"
msgstr "=A5=D1=A5=C3=A5=B1=A1=BC=A5=B8=A4=F2=BA=EF=BD=FC=A4=B9=A4=EB=BA=DD=
=A1=A2Drupal =A4=CE=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=E2=BA=EF=BD=FC=
=A4=B7=A4=DE=A4=B9=A4=AB?"
#. Type: boolean
#. Description
#: ../templates.master:71
msgid "Remove former database backups when the package is removed?"
msgstr ""
"=A5=D1=A5=C3=A5=B1=A1=BC=A5=B8=A4=F2=BA=EF=BD=FC=A4=B9=A4=EB=BA=DD=A1=A2=
=B0=CA=C1=B0=A4=CE=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=CE=A5=D0=A5=C3=A5=
=AF=A5=A2=A5=C3=A5=D7=A4=E2=BA=EF=BD=FC=A4=B7=A4=DE=A4=B9=A4=AB?"
#. Type: boolean
#. Description
#: ../templates.master:71
msgid ""
"These backups are stored in /var/lib/drupal/backups. This will not remov=
e "
"the current database from the DBMS."
msgstr ""
"=A4=B3=A4=CE=A5=D0=A5=C3=A5=AF=A5=A2=A5=C3=A5=D7=A4=CF /var/lib/drupal/b=
ackups =A4=CB=CA=DD=C2=B8=A4=B5=A4=EC=A4=C6=A4=A4=A4=EB=A4=E2=A4=CE=A4=C7=
=A4=B9=A1=A3=A4=B3=A4=EC=A4=F2"
"=B9=D4=A4=C3=A4=C6=A4=E2=A1=A2DBMS =A4=AB=A4=E9=B8=BD=BA=DF=A4=CE=A5=C7=A1=
=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=CE=BA=EF=BD=FC=A4=CF=B9=D4=A4=A4=A4=DE=A4=BB=
=A4=F3=A1=A3"
#. Type: multiselect
#. Description
#: ../templates.master:79
msgid "Web server(s) that should be configured automatically"
msgstr "web =A5=B5=A1=BC=A5=D0=A4=CF=BC=AB=C6=B0=C5=AA=A4=CB=C0=DF=C4=EA=A4=
=B5=A4=EC=A4=DE=A4=B9"
#. Type: note
#. Description
#: ../templates.master:83
msgid "User creation failed"
msgstr "=A5=E6=A1=BC=A5=B6=A4=CE=BA=EE=C0=AE=A4=AC=BC=BA=C7=D4=A4=B7=A4=DE=
=A4=B7=A4=BF"
#. Type: note
#. Description
#: ../templates.master:90
msgid "Attempt to modify config file ${conffile} failed"
msgstr "=C0=DF=C4=EA=A5=D5=A5=A1=A5=A4=A5=EB ${conffile} =A4=CE=CA=D1=B9=B9=
=A4=AC=BC=BA=C7=D4=A4=B7=A4=DE=A4=B7=A4=BF"
#. Type: note
#. Description
#: ../templates.master:97
msgid "Database creation failed"
msgstr "=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=CE=BA=EE=C0=AE=A4=AC=BC=BA=
=C7=D4=A4=B7=A4=DE=A4=B7=A4=BF"
#. Type: note
#. Description
#: ../templates.master:104
msgid "Database initialization failed"
msgstr "=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=CE=BD=E9=B4=FC=B2=BD=A4=AC=
=BC=BA=C7=D4=A4=B7=A4=DE=A4=B7=A4=BF"
#. Type: note
#. Description
#: ../templates.master:111
msgid "Automatic database update failed"
msgstr "=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=CE=BC=AB=C6=B0=A5=A2=A5=C3=
=A5=D7=A5=C7=A1=BC=A5=C8=A4=AC=BC=BA=C7=D4=A4=B7=A4=DE=A4=B7=A4=BF"
#. Type: note
#. Description
#: ../templates.master:111
msgid "The automatic update script failed to update the database."
msgstr ""
"=BC=AB=C6=B0=B9=B9=BF=B7=A5=B9=A5=AF=A5=EA=A5=D7=A5=C8=A4=AC=A5=C7=A1=BC=
=A5=BF=A5=D9=A1=BC=A5=B9=A4=CE=A5=A2=A5=C3=A5=D7=A5=C7=A1=BC=A5=C8=A4=F2=B9=
=D4=A4=AA=A4=A6=A4=C8=A4=B7=A4=DE=A4=B7=A4=BF=A4=AC=A1=A2=BC=BA=C7=D4=A4=B7=
=A4=DE"
"=A4=B7=A4=BF=A1=A3"
#. Type: note
#. Description
#: ../templates.master:120
msgid "Automatic update script can not be run"
msgstr "=BC=AB=C6=B0=B9=B9=BF=B7=A5=B9=A5=AF=A5=EA=A5=D7=A5=C8=A4=AC=BC=C2=
=B9=D4=A4=C7=A4=AD=A4=DE=A4=BB=A4=F3"
#. Type: note
#. Description
#: ../templates.master:120
msgid ""
"Configuration files of a Drupal package ${oldversion} have been found, b=
ut "
"the package itself has been removed. Therefore, it is not possible to ru=
n "
"the automatic update script."
msgstr ""
"Drupal =A5=D1=A5=C3=A5=B1=A1=BC=A5=B8 ${oldversion} =A4=CE =C0=DF=C4=EA=A5=
=D5=A5=A1=A5=A4=A5=EB=A4=AC=B8=AB=A4=C4=A4=AB=A4=EA=A4=DE=A4=B7=A4=BF=A4=AC=
=A1=A2=A5=D1=A5=C3=A5=B1=A1=BC=A5=B8"
"=BC=AB=C2=CE=A4=CF=BA=EF=BD=FC=A4=B5=A4=EC=A4=C6=A4=A4=A4=DE=A4=B9=A1=A3=
=A4=C4=A4=DE=A4=EA=A1=A2=BC=AB=C6=B0=B9=B9=BF=B7=A5=B9=A5=AF=A5=EA=A5=D7=A5=
=C8=A4=AC=BC=C2=B9=D4=A4=C7=A4=AD=A4=DE=A4=BB=A4=F3=A1=A3"
#. Type: note
#. Description
#: ../templates.master:120
msgid ""
"Please run it by hand after the package has been successfully installed.=
"
"Either point your web browser to ${site_root}/update.php or run /usr/sha=
re/"
"drupal/scripts/debian-update.php from a shell."
msgstr ""
"=A5=D1=A5=C3=A5=B1=A1=BC=A5=B8=A4=CE=A5=A4=A5=F3=A5=B9=A5=C8=A1=BC=A5=EB=
=A4=AC=B4=B0=CE=BB=B8=E5=A1=A2=BC=EA=C6=B0=A4=C7=BC=C2=B9=D4=A4=B7=A4=C6=A4=
=AF=A4=C0=A4=B5=A4=A4=A1=A3=A4=DE=A4=BF=A4=CF=A5=D6=A5=E9=A5=A6=A5=B6=A4=C7=
"
"${site_root}/update.php =A4=F2=BB=B2=BE=C8=A4=B9=A4=EB=A4=AB=A1=A2=A5=B7=
=A5=A7=A5=EB=A4=AB=A4=E9 /usr/share/drupal/scripts/"
"debian-update.php =A4=F2=BC=C2=B9=D4=A4=B7=A4=C6=A4=AF=A4=C0=A4=B5=A4=A4=
=A1=A3"
#. Type: note
#. Description
#: ../templates.master:132
msgid "Database removal failed"
msgstr "=A5=C7=A1=BC=A5=BF=A5=D9=A1=BC=A5=B9=A4=CE=BA=EF=BD=FC=A4=AC=BC=BA=
=C7=D4=A4=B7=A4=DE=A4=B7=A4=BF"
#. Type: note
#. Description
#: ../templates.master:132
msgid "Script output:"
msgstr "=A5=B9=A5=AF=A5=EA=A5=D7=A5=C8=A4=CE=B7=EB=B2=CC:"
#. Type: note
#. Description
#: ../templates.master:132
msgid "${result}"
msgstr "${result}"
--===============1335817586==--
---------------------------------------
Received: (at 290439-close) by bugs.debian.org; 16 Jan 2005 16:35:35 +0000
>From katie(a)ftp-master.debian.org Sun Jan 16 08:35:35 2005
Return-path: <katie(a)ftp-master.debian.org>
Received: from newraff.debian.org [208.185.25.31] (mail)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CqDNH-00089W-00; Sun, 16 Jan 2005 08:35:35 -0800
Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian))
id 1CqDK1-0005G6-00; Sun, 16 Jan 2005 11:32:13 -0500
From: Hilko Bengen <bengen(a)debian.org>
To: 290439-close(a)bugs.debian.org
X-Katie: $Revision: 1.55 $
Subject: Bug#290439: fixed in drupal 4.5.2-1
Message-Id: <E1CqDK1-0005G6-00(a)newraff.debian.org>
Sender: Archive Administrator <katie(a)ftp-master.debian.org>
Date: Sun, 16 Jan 2005 11:32:13 -0500
Delivered-To: 290439-close(a)bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
Source: drupal
Source-Version: 4.5.2-1
We believe that the bug you reported is fixed in the latest version of
drupal, which is due to be installed in the Debian FTP archive:
drupal_4.5.2-1.diff.gz
to pool/main/d/drupal/drupal_4.5.2-1.diff.gz
drupal_4.5.2-1.dsc
to pool/main/d/drupal/drupal_4.5.2-1.dsc
drupal_4.5.2-1_all.deb
to pool/main/d/drupal/drupal_4.5.2-1_all.deb
drupal_4.5.2.orig.tar.gz
to pool/main/d/drupal/drupal_4.5.2.orig.tar.gz
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 290439(a)bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Hilko Bengen <bengen(a)debian.org> (supplier of updated drupal package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster(a)debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Sun, 16 Jan 2005 14:49:50 +0100
Source: drupal
Binary: drupal
Architecture: source all
Version: 4.5.2-1
Distribution: unstable
Urgency: low
Maintainer: Hilko Bengen <bengen(a)debian.org>
Changed-By: Hilko Bengen <bengen(a)debian.org>
Description:
drupal - fully-featured content management/discussion engine
Closes: 290439 290745
Changes:
drupal (4.5.2-1) unstable; urgency=low
.
* New upstream version (Closes: #290745; That was fast, wasn't it?)
* Updates Japanese Debconf template, thanks to Hideki Yamane
(Closes: #290439)
* The config file /etc/drupal/conf.php is only generated if it hasn't
existed. It is no longer edited.
Files:
a1d7087021192176c80ccece1a6b84c7 609 web extra drupal_4.5.2-1.dsc
90b11363f95351e09e1bcf3f32708d78 471370 web extra drupal_4.5.2.orig.tar.gz
1b0fde2e38840d8136264a849fd2044f 32990 web extra drupal_4.5.2-1.diff.gz
eb4c3690b7c05f5868c4bbb3f8638504 482384 web extra drupal_4.5.2-1_all.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFB6pKTUCgnLz/SlGgRAuf3AKCpjP0xSW81PEkaXMqH5T+W6AAklwCeNcK1
rajdXLXgVH2U7wb9o/LDAfc=
=hSnn
-----END PGP SIGNATURE-----
1
0
[drupal-devel] Bug#290745: marked as done (new version with important updates)
by owner@bugs.debian.org 16 Jan '05
by owner@bugs.debian.org 16 Jan '05
16 Jan '05
Your message dated Sun, 16 Jan 2005 11:32:13 -0500
with message-id <E1CqDK1-0005G8-00(a)newraff.debian.org>
and subject line Bug#290745: fixed in drupal 4.5.2-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 16 Jan 2005 12:55:54 +0000
>From aportela(a)fastmail.fm Sun Jan 16 04:55:54 2005
Return-path: <aportela(a)fastmail.fm>
Received: from 208.red-83-42-18.pooles.rima-tde.net (alcatraz.dns-local.net) [83.42.18.208]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1Cq9wg-00042s-00; Sun, 16 Jan 2005 04:55:54 -0800
Received: from z0mbie (helo=localhost)
by alcatraz.dns-local.net with local-esmtp (Exim 3.36 #1 (Debian))
id 1Cq9w9-0000aq-00
for <submit(a)bugs.debian.org>; Sun, 16 Jan 2005 13:55:21 +0100
Date: Sun, 16 Jan 2005 13:55:21 +0100 (CET)
From: alex <aportela(a)fastmail.fm>
To: submit(a)bugs.debian.org
Subject: new version with important updates
Message-ID: <Pine.LNX.4.61.0501161348560.2265(a)alcatraz.dns-local.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: alex <aportela(a)fastmail.fm>
Delivered-To: submit(a)bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-5.2 required=4.0 tests=BAYES_40,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
Package: drupal
Version: 4.5.1-2
Drupal 4.5.2 was released, with an important vulnerability fix (cross-site
scripting). In addition, the 4.5.1-2 version has a bug with the comments
in the nodes, as you can read here:
http://drupal.org/node/11777
---------------------------------------
Received: (at 290745-close) by bugs.debian.org; 16 Jan 2005 16:35:40 +0000
>From katie(a)ftp-master.debian.org Sun Jan 16 08:35:39 2005
Return-path: <katie(a)ftp-master.debian.org>
Received: from newraff.debian.org [208.185.25.31] (mail)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CqDNL-0008Bw-00; Sun, 16 Jan 2005 08:35:39 -0800
Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian))
id 1CqDK1-0005G8-00; Sun, 16 Jan 2005 11:32:13 -0500
From: Hilko Bengen <bengen(a)debian.org>
To: 290745-close(a)bugs.debian.org
X-Katie: $Revision: 1.55 $
Subject: Bug#290745: fixed in drupal 4.5.2-1
Message-Id: <E1CqDK1-0005G8-00(a)newraff.debian.org>
Sender: Archive Administrator <katie(a)ftp-master.debian.org>
Date: Sun, 16 Jan 2005 11:32:13 -0500
Delivered-To: 290745-close(a)bugs.debian.org
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
X-CrossAssassin-Score: 2
Source: drupal
Source-Version: 4.5.2-1
We believe that the bug you reported is fixed in the latest version of
drupal, which is due to be installed in the Debian FTP archive:
drupal_4.5.2-1.diff.gz
to pool/main/d/drupal/drupal_4.5.2-1.diff.gz
drupal_4.5.2-1.dsc
to pool/main/d/drupal/drupal_4.5.2-1.dsc
drupal_4.5.2-1_all.deb
to pool/main/d/drupal/drupal_4.5.2-1_all.deb
drupal_4.5.2.orig.tar.gz
to pool/main/d/drupal/drupal_4.5.2.orig.tar.gz
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 290745(a)bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Hilko Bengen <bengen(a)debian.org> (supplier of updated drupal package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster(a)debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Sun, 16 Jan 2005 14:49:50 +0100
Source: drupal
Binary: drupal
Architecture: source all
Version: 4.5.2-1
Distribution: unstable
Urgency: low
Maintainer: Hilko Bengen <bengen(a)debian.org>
Changed-By: Hilko Bengen <bengen(a)debian.org>
Description:
drupal - fully-featured content management/discussion engine
Closes: 290439 290745
Changes:
drupal (4.5.2-1) unstable; urgency=low
.
* New upstream version (Closes: #290745; That was fast, wasn't it?)
* Updates Japanese Debconf template, thanks to Hideki Yamane
(Closes: #290439)
* The config file /etc/drupal/conf.php is only generated if it hasn't
existed. It is no longer edited.
Files:
a1d7087021192176c80ccece1a6b84c7 609 web extra drupal_4.5.2-1.dsc
90b11363f95351e09e1bcf3f32708d78 471370 web extra drupal_4.5.2.orig.tar.gz
1b0fde2e38840d8136264a849fd2044f 32990 web extra drupal_4.5.2-1.diff.gz
eb4c3690b7c05f5868c4bbb3f8638504 482384 web extra drupal_4.5.2-1_all.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFB6pKTUCgnLz/SlGgRAuf3AKCpjP0xSW81PEkaXMqH5T+W6AAklwCeNcK1
rajdXLXgVH2U7wb9o/LDAfc=
=hSnn
-----END PGP SIGNATURE-----
1
0