the other day, sepeck hipped me to the amazingly useful book outliner functionality. for example (if you're a site admin @ d.o): http://drupal.org/admin/node/book/257
so, i fixed up a few things on the theme update pages for the switch to 2-digit version numbers, and hit the "Save book pages" button. out of curiosity, i wanted to see what the log message was going to say, and was sadly disappointed. for example:
http://drupal.org/node/25297/revisions
30/09/2006 - 18:17 by dww
themes shouldn't use theme_add_style internally (see bug 52508)
07/03/2006 - 18:39 by TDobes
themes shouldn't use theme_add_style internally (see bug 52508)
this appears to be another instance of a bug i thought i had fixed in http://drupal.org/node/39124
however, i'm submitting it as a new issue, since it's really a different thing: that was the book edit form, this is the outliner.
when i have a chance, i'll post a patch for this. if someone else is inspired and gets it done first, all the better. ;)
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | book.d5.log-message.patch | 1.28 KB | Freso |
| #16 | book-log-message-86857-16.patch | 1.37 KB | webchick |
| #15 | book-log-message-86857-15.patch | 1.37 KB | webchick |
| #14 | book-log-message-86857-14.patch | 822 bytes | webchick |
| #11 | book-log-message-86857-10.patch | 1.65 KB | webchick |
Comments
Comment #1
magico commented@dww: any news about this. The links point to drupal, an you provide some steps to recreate this?
Comment #2
dwwthis is still broken.
i've had no time to fix it.
here's how to reproduce:
at the very least, the log message should be blank in this case. better yet, it should automatically set to something like "Changed via administrative book outliner interface". in D6, we should probably add a log field textarea to this UI, and use that.
cheers,
-derek
Comment #3
pwolanin commentedThis bug seems to occur still in 6.x, even though the dedicated node type is gone.
Comment #4
pwolanin commentedhere's a patch for 6.x
Comment #5
pwolanin commentedbump. This is a trivial patch, so the only question is whether to use a message as proposed, or just put an empty string.
Comment #6
Freso commentedI could reproduce the bug without a checkout from latest CVS. Then fetched the patch, which applied cleanly. Trying to reproduce the bug fails, as the patch works as advertised. Yay! :)
Some comments though:
The first one is rather minor and can be quickly fixed by the committer, but the second one, as noted, is probably a bigger patch. Since the present patch is better than the present situation, I'm marking RTBC, though still requesting a comment from someone on whether to open a new issue to allow one to enter a custom log message for changes made through admin/content/book.
Comment #7
dries commentedI'm not sure I like that fix. The wording of the message is not user-friendly, and I wonder why we should bother recording such a message.
Comment #8
pwolanin commented@Dries - I'm fine with an empty log message too - the idea was just to indicate where/how the revision was generated.
Comment #9
gábor hojtsyYes, it might still be a good idea to store if a change was made on the outline form I think. Having an empty log message looks cleaner, but does not retain what is possibly important information here. Although the log message could be a bit more user friendly, eg
t('Changed on the book outline form at admin/content/book'). Including the path is also a bit tricky as it can be aliased or moved around, so a drupal_get_path_alias() call would make it provide more exact information there.Comment #10
webchickMy vote is for empty log message, personally. The only way the automated log message would be useful is if it said:
* Changed page weight from 7 to 18.
* Changed title from 'hello' to 'goodbye'
The fact that it was changed, and from where it was changed, isn't useful.
Comment #11
webchickHm. Actually. Could we just do that?
Comment #12
Freso commentedFWIW, my vote is for some message. With an empty message you'll have to look at the revision to say "Ahh, that was what I did then.", while you might far sooner come to the same revelation if it said that it was changed on this-and-this page (since that page would only have limited options for changing it in the first place).
Also, see my point no. 2 in comment #6.
Comment #13
Freso commentedwebchick, I love you!
Patch applies cleanly and works wonderfully as advertised. The new log messages are clear and to-the-point. If anything, there's too much/specific info in the log message, but hey, I'm not complaining! :) Marking RTBC.
(I'd still like to be able to specify custom log messages, as previously stated, to explain motivation etc., but this is excellent for now. :))
Comment #14
webchickI realized we already have the original and new values, so no need to store them in the form definition.
Comment #15
webchickSorry. here's one with -up.
Comment #16
webchickOk. No more patch rolling before coffee. :P
I *think* this is good to go now.
Comment #17
Freso commentedPatch from #16 shows same behaviour as reported in comment #13, in addition to being leaner code. I believe it's RTBC, unless webchick has further objections to her patch. ;)
Comment #18
gábor hojtsyThis looks way better. Thanks for the patch, committed.
Comment #19
pwolanin commentedgreat, thanks!
some version of this should be backported as well.
Comment #20
Freso commentedHere's an almost identical patch for D5, which hasn't been tested. So, please, test.
Comment #21
webchickCan we do this? It changes strings in a stable release.
Comment #22
gábor hojtsy@webchick: There is no hard rule. We did this before, some strings were added/changed when it was necessary. It needs consideration in each case.
Comment #23
Freso commentedSo, who should make the decision? Dries? Drumm?
Comment #24
dwwBump: #20 still applies (without fuzz!) to DRUPAL-5. I just tested it and it all works as expected. I'd support this being committed -- yes it "breaks" the translations, but only in a very obscure place in the UI. ;) Therefore, I'm marking this RTBC, to put this on the radar for the core committers -- probably drumm will ultimately be the one to decide about this particular backport.
Comment #25
drummI would say this is a feature that could be implemented in a module for 5.x.