From #1647646
I re-installed the module with the last commit bad2c1a on 7.x-1.x but no changes.
I tried different configurations:
- without jQuery update module activated: StatusText: OK
- with jQuery Update (jquery 1.5 version): StatusText: parse error
- with jQuery Update (jquery 1.7 version): StatusText: OK
I used different themes (Garland, Seven, custom theme).
In any case I use Commerce Starterkit.

In the view I use the "views megarow link" field. I tried links like "Edit node|node/[node:nid]/edit" (with token) or "add a page|node/add/page". Is there any other way to do it?
Here is a export of my view. Many thanks for your time.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

matsjacobsson’s picture

Hi,

I have the exact same problem... And if the node has a file or an image with it I get a different error: TypeError: b.handleError is not a function (in jquery.form).

Is is supposed to work at all with editing nodes directly (like "Edit node|node/[node:nid]/edit") or just for previewing?

Best regards,
Mats Jacobsson

matsjacobsson’s picture

Hi again,

I did a test on a fresh installation of drupal 7 with minimum of modules installed. This is what I got...

Editing a node gives a AJAX(?)-popup (success or error?) message as stated before. Closing the Megarow and refreshing the page the changes has been made.

An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: /drupal7/display_megarow/2/node/2/edit/
StatusText: OK
ResponseText: 
test5 | localhost

If I edit the node once more (and click on save) before closing the Megarow it gives the error message when refreshing the page:
"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."

It would be awsome it this would work, then it would definitely be one of my favorite modules ever!

/Mats

xatoo’s picture

I have the same or a similar problem using JQuery Update.
Without JQuery Update everything works fine, but when JQuery Update is enabled the same form hangs when saving.
When waiting long enough the data is actually saved but since the throbbler keeps running, the user gets no feedback whatsoever.

I experience the problem with JQuery 1.5, 1.7 and 1.8.
I've tested with Bootstrap, Bartik and Omega Kickstart. All three have the problem only when JQuery Update is enabled.

The error I get in the console:

Uncaught TypeError: Object function ( selector, context ) {
		// The jQuery object is actually just the init constructor 'enhanced'
		return new jQuery.fn.init( selector, context, rootjQuery );
	} has no method 'handleError' jquery.form.js?mogsza:12
s jquery.form.js?mogsza:12
window.(anonymous function) jquery.form.js?mogsza:12
onload

Btw: I thought this issue might have something to do with: #1675794: Update jquery.form.js - older versions break in IE8
(Because of #1203532: jQuery Form Plugin update to latest stable release, same error, same solution)
But upgrading JQuery Update to 2.x-dev and applying the patch does not change anything for me.
@julien.reulos, matsjacobsson: Could you try whether the patch in that issue solves the problem for you?

mesch’s picture

From my very limited review of the issue, I think what's happening here is that the ajax request is being redirected, and an entire page is being returned instead of an ajax response.

For example, if I save an edit node form with an error (such as not inputting a required field), the form will not redirect, and there will be no problem. However, if I save the form without any errors, the form will redirect (from "node/[node:nid]/[edit]" to node/[node:nid]), and a full page will be returned.

You can test this in views_megarow_generic_render(). When a redirect happens, nothing gets executed past the call of menu_execute_active_handler.

You may be able to get around this by forcing the redirect to the views_megarow ajax menu item (display_megarow/%/%. This rule redirects on node creation or save:

{ "rules_node_save_redirect_views_megarow" : {
    "LABEL" : "Node Save Redirect Views Megarow",
    "PLUGIN" : "reaction rule",
    "ACTIVE" : false,
    "REQUIRES" : [ "rules" ],
    "ON" : [ "node_update", "node_insert" ],
    "IF" : [
      { "data_is" : { "data" : [ "site:current-page:path" ], "value" : "megarow-test" } }
    ],
    "DO" : [
      { "redirect" : { "url" : "display_megarow\/[node:nid]\/node\/[node:nid]" } }
    ]
  }
}

However, if there are any stray drupal_goto() calls before hand, the rule won't get invoked. You could also look at invoking hook_drupal_goto_alter(), something like:

/**
 * Implements hook_drupal_goto_alter()
 */
function [module_name]_drupal_goto_alter(&$path, &$options, &$http_response_code) {	
	// If this is a request to the views_megarow callback that is being redirected, rewrite the redirect
	if (substr($_GET['q'], 0, 15) === 'display_megarow') {		
		$page_path = explode('/', $_GET['q']);
		$path = $page_path[0] . '/' . $page_path[1] . '/' . $path;
	}
}

This is all highly experimental... I haven't had an opportunity to test it much at all, but I thought I would share my thoughts in case they are of any value.

julien.reulos’s picture

Thanks Morgan,
The drupal_goto alter function works perfectly. Would be great if the bug could be fixed from the own module, as the drupal_goto_alter is requested everytime a page (with a megarow view or not) is loaded.

Note for the other issue followers: Jquery Update module is not necessary.

Kgaut’s picture

I had the same probleme but without jquery update installed.

The fix in #4 worked for me.

Thanks

yannickoo’s picture

The solution in #4 works but it is very very ugly. We should fix that in the views_megarow.module.

logii’s picture

#4 works for me as well. Dirty, but it made me look good :p
Thanks.

Looking forward to test patches on the actual fix.

Artusamak’s picture

Title: AJAX HTTP error on saving a node » Make Views Megarow compatible with node edition
Priority: Normal » Major
Status: Active » Fixed

Alright, i should have a good news here. This is not related to jQuery update but to Drupal design.
After editing a node, the submit functions processed are redirecting the user to the node to view it. The problem was that views megarow wasn't expecting something like that.

It's normaly just an issue for the nodes, the "correct" entity types doesn't behave like that.

I invite you to test again with the latest dev version (http://drupalcode.org/project/views_megarow.git/commit/e636ad320b9f0ee16...) and let's also test it against each version of jQuery we can. My preliminary tests didn't raise any problem with jQuery 1.5, 1.7 or 1.8.

One note though about the view that you exported, you have a link to create a page, due to how Views megarow is designed for now, it's not doable to have out of the box working node creation, Views megarow is expecting entity ids and we don't have it yet.

It's on the roadmap to get ride of this limitation but it's in the scope of another issue.

Please reopen the issue if you find any bug.

yannickoo’s picture

Awesome work Julien! Works fine for me with all jQuery versions (provided by jQuery Update - 1.5, 1.7, 1.8) but there is a problem with the Overlay module enabled: Uncaught Error: Syntax error, unrecognized expression: #overlay-context=node but that is not Views Megarow related, the saving part works fine!

Artusamak’s picture

I just tested in the overlay context and didn't see an issue. How could i reproduce the problem?

Status: Fixed » Closed (fixed)

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

geek-merlin’s picture

Status: Active » Closed (fixed)

On my setup i get a very strange result from this patch:
* View a node edit form with a date field
* On view (YES!) see the form error: "A valid date is required for Foofield." which is a datefield with recurring support.
I can reliably boil this down to this line:

function views_megarow_menu_alter(&$items) {
  $items['node/%node/edit']['page callback'] = 'views_megarow_node_page_edit';
}

If i comment it out and clear menu cache the problem is gone.

I have both DS and Page-manager on the system and Page-manager also messes with the node edit form, but not for this content type.

EDIT: Page-manager even deactivated its override so this approach is not panels friendly.
Page manager module is unable to enable node/%node/edit because some other module already has overridden with views_megarow_node_page_edit.
OTOH this indicates that the primary interference is not with panels.

As a conclusion i suggest that capturing this often wanted hook in the way committed seems to have lots of interfernces and should be reverted.

geek-merlin’s picture

Issue summary: View changes

input test error

geek-merlin’s picture

Status: Closed (fixed) » Active

Meant to reopen.

geek-merlin’s picture

#4 works like a charm, besides the - for my use desirable - result that the final node view page is displayed in the modal.

we might move the offending menu-alter and the approach from #4 into little sub modules.

Status: Closed (fixed) » Active
Artusamak’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)

I' marking this one as a duplicate of #2109381: Make views_megarow compatible with Panopoly Admin where the issue has been solved.

esolano’s picture

Hi,

Solution in #4 (hook_drupal_goto_alter) works like a charm; though we wanted to keep the user in the same node/[nid]/edit page. The only problem is that after the node saves, you can't see the confirmation message saying that the changes were saved.

We dig into the code, and found that theme_status_messages() is being called with this argument array('display' => 'error'), so it will only show errors.

We're adding a little patch so that theme_status_messages() would show all messages.

inno81’s picture

Status: Closed (duplicate) » Needs work

I am reopening because I still see the exact same problem as described in #2, with both 7.x-1.3 and 7.x-1.x-dev.
I have jQuery Update installed, and using 1.7.

Trying to node/[node:nid]/edit a content with title only. The view only has Title and Megarow Links fields.

I do not see it as a duplicate of #2109381: Make views_megarow compatible with Panopoly Admin, and anyway it is not fixed. I use Display Suite, no Panels. I am happy to provide more info if needed.

Artusamak’s picture

Status: Needs work » Closed (fixed)

Please don't reopen the thread.

The error messages are the only one catched on purpose. The validation messages should be catched in order to by displayed if the row has been closed as soon as its submitted. It's not handled yet. I created #2313873: Improve status messages management in order to trace the request.

For the support request, i can't reproduce your issue with a clean installation of Views megarow 7.x-1.x-dev, jQuery 1.7 so please find more stuff for debugging and opend a dedicated issue.