Views Form fails when using ajax

Here's one that fixes the argument problem, I believe.

Does not work with my view that uses VBO. When I submit VBO action it just redirects to frontpage.

Yes, that's true....

Assigning to dereine by request from bojanz.

Patch looks fine and said before. Commited to both branches.

This commit broke the shopping cart form in Commerce, because the View is actually embedded at the /cart URL by the Cart module. Accordingly, it doesn't have a URL of its own and just submits the form to /. : P

It would probably be wise to check to see if $view->get_url() actually returns anything before setting this form to submit there.

Damien mentioned the possibility of allowing us to specify a URL override when we embed a View. If that worked, then this would work just fine. Might get his opinion one way or the other before reverting - Commerce has tried to keep pace with RC1, so recommending that in the short term doesn't hurt anyone.

$view->override_path will always work -- if you're embedding then you have the ability to do this.

Hmm, in my embed function, I tested this by setting $view->override_path = 'cart';, but examining the form action shows "/cart/2". For some reason the order ID is getting appended to the path even though no such path is defined by commerce_cart.module.

Right, views assumes that the arguments need to be part of the path. If you're passing the arguments through, there's no really easy way to have it NOT put the arguments in the path right now. :/

If you've got default argument (er, contextual filter) there's a checkbox that will prevent adding that to the path, though.

Ok, that's a good lead. We are using a contextual filter for the form, and I did check the "Skip default argument for view URL" box, but it's still showing in the form action (i.e. $view->get_url()). I can check two things on my end - it could be our argument handler is screwing that up somehow, or perhaps since I'm setting the "contextual filters" via $view->set_arguments($arguments); it's functioning different than if it came through the URL. Not sure how stupid those ideas sound, but I'll start there when I get a sec to pursue this further. : )

EDIT: Maybe I'll save myself some time. On save, I saw that this would only affect a default argument, which I'm not sure we're specifying any. Will check there before bothering with those other ideas. : P

One way of properly supporting embedded views would be to add a ->override_url property that completely skips the argument logic inside ->get_url(). views_embed_view() could set this property to $_GET manually.

An alternative would be to only set #action if ->get_url() has returned a valid path, so that displays that do no support paths stay unaffected.

reverted the patch.

Panels works fine with path override for exposed filters by filling a "Override URL" maybe batter to take a look at working implementation

Subscribe. Just hit this issue when trying to embed a block with an exposed form/Ajax on one page on my site. Users are redirected to / if they hit enter, or to the path of any prior page-type display in the view providing the block display I'm using.

[Edit: To others having this problem when embedding blocks: if you just create a page display *exactly* the same as the block display, and set the path of the page display to the path where the block is being displayed, the view should work correctly (and won't overtake your module-defined (hook_menu()) page).]

Subscribe. Use case:
- Using VBO for the admin/content/node view
- Added an additional field to display the "project number" of the content (just a node field)
- Search by that project number
- Click the edit button
- The URL comes up: http://www.website.com/node/202/edit?destination=views/ajax
- Obviously the ?destination=views/ajax is the problem

+++ b/views.moduleundefined
@@ -1988,6 +1990,9 @@ function views_embed_view($name, $display_id = 'default') {
+  $view->override_url = $_GET['q'];

This would kill the path from views with arguments. If the user want's to override the url, he should use the view object and preview.

Does someone uses this patch on real world?
I'm just wondering as this might be possible to break a lot of things.

Not that i think that it does, just general interest.

I still need to test. Right now the problem only exists on some admin views I'm using, as I don't have AJAXy goodness on any user-facing forms. I will try to test when I get a chance.

@bojanz
Please post when it's time to commit the patch.

And commited.

[18:00] <merlinofchaos> dereine: Visit http://ehalseymiles.com/news/ -- see that 'archive' block on the right?
[18:00] <merlinofchaos> dereine: That relies on the link display to go to the right location. That's the use case I always envisioned for blocks. Also, the 'more' link uses the link display path as well.
[18:00] <merlinofchaos> dereine: Overriding the path universally will break that.
[18:00] <dereine> great
[18:00] <merlinofchaos> dereine: So here's my proposed solution.
[18:01] <merlinofchaos> The 'link display' setting only shows up on items without a path, IF there are > 1 possible displays that have a path. We make this show up always if a display does not have a path of its own. We change it to 'link path' or something. The choices become: A list of all displays with a path, 'current page' and 'custom'.
[18:02] <merlinofchaos> Custom would let you enter an arbitrary path.
[18:02] <merlinofchaos> Then the get_url() method which uses the link_display stuff could act appropriately under the hood.
[18:03] <merlinofchaos> Plus, that'd fix the whole custom 'more' link stuff and a whole host of other issues of sending links in a view to a custom path.

Let's do this in a new issue as this has absolute nothing to do with views form and ajax anymore.

Please link new issue here

Yes, a link to the new issue would help. I tried to find it by searching the issue queue, but I failed. (I'm using Views 7.x-3.3 and the block usage issue seems to be unresolved.)

Update: I just noticed that VBO is working around the block usage issue.

Hi, bojanz. Thx for commenting.

VBO still contains the "Allow VBO to work when embedded using views_embed_view(), or in a block." code (in views_bulk_operations_form_alter). You might not consider that a work-around, but the fact that I had to repeat that code in Views Send makes me think that this should have been a part of Views.

I cant seem to get this patch to apply. did the issue of the views/ajax problem get fixed or moved to another issue?

We are having this same issue or issues with ajax and the add to cart button on our production server but not on our Dev Ubuntu server. Ajax and Add to cart button works fine on our local dev servers. We can not create the Add to cart or Ajax error on our Ubuntu 12.04 lts

The dev server is the following:
Ubuntu 12.04
Apache/2.2.22 (Ubuntu)
PHP 5.3.10-1ubuntu3.5
Drupal 7.20
Php.ini memory_limit 512

Production server:
CentOS 5.6
Php 5.2.17
Apache/2.2.22
Drupal 7.20
Php.ini memory_limit 512

Any thoughts the ajax and add to cart maybe separate issues as well. Could this issue be caused from Php 5.2?

Further research on the ajax and add to cart breaking seems to have something to do with compressing files under Performance? more later on this...

Did anyone ever find the solution to this problem?