I get the 404 page when editing Home page

[baki]

Hi,

I have just installed processwire 2.1 on my server and if I edit the Home page and hit the Save page button, I get a 404 page at www.mydomain.com/processwire/page/edit/?id=1. When I reload that page I can see that the changes are not saved.

I have found a post (http://processwire.com/talk/index.php?topic=315.0) about this error, but there was no solution for this. I have tried the suggestions made by Ryan in that post, and the page's title was modified successfully. After this test I still get the 404 page when editing the Home page. All other pages can be edited.

Thank you for your help!

Regards,

baki

[ryan]

Welcome to the forums and thanks for posting. I always wondered how that person resolved the issue you linked, as I never heard back. This is the only other time I've heard of it, so we might need to test a few things to track it down.

Can you edit your /site/config.php and find the line that says $config->debug=false; and set it to true? I'm just wondering if that might help us to get a better error message.

What is your server software? (PHP version, Apache version, platform?). What browser and version are you using?

Thanks,

Ryan

[baki]

Welcome to the forums and thanks for posting. I always wondered how that person resolved the issue you linked, as I never heard back. This is the only other time I've heard of it, so we might need to test a few things to track it down.

Can you edit your /site/config.php and find the line that says $config->debug=false; and set it to true? I'm just wondering if that might help us to get a better error message.

What is your server software? (PHP version, Apache version, platform?). What browser and version are you using?

Thanks,

Ryan

I have edited /site/config.php and set debug to true, but after hitting the Save button, the debug information is not seen on the 404 page because it's not an admin page.

My virtual Linux server's detatils:

- PHP version is 5.2.17

- Apache version is 2.2.21

I am using Firefox 7.0.1, but I have tried to edit the Home page with Internet Explorer 9 (no success).

Thanks,

baki

[ryan]

Your setup sounds just fine, though if we can't figure it out we may want to take a look at your phpinfo. If you have a URL with a "<?php phpinfo();"  script, please email it to ryan at this domain name. Though first, lets take a look at this:

When you see the 404 page, what is the exact URL remaining in your address bar? I think this might help us to determine what is happening.

Lastly, can you post the resulting error in your /site/assets/logs/errors.txt , as it would help to get a look at that too.

[manddar]

Your setup sounds just fine, though if we can't figure it out we may want to take a look at your phpinfo. If you have a URL with a "<?php phpinfo();"  script, please email it to ryan at this domain name. Though first, lets take a look at this:

When you see the 404 page, what is the exact URL remaining in your address bar? I think this might help us to determine what is happening.

Lastly, can you post the resulting error in your /site/assets/logs/errors.txt , as it would help to get a look at that too.

@ryan @baki

I got just similar issue but not for home page but admin page.

If you see my previous post, I asked how to change default URL of Admin from processwire to admin, after renaming page to admin when I hit save, I got that error, but after trying my new admin URL it works.

Thought to post my experience considering it will give you some clues on this.

[ryan]

If you see my previous post, I asked how to change default URL of Admin from processwire to admin, after renaming page to admin when I hit save, I got that error, but after trying my new admin URL it works.

This is actually the expected behavior when you change the admin page's name because the system URLs are defined at bootstrap, so it doesn't immediately know that you changed the URL. Not ideal I know–I can think of a way to get around that, just haven't done it yet (changing the admin URL isn't something I do every day). But I think the issue mentioned in this thread is something completely different. I'm guessing it's got something to do with an apache setting that is removing trailing slashes from URLs, but need to find out more from  Baki to be sure.

[baki]

Your setup sounds just fine, though if we can't figure it out we may want to take a look at your phpinfo. If you have a URL with a "<?php phpinfo();"  script, please email it to ryan at this domain name. Though first, lets take a look at this:

When you see the 404 page, what is the exact URL remaining in your address bar? I think this might help us to determine what is happening.

Lastly, can you post the resulting error in your /site/assets/logs/errors.txt , as it would help to get a look at that too.

I have mailed you my phpinfo.

The url in the address bar is this: www.mydomain.com/processwire/page/edit/?id=1

The /site/assets/logs folder is empty.

[ryan]

Thanks I received your phpinfo and have reviewed it. It looks good to me, though there are two things there that I've not tested on my own before. That is eaccelerator and suhosin. A search for these on google reveals that there are apparently a few rare conflicts with other CMSs, so it's possible there's something there. Though I think both eaccelerator and suhosin are relatively common in commercial hosting environments so if that's the issue, it's more likely to be a particular setting in the extension rather than than the extension itself. However, I think there's only a 25% chance that either of these are the issue. If you are seeing a ProcessWire 404 page (as opposed to an Apache one), then it's PW that's still handling the request.

Since there's not a clear answer yet, would it be possible for you to create an account for me in your ProcessWire installation? I would like to login and reproduce it myself while watching the request headers to see if there is anything unusual I can spot. Even better would be if I could get ssh or ftp access to make and test debug edits to track down exactly what's happening–that would be a sure way to tell. But let me know what works for you.

Thanks,

Ryan

[baki]

Thank you for reviewing my phpinfo. I have a hosted web server so I cannot change PHP settings. However I have created a superuser for you and mailed the user name and password. Unfortunately I don't have ssh access to the server. Maybe I can create an FTP user for you but it is much more complicated than creating a user in processwire and I have to take a look at that.

Thanks,

baki

[ryan]

Thanks I received your email and logged in and was able to reproduce the issue you mentioned. I think I also have a better understanding of what is going on. Though it is rather bizarre.

Try editing your homepage. You should be able to save it now. Then try going down to the 'sidebar' field, and type "<p>" tags around the the last line. Then hit save. Notice you now get a 404.

It appears we are running up against a strange filter (mod_security or something with suhosin)? It is behaving with this rule set:

If there is more than 1 field in a POST request with HTML tags on more than 1 line in both fields, then remove all GET and POST fields from the request.

There may be more factors to the rule, but that's it as best as I can tell.

Note that you can reproduce this issue on any other page by applying that rule to any other page. I turned your sidebar field into a  regular textarea just to make it easier to test. Go and type "<p>test</p>" in the sidebar field on any page, hit enter twice, and type it again, then save. You'll trigger the filter and get the 404.

To test that the server really was wiping out the GET/POST vars, I tried changing your 404 page to use the Admin template, which shows debugging info. Then I saved the homepage. See the attached screenshot which shows the POST vars in the 404 page–there are none. Yet my HTTP header log shows all the vars that were POSTed and no redirects. Meaning, it appears something at the server is wiping out the vars before ProcessWire even loads, which is why it's giving a 404.

Pretty bizarre. I think we're hitting up against a bad mod_security rule or some other server-side "security" filter that is getting triggered by the presence of some HTML combinations in a POST request. Another indication is that the server handles most requests pretty quickly, but as soon as a POST request has any kind of HTML in it, the POST request becomes unusually slow… as if the server is loading some other software to analyze the request before letting it go through.  I believe your webhost may have made a mistake in whatever security measures they've put in place to cause this.

[Pete]

This has reminded me that I've had similar issues with MODx like this before - some server security modules have really tight rules (usually mod_security) and won't allow HTML to be inputted via forms.

In my case there were several rules causing the issue and I was able to ask my host to alter the rules to allow posting HTML in forms so it's worth a shot asking them if you can.

[ryan]

I agree, it is worth asking. But I also think that a hosting environment with such tight mod_security rules is a CMS-unfriendly environment (for any CMS). It looks to me like in this particular case, Baki could probably get around this one by just limiting each template to having only a single TinyMCE field, and using Markdown for any other fields that need any kind of formatting (given that HTML won't be allowed except in POST field). But personally I would consider looking at alternate hosting providers... there are so many, and it's not really worth jumping through a lot of hoops to get around overly aggressive mod_security settings. I also worry about hosting environments that have this kind of setup because I think these strict rules are sometimes in lieu of real managed security.

[baki]

Ryan and Pete, thank you for your help!

Now I can modify my Home page, and I was able to reproduce the 404 error with the html tags on other pages also. The strange thing about my hosting environment that before ProcessWire, I was testing Joomla and Wordpress for months and there were no such problems with them. Anyway, I will ask my host about this.

Thank you again!

Regards,

baki

[ryan]

I was testing Joomla and Wordpress for months and there were no such problems with them.

I think that both WordPress and Joomla are only configured with one rich text (HTML) field per entry, by default. ProcessWire is different in this respect in that it's built around all custom fields and you may have as many or few of them as you want. PW's default profile is using the rich text editor for both the body and sidebar fields, so when both were populated with HTML, that's what was triggering it.

[Svet]

I just have to say...

Had the same issue today. This thread got me thinking, so I broke up my content into smaller pieces and kept troubleshooting until I found the offender!

It was /  - only little backslash character that caused me so much brain pain.

Another one was word "CD"...bewildered!

After I got rid of it, everything worked for me.

So thanks Ryan and hope this helps someone.

And - Pete - yes, the server has mod_security (which can cause trouble for developer)

Regards,

Svet

[Pete]

The match against CD is insane, but I suspect what it thinks you are trying to do is change directory and that with the slash is probably enough to trigger it.

mod_security is such a pain. Glad I don't have to worry about it with ServInt

[drpuff]

I was having the same issue (404 when saving the home page), and it was caused by open/close braces in one of the text fields.

Had exactly the same issue with a MODX install about a year ago. 

[Jonathan Lahijani]

I hit this issue today as well.  I have a page that has a regular textarea field (not CKEditor) and it contains an embed code with <script> in it.  Just that alone in the field causes a 404 when saving a page.  Probably some PHP setting I have to adjust.

[sandimilohanic]

I have had problems with pw version 2.5.3. When i editing a home page I got an error 404. The problem was because to the homepage i had field types Repeater. When I removed the field Repeater from homepage everything worked ok.