Support

Start by removing all contents of the .htaccess file except for the code you said is used to change the PHP version.

Edit the file Solo/assets/private/config.php and set the live_site line to an empty string:

"live_site": "",

Then, try logging in again.

You can try to install Solo again, but I think you will run into the same problem. The .htaccess files cascade through filesystem directories. The .htaccess file from Moodle does take effect when you try to access Solo and since we have no control over its contents it might very well be causing the redirection you observe. I would indeed recommend creating a subdomain and install Solo in there. 

As per your host's documentation, they place subdomains' web root directories under the subdomains directory which is next to httpdocs, not under it. Therefore, the subdomains are isolated from the main site as far as .htaccess file cascading goes.

What you describe is not the behavior of the software I have released. There are no external redirects beyond form submission. 

If you are not logged in, visiting any URL –even one that would normally result in a 404– results in the login page being displayed. The login form submits to the /index.php?view=login&task=login URL which redirects you to /index.php?view=main. This is the only kind redirection that takes place: on form submission.

When you go to the / (or /index.php) URL there is no external redirection happening. The default view is main. If you do not specify a view in the URL, it displays the main view (control panel) WITHOUT redirecting you.

What exactly is the live_url you see in your config file?

What happens if you empty it as per my previous instructions?

What happens if you set it to https://solo.mydomain.com?

I understood you just fine. What I am saying is that the behavior you observe is NOT how the application works. Since it's not a case of the Host HTTP header not being passed correctly –that's what live_site works around– my only conclusion is that you have some other kind of server issue.

Maybe you are using a CDN, or your LiteSpeed with its fairly broken PHP implementation?

PHP uses its own session management. Developers do not set a session cookie manually; PHP does it automatically (it's the PHPSESSID cookie). Authentication (logging in) sets the appropriate information in the PHP session. Moreover, if you had a login issue you'd be redirected back to the login page where you would have to log in again. Further to that, you have said yourself that using a different view name works, i.e. you are logged in. Therefore, claiming that this is an authentication issue is quite obviously false as per the information that you have provided yourself.

Not to mention that you essentially claimed that this software has never worked in the 13 years that's been around and that both me developing and using this in production, as well as thousands of clients who use the software, are all morons who didn't notice the software doesn't work and can't be configured. I think I do not have to tell you how you sound making such a claim, through the voice of a generic AI chatbot that you fed wrong information and spat out bullshit in response – the cookie is obviously set in the HTTP 200 showing you the login form, not the post-login redirect which only updates the session data exactly like Joomla itself does...

I am afraid there is nothing more for me to do here.

The behavior you observe cannot be reproduced in a wide assortment of servers. I have tried servers I have set up myself –both local and on commercial server virtualisation services– as well as commercial hosting provisioned by Rochen. There is no such issue.

Further to that, the behavior you report is NOT congruent with the code we ship. However, since you explicitly reinstalled the latest published version of the software from its distribution package we can be certain that you are not using an outdated or modified version of the code.

Given the fact that this behavior has not been observed by anyone else in those past 13 years, cannot be reproduced in any of the dozens of environments we have access to, and has only be reported by you and for only this particular site we can say with absolute confidence that this is a problem that only has to do with your site, web server, or server environment configuration.

You have explicitly stated that you have used a subdomain whose web root is outside your main site's web root, and you have implied you have checked your subdomain web root's parent folder for any .htaccess files. Therefore, we have ruled out that this is a .htaccess cascading issue.

Further to that, you have explicitly stated that you are using a minimal .htaccess file which only has the three lines necessary to select your PHP version. Therefore, we conclude that this is not a .htaccess issue in general.

This leaves us with only one possibility: something in the configuration of your web server or your hosting environment.

Given the fact that we are not your host, we are objectively neither involved nor responsible for the configuration of your server, or any hosting, networking, and content delivery infrastructure which may be in place in front of your site. As a result, this issue is outside the scope of our support.

As per our Terms of Service, I am now closing this ticket for an issue that is outside our support scope as invalid.