Ajax returned as new page when updating a field

I can confirm the same behavior and would love to find a solution, or at least a workaround...

If you get directly to a page with JSON output, it might mean that something caused javascript to crash during or before the click. If using firefox, you can use firebug or the built in javascript console to watch for javascript error messages. Do any of these messages show up?

Open firebug's console ctrl-shift-j I think -- that one does not clear when the page reloads.

Beats me. I'm not at all familiar with securepages and how it does the https thing. It's entirely possible that it may not actually catch the URL but I dunno why that'd be.

(such a headache, securepages)

I'm hesitantly marking this as a bug instead of support request. I'm experiencing it on a site which doesn't have securepages installed but does have an Apache configuration to forward from http to https for the /user/* and the /admin/* pages.

I don't see anything that submits directly to HTTPS in the form which confirms the workaround from #2 of disabling the JS in views to get around this problem.

If there's any more help I can provide to debug this please let me know.

It seems that perhaps #339295: Minor fix to allow multiple ajax-paged views on a page could be the same issue. I'll try to confirm whether or not that fix solves this problem as well, but it's a multisite which makes it harder to test :/

In case it helps, here is the http header log to repeat this error. It looks fine to me, but I'm not particularly savvy with Ajax.

The first click was to edit a field, the second is to "Update" the field.

Note that http://example.com and https://example.com are considered different sites and browsers get picky about that.

Unfortunately they aren't actually relative; Views encodes the base_url into the settings. It's that base_url that is not getting corrected by whatever is making https links.

One important question: has anyone used the views6.x-2 admin interface on HTTPS successfully?

Then we can start narrowing it down to specific configurations. I asked in #drupal-support and #drupal and at the time nobody confirmed it working on https.

Also, marking #274299: Ajax problem on https as a duplicate. Note that drfuzetto states that setting a specific $base_url fixed his problem.

I am developing a site on localhost that's set up to use both http and https. I don't have securepages installed and am seeing the issue with the http side but not https.

Glad to provide any further info that will help.

Updating the version to -dev because I've seen it with the latest version too.

Nigel

There has been speculation that this is limited to secure (HTTPS) sites, but that isn't the case.

I have a development machine behind a public production server. These means all incoming requests come into Apache on the production box. I have a virtual host on that which is a reverse proxy to the development machine. This might not be very elegant but it works.

The point is, Drupal on the development machine exhibits the same AJAX problems when accessed via the reverse proxy. (BTW - this is not limited to Views, the update script doesn't work either) when being accessed this way. If I access the development from local office LAN (therefore bypassing reverse proxy) then all is well.

Therefore reverse proxy setups (or perhaps just my implementation of this?) will also cause this issue.

I experienced this error because my $base_url (settings.php) was set to http://domain.com while I was redirecting all requests to http://www.domain.com in my .htaccess file. I adjusted the $base_url to http://www.domain.com to fix it.

I had exactly the same problem as mzacher; correcting the $base_url fixed it for me as well

There are two things i'd like to do:

1) Find a way to detect the mod_security issue and either warn the user or just turn off the javascript (or both).
2) Find a way to somehow disable visiting the link if there is a javascript error. One of the biggest annoyances I have with javascript is that if .js gets an error, it doesn't return false and the browser happily keeps going to visit the link, which is not the intended behavior. AT this point, though, I don't know how to fix that. Maybe there is some kind of exception we can catch?

Check for mod_security with http://us2.php.net/manual/en/function.apache-get-modules.php

Are you sure it's mod_security?

We've seen issues with https and turning that off fixed it. We've seen issues with $base_url being one thing and changing that fixed it. Is this only because of mod_security _and_ those things?

mod_security isn't the only issue but it's *an* issue, and we're kind of lumping them together here. But that does lead to:

3) Check to see if base_url matches the actual URL being used and if it does not, override it. That one is probably more tedious than anything since there isn't a single place that ajax links are handled, and to do this there will need to be.

I have a site that is using the securepages module and is not experiencing this issue. I only noticed this issue when I cloned the site for development and had to set the $base_url value in settings.php

The original site (without the issue) did not have a $base_url value set.

Well, I had the same problem but my solution was to remove the "base_url"from the settings file.

I'm using "Secure Pages", so all the adminsection is sent to https, and when not on admin it goes back to http. I had my base_url as my http url (http://www.example.com) and since the links for views get the url hardcoded, they where being redirected to the http url, which was leading to the error.

I removed "base_url" setting (# commented it) and now the links are created using the url that is being used by the browser, which is the https one (https://www.example.com).

Using or not using "Secure Pages" does not affect the way the problems behave. I tried disabling the module, and the problem was still there. Just pointed it out cause ut is relevant to whether you should specify the "base_url".
My recommendation is that if you are going to be using both http and https protocols, you shouldn't set up a base url within the settings file.
On the other hand, if you are ONLY going to be using one of both protocols, specially if you are using https, you should set it. This will prevent some modules from creating links directing from https to http pages.

Cheers

-

I'm seeing issues with mixed SSL/non-SSL also. One way I see the problem is to set up a view on an SSL page that uses ajax for column sorting; something goes wrong with that and I get the alert on line 147 of views/js/ajax_view.js on a regular basis - every other click, basically. I wonder if perhaps there is a way to replace the alert about the ajax error with something that would create a watchdog entry instead (this is complicated by the fact it's a client script of course); the typical user won't care about the cryptic error ("error in view/ajax.") and there isn't any way for an admin to learn about it except by seeing it first hand. I've tried this with 6.x-2.6 and 6.x-2.x-dev, same results. I hope someone is able to figure this out; there are many situations where mixed SSL/non-SSL makes a lot of sense and this is preventing me from using views to their full potential because I have to turn off ajax in these situations.

This error started when i added the "nice menu" module. After I disabled it and deleted the folder it was fixed. So Ajax stopped doing that error with it's own page.

Hope it gives insight.

I am having the same issue =/ Earl Grey what would the base_url have to be if i am running my site from a localhost?

Nope dosent work for me =/ Why did this problem suddenly appear? I always find it odd how things that were working perfectly awhile ago just randomly break.

Thanks for the reply, i dont know, how do i enable it?

I also seem to have this problem, however I don't use https... views works fine with JavaScript disabled but would be nice to find a way so that functionality don't have to suffer because of this small bug...

I am experiencing the same problem
- new Drupal install 6.17
- views 6.x-2.11
- PHP 5.2.6-1+lenny8
- problem in Safari and Firefox

I have been using previous versions of views (6.x-2.3, 6.x-2.10) on the same box for over a year now - no problems.

I then removed views (6.x-2.11) and installed views 6.x-2.10, however encountered the same problem.

@9802008
Are you using https on any page?
Did you set the base_url in your settings page?

Ok,
There were quite a few issues listed on this page. merlinofchaos pointed out 3 issues, that I think have been addressed.

1. Find a way to detect the mod_security issue and either warn the user or just turn off the javascript (or both).
   
   Addressed here #370651: AJAX Error with mod_security enabled




2. Find a way to somehow disable visiting the link if there is a javascript error. One of the biggest annoyances I have with javascript is that if .js gets an error, it doesn't return false and the browser happily keeps going to visit the link, which is not the intended behavior. AT this point, though, I don't know how to fix that. Maybe there is some kind of exception we can catch?
   
   
   Alot of the js crashes have been addressed from 6.8 to 6.10, but there are always new ways that haven't been addressed please check http://drupal.org/project/issues/views?text=javascript&status=All&priori... to see if your issue has been addressed or is being worked on.
   
   
3. Check to see if base_url matches the actual URL being used and if it does not, override it. That one is probably more tedious than anything since there isn't a single place that ajax links are handled, and to do this there will need to be.
   
   I am reopening #274299: Ajax problem on https and marking this issue as a duplicate, as that issue is dealing with only the ajax/base_url/https issue and is easier to follow.

If your issue has not been solved, please check it against the existing the issue queue if it's not there open a new one and reference here.

I don't know what causes it but I'm having the same problem... but, only with one of my profiles of Firefox 3.6.13, in both I have installed firebug, so firebug is not the problem.
I also have Google Chrome 8 and my views work fine... ajax works on editing and on submits.
The problem is definitely weird, seems that one of my Firefox extensions causes ajax to fail.
I recently tried IE8... and works fine on editing and submits... :( ???
My views have ajax, but are working as it is disabled (in one of my profiles of FF only).
Really don't know what to think...

@comment #20,

This was the solution I was looking for as well. Thank you!

I was having the same problem and found that there were indeed competing jQuery versions employed. I got rid of one and that fixed it.

Yep, competing calls of jquery was indeed the culprit. Thank you.