Hello there,

Interesting module, would really like to use this, however every path I try and open in the table returns with An AJAX HTTP error occurred.
HTTP Result Code: 200

Any ideas?
Cheers
Dan

Comments

shashi_lo’s picture

Same issue here. Mine's with Colorbox links.

Yurii’s picture

Hi same issue for me, im trying with really simple nodes. Can you provide some help how to properly setup and use this module? Small documentation will be helpfull. Thanks

rerooting’s picture

Same here, and the actual view result works. To look for a working example, see Commerce Kickstart. I'm trying to figure out what they are doing differently. I've noticed that with Kickstart, they are using Operations Links provided by commerce, instead of the Megarow Links field... hmm..

rerooting’s picture

Looks like this is how they are implementing views megarow in commerce kickstart 2.x:

http://drupalcode.org/project/commerce_kickstart.git/blob/refs/heads/7.x...

So it seems that the default capability as provided is not entirely working, but this shows a workaround to get the links working and rendering paths properly. See the other handler for orders if you need more examples.

rerooting’s picture

I can also confirm that this happens without an argument (i.e. on node/1). I thought I had discovered some error output in dblog, which looked like this:

Notice: Undefined offset: 0 in views_handler_field_megarow_links->render() (line 108 of /srv/bindings/8b105e614a7e4a1584123048b6eb6953/code/sites/all/modules/views_megarow/includes/views/handlers/views_handler_field_megarow_links.inc).

But this was coming from the view preview freaking out when I add the megarow links field and there aren't any links provided yet. Needs a error handler, which is a seperate issue.

Considering that this is throwing a parser error, we might want to start looking into (vaguely) similar issues like these: http://drupal.org/node/1161326

rerooting’s picture

Actually, the above mentioned reference to commerce kickstart was only for the field handler for the custom dropbutton, which is handy if you are looking for a custom handler example.

Here is the actual integration code from commerce kickstart (for products):

http://drupalcode.org/project/commerce_kickstart.git/blob/refs/heads/7.x...

 // Megarow callbacks.
  $items['commerce_backoffice/variations/%node'] = array(
    'page callback' => 'commerce_backoffice_product_variations_view',
    'page arguments' => array(2),
    'delivery callback' => 'ajax_deliver',
    'access arguments' => array('administer commerce_product entities'),
  );
/**
 * Displays a view of products referenced from the given node, in a megarow.
 */
function commerce_backoffice_product_variations_view($node) {
  $title = t('Variations for product %title', array('%title' => $node->title));
  $output = views_embed_view('commerce_backoffice_product_variations', 'default', $node->nid);

  return views_megarow_display($title, $output, $node->nid);
}

The handler I mention above then statically points to menu path defined in the above callback:

$quick_edit['quick-edit'] = menu_get_item('commerce_backoffice/variations/' . $nid);
     $quick_edit['quick-edit']['title'] = t('Quick edit');
     $quick_edit['quick-edit']['attributes']['class'] = 'views-megarow-open';
     $links = array_merge($quick_edit, $links);
scresante’s picture

for reference, here's the complete error message
http://pastebin.com/wQwNHZ3p

bryan1221’s picture

I am having the same error message "An AJAX HTTP error occurred. HTTP Result Code: 200" when Checking for available updates. However my error appears to be referring to a permission issue. I have been searching for a resolution but unable to find one at this time. Anybody have any ideas?
The entire error is shown below:
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /batch?id=494&op=do StatusText: OK ResponseText: {"status":true,"percentage":"12","message":"Trying to check available update data ...\u003Cbr \/\u003EChecked available update data for \u003Cem class=\u0022placeholder\u0022\u003EViews Gallery\u003C\/em\u003E."} #sidebar { display: none; } #content { width: 100%; } #customer-orders td, #customer-orders th { padding: 0 5px 0 5px; } You are not authorized to view this page. If you believe this message to have appeared in error, please contact a representative to have this issue resolved.

Artusamak’s picture

The module is designed to work with AJAX commands and when you call a "classic" path like node/add/article you get this error due to the fact that the menu entry returns actual output.

To have it working you need to use *for now* a custom menu entry that will return the AJAX command.

I will push an example and more explanations on the project page.

rerooting’s picture

Yes, I'm aware of this approach re: Commerce Backoffice and we are using it for some things, just trying to get the views field widget working properly for an easier and more future proof approach. The classic paths are just an attempt to test it at the baseline core capability and identify where/why the more dynamic option is not working yet.

Artusamak’s picture

I pushed a commit introducing a generic wrapper that can be used to display any path in a megarow, you can try it by adding a megarow link to a classic path eg: node/add/article or node/123 you should see that the form handling perfectly works.
My todo is to catch the messages if required there and to use the access callbacks of the called pages. Once it's done we will have a smoothly working megarow pattern :)

Artusamak’s picture

Status: Active » Fixed

So the display and the access control implementation have been added, if you guys want to try it again, be my guests!

rerooting’s picture

Lookin mighty fine! I'm rendering a custom panel page and multiple different profile 2 and party module forms without a problem. Using bartik & seven. There are some issues with ajaxified form widgets (i.e. field collection) but that's for another issue!

rerooting’s picture

So I'm getting this error again upon submission of forms inside the megarow, however the form data is going through quite flawlessly. Should I create another issue for this?

rerooting’s picture

Status: Fixed » Closed (fixed)

Well it's not really an error but a success message, haha. I'll go ahead and create a seperate issue. I would say that this issue is *fixed* as it involves the rendering of the AJAX content request inside the megarow (which now works great), not necessarily submitting forms.

deanflory’s picture

Anyone having lots of AJAX issues might want to try disabling the jquery_update module, worked for me. Just spreading the info, unsure if it's related to this issue.

julien.reulos’s picture

Status: Closed (fixed) » Active

Hi,
It has been days since i am struggling against the 200 Ajax error without success. Same error as #14.

In #11, @Artusamak explains that he enabled the classic path, so that in a "Megarow links" view field we can now put "Add a page|node/add/page". Is it possible that the error is related to this?

Another thing I checked is the jquery version in use. On a fresh Drupal 7.21 install + views-7.x-3.x-dev.tar.gz 03/2013 + ctools-7.x-1.x-dev.tar.gz 03/2013O, the default jquery version is 1.44. If I enable jQuery Update module, for whatever version of jquery I choose, the error is still present:

- error with jquery 1.5:
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /drupal2/display_megarow/203183/node/add/introduction
StatusText: parsererror

- error with jquery 1.7 or 1.8:
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /drupal2/display_megarow/203178/node/add/introduction
StatusText: OK

If I switch to Views Megarow 7.x-1.0 and I submit a node form, then the node is created, and there is no Ajax 200 error popup, but the form doesn't close and the throbber next to the Save button keep spinning.

Related issue: #1811190: 200 Message on Form Submission and #1914860: Is it possible to close the row on form submit?? (comment #3)

Any help would be welcomed!
Thank you

Artusamak’s picture

Status: Active » Closed (fixed)

Could you retest with the latest dev version of Views megarow i pushed some fixes related to the jQuery version and weird behaviors.

Could you also post your exact configuration, if you use the views megarow links, copy an export of the view.

Please let's discuss this is a separated issue.

rickharington’s picture

Issue summary: View changes

Hi Artusamak

I truly apologise for commenting on a closed issue but I've been trying to get this right for a couple of days now and am just unable to no matter what I do

You mentioned that we can use classic paths with a generic wrapper on node/add. My form works perfectly but when I press submit I get the Ajax 200 error. Can you perhaps explain the generic wrapper method?

Again sorry but thanks.

Artusamak’s picture

Hello, i invite you to create a support request issue in such case that can link to this issue if necessary. ;-)

If you want to see how it has been implemented to edit nodes, i invite you to have a close look to this commit http://cgit.drupalcode.org/views_megarow/commit/views_megarow.module?id=... it should help you.

rickharington’s picture

:) Apologies again. Have created the support issue at https://www.drupal.org/node/2572609

Thanks again for a great module.

WriteCo’s picture

I'm reviving this old thread so there is a solution in the event someone has this problem.

Set php.ini display errors to OFF.

display_errors = off

The story:

My webhost updated php and it caused errors, as my system was not ready for anything "new."

I called tech support and they showed me where to choose a lower version php. That fixed access problems.

I had Drupal issues last night that I could not fix.

AJAX Error with HTTP code 200 and the word OK means everything is fine. That's not useful.

I called tech support today and while on the phone, everything started working right.

Tech support found that "display errors" was turned on in php.ini and that caused the Drupal issues.

Laurentino’s picture

Hello!
for me, it was resolved by giving temporary permissions 777 (only during installation) to ./sites/defaults and ./sites/defaults/settings.php