Whether I try to submit a profile2 form, a node/edit form, or otherwise inside the megarow, an http 200 message pops up in an alert() and gets all up in my business! I'm guessing this is a debugging message because it indicates a successful request. From what I recall, this prevents the megarow's action of closing properly after the form submission (if it should? I would need to pull up a commerce kickstart site again to see an example of what the megarow behavior should be), however it's important to note that the form submission works fine.

Comments

Cellar Door’s picture

Cellar Door CreditAttribution: Cellar Door commented

This same issue is happening in the Kickstart RC2 as well, same error and same results. Form is saved just not reloaded properly.

vasike’s picture

vasike
Location Ramnicu Valcea
CreditAttribution: vasike commented

there is the Commerce Kickstart issue related with this one : #1804928: AJAX error 200 when adding new message

rerooting’s picture

rerooting CreditAttribution: rerooting commented

It's worth noting that:

  • 200 = http 'success' message, thus 'error' is a misnomer
  • At least for me, all POSTS are successful. Thus this javascript prompt() showing up *seems* to be the only problem.

I get the feeling that this is leftover from debugging?

Is *this* the active issue for this per http://drupal.org/node/1804928#comment-6735350 ?

rerooting’s picture

rerooting CreditAttribution: rerooting commented

Looks like we are re-using this code almost verbatim for two functions in views_megarow.module:

http://drupalcode.org/project/ctools.git/blob?f=includes/modal.inc

So this behavior might be ctools's debugging, and just needs to be switched off somehow? I think I'm in over my head.

bojanz’s picture

bojanz CreditAttribution: bojanz commented
Category: bug » support
Status: Active » Fixed

The "200" message means that the form has issued a redirect instead of rebuilding itself.
In Kickstart it happens when adding a new order message, due to a bug in that code (will be fixed in commerce_message).

There are no active megarow issues around this, if you're seeing the error outside of the Kickstart add message form, you're either not wrapping your form correctly or at all.

rerooting’s picture

rerooting CreditAttribution: rerooting commented

Ah ok! So are you indicating that one *must* implement something analagous to :

/**
 * Implements hook_menu().
 */
function commerce_backoffice_order_menu() {
  // Megarow callback.
  $items['commerce_backoffice/order/%commerce_order'] = array(
    'title callback' => 'commerce_order_ui_order_title',
    'title arguments' => array(2),
    'page callback' => 'commerce_backoffice_order_view',
    'page arguments' => array(2),
    'delivery callback' => 'ajax_deliver',
    'access callback' => 'commerce_order_access',
    'access arguments' => array('view', 2),
  );

  return $items;
}

As is indicated in the documentation, and then as well, for the edit form, something that does a more specific version of this (as you indicate just now):

function views_megarow_form_wrapper($form_id, &$form_state, $entity_id) {
  $form_state += array(
    're_render' => FALSE,
    'no_redirect' => !empty($form_state['ajax']),
  );

  $output = drupal_build_form($form_id, $form_state);
  if (!empty($form_state['ajax']) && empty($form_state['executed'])) {
    $output = drupal_render($output);
    $title = empty($form_state['title']) ? drupal_get_title() : $form_state['title'];

    return views_megarow_display($title, $output, $entity_id);
  }

  return $output;
}

Possibly is my problem caused by the fact that I am using system urls, such as node/%/edit or user/%/edit in the views ctools dropbutton widget thingy, without implementing special system menu urls with the ajax delivery callback that you suggest? I'll be very embarassed for not trying this if this is the case, and will report back summarily. I have the feeling I will be closing this issue as soon as I implement a system menu path for this, and hanging my head in shame, haha!

Thanks a bunch for following up on this Bojanz! Much appreciate the work you do. You are an exemplary drupal dev and community member!

Status: Fixed » Closed (fixed)

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

Rory’s picture

Rory CreditAttribution: Rory commented
Status: Closed (fixed) » Active

Please bear with me re-opening this issue, as I may have found a pattern. I tested node edit links in a Views Megarow table and received the AJAX HTTP 200 message dialog, but only on the initial submission of the node edit form.

Each subsequent submission did not but instead added this message to the display queue:
"The content on this page has either been modified by another user, or you have already submitted modifications using this form. As a result, your changes cannot be saved."

I investigated a fix for this message and found one: http://drupal.org/node/394694#comment-5636568. After adding the following code to Views Megarow 7.x-1.0 that fixed the concurrent node editing message:

/**
 * Implements hook_form_alter().
 */
function views_megarow_form_alter(&$form, &$form_state, $form_id) {
  if (strpos($form_id, '_node_form') !== FALSE) {
    // Ensure our own validation is called first to overcome the node changed error node.module: 971
    array_unshift($form['#validate'], '_views_megarow_node_edit_validate');
  }
}

function  _views_megarow_node_edit_validate($form, &$form_state){
  // Update changed value to avoid node changed error node.module: 971
  $form_state['values']['changed'] = $form_state['node']->changed;
}

Now the HTTP 200 message appeared every time. The node was updated fine either way, but it boiled down to choosing whether to have the HTTP 200 dialog... or the concurrent node edit message appear.

It also occurred to me this module may not be protecting against concurrent node editing.

Correct me if I'm wrong, possibly under views_megarow_generic_render()... I'm not sure though, perhaps elsewhere... something could be done here to resolve this issue. The comments from #5 onwards appear to be leaving a solution dangling in the wind, which is somewhat technical.

The evidence I've provided here may at least suggest work is needed on protecting against concurrent node editing.

Rory’s picture

Rory CreditAttribution: Rory commented

Perhaps this is a related issue with CTools: #1710710: ajax_render should not be used; ajax_deliver should be used instead.

I noticed a comment that suggests Views Megarow expects ajax_deliver to be used.

line 217::views_megarow.module:

/**
 * Displays the provided output in a megarow.
 *
 * Works by returning an array that ajax_deliver() can understand.
 */
function views_megarow_display($title, $output, $entity_id) {
...
Artusamak’s picture

Artusamak
he/him
Primary language French
Location Bzh
CreditAttribution: Artusamak commented
Status: Active » Fixed

1/ Views megarow purpose is not to prevent from concurrent editions of the same ressource, if you open the same form in two different tabs and submit one after the other without reloading your page you will end with the same issue. It's not a feature that we are going to cover.

2/ We can't add the validate function in Views megarow due to the fact that's it's related to the action your form is performing, it's the responsability of your form to call the appropriate validate function if required.

3/ I will follow #1710710 to see what should be done here.

I don't see further actions to take from here.

Status: Fixed » Closed (fixed)

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