Conflict with the preview for comments

Thanks for the bug report.

This is a major issue for me. Any progress?

Quickfix:

function [MODULE]_form_comment_form_alter(&$form, &$form_state, $form_id) {
unset($form['comment_output_below']);
}

Sorry for the lack of reply on this one, I'm looking into this, I didn't really use fivestar with comments much.

When I meant to say was comment preview :)

I just tested this with the latest fivestar-dev version and I didn't have a problem.

Can you explain it a bit more?

Hey Eric,

don't know what else to say here:

Fivestar is activated for a specific node type. It is not activated for the comments. You write something in the comment form and hit "Preview" -> on the next page "Save". In my setup, the comment was not saved, but was just gone.
The problem narrowed down to the full content of the node to be commented being shown below the preview, which includes the Fivestar field. Hitting "Save" therefore triggers processing of the Fivestar field as well as the comment one. Somehow Fivestar breaks the comment saving process.
Using aforementioned Quickfix to just hide the node display under Preview, will stop Fivestar from being processed and let the comment be saved fine.

Ok, I'll tried that now. That is not what I was doing before.

Ok, now I'm able to reproduce what you mention.

I'm looking into this now.

Ok, I've spend some time trying to fixed this and sadly is not an easy problem.

This has to do with the way we render the widget and the node being embed inside the comment form. Which has a form inside a form. This is probably going to be probably for any field that uses a form in it's display.

Now the short answer is there's not really a quick fix, I try detecting when a form is being called from inside another form but drupal doesn't make this easy.
Also this means we have to change some of the ways the field is render, making this a pretty big/complex issue.

Opening this back up.

Sorry for the hassle :/

Thanks for your effort

Double - http://drupal.org/node/1370526

Marked #1370526: Fivestar conflicts with comment form and #1637524: Fivestar interferes with comment preview as dups

Patch for the fix suggested by ChristianAdamski in #3. This works fine in my test system. I think that a preview page that only has the comment being previewed (rather than parent node, fivestar, and comment) is fine, and much better than the surprise of losing the new comment.

Hey whiteph,

I'm not sure if mainlining that "patch" of mine (and you of course) is the way to go. It disables a core feature of Drupal that is not directly related to Fivestar and pretty much an unexpected behavior to users.

I guess we both agree that displaying the full node on comment preview is not exactly a corner stone functionality of Drupal, but some people might still require it.

The reason to disable that in the first place anyway, is because the processing of Fivestar prevents/exits the processing of the comment form. Best approach would be for Fivestar to not break subsequent processing functions.

No idea how to do that though.

Hi, I agree that this is a kludge, but I think it's the better of two evils - data loss is really bad.

The problem is that when the final "Save" button is pressed and the form is posted, the $_POST parameters contains a form_id of "five star_custom_widget" and the rest of the new comment's data is already lost - five star's post processing isn't scrambling it, it's already scrambled.

The other option would be to render the preview form (complete with parent node and five star) in such a way that "Save" posts the comment data rather than five star's data. I traced this through in the debugger for hours, and didn't see a way of enforcing this though. The issue seems to be five star's use of a form contained within the outer comment form.

I've updated my patch from #13. It now only activates when a Fivestar field is present on a comment preview page, and will only delete the Fivestar field rather than the whole parent node. So the preview page is complete, apart from Fivestar being missing (of course, it reappears once preview is over); and the patch doesn't interfere with any comment previews where there are no Fivestar fields visible. This is as non-intrusive as I can get at the moment.

I'd appreciate testing help.

Thanks,
Philip.

13: fivestar-commentPreviewConflict-1289832-13.patch queued for re-testing.

Hey,

until there is a general solution in FiveStar, whitephs approach in #17 https://drupal.org/comment/8343015#comment-8343015 seems the way to go. To only filter, if fivestar is present.

I cannot test the patch, no current project using, but the code is short enough to assume it works fine.

CodeSniffer would correctly object the camelCase variable names though, Drupal expects lower_case variables.

Also: there seems to be spacing issue in the patch at the top, there is a change without different code...

It's weird, but I went back to clean up my patch after the latest comment re coding standards. Working on the latest dev branch, I can no longer reproduce the issue. I've checked in fixes for issues 1960104, 1783072, 1835476, 1800580, 2050141 and 2168897 since I worked on this comment preview issue (on the at the time very old dev or alpha2 branch).

If anyone is inclined, please test the latest dev version to confirm the issue has (accidentally) been fixed. If you find it's still there, re-open this issue.

I am still experiencing the problem with Fivestar 7.x-2.0-alpha3 (with no patches).

I will try the above-mentioned patch to see if this does the job.

I didn't explain that very well. The alpha3 version, although a new tag, is actually over a year old i.e. its last fix was more than a year ago. This comments preview issue was definitely visible in alpha3. I've applied several fixes and features to the dev branch since the alpha3 version, and the dev branch is where I couldn't reproduce it.

So, please test the latest dev version to see if you can reproduce it.

I installed 7.x-2.0-alpha3+8-dev and still experience the problem.

What information can I provide to help identify the cause?

After looking deeper, I could reproduce the issue after all. Its symptom had changed, I was no longer getting the "Your vote has been deleted" message, but another message implying the comment had been saved. But when I refreshed the node, the new comment had disappeared.

I then found a different form of issue - no matter what Fivestar version I tried (alpha3, latest dev, my local branch from which I created the patch), the issue persisted i.e. my patch made no difference. I tried my usual Firefox, then Safari - same issue. My test system has very few other modules enabled, to keep it as "pure" as possible for Fivestar testing. In desperation I tried disabling the Devel module - and my fix started working. Then I remembered that I'd installed the 7.x-1.14 version of Devel last week. I suspect it is somehow interfering with the hook system, as fivestar_form_comment_form_alter just wasn't being called.

After that was resolved, I confirmed that this comment preview conflict issue was there in alpha3 and the 7.x-2.0-alpha3+17-dev versions. I've just committed a cleaned up version of the patch, which is now in the 7.x-2.0-alpha3+18-dev version.

I started creating an issue in the Devel module's queue, but as I wrote the detail I began to think that Devel was unlikely to be the problem. Rather, enabling/disabling modules probably did the equivalent of clearing caches.

I tested again with 7.x-2.0-alpha3+18-dev, using both Firefox and Opera, and the problem appears to be fixed.

Unfortunately it appears that this fix, though workable in most cases, is not complete. It does not accommodate for cases where multiple fivestar fields may be added to the same node.

Because a fix was already committed it makes no sense to re-open this issue. As a result I've started another one at #2223391: Conflict with previews in comments with multiple fivestar fields (continuation of #1289832). The patch posted there is not a replacement for this fix, but instead builds off it (against the current dev).