Previously on the CogitActive Saga:
Not able to fix (or even comprehend) the problem on my own, I had to resign myself to post a ticket in SiteGround Help Desk. I thought I was entering The Twilight Zone.
… starting from the point where the story stopped.
The ticket
After infructuous exchanges with three useless Gurus (K, A and M), I thought the ticket would be closed – unresolved. However, a fourth one – Guru S – would prove a destructive force to be reckoned with. The ticket was not over . . . the nightmare had just begun.
Here is my answer to Guru S:
Dear [S] (or whoever will be next), I am afraid the situation went out of control. As for now, my blog is BROKEN! Whatever you have done, UNDO IT! Put everything as it was before! I do not understand what you (or [M] before you) are trying to accomplish. My initial problem was simple: the subdomain site, in contrast to the main site, requires me to use the Enforce HTTPS tool to avoid duplicate content, and doing so, I had a wrong (DOUBLE) redirect (from http://www to https://www and then to the correct https://). That is it. [A] told me she could not fix my problem, and I thought that was it. However, [M] and you ([S]) have done things I did not ask for and that are breaking my site. Stop this disaster, please, UNDO all what you’ve done. Put my site as it was before I opened this ticket. You are doing more damages than helping. Sorry. Alexandre
Support Guru Y (day 3)
A new, unfortunate Guru (from the “Senior Technical Support”) inherited this screw-up:
We are currently investigating the issue. Please allow us some time. We will update the ticket as soon as possible. Thank you for the patience in advance.
It would be unfair to blame him for the situation, but try to put yourself in my shoes. His reply, no matter how soothing, could not have dampened my anger:
Dear [Y], Thank you for the update. The issue is simple: By doing things not requested (replacing the blog sub-domain with actual Wild Card sub-domain, for example), [S] broke my blog and affect the configuration on my main site. Not only I didn’t ask for this, but I configured my WP multisite installation with subdomain WITHOUT wildcard on purpose. I don’t even comprehend why [S] decided to manipulate this. The point, now, is that I can’t even access my blog. I am not asking anything more from you but to fix the mess by putting everything back to its initial state (before I start the nightmare ticket). Thank you. Alexandre
Again, as it appears to be the norm in Guruland, he didn’t read the ticket or comprehend my requests:
I believe that the blog subdomain is not fixed. There was a problem with the DNS resolving which is not fixed, but that might need some time to fully propagate worldwide. . . . You said that you want only the blog fixed which is why I did not touch anything else.
Where did I say that? Which part of fix the mess by putting everything back to its initial state
did he not understand? Clearly, I was running out of patience:
Let me be clear. I want my sites (both main and subdomain) as well as my WP settings exactly as they were before I opened this ticket. [S] did things that I didn’t ask for and that I don’t want. I don’t care anymore about [SiteGround] fixing my initial problem (which, by the way, has nothing to do with what [M] and [S] were doing) as: 1) you cannot fix it (you can read the all ticket if you please) 2) you are producing more issues than resolving any. I prefer to keep my site as it was (i.e. with my initial problem). It is far less bad than the mess resulting from the “fixes” that your co-Guru have provided. I repeat: put EVERYTHING back to its initial state (before this ticket was opened).
I even suggested him to reverse (restore) the installation to the state it was [before I opened this ticket]
as I will not lose anything
. Sapped by the turn of events, I concluded: I just hope to put an end to this ticket (not a happy end, anyway)
. Naïvely, I thought the end of this nightmare was nearing. One more time, I couldn’t know where the bottom was:
The problem is that I am not aware of the exact changes made by my colleagues before me.
The point is that I don’t know what they have done either . . . That is why I offer you the possibility to do it the quick and easy way: restore everything as it was before their mess. Is there really no way for you to reverse (in one click, as SiteGround often says) the all thing (WP install, server configurations …) as it was before this nightmare?
Desperate, I also commented:
I can’t believe that they ([S] in particular) took the liberty to destroy my configurations without any reason. I really wish there was a way to go back in time to undo every single changes that they have done in the past two days. If this can help you, I have and will not change anything (on my side); until everything is back to the way it was before I opened this ticket.
This was actually easy to do insofar as I could not even access my WP admin
.
Support Guru Z (day 3)
Everything changed when the ticket was escalated to a Guru from the “Technical Support Supervisor”; I could finally start to see the denouement:
Your account is restored from restore point . . . as per your request. Now both cogitactive.com and blog.cogitactive.com are loading as expected on my end and the free Let’s Encrypt WildCard SSL certificate is working properly. In case you want all request to www.blog.cogitactive.com to be forwarded directly to https://blog.cogitactive.com you should use the following lines in your .htaccess file.
I could not believe what just happened. Was it the end, and what is more a happy end, of this tragic ticket? Not only, Guru Z restored my website, as suggested, but also provided me with a code to fix the double redirect issue. The supposedly unmanageable (according to Guru A) task, which would require different configuration of [my] network, like using Subdirectories and not subdomains
, did not require a professional developer
either – just a “Technical Support Supervisor”. Admittedly, he didn’t answer the main question – why for the main site, but not the subdomain one, I don’t have to use the Enforce HTTPS tool and all the redirects are “direct”?
. However, at that point, I was just thankful that he put a stop to that hellish spiral. Yet, I remain a fusspot:
Thank you for restoring my website ALMOST as it was before. There are only two differences:
– I didn’t use Let’s Encrypt WildCard SSL certificate before,
– The 301 redirect https://www.blog.cogitactive.com to https:// blog.cogitactive.com is not here anymore.
I also learned my lesson; here is the rest of my reply:
However, do NOT touch anything. I don’t know if these two things are related (or how the WP built-in www to non-www is not working on the https at least), but I don’t want to enter this vicious circle again. So, let me repeat: DO NOT DO ANYTHING! Anyway, you have provided a code (for me to implement in my .htaccess file) to force all www.blog.cogitactive.com to https://blog.cogitactive.com, but I assume this will not redirect http://blog.cogitactive.com to https://blog.cogitactive.com. As stated above, I should not need that code, as there is a built-in redirect in WP for www to non-www; why this is not working anymore? In addition, I have tried to use the Enforce HTTPS tool, but it is not working (stay on OFF). I assume I could also force SSL through my .htaccess, but [A] (one of the Guru) already tried and it was messing up my main site. So to sum up, here are my questions (to be answered – don’t touch anything on your own): - Is there a way to fix all the redirects for the subdomain (without affecting the main site) using this configuration (Let's Encrypt WildCard SSL certificate)? If so, explain it to me, don’t do it yourself, please! - If not, can I safely cancel this Wildcard SSL, to reinstall standard SSL certificates on each site (one on the main and one on the subdomain blog)? If yes, let me know the procedure; I will do it myself! - Would this finally put my sites (and all the redirects) as they were before this nightmare? If not, is there something else that was messed up and that I don’t know about? Again, DO NOT TRY anything; just answer these questions, please! I am aware, that putting my site as it was before, will not fix my initial problem (the one I opened this ticket for), but opening this ticket creates more problems that I could ever imagine. Of course, I would have preferred my issue to be fixed, but after this misadventure, I am okay to stay with my (small) initial problem. It is much better than all the fixes that you have tried so far. I just want everything to be back as it was before some Guru messed up. Thank you for providing me with ANSWERS (just answers, NO ACTION). If there is anything unclear, ask me, I will try to clarify it. I hope that this nightmare will end soon!
Suport Guru G. (day 4 & 5)
He might be a “Senior Technical Support” only (a downgrade compared to Guru Z), but he was the only Guru that did what I expect from a Support person. He read my requests, and what is more, he provided me with answers:
First I would like to apologize about the misunderstandings in this ticket. I have gone through it and I noticed few times where the problem was not properly understood and therefore false actions taken on our end. Now I will answer the questions you got and then put my comment on the matter.
To summarize his 770-long word response, he first confirmed that there is indeed a built-in redirect in WP for www to non-www and that the only way to get this function interfered with
is through a rule in .htaccess that would overwrite the default rule
. When I read the following sentence, I thought I was dreaming:
Now all of the other questions are closely related with the solution I will offer you below.
Did I read that correctly? A solution! I could not believe it. I started to read with anticipation the rest of his reply. He first provided a little explanation on what [he] believe[d] caused the issue
; a crucial
step according to him for the further steps [I] decide to take
. Apparently, the core issue was related to vhost record created under the Apache configuration file
. Granted this was a little too technical for me, so let me skip this very complex
part. According to him, the solution (given my Multisite installation) would be to have WildCard SSL installed for cogitactive.com
as this substitutes the need to have the blog subdomain created and the new vhost for it generated in Apache
. Here was his proposition:
Having that said you can either reverse the things done on our end . . . and things are as they were before the ticket was opened. OR you can follow the alternative steps and benefit from the WildCard SSL — WordPress Multisite integration.
For both approaches, he was providing me with step-by-step instructions and was concluding with this: I believe in both approaches the sites will work as intended, but the second one I offered will eliminate the not-desired redirections for the blog
. Again, I did not fully comprehend his technical explanation, but it was convincing enough to get me interested. Yet, I wanted to know more before to try anything
. As a safety measure, I put this warning message at the beginning (and at the end) of my reply:
!!!TO BE HANDLED BY [G] ONLY!!!
First, I acknowledged I was a little lost with [his] vhost explanation
, still trying to rephrase it so that I [would] be sure that we understand each other
. Then, I described, one more time, my exact configuration (i.e. the multisite network WITHOUT using the wildcard subdomain in purpose
), before to restate:
So, if I understand correctly, if I choose your first option (‘reverse the things done on our end’). I can’t fix my initial issue that is to have a proper, single redirect for the subdomain. Quick aside, this option (back to square one) is better than the current situation: none of the redirects (for the blog) is working, except for http://www to http://, and therefore, I have 3 instances of my blog (and a certificate error on https://www).
Here is the rest of my reply:
I want to be sure to understand the next part. You say that with Let’s Encrypt Wildcard SSL certificates installed on cogitactive.com, I don’t have to create a subdomain in cPanel (as I did originally, see above); adding the new site (i.e. subdomain) within the WP dashboard is enough. Do I understand correctly? This is what you mean by "1. Delete the subdomain name"? This looks too beautiful to be true. I trust you, but this is complex as you said and I made the mistake before to trust the other Gurus. Yet, I like your proposition. Just few questions to feel reassured: - There is currently no rule to force SSL with .htaccess (same before when it was not Wildcard SSL) and the main site, but not the blog (I had to use Enforce HTTPS), is still properly redirected (all to https://). Why I have to add the rule now? - If I delete my subdomain in cPanel, what will happen to my blog? Is it safe? Any change (WP dashboard, internet access…) to expect? I don’t want to lose my content! - Will this method work, even though I did NOT use the wildcard subdomain when I create my multisite network? It was clearly specified in the WP codex to create the subdomain in cPanel in that case. I don’t care how the ticket system work, I want you ([G]) to handle this ticket. I am not in a rush and I will wait for your answer. If, and only if, you answer my questions and convince me that your approach can work, then I will ask you to proceed with these "alternative steps" to "benefit from the WildCard SSL -- WordPress Multisite integration." !!!TO BE HANDLED BY [G] ONLY!!! Thank you for giving me hope. Best, Alexandre
Funnily, his response started with this: I will not make the reply as long as it was the last time
. To my question concerning the suppression of the subdomain in cPanel, he replied:
You can test that very easy, simply delete the subdomain (you can add it again if problem arises and point it back to the /public_html). What I guarantee you is that this change will not delete the content from the Multisite network and the change would easily be reversible . . . As you said no modifications can be done on our end so I have not tested that, but what I suppose is things will work out successfully.
To my concern about the efficacy of his method even though I did NOT use the wildcard subdomain when I create my multisite network
, he was a little less confident:
Since the site was converted later on I cannot tell for sure, basically in my experience I have encountered many problems when sites were not created as Multisite but converted as such later on. Still I advise you to test that. Nothing can be lost to a point changes cannot be reverted or backup restored. Another test you should do is to create a new test subdomain, but only from the Multisite backed [sic]. Then test if the subdomain will work out as expected for you, even though it is not created as subdomain in cPanel itself.
Anyway, as he asserted that I will not lose my content and that it will be possible to revert the changes thanks to a backup, I give him the green light to go forward with his approach:
Ok, you convinced me. YOU can try this approach. You will be more capable than me to react in case of problem anyway (but whatever you do, I want to keep the multisite without wildcard subdomain). I am not touching anything on my side to avoid interference. If anything goes wrong, just put the sites as they were before to start this ticket (that is the other option). Thank you for your help, patience and expertise. Good luck.
I will test everything and in the worst case scenario bring the sites to the initial condition when the ticket was not opened. However to check and test on your behalf I will need the Super Admin privileged user login details. Only then I can test in full aspect and ensure nothing will go wrong in the future.
The following day, I did my part (i.e. create a Super Admin user
) and encouraged him one more time: Good luck and thank you again for trying. This is very nice. I do appreciate.
Unfortunately, the outcome was not exactly as he expected:
I have tested everything on my end and I can surely say that something has happened at the time the Multisite was converted from default WordPress into a Network.
He expounded his attempts and the outcome. Specifically, he concentrated on making things work via the second method [he] presented [me] with few replies above – no subdomains in cPanel created but subdomain websites opening within the network
. However, he immediately added:
I am aware you said you are not a fan of the wildcard subdomain method, but as a Network setup with subdomain and mapped by WildCard SSL this should be working properly set like that.
Using a wildcard subdomain was not helping with the issue!
Not a fan? What an understatement! How many times in this ticket did I maintain that I had a multisite installation that was not using Wildcard subdomains and that I wanted to keep it that way? Even my green light (see above) included a reminder of this desideratum:
Whatever you do, I want to keep the multisite without wildcard subdomain.
Anyway, despite my insistence on refusing wildcard subdomains, he added one and then created a new subdomain – within the WordPress dashboard only. Unsurprisingly, the new subsite was accessible. However, the irony is that he still had to force HTTPS (using the SG Optimizer
plugin) and, guess what:
Now when I test with the redirection tool you specified it displays two redirects similar to the blog subdomain. Unfortunately I cannot tell if those are supposed to be like that, I believe I remember such behavior on another Multisite network I worked on in the past. I can assure you this is not enforced by the server, as the [new] subdomain is not existing (therefore there is no www DNS zone record and nothing that can enforce it’s initial load to be https://www.[new].cogitactive.com and then https://[new].cogitactive.com. I am not entirely sure of the checks done by the tool as well.
So, to summarize, no improvement as compared to my own configuration; and what’s worse:
In this way of testing (not creating the subdomains but using the wildcard one) the blog subdomain is not included in the list of created sites below the Network admin and upon its removal from cPanel the subdomain is no longer accessible. This functionality is not expected, however enforced by the conversion of the default and Network admin.
At least, he kept his (other) promise:
Since the main subdomain that is expected to work, is actually not behaving as expected with the Wildcard subdomain method I have done as promised and brought the condition of the Network as before the ticket was opened. Wildcard SSL is a history, the subdomain has its own SSL and the main site has different one. The enforce rules are set up . . . and the subdomain resolved with https:// by default. Now everything should be as it was – not affected by my tests and by any of the changes done by the colleagues.
And him to conclude:
I am sorry that I was not able to fully resolve the issue and I hope that we have regained your trust in us, since the changes done by the colleagues were only intending to help you out as much as possible – this is something that all of us in SiteGround are bound to do to the bottom of our bone-structure. I will close the ticket, however in case you need any additional help, we are here for you. You can always open a new ticket in case any other issues arise. You can also delete the super admin user you created for me.
Do you see it coming? Sure enough, my response has become quite predictable:
Thank you for everything, but before to close this ticket, there is one last thing. The site is not exactly as it was before. I assume this is due to the .htaccess rule you have added. What I mean is that before, the redirects for the main site were perfect (and this was without any rule). Now, both the main and the blog have the double redirect for the http://www. I prefer the way it was before, i.e. to have at least one site working correctly . . . So, please, remove this rule and let’s hope that it will look really like before. Thanks. Once this is done, and if everything is good, yes, this ticket can be closed.
I also told him that I will try to combine [his] .htaccess code with the one provided by [Z] (that is a redirect only for blog.cogitactive.com)
. Hoping he could help me with this task, I asked if [he] can provide me with this code, or tell me that it is not possible, either way, I would greatly appreciate
, but to no avail. Indeed, his answer was rather disappointing: You can test how things will behave with the SSL enforce code and the one provided by [Z] if you want to see the redirections eliminated
. In short, sort this out yourself!
Trying to finish on a good note, or at least to defuse any tension, I concluded with this:
Last, but not least, it is very nice from you to justify the actions from your co-guru. Please, excuse my heated reactions, but I was losing my nerves with this ticket. And don’t worry, I still believe that SiteGround is great!
His last reply was not like any of his previous, rather cold (never mind the aforementioned disappointing answer to my help request with the code):
The code in the .htaccess file is removed now . . . Thank you for your patience and understanding.
In keeping with Guruland’s custom, he rushed through things and the Enforce HTTPS was mixed up (ON for the main site and OFF on the sub)
. Anyway, I put it back to what it was (the opposite way round)
and replied politely that:
Now, everything looks like it was before I opened the ticket. Thanks again for fixing everything and for trying to find a solution . . . Thank you again. I will now remove the Super Admin from WP. I assume there will be no cleaning to do (database). It was a real pleasure to have you handle my ticket. Have a nice day and weekend.
Finally, not giving up, yet hopeless, I carried out a last attempt:
Everything looks back to normal. So, except if you want to provide me with the code (forcing SSL for blog only), the ticket can be closed indeed.
Would I never learn the lesson? Why did I ask? Would history repeat itself?
To be continued…
1 A version control system allows you to store incremental backups and the option to revert any of them. This also involves commenting the increments. Keeping track of your modifications goes beyond coding best practices. Not implementing such a management of changes is indeed risky. ^
2 This has to do with the following statement: knowledgeable agents who go through a 6-months training
. You will have to wait the end of the story, though, to know my opinion on that matter. ^
3 For the sake of transparency, I revealed my intentions to write a post about this story; a fair one taking into account what [he had] told me about my install and the actions of [his] co-guru
. In addition, I made it clear that I will not rate this ticket well, as [he] can imagine, but will rate [him] and some other Guru better (separately)
. ^