Confirmation window problems

[tpwalsh]

We here at Illinois State have clone off our production Archon installations for testing the new code and have run into an issue with confirmation pop up winodows. They come up blank in Chrome or don't come up at all in Firefox and Internet Explorer. I'm not sure why yet. This is installed on RHEL7 running Apache 2.4.6 and php 5.6.30

http://my.ilstu.edu/~tpwals1/Archon.png

Has anyone else run into this? -Tim Walsh.

[chrisprom]

Tim, we are not having this trouble with the new code. is it possible you logged out on the other tab? The only other times I’ve seen this happen is if you have logged out on a different tab, then the admin interface does not know what to do with the input.

Chris

On Jul 12, 2017, at 3:35 PM, tpwalsh notifications@github.com wrote:

We here at Illinois State have clone off our production Archon installations for testing the new code and have run into an issue with confirmation pop up winodows. They come up blank in Chrome or don't come up at all in Firefox and Internet Explorer. I'm not sure why yet. This is installed on RHEL7 running Apache 2.4.6 and php 5.6.30

http://my.ilstu.edu/~tpwals1/Archon.png <x-msg://19/url> Has anyone else run into this? -Tim Walsh.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/archonproject/archon/issues/83, or mute the thread https://github.com/notifications/unsubscribe-auth/ABMJarKBDgQRUODrNkbPVIn3GBwrd_5wks5sNS4TgaJpZM4OWKy9.

[tpwalsh]

I just tested that and it doesn't seem to be that. In a fresh Chrome window I went to Archon, clicked on login, then admin and then tried to change my first name. Same behavior. We actually have 2 test instances(on for each production installation) and both are doing that same thing.

The only thing that comes to mind is that we're using our old theme, which seems to include an older installation of javascript(1.7.2) but when I switch to the illinois theme, I still receive the same error. I'm going to keep digging.

When I stepped through production(Rev1) and test(Rev3) side by side I got to jquery.form.js line 181 when I ran into a difference/error. Rev1 throws a deprecated error for NodeValue where Rev3 just throws this error: "XML Parsing Error: XML or text declaration not at start of entity Location: https://tempest-test.lib.ilstu.edu/univ/index.php Line Number 2, Column 1:"

This is what I received in FireFox developers edition. Also as a note I have not implemented ModSecurity yet. I wanted to get through basic testing before implementing it to make troubleshooting easier.

[tpwalsh]

Just to keep a record of what I'm doing. I've downloaded a new instance straight from github to a new directory, changed the DB settings to the same db as the broken codebase, and it works great. diff shows no differences between the two codebases including down to selinux permissions. Even after clearing cache/cookies between tests of the two I'm still getting the same error. . bizarre.

At this point I have one working test installation and one not working The code bases are exactly the same(same files with the same content and the same permissions), and they point to the same databases. I'm baffled but the brute force way to fix it was to delete the old code base and do a git clone. So at least there's a way to move forward.

[tpwalsh]

Just to report my findings, I found the issue and it's one that doesn't make sense to me, but it's repeatable. Inside of config.inc.php, I had a extra newline after the final ?> I was able to repeat this with two different installations on two different servers One was CentOS7 and one REHL 7 both running PHP 5.6.31.

I'm not sure why this extra newline is significant or why it bleeds over to javascript(I think), but that's how I fixed it.

[wdmartin]

Ah. So what went wrong was:

1) That extra newline got stuck after the closing PHP tag ?>

2) Because it was outside the PHP block, Apache transmitted the newline as part of the document.

3) Transmission of the whitespace triggered Apache to send the HTTP headers. Although this probably wasn't the cause of your issue in this particular case, it does make it impossible for subsequent PHP calls to manipulate the headers (or set cookies).

4) Finally, the presence of that newline character made the XML parser choke, because the XML specification does not allow whitespace before the opening <?xml tag. It's finicky that way.

One of the coding standards that the Drupal project adopted years ago was that in any document which is 100% PHP, you're not supposed to put in a closing PHP tag. When the PHP parser reaches the end of the file, it automatically supplies the closing tag if there wasn't one. And omitting the closing tag avoids confusing situations just like this one. It's impossible to accidentally put whitespace characters after a closing tag if there isn't a closing tag at all.

[tpwalsh]

OK. That makes sense then. I wasn't aware of the Apache whitespace protocol, not that it would have helped that much as this was a classic case of eliminating variables and differences until you find the exact change that generates the results expected.