Stuck in "Welcome loop" during install under Windows.

Steve Gibson

New Member
Hi!

I would love to use (and be able to recommend) MailWizz. But I'm stuck at install. My Windows 2008 R2 server has a mature execution environment which is running XenForo (like this forum, at https://sqrl.grc.com) and EasyForms (another PHP-based app from Envato), Wordpress (at https://blog.grc.com), WikiTiki (not currently public)... all without any problems.

But when attempting to install MailWizz I'm unable to get past the install "Welcome" screen.

I tried updating my license HERE at MailWizz and it was accepted. If I deliberately mess-up the license code, the incorrect license is detected and I'm told to go over to Envato to check it. So my correct license is apparently being accepted.

My server's log shows these four entries:

2020-01-13 20:02:34 10.0.1.57 GET /install/index.php - 80 - 200 0 0 31
2020-01-13 20:03:10 10.0.1.57 POST /install/index.php - 80 - 302 0 0 826
2020-01-13 20:03:10 10.0.1.57 GET /install/index.php route=requirements 80 - 302 0 0 78
2020-01-13 20:03:10 10.0.1.57 GET /install/index.php route=welcome 80 - 200 0 0 15


The first "GET" entry is my manual entry to begin the process. The second "POST" is my submission of the license and acceptance of the terms and conditions. We can see that the POST returns a 302 Redirect to "route=requirements" which then, in turn, 302 Redirects us back to route=welcome.

There are reports of some users getting MailWizz running under Windows, so I was encouraged. If MailWizz's use under Windows is completely unsupported due to its clearly-stated need for Linux, then so be it. Let me know that you have no interest in helping -- despite the fact that I have built a highly PHP-friendly environment -- and I'll go away and find some other solution.

But... if you have anything to suggest and/or are interested in working with me, I'll be glad to jump through hoops at this end. :)
 
Hi! Thanks for your reply. I should have mentioned in my original post that I had already scoured these groups for any solutions and that I did see that note about the session persistence. My PHP installation's configured "sessions" directory is definitely writeable and accessible to PHP. It's currently full of current session state files from several of the other PHP apps that are running on the site.

In examining your solution a bit further, I saw that you have a dedicated Linux daemon for performing the mailing... so it does seem as though your solution is strictly Linux-only? Not even and of the *BSD Unixes. This makes me wonder how others have managed to get it working under any flavor of Windows?

Thanks, again, for any help you can provide or any suggestions you might have. Is there any debugging / trace facility that I could turn on to produce more information for you?
 
@Steve Gibson - You are correct in assuming this is linux only and anything else is not officially supported so if it works it works, if it doesn't, it doesn't.
If you open install/index.php you have this code:
PHP:
ini_set('display_errors', 0);
error_reporting(0);
You could make it:
PHP:
ini_set('display_errors', 1);
error_reporting(-1);
Which would enable error reporting which might give you some hints as to what is going on.

Another place to look at is your web server and php logs, if something doesn't click, the logs should have the reason why.
 
YAY!!! Got it!! :)

I really wanted to get this working. It appeared to be a session problem since the "welcome loop" was generating some null session entries. The problem was SO OBVIOUS once I saw it: I am setting this up in a new domain for which I do not yet have a TLS certificate. So it's not HTTPS yet. But since ALL of the other domains on the server enforce HTTPS, I had "require secure cookies" set in my PHP.INI file. :) The instant I relaxed that requirement everything worked!

Thanks for your courteous replies and suggestions. I'm moving forward again! :)
 
Dear "Twisted"...
  • Okay. EVERYTHING appears to be working under WIndows.
  • I have all of the cron jobs running with Windows' Scheduler.
  • And I am able to move throughout the entire backend UI without any trouble, with one exception...
The Web Server view of the PHPINFO page at (/backend/index.php/misc/phpinfo) is not displaying. The CLI version does showup correctly. But the Web Server shows the unhappy icon and "{server} refused to connect" message.

I fired up Wireshark to look at the packet flow to see what was going over the wire (which is easier since I'm not using https yet), and I see the whole page being returned, along with a fully HTML-formatted version of the PHPINFO output. So... it's working... so far as I can see.

I know this is not critical, but I would love to have everything working and I'm wondering whether you have any idea why this might not be working??? If nothing pops into your head immediately, is there a debugging info switch I can flip to get some more information? Thanks again!!
 
That page is actually loaded via an iframe, so if your domain is https and the iframe is http or vice-versa, then you would get this issue.
Could you look at the page source and see the iframe url and then access it separately in the browser and see if that works?
Is it using same protocol as the main site?
 
Back
Top