are you using a custom theme?
is there anything else on that page that is odd?

have you tried clearing your cache and logging out/in?

never had this.

Thanks for your help. I am using a custom template, but I don't see how that could cause the problem. If I edit other block types, they seem to work fine... it's only the content type.

I thought it might be related to mod_rewrite, but I disabled that in the config and removed the htaccess file, but the problem persisted.

I developed this site on my local server and then uploaded everything to the remote. On my local server everything works fine. It's only on the remote.

My next step is to try reinstalling concrete on the remote.

So I did a new install of Concrete 5.3.1.1. I got the green light on everything and installation was successful. On the default home page of the new site, I tried editing the content and got the exact same behavior: when I click 'Update' to save my edited content, it redirects immediately to the base url and the changes are lost.

Any ideas what it could be? My best guess is that there is something different about the PHP configuration. I'm looking there next.

I've determined the problem has something to do with the form submission. I've tested this in Firefox and Safari with the same result. The form's action is not being sent when the form is submitted, but instead it directs to null (or base url).

I've tested this more with other block types. The slideshow block type works fine, but content and HTML types exhibit the problem. It's not just editing, but also adding new blocks.

Logic would dictate that if this is purely a Javascript issue that the same results would occur on both the local and remote server, but that's not the case. There's some condition or variable I'm overlooking.

I've looked over the entire php.ini matching everything I can. I've also looked at .htaccess and all there is is mod_rewrite (which I already tried disabling).

Between clicking 'submit' and the form being submitted, something is causing the form action to be wiped out to null and the page goes to the base url (domain root) without any data.

It's really difficult for me to figure out what's going on under the hood in regards to these forms and I'm getting into the core concrete code. If someone from concrete has the time, I'll gladly give you access to my web server so you can investigate this.

This is a big problem for me because I'm just wrapping up my client's site and they won't be able to edit the content. Until I can find the fix, this is not going to work.

Thanks for your help.

I couldn't figure out why the block inside the package wouldn't save, and it boiled down to:

A malformed select form element that was throwing an error but not displaying said error.

This was a totally custom everything, so I would make sure that you haven't mistakenly edited something in your block controller and that the html from the content box is well formed.

Really weird to nail down, wish I could help more, but the selector thing had me stumped until I knocked everything down to textboxes until it would save.

I didn't make any custom packages and also, I tried this with a fresh install, unmodified of 5.3.1.1. Maybe I'll try an earlier version to see if it makes a difference.

I suspect it must be some server configuration issue related to PHP or Apache. Very bizarre.

Whelp, try it on the demos we host athttp://getconcrete5.com/demo

if you get the same behavior there, its something browser/client side related we need to figure out.

if you don't something's funky with your install. I can have someone look at it if you want to pay em, might be something easy to fix but I can't make any promises.
http://www.concrete5.org/support/professional_services...

This is not the first site I've built with C5. I know it works. It's just this one project.

I just have to start dissecting the parts.

I know as a developer that whenever I see the impossible, it is that I'm simply learning something new ;-)

So I did some basic tests with a plain HTML form (not using Concrete) and discovered that the website hosting has for some reason disallowed the use of the 'post' method for forms. Only 'get' is allowed. This results in an http 405 error.

I'm now wrestling via email with some support person who has no clue and apparently doesn't speak english very well to get this fixed. argh.

Were you able to get this resolved? I am having the exact same problem...glad to know that I am not alone.

Yes, it was on the server config side of things. I contacted the hosting company and they fixed it, though I'm not exactly sure how (they weren't very helpful with specifics).

It had something to do with the httpd.conf not allowing POST actions from forms.

Sorry I can't be more specific, but your hosting support should know how to enable it.

My host actually remedied it quickly. It was a mod_security problem...something I couldn't detected with phpinfo. The disabled it for the domain, and C5 is perfect again.

Thanks for the response.