Version 2.7.0: Fresh install fails with The page isn’t redirecting properly

[jimmyorkin]

Verify the Following
Reporting About the Latest Version? Yes

Searched Issue Reports for Bug? Yes

Reviewed the Good To Know Issue Reports? Yes

BCOE&M Info
Version: 2.7.0.1
Installation URL: entries.texasredcoat.com
Hosted Installation? No

Describe the Bug
The initial installation dialog fails with a "The page isn't redirecting properly" message. If you change the setup_free_access variable to false, you get a message that you need to change it to TRUE.

To Reproduce
Steps to reproduce the behavior:

1. Do a clean empty database install and go through browser based initial configuration.

I tried the offline database install method and it gets stuck on wanting to enable the setup_free_access variable.

I dropped back to v2.6.2.1 and browser setup works.

Thanks, Jimmy

[javasavvydev]

I am having the exact same problem. When set to setup_free_access is set to FALSE I can see the setup page and there is a message at the top that I need to change $setup_free_access = TRUE;

However when I change that line to true I get redirected back the index.html of the parent website.

Does this have something to do with the new code at the top of the config.php?
if ((session_status() == PHP_SESSION_NONE) || (!function_exists('sterilize'))) { $redirect = "../../index.php"; $redirect_go_to = sprintf("Location: %s", $redirect); header($redirect_go_to); exit(); }

I tried commenting this code out (It was not in previous version) and was able to get to the Install DB Tables and Data.
I have not tested further yet, but will report back if I run into any issues.

[javasavvydev]

*Note. I setup another competition and it breaks durring the install with this code commented out. I believe the code I commented out is intended to clean up cached session information that would be there if the configurer has previously setup BCOEM. However this commented outcode won't run in any of my browers. I get an error that the page is blocked because it contains a request to an insecure style sheet, and that all content must be served over https.

Plan now is to comment out this code, and run the configuration script from an incognito browser that should not have any previous session information.

[geoffhumphrey]

@jimmyorkin - you should be able to now do an upgrade to 2.7.0 now that you've got 2.6.2.1 installed successfully.

@javasavvydev, that may be the route to take while I try to nail down where the issue lies as I'm not having the same issues in my own dev environments.

Thanks for reporting and stay tuned.

[javasavvydev]

@geoffhumphrey I am seeing this bug in version 2.7.0.1. I do a fresh install for every competition, I never try to do upgrades.

My Current work around is to comment out that block of code I posted above.

However after setting up a second competiton, I had the guy running it run through the install and it didn't install right. I realize that the block of code I commented out cleans up left over session information. So I think the code is needed to do that, and thus lead to the second configuration not working right.

My work around for this is to leave the code block commented out, but have the user install using an incognito / private browser so there will not be any stale session information.

I wanted to try the following test, but didn't get around to it yet.

Do an install on 2.7.0.1 with the block commented out. Run through the configuration.
Then do another install of 2.7.0.1 but leave the code block in, run through the configuration. Maybe it will work ok this time because it finds the stale session that wouldn't exist the first time you install it?

@geoffhumphrey If you do a clean install of 2.7.0.1, can you configure it from an incognito browser (no previous cached session?)

These are just test ideas and I may be way off track here. I will try to run this test next competition I setup.

[jlawless1]

@geoffhumphrey can confirm, I was also installing a fresh BCOEM on an empty db. Commented out the following code and it is now installing. What is the intention behind this code snippet?
if ((session_status() == PHP_SESSION_NONE) || (!function_exists('sterilize'))) { $redirect = "../../index.php"; $redirect_go_to = sprintf("Location: %s", $redirect); header($redirect_go_to); exit(); }

The redirects seem to cause the software to infinitely redirect to the the html root when running setup freeaccess TRUE