Clicking "Edit Page" Causes Edit Bar to Disappear...
Permalink
I'm getting the same strange behaviors on two separate 5.4 installs. 5.3 installs on the same server seem to be behaving normally.
This is what I'm getting:
-clicking "edit page" causes edit bar to disappear.
-Clicking the back button brings the editing bar back (changes the path away from the "cID=" back to the alias.
-Attempts to change anything in the page properties causes the page to hang, with the AJAX throbber thingie spinning and spinning.
-Attempts to change page properties from the site map generate an "Unable to Load Sitemap Data" dialog.
-Randomly get thrown to /login. But when this happens I'm still logged in.
-Attempts to add new pages from the front-end or the site map fail by taking user to the page you're trying to add the new page under, with no edit bar. It's as if nothing ever happened.
These problems go away for short periods. In other words occasionally the sites behave normally.
Both sites seem to have degraded slowly. Now both are essentially unusable, but, fortunately, up-to-date for the time being.
I have tested on different browsers on different platforms and at different locations.
The problem seems to be independent of the browser cache. It occurs whether or not the site cache is enabled. Likewise clearing the site cache has no effect. It also occurs whether or not pretty urls are enabled.
Any thoughts?
This is what I'm getting:
-clicking "edit page" causes edit bar to disappear.
-Clicking the back button brings the editing bar back (changes the path away from the "cID=" back to the alias.
-Attempts to change anything in the page properties causes the page to hang, with the AJAX throbber thingie spinning and spinning.
-Attempts to change page properties from the site map generate an "Unable to Load Sitemap Data" dialog.
-Randomly get thrown to /login. But when this happens I'm still logged in.
-Attempts to add new pages from the front-end or the site map fail by taking user to the page you're trying to add the new page under, with no edit bar. It's as if nothing ever happened.
These problems go away for short periods. In other words occasionally the sites behave normally.
Both sites seem to have degraded slowly. Now both are essentially unusable, but, fortunately, up-to-date for the time being.
I have tested on different browsers on different platforms and at different locations.
The problem seems to be independent of the browser cache. It occurs whether or not the site cache is enabled. Likewise clearing the site cache has no effect. It also occurs whether or not pretty urls are enabled.
Any thoughts?
What is the URL of the page when the edit bar shows ,and what is the URL of the page when the edit bar is gone?
It's breaking when the url uses the "cID=" instead of the page alias.
http://www.redtribal.com/index.php?cID=77...
(no bar)
http://www.redtribal.com/index.php/pre-columbian-art/...
(bar)
http://www.redtribal.com/index.php?cID=77...
(no bar)
http://www.redtribal.com/index.php/pre-columbian-art/...
(bar)
The session cookie is being set to the first domain, which I don't believe is the domain that actually corresponds to the BASE_URL that's been set in your config/site.php.
An easy way to keep this from happening is to simply edit the site from the redtribal.com URL.
An easy way to keep this from happening is to simply edit the site from the redtribal.com URL.
Thanks for that, Andrew. This makes sense, sort of.
I've been building sites at a development url, then moving them over to an appropriate domain and manually editing the config.php. In these two cases, I created a site at redtribal.com then moved it to tribalantiques.com, and another at jl.redtribal.com, and moved it to joelouxasianandtribalart.com. In both cases I edited config.php to reflect the new domain and redirect to 'false':
Trying your suggestion, and editing at redtribal.com, I'm getting redirected to tribalantiques.com when I try to enter edit mode. Oddly enough, this exercise has seemed to stabilize the situation at tribalantiques, as I'm now able to log in in there and edit. Trying again after deleting my cookies yielded the same result.
I tried the same routine with jl.red... and joelouxetc... and found that I was also getting redirected and other weirdness.
Either way I'm going to need to build more sites in 5.4 at temporary domains before making them live, and this has been fine in the past. Is there a way to fix the session thing so it behaves predictably?
Thank you again. If this is an issue with something I've done and not the C5 update, I should probably pay you guys to trouble-shoot for me?
I've been building sites at a development url, then moving them over to an appropriate domain and manually editing the config.php. In these two cases, I created a site at redtribal.com then moved it to tribalantiques.com, and another at jl.redtribal.com, and moved it to joelouxasianandtribalart.com. In both cases I edited config.php to reflect the new domain and redirect to 'false':
Trying your suggestion, and editing at redtribal.com, I'm getting redirected to tribalantiques.com when I try to enter edit mode. Oddly enough, this exercise has seemed to stabilize the situation at tribalantiques, as I'm now able to log in in there and edit. Trying again after deleting my cookies yielded the same result.
I tried the same routine with jl.red... and joelouxetc... and found that I was also getting redirected and other weirdness.
Either way I'm going to need to build more sites in 5.4 at temporary domains before making them live, and this has been fine in the past. Is there a way to fix the session thing so it behaves predictably?
Thank you again. If this is an issue with something I've done and not the C5 update, I should probably pay you guys to trouble-shoot for me?
I think you're doing everything right; I think the problem is REDIRECT_TO_BASE_URL is set to false in your config/site.php - when you really ought to set it to true or just omit it from the file directly.
Basically, in order to avoid situations like this, concrete5 assumes its sites live at one base URL. This is a combination of the BASE_URL and DIR_REL constants. If REDIRECT_TO_BASE_URL is set to true (which it usually is, unless its explicitly overridden) it will redirect to this canonical URL every time the site is loaded, no matter what the original request URL was.
So, in most situations, simply set your BASE_URL to the URL of the site in question, once you push the site live. e.g. if you develop athttp://dev.mytestserver.com, you'll keep BASE_URL equal to that value, until you go live with the site, at which point you'll manually change BASE_URL to point to 'http://www.mylivesite.com'
The only time turn REDIRECT_TO_BASE_URL off is when we need multiple domains to point to the same concrete5 site, and the site should NOT redirect them to the base URL. Typically the only time that is the case is when we're using the domain mapper or some other trickery to host multiple domains at one concrete5 site. You won't typically need to do this. So I'd remove that line, and make sure that BASE_URL is set to the URL of the live site, and it should work for you, and editing shouldn't lose session either.
Hope this helps!
Basically, in order to avoid situations like this, concrete5 assumes its sites live at one base URL. This is a combination of the BASE_URL and DIR_REL constants. If REDIRECT_TO_BASE_URL is set to true (which it usually is, unless its explicitly overridden) it will redirect to this canonical URL every time the site is loaded, no matter what the original request URL was.
So, in most situations, simply set your BASE_URL to the URL of the site in question, once you push the site live. e.g. if you develop athttp://dev.mytestserver.com, you'll keep BASE_URL equal to that value, until you go live with the site, at which point you'll manually change BASE_URL to point to 'http://www.mylivesite.com'
The only time turn REDIRECT_TO_BASE_URL off is when we need multiple domains to point to the same concrete5 site, and the site should NOT redirect them to the base URL. Typically the only time that is the case is when we're using the domain mapper or some other trickery to host multiple domains at one concrete5 site. You won't typically need to do this. So I'd remove that line, and make sure that BASE_URL is set to the URL of the live site, and it should work for you, and editing shouldn't lose session either.
Hope this helps!
That did indeed help! Thanks so much...
Np! Glad to hear it.
