I am having this issue again though last time my host solved it, but this host cannot figure it out,

When I go to save changes in Edit Post/Pages area and I do have php code in some of the fields, i get 404 page and no changes will update on the theme.

This is happening on ALL sites on this host, 6 of them, so I know it's PHP issue.

ATA 3.7.3
PHP VERS ON CPANEL 5.3.22

What do I need to tell my host to fix, they are clueless???

What changed on the host?

Originally Posted by juggledad

What changed on the host?

Nothing changed on the host, I moved these sites from another host and now I am getting this error. They have been working all night and cannot fix it.

The other time it happened that host was able to figure it out quickly and it had to do with PHP permissions of some sort, but I don't know what exactly, and I told this host to check permissions, but they say that my permissions are fine.

I even tried to look at the Error Logs at cpanel, but they show nothing, not sure if this type of error would show.

what happens if you swap to twenty-twelve? can you edit things then?
If not, then this issue is not related to the theme at all.

so the last time this happened it was on another host? don't you think that peice of information would have been usefull to mention in your first post?

Sorry, I figured that mentioning it was a hosting issue was enough.

As I said this happened before and so I thought the host would fix it again.

Switching to Twenty Twelve won't be a good test because PHP is the issue, where there is PHP code on the Ata Edit Post/Pages interface, and Twenty Twelve doesn't have that do they?

This has to do with making changes in PHP areas of ATA only, because I can edit and save changes in other parts of ATA, like Body, Text & Links for example, that one updates fine because there is no PHP in that area.

I don't think this is because of ATA, I think it's a PHP server setting of some sort but I just don't know what to tell the host to check or fix, and because it's happening on ALL ATA sites on that host only, it must be a PHP server issue.

I just tried another site on the host and this does show the following error after trying to save changes in Edit Post/Pages

403 Permission Denied
You do not have permission for this request /wp-admin/themes.php?page=functions.php

I think the other sites go to 404 instead of showing this error, but I think that's the error all around

are you talking about the theme options or editing a post or a page? your question is unclear.

If it is the theme options, you can no longer add PHP to the theme options due to a Wordpress theme restriction that went into effect about 12 theme release ago.

what versions of WP and Atahualpa were you using?

WP

Ata - 3.7.3

I am talking about Theme Options the Edit Post/Page Info Items Area, where you can add Home Kicker, Single Post Kicker etc..

I am not adding PHP to that area, I am just trying to delete some text from Kicker Home Page, but there is some php code in that area from before, but all my other 66 sites save changes fine on other hosts even when I have some php allready in there, this is a specific issue with this server.

Atahualpa 3.7.3 is two years old! the current version is 3.7.13 - are you on a two year old version of WP also?

I would try updating to 3.7.13 on your test site (You do have a test site you can play with…right??) and see if things work on it.

The WP version is current, I just tried updating ATA to current theme 3.7.13, that still comes back with 403 permissions errors.

If you are getting a 403, then you need to talk to your host's support once again. Nothing we can do, it seems to be a server issue.

(Maybe you shouldn't have moved hosts - who is the new host?)

SOLVED - SOLUTION FOR OTHERS

Finally found the solution online and knew what to tell my host.

Contact your host (some hosts would know this right away, mine didn't) so once I told them what to do it was fixed immediately.

THE FIX

Tell them to check your mod_sec settings and make sure that all your domains are whitelisted.

Specifically they need to whitelist rule 340163 for EACH DOMAIN ON CPANEL because its hitting a mod_sec rule.