One of the big annoyances I run into during WSN installations is cookie conflicts. If you only have one installation per domain you never have to worry about this, but I've often got dozens. There's nothing more frustrating than running the setup and then not being able to login to the admin panel because some other installation used the same cookie names from who knows what path, perhaps a global cookie from some other subdomain even. Digging through Chrome settings to remove the cookie to get in to change the cookie names is no fun.

Some time ago, I added a section to setup.php which checks to see if the installation is in a subdirectory of another WSN installation. When it detects that scenario, it automatically sets unique login cookie names. And that helps one common scenario... but it does nothing for all the other places cookies can come from.

To solve this, my first thought was to make setup.php check for $_COOKIE['wsnuser']. But then I realized that would only work for a manual setup (which almost nobody does anymore), because autosetup.php loads setup.php in a programatic way that does not transmit your browser cookies. So what I ended up having to do is modify both setup.php AND autosetup.php, so that autosetup.php can do the cookie check and can then send the request for de-conflicted cookie names to setup.php as a url parameter which setup.php then obeys.

The end result? No further risk of being immediately unable to log in to a fresh installation. There is still a risk of cookie conflicts though: you might have another installation capable of setting a conflicting login cookie, but which you are not presently logged into in that browser, but which will create a problem when you login later. I'm not sure if there's anything I can do to automatically handle that scenario.

If you encounter such a problem, by the way, you can solve it using a tweaks.php file.