Project:Live
Version:6.x-1.2
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:needs review

Issue Summary

Live Preview doesn't work on forum posts.
There is an error:

Error requesting data!

Comments

#1

Using D6 and Advanced Forums, this excellent module fails for creating forum posts with the above error, using plain text. The comment portion works correctly.

I have confirmed that by simply deselecting Forum Post in the options for Live allows the user to preview the post as normal.

I am highly interested in seeing this fixed, I love this module! Let me know how I may help.

Some additional troubleshooting:
This fails for a normal authenticated user, but not an administrator (live preview of a forum post works for an admin).
Authenticated user IS checked for both "use live comment preview" and "use live node preview".

Maybe the bug is in permissions setting?

Lily

#2

Status:active» fixed

Try 6.x-1.2. I has a fix to properly use "use live node preview" permission and several other permission + filters fixes. I'm marking this as fixed; reopen if you still encounter the same problem on forum node type. If it's anything else, open another issue.

#3

Advanced Forum really isn't necessary for most sites, anyway. The default forum module already provides most of the forum features. You can also theme the regular forum module a lot easier.

#4

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

#5

Status:closed (fixed)» active

I’m encountering the exact same problem as #1, comments work perfectly and the Administrator can view forum topic previews but everyone else gets an error. I’m using Drupal 6.14, Advanced Forum 2.0 alpha2 and Live 1.2. Through trial and error (I’ve really no idea what I’m doing) I’ve stopped the error message appearing by deleting:

|| !node_access('update', $node)

from line 23 of live.node.inc. I did this after searching through the forum.module and seeing the only node_access call was for create. This makes the preview appear but the username is Anonymous and the date/time is wrong. If I submit this entry the output shows as it should, username and date/time are correct. Everything else I’ve tried editing so far has either no impact or errors. I’m guessing this is a permissions problem (how they’re called, the tokens sought?) as forum nodes are separate from general content nodes in the permissions page. Any assistance (even if it breaks the rest of the functionality, I only plan on using Live currently for a forum) is appreciated, thanks.

#6

Title:Live Preview doesn't work on forum posts» Error requesting data!
Version:6.x-1.0» 6.x-1.2

The same trouble. User 1 can, but no one else.

I'm using:
Live 6.x-1.2
Advanced Forum 6.x-1.1
ACL 6.x-1.2

It also happens when I (under UID1) try to preview custom content types.... so maybe Better Formats (6.x-1.2) module is cause of this.

#7

Live preview gives the Error requesting data! under certain conditions.
The problem is certainly on the check

if (!filter_access($node->format) || !$access || !$valid_token || !node_access('create', $node) || !node_access('update', $node)) {
    // ...
    used after validating token).
    drupal_access_denied();
    return;
  }

Step which recreate the problem:
(I suppose we have only the two default input filters Full HTML and Filtered HTML)

  1. Install and configure Live as usual.
  2. Create new input filter, no aprticular configuration needed.
  3. Give to all the roles the permission to use it. Make this filter default.
  4. Remove permissions for any role from the previous default (usually Filtered HTML on a clean Drupal installation)
  5. Go create a new node of the type which have Live configured.
  6. Using Live preview = Error requesting data!
  7. Go and give all role permissions on the original default filter (Filtered HTML for us)
  8. Using Live preview = Live Preview fully functional!

It seems that I can use custom Input filter only if paired with a default one or only if I customize the default one.
Any idea?

Note that with ordinary preview mode there is no problem, so I think is a Live issue.
Can I help in any way?

Thanks

#8

Good find policleto.

In my case, I had BBcode + Quote modules, for which I made a new input format "Forum". I made it the default input format and the only one allowed for authenticated users. Giving back the right to use Filtered HTML does indeed subvert this error.

It must be a bug, seems like it wrongly determines the used input format (as Filtered HTML)

#9

I searched a bit further and I checked the live.comment.js file, where I found this:

var format = $("input[@name=format][@type=radio][@checked]").val() || 1;

So I tried disallowing the Filtered HTML format and allowed the Full HTML format instead. And with the same result: it works.
It seems to be caused by this: only having one input format allowed for a role, disables the Input Format option for submitting content. When this option is available, the user could switch between input formats, causing different filters to be applied (also to the live preview). The module uses JS to determine the current input format, but there is no way for it to determine the input format when the option to choose it is unavailable. In that case it will simply assume the first input format is used, and if the user doesn't have the right to use the first input format, we get this error.

The same would apply to live.node.js, so this would require the same patch in two places.

If the Input Format you're using is the third input format (like in my case), you could hack the JS like this (which is suboptimal btw and doesn't solve the problem, only changes the assumption):
var format = $("input[@name=format][@type=radio][@checked]").val() || 3;

#10

Actually, I think I've found the solution. On the server side, we find this piece of code:

$format = !empty($_POST['format']) ? $_POST['format'] : FILTER_FORMAT_DEFAULT;
In other words, the JS sends the format being used via POST, but if the value given is empty, the server will assume the default format is being used. Of course this is correct, since the JS won't be able to determine what input format is being used in case the author has access to only the DEFAULT input format (in which case the option to choose the input format is unavailable). BUT, when the JS sends format = 1 (when it can't determine the selected Input Format, like it does now), this piece of PHP will be useless. So in fact, all we have to do (for both JS files) is the following:

Change this:
var format = $("input[@name=format][@type=radio][@checked]").val() || 1;
To this:
var format = $("input[@name=format][@type=radio][@checked]").val();

#11

Status:active» needs review

Tested and seems to work. Can someone verify?

#12

Patch attached

AttachmentSize
live-362604.patch 1.68 KB