Preview changes doesn't work for all special fields

Its quite possible this preview changes would not work for other (not core) node types too. In my case, I have my own defined node and 'preview changes' doesn't make sence because the body data is being rendered after submit.

In any case, wouldn't it be better to have an option under admin/settings/node where you can select the nodes where the 'preview changes' should appear?

This follow up is a duplicate from http://drupal.org/node/115226#comment-192611

I can create a patch for this if you think this would be a good idea.

The webform module should be included in the group of modules listed above. +1 to toemaz's suggestion. He's even offering to contribute the patch, please reconsider your stance on this.

As proposed by Moshe (http://drupal.org/node/115226#comment-192669), I made a contrib module implementing the form_alter hook. I can still create a patch, but only if the module devs will consider to commit it.

We need to hear from the mod authors how they wish to tackle this issue. Any ideas?

personally, i wouldn't mind a checkbox on the configure node type forms to indicate if you want the "preview changes" button. seems like making it always work, all the time, is a lot of work, and it'd be easier to just provide an admin UI to turn this on/off on the site.

however, i'm guessing moshe will consider that bloat for diff.module itself.

most of the work for this would be shared if it was a separate module using form alter, or code native to the diff.module. the bulk of the code would be the admin UI, and some DB stuff to store the results (probably via variable_set(), possibly via another table, instead). the actual code to hide the button is basically 3 lines, no matter what (either an if() clause around the $form declaration in diff.module itself, or an if() and an unset() in hook_form_alter())...

so, i say, just write something, however you want to do it, and we can see how big it is. if it's huge, it should probably become a separate module (which i'd have no problem including in the same directory/package as diff.module). if it's tiny, i'd probably vote to just put it in diff.module directly.

thanks,
-derek

dww, this is exactly what has already been discussed and suggested by myself and toemaz. In fact, the introduction of the "Preview changes" button seems unnecessary as someone with the correct permissions can already generate a diff through the revisions tab. Why would someone edit a node, add/remove/modify content and then wants to see a diff before submit?

Seems like not enough thought went into it before it was committed from the patch posted.

i'm not claiming i have a new idea, i was (as requested) giving my thoughts on this as one of the mod maintainers with commit rights... ;) i was just outlining exactly how little code this would involve, as justification for my vote to include it in diff.module proper.

re: the merits of the "Preview changes" button in the first place, this isn't the right place to discuss that. but, briefly: just because i *could* make an edit to an important page on a live site, *then* go look at the revisions tab to see if my change was really only touching what i wanted, and then repeat (all while 100s of people are seeing my live edit before i had a chance to verify it), doesn't mean that's a good idea. it's nice to see exactly what you've changed with a given edit, to make sure something you had no intention of touching wasn't changed too. just seeing a preview of your new copy (especially on a very large post) makes it extremely difficult, time consuming, and error prone, to verify you're only changing what you think you wanted to change. that's the whole reason diff exists in general, and diff.module exists in particular.

think of CVS: you should *ALWAYS* run "cvs diff" in a workspace before you commit it, to make sure no debugging code, other modifications, etc, snunk into a workspace before you commit a given patch. likewise, it's nice to review the diff on your text modifications to a piece of content before you press "submit", and "commit" it to a live site.

anyway, digression over. ;)

cheers,
-derek

Derek, that's why life revolves around diff.module and revision_moderation.module - in case an admin needs to approve of changes before they go live ;)

what if you're the admin? ;) you still want to (be able to) see the diff of your change before you submit it. again, just becuase i maintain a bunch of modules (am the admin) doesn't mean i'm *always* 100% right and never screw anything up. "cvs diff" before commit goes a long way to avoiding problems. likewise "Preview changes" before "submit"...

anyway, back to the issue at hand. where's this code? ;) once we have a patch to start from, we can make a better decision on where it goes.

thanks,
-derek

Marking as duplicate of: http://drupal.org/node/198917

This is the earliest issue about the topic, we should discuss it here.
To review: http://drupal.org/files/issues/diff_125494_preview_changes.patch

No longer applies after http://drupal.org/node/153234 and http://drupal.org/node/180069
Should be an easy re-roll... anyone?

patch re-rolled.

There were a few remaining code style problems with the patch, but I fixed those, did some final review/testing, and committed the attached patch to HEAD and DRUPAL-5.

This would require some larger backporting to 4.7.x, since the content editing form is handled very differently back then. I'm not sure anyone cares, so we can just set this back to 5.x and fixed, but I figured I'd leave it like this for a little while to see if anyone steps up to backport this. Thanks.

set it back if someone cares to do a 4.7 port.

Hi dww, moshe & everyone...

I'm using Diff 5.x-2.0 on a clean D5.7 install, and had problems with the Preview Changes feature. It shows 'Changes to Taxonomy' when there are none.

I tried to apply the patch in #18 (not clear to me if this was for the first part of this issue, or the taxonomy part).
In any case, I got the following warning when trying to apply the patch:

patch < diff_125494_preview_changes_2.patch
patching file diff.module
Reversed (or previously applied) patch detected! Assume -R? [n]

Which makes me wonder if this isn't already added to 5.x-2.0 .
If so, I'm still having the taxonomy problem.
If not, can you please advise which patch I should use?

Thanks in advance!
Scott

@scottrigby: You don't seem to understand the point of the patch that was committed (or seem to have read closely the comments in this issue). You found the path in #18, but didn't realize that I said I committed that. Anyway, the point of this change was to let you disable the "Preview changes" button on certain node types. What you're talking about isn't a bug, it's completely by design. There are little headers for the different kinds of things that diff can tell you about the differences between 2 revisions, and it'll happily write "No visible changes" for headers where there was no change. Please leave this issue closed. Thanks.