A (SiteGround) ticket to hell concl’d

Previously on the CogitActive Saga:
A solution! I did not fully comprehend his technical explanation, but it was convincing enough to get me interested. Yet . . . I was rather dubious about this approach . . . and, as anticipated, it did not work. Not giving up, yet hopeless, I carried out a last attempt…

… starting from the point where the story stopped.

The ticket

From “Senior Technical Support” to “Technical Support Supervisor” and back again, it took three Gurus to fix the mess of Guru [S] and bring me back to square one. An unexpected journey through powerlessness, expeditiousness and hope! Would it end here?

Support Guru R (day 5)

Once again, I experienced the competence of the upper level:

I am glad to see that [G] has manage to assist you up until now and that you are satisfied with his work. I’ve read throughout the ticket and I can see that my colleague [Z] has provided you with partially correct rule that will match and force only the blog website to https.

After many infructuous requests for this rule (see A (SiteGround) ticket to hell cont’d) – not mentioning the numerous failed tries from the other Gurus – I thought I would have to sort this out myself. I didn’t had to; this Supervisor gave me the code which would force https only if the requested URL contains blog.cogitactive.com or www.blog.cogitactive.com to https://blog.cogitactive.com/. The rule was also including a condition that the redirect should work only on requests that are over HTTP. Here is that supposedly unachievable code:

RewriteEngine ON 
RewriteCond %{HTTPS} off 
RewriteCond %{HTTP_HOST} ^blog.cogitactive.com [NC,OR]
RewriteCond %{HTTP_HOST} ^www.blog.cogitactive.com [NC] 
RewriteRule ^(.*)$ https://blog.cogitactive.com/$1 [L,R=301]

Five lines of code (and what is more an explanation of its functionality) that would pave the way for forgiveness (regarding the disastrous handling of this ticket). Admittedly, Guru R was not answering the core question of this ticket – 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, not willing to open Pandora’s Box again, I would have to be content with this solution.

If I could not fix the canonical URL functionality for the blog, at least, I could try to achieve the same result with a 301 redirect.

The time for fixing things the proper way was indeed over (at least for now), and I added the code to my .htaccess file (at the very top). For the first time since I opened this ticket, something worked as projected. Not only the rules did not break anything – a real “first” – but also they worked PERFECTLY (i.e. better than the HTTPS Enforce tool). By this I mean that all the redirects for the blog were as desired, namely direct – like for the main site (see A (SiteGround) ticket to hell). Given the outcome, I expressed my gratitude (with a slight bitterness, though) to Guru R:

Your code resolves my issue perfectly. For this, I am grateful. I wish you had provided me with the code earlier (as a first answer to the ticket) that would have spared me a lot of frustration, stress and trouble. For this reason, I will keep the overall bad rating given the misadventure of this ticket. Yet, you can change the status of this ticket to RESOLVED.

Support Guru V (day 6)

I don’t know if my Thank you [R], thank you so much! . . . This is a happy end! did ever reach Guru R. One more time, I was introduced to a new Guru; this time from the “Senior Technical Support Team”:

You are most than welcome. I happy to hear my colleagues assisted you. I will mark the ticket as closed. If there is anything else that we can help you with, please do not hesitate to contact us back anytime by submitting a new ticket in the proper category!

I will think twice before to go back on that track: Thank you, but no thank you! Anyway, this nightmare was over; I was done with this ticket.

Ticket RESOLVED!

Back from Hell

I didn’t wait long to submit my rating of this miserable ticket – a mediocre two stars. First, they patently ignored my claims that the blog was not working properly (or at least not like the main site). I kept explaining my problem, maintaining something was wrong – four times to be precise – before Guru A finally deigned to accept that there was indeed a problem. Second, they tried some quick, superficial fixes (redirect rules in .htaccess) instead of tackling the core issue. Not a single Guru – with the notable exception of Guru G – bothered to address my concern. Thus, I still have no explanation whatsoever concerning the dysfunctional – yet limited to the blog – built-in canonical system.

Our customer support is available 24/7 and consists of over 350 knowledgeable agents who go through a 6-months training.SiteGround

Third, despite their multiple attempts, they were not able to come up with such a quick fix (redirect rules). Mercifully, their supervisor (Guru R) stepped in (after five days of struggle) and accomplished this supposedly unmanageable task. Fourth, in keeping with the previous idea, they blatantly bullshit me in order to cover up their incompetence: The task that you are trying to achieve will require different configuration of your network. Last, but not least, they messed up my websites, and what is more my whole installation, by doing things on their own initiative. Despite my insistence on refusing wildcard subdomains, they ignored my desideratum – for [my] convenience.

Of course, none of this would have happened if I had followed this sound advice:

If you are unsatisfied with the resolution from the ticket channel, you can ask to have your ticket escalated to a supervisor.SiteGround

While the above critics apply to the ticket as a whole, it is important to understand that eight Gurus were involved (each with a different level of implication). Clearly, they are not all tarred with the same brush. In particular, two of them stand out in terms of merit, namely Guru G² and Guru R; but this is more than I can say for some others. Here is the individual rating (on a one-to-five-stars scale):

Now, this unfortunate ticket is not so different compared to other support channels that I went through under other circumstances (i.e. not limited to SiteGround). Typically, they receive (too) many very basic questions, often already addressed in the available documentation. Indeed, most people do not bother searching through the Tutorials or Knowledge Base (in the case of SiteGround), and what I call the front line (of Support Gurus) is here to deal with those demands. Given this reality, I do understand the necessity to have many agents – over 350 knowledgeable agents who go through a 6-months training.

What to expect from a 6-month training, though? The key point, here, is probably to be found in the definition of “knowledgeable”; I am not questioning the “intelligence”, but the “well informed” part of the definition. This concern becomes particularly relevant when the ticket involves WordPress Multisite. The mere mention of this feature, which adds an indubitable layer of complexity, should be enough to bypass the aforementioned front line.
One should acknowledge one’s lack of expertise when facing more challenging problems and hand over the ticket to a supervisor. Interestingly, one of the cons against using Multisite (that I read about when pondering my decision to implement it or not) is the fact that support teams might not be qualified to handle this feature. Add an unusual configuration (e.g. without wildcard subdomain) to this and you have a recipe for disaster.

The aftermath

My stress and frustration aside, this ticket leaved its marks. I thought Guru G cleaned up the mess and let my account EXACTLY as it was before this misadventure. I should have known better (given the many time I told the Gurus that NO it is not as it was before).

AWStats

Sure enough, two weeks later, when I accessed AWStats (the open source Web analytics reporting tool), I noticed a new domain entry, namely the wildcard subdomain. Logically, the statistics reported there were limited to the day 5 of the ticket. Still, Guru G should have taken care of putting everything as it was before, removing all traces of his modifications.

Fortunately, the procedure to remove this unwanted domain was relatively straightforward³. Using File Manager, I navigated to the /tmp/awstats folder and deleted the .conf file associated with the wildcard subdomain. I did the same for the only monthly record associated with this domain (i.e. the .txt file). It was reassuring to see that neither file had been modified since that infamous day 5.

Even though Webalizer (another web log analysis software) is not available in SiteGround cPanel (probably given its not-so-recent last release: August 26, 2013), there is still a /tmp/webalizer folder. As anticipated, the wildcard subdomain was there too. However, given my lack of familiarity with this software, I didn’t dare to tinker with anything.

Database

You might recall that my question I assume there will be no cleaning to do (database) was not heeded. Therefore, my next guess (for where to look for other breadcrumbs) was the WordPress database. I thought I managed to remove the [G] user (after unchecking Grant this user super admin privileges for the Network in the WordPress dashboard). Indeed, he was not in the wp_users table anymore, but apparently, he was still haunting my database.

There was no table related to the subsite that G created – a good thing. However, when I run a search for the subdomain he added, I found two matches in wp_usermeta. Similarly, there was one match for the [G] user I created in the wp_registration_log table. Concerning the former table, I was able to find online accounts of deleted users whose information remained in the database (an issue probably linked to a Multisite installation). With this information in mind, I deleted these entries at my own risk; 32 rows to be specific (16 for each of the two user_id identified earlier). I took the same approach for the wp_registration_log table, which records the user who registered a new site once it has been activated. Clearly, there was no reason to keep this admin user entry. At the time of this writing, I did not notice anything bad resulting from my “clean-out”.

What else?

While trying to figure out what else should be done, I discovered that removing a subdomain using the cPanel tool (i.e. Subdomains) is only affecting the DNS entries. Indeed, the web files/data are not removed by the system and you have to remove them manually (using File Manager, for instance). Now, when I searched all my files for “wildcard”, there was nothing to be found – except for those aforementioned Webalizer folders and a Raw Access Log.

However, many online sources were referring to files and directories I could not find using File Manager. Similarly, others were mentioning the Apache configuration file httpd.conf that should be located in the /etc/http/conf folder. The problem is that to access those, you need root access, which is understandably not available on shared hosting plans. Hence, any residual bits of the wildcard subdomain are beyond my reach.

There is always more!

I really thought I was done with this matter. Still, notice that I didn’t add “once and for all” to this statement. Few weeks later, when my concern had shifted to another topic, I encountered a repercussion from this nightmare.

Imagine my bewilderment, when trying to access my website I was issued a warning like: this site is not secure. Why? What happened? Panic had set in before I could read the word “certificate”. Thankfully, the “ticket to hell” was still a fresh memory; it did not take me long to figure out this has to do with HTTPS and the SSL certificate. Sure enough, while the latter is supposed to be renewed automatically (by SiteGround), it did not. Again, I don’t know all the modifications the Gurus experimented with, but obviously they did something wrong – the auto-renewal feature was down.

Anyway, I immediately renewed (manually) the Let’s Encrypt certificate and the warning message vanished. When the same things happened to the blog few days later, I was ready to handle the situation. Fortunately, the simple fact to renew manually the SSL certificates was enough of a fix. Things got back to normal!

Conclusion

In fact, I don’t even know if now everything is as it should be. Granted, I haven’t encountered other repercussions or bugs since. Furthermore, the duplicate content issue (for the blog) is under control with the 301 redirect rules in my .htaccess and both sites are now working properly – seemingly! On that matter, I am appreciative that Guru R provided a (temporary) fix to the redirect problem.

Yet, the main issue (i.e. with the WordPress built-in redirect) remains unresolved! The only person who tried to provide some answers was Guru G; still his attempts were infructuous. Actually, his justifications even cause me to doubt the integrity of my WordPress Multisite. Did something wrong happen⁴ – as he asserted – during the conversion? Sadly, the “Technical Support Supervisor” did not comment on this statement. The point is that I don’t have another installation to compare with (being limited with my StartUp plan) and, as you can imagine, I haven’t found any information on that matter – not yet, at least! Hence, I still don’t know whether the issue I experiment with the subdomain is normal (i.e. not a bug) or an actual dysfunction.

As a bitter-ender, I will keep searching for answers. At least, I learned that neither wildcard subdomain nor wildcard SSL certificate are of any help here. I still believe that there is something not properly set with the subdomain (or different from the main site) and that this is affecting the proper functioning of the redirect_canonical() function⁵. I wish I could access the httpd.conf file to check some hypotheses of mine…

Who knows, perhaps, I am looking for a chimera and will never find this long-desired solution? Still, any information on that matter is greatly appreciated. Thank you for your help!

The End?

---

¹ As explained after, I did not even start to search for this code since I was trying to fix the canonical URL functionality for the blog. In my mind, this 301-redirect approach remained a means of last resort. At the time of this writing, I – as strong-willed as I can be – am still looking for a better solution. ^
² As stated in the escalation e-mail I sent to SiteGround, I was desperate until [G] came to the rescue. Not only he put everything back as it was (i.e. as before the damaging manipulations), but also tried to find a solution to my initial problem. Admittedly, he could not provide me with answers, but it’s the thought that counts. He also ignored my request not to use a wildcard subdomain and tried it anyway. However, the take-home message is that [G] saved the day from what could have been a ‘ticket to hell’. I want to thank him for the amazing support he provided. ^
³ See AWStats Remove Unwanted Stats and Domains. ^
⁴ Could this be related to the fact that my installation was not properly configured to work with HTTPS before to create the Multisite network? Shame on me! Or, should I blame the HTTPS Enforce tool for its misleading claim? ^
⁵ This function, introduced in WordPress 2.3, redirects incoming links to the proper URL based on the site url. I assume that “site url”, here, refers to Site Address (URL), aka Siteurl, which I properly set (see Making my website work over HTTPS – the proper way). ^