Brilliant!
Well done and thanks for taking time writing this down.
My only concern is this:
‘That is the equivalent of running around with two active nuclear warheads ducktaped to your arms in a porcelaine store while walking on lego blocks’.
If you hear a blast it might have been my sudo user.
Thanks one more time for your help! Can you send me as a text how to avoid this to happen again please? How I understood yesterday I need to install a SSL, because people coming to the page and they want to use SSL and there’s no valid one and it looked like person with expired ID. So, need to install SSL and you can send me some commands which will be helpful to do it.
Also, how I understood steps are like that (correct me or write me the right explanation please):
Note for myself: don’t clear a cache with php bin/console cache:clear
And this is because of the permissions. So there is one virtual user who is responsible for running the web-show. ps aux | egrep ‘nginx’ and this user runs my webserver most likely apache or nginx.
When I tried to actually see what the name of this virtual user is. and I tried:
ps aux | egrep ‘(apache|httpd)’ So when I regerate my cache and run the php bin/console cache:clear command NOT as the www-data user, but for example sudo user I can run into problems. Sudo is the post powerful user on the server, and this command is the equvalent of the hotel director rewriting all the recipes, but not letting in anyone into the kitchen under his ranks.
Don’t just update or clear the cache in the name of any user. Especially if I am logged in as sudo. Even if I am sudo user, you can issue the commands as www-data user by using this format: sudo -u www-data php /var/www/html/mautic/app/console cache:clear
Once my permissions are already messed up, I can try any time fix it. Go to your Mautic folder, and:
This is like a general fix, I can run any time I have an issue with “unable to write” or “cannot be found” type of errors. I can also regerate the cache by warming it up: sudo -u www-data php bin/console cache:warmup
It gave me a nice green output, which means that everything should be okay:
“Cache for the “prod” environment (debug=false) was successfully warmed.”
Symfony also works with assets. These are not inclided in the cache, and I might need to regenerate them from time to time, after update when big changes have happened in the background. This solves issues like previously working fictions not working, like dropdown in segments. So Issued the right command: sudo -u www-data php bin/console mautic:assets:generate
So my steps combined and minifed asset files from each bundle into single production files. In other words: reseted big changes. But server was still down. I fixed permission issue with sudo chown -R www-data:www-data. And sudo chmod -R 775
Afterwards cd app/config ; and we deletes S in https site url
Cleared cache with rm -rf var/cache/*
I forgot what commands we used to open GNO nano5.4 and why we deleted S and why it caused a problem?
You need to install SSL, I PMd you a tutorial, but there are many on the internet.
You need to use the one that fits your webserver, and operation system.
You got the error “too many redirects”.
The reason was, that your site URL was saved with “https” protocol in front. This is how Mautic calls itself.
When your visitors opened the page, your webserver directed the traffic to http, but Mautic claimed it is https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https, but your webserver didn’t agree, so redirected to http, but Mautic claimed it’s https…