A new install of CWIS 3.2.0. Copied in a local interface from a previous site.
We need to configure some fields to hide for normal users. On the previous site this is done with privs on fields.
Admin user is using default interface.
I make the adjustments on index.php?P=EditMetadataField&Id=10 and click Update Field. This results in a 404 page being displayed, and the field is not updated. What's very odd is that the URL displayed (which is also the action of the form) is still index.php?P=EditMetadataField&Id=10
This also happens when clicking Cancel.
No PHP errors appear to be logged in conection with this.
Can you help me figure out why this is happening?
That is very odd. A few questions:
Does it happen for any metadata field that you edit, or only that one field?
Does it happen for metadata fields in any schema (Default, User, etc) or just those in one schema?
Is this a fresh database, or a database upgraded from a previous site?
Looking at the HTTP response headers on the page you end up on, is there a
Locationheader value set?It seems like what's going on may be a combination of an issue with the metadata schema valuies and how the web server is configured.
It seems to be only that one field, Format.
Fresh database. Resources inported from other CWIS sites.
No Location header set.
So, not sure what is happening. Does CWIS sometimes return 404 for trapped 500 errors or something?
Really not sure what is going on here; we can't replicate it on our end at all.
Would it be possible to see the last 10 lines or so from your apache access_log, error_log, and the local/logs/cwis.log from inside your site right after one of these errors?
CWIS should only return a 404 if it genuinely can't find the page. We don't trap 500 errors and substitute any other error code (It's not clear to me how we even could, let alone why we would).
It might also be helpful to have a screenshot of the 404 page -- I'm wondering if it's a CWIS 404 or an apache one, perhaps resulting from a rewrite rule invoked before CWIS starts?
Email is fine if you don't want to post that stuff on the forum.
The answer turned out to be mod_security - the form submission was matching a pattern there and it was getting blocked.
I disabled that rule via WHM and now can save changes to the Format field!