I am being told that the Gibbons have escaped whenever I click a Submit button when changing an Admin setting (e.g. School Admin>Manage School Year).
The only odd configuration that I can think of is that Gibbon is running behind an Apache reverse proxy, perhaps Gibbons do not like being aped!
What direction should I take to re-tame the Gibbons?
I should mention that the setting does seem to be taking despite the flight of the Gibbons.
Thank you,
FV
Upon further investigation it appears to have nothing to do with the reverse proxy. The problem persists when the proxy is bypassed.
I have my suspicions about the URL being malformed somehow. Here is an example:
It seems the URL section “School Admin” is being double escaped so twice the number of Gibbons are getting out!
Maybe we can turn these Gibbons back into great apes?
The browser (Safari) window title seems to corroborate the story:
Installation details: Gibbon v15
Linux system (Cloud VM): Fedora 27 4.13.9-300.fc27.x86_64
PHP version: 7.1.16
Server version: Apache/2.4.33 (Fedora)
Hi fvlasie,
This is unusual, you’re right it does appear to be caused by the URL double-encoding. I wonder if it’s something in the server configuration that’s modifying the header Location: string, as I don’t believe we’ve seen this particular issue before.
To help debug:
Hope we can help tame your Gibbon escapees 
Give a shout if you find any more clues as you troubleshoot this. Thanks!
Hello Sandra,
I just tried a different browser (Firefox) and the problem persists.
It also occurs with other space-in-the-name modules.
So we are narrowing it down…these are some pretty crafty Gibbons!
BTW, thank you for the Data Admin module, it is wonderful! It saved me hours and hours of work.
Thanks!! When my school started up with Gibbon we had 10 years of data in a previous system, creating a way to migrate it all over was a top priority. Glad to hear it’s been useful for you too.
Is there any redirection setup on your server either in the directory-level .htaccess or server-level httpd.conf? Perhaps related to the proxy? If it’s mod-rewrite related, adding [NE] or [NE,B] to the redirection may stop if from double-escaping: https://stackoverflow.com/a/6529394
This is the only URL modifying code I am using in my Apache config:
<VirtualHost :80> #nohttps
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.) https://%{SERVER_NAME}/$1 [R,L]
The Gibbon install folder is unmodified except for user permissions and selinux contexts.
Maybe there is something up with the php version I am using?
The previous post changed my config code:
redirect http to https
<VirtualHost :80> #nohttps
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.) https://%{SERVER_NAME}/$1 [R,NE,L]
`
I have now added the NE but the problem remains. I would be surprised if Gibbon were providing http rather than https to the browser after form submission.
I do have my base URL set with https BTW.
I’m stumped…
It seems the code feature of Vanilla forums does not support line breaks. 
The redirect URL is based on your Base URL in System Settings, so if that url starts with https:// then all the links and redirects Gibbon uses will also be https (and shouldn’t trigger the RewriteRule).
If this is in your Apache config though you’d also need to restart after making any changes (such as adding the NE).
Yes, I did restart, both Apache and php-fpm…
I just realised that your amazing Data Admin module is NOT exhibiting the problem despite having a space in the name. The Gibbons have not gone totally feral…
This a real headscratcher…
Hmm. In your initial URL I see what looks like a double slash in the Base URL: https://gibbon.spots.school/c//index.php` Is there a trailing slash on the end of your Base URL in System Settings? If so, remove it, then log out and back in again (to refresh the Session) and see if that does the trick. The extra slash may be triggering an internal redirect which could double-encode the GET params.
Yes, actually I already caught that! (I have been poring over these settings…)
Unfortunately it made no difference.
Would you like access to gibbon.spots.school?
I suspect it’s server configuration or redirect related at this point. For example, if I visit https://gibbon.spots.school` it will redirect to https://gibbon.spots.school/c/`, is this a redirect in the .htaccess or httpd.conf file (and perhaps needs [NE] added to it too?)
As a test, if I visit http://gibbon.spots.school/c/index.php?%40` it is redirecting to https://gibbon.spots.school/c/index.php?%2540` which is double-encoded, and seems to indicate the previous change adding [NE] hasn’t affected anything … but this is a tricky one to nail down, there’s no saying if the https redirect is even related to the current issue (from some google searches, it does seem to be a common cause though).
I suspect it's server configuration or redirect related at this point. For example, if I visit https://gibbon.spots.school` it will redirect to https://gibbon.spots.school/c/`, is this a redirect in the .htaccess or httpd.conf file (and perhaps needs [NE] added to it too?)
This one is a REFRESH header in index.html `
As a test, if I visit http://gibbon.spots.school/c/index.php?%40` it is redirecting to https://gibbon.spots.school/c/index.php?%2540` which is double-encoded, and seems to indicate the previous change adding [NE] hasn’t affected anything … but this is a tricky one to nail down, there’s no saying if the https redirect is even related to the current issue (from some google searches, it does seem to be a common cause though).
Aha, so it does seem to be Apache’s fault. I will focus my search on that…thank you!
I suspect it's server configuration or redirect related at this point. For example, if I visit https://gibbon.spots.school` it will redirect to https://gibbon.spots.school/c/`, is this a redirect in the .htaccess or httpd.conf file (and perhaps needs [NE] added to it too?)
This one is a REFRESH header in index.html `
^I wrote this^