Comment email notifications were the reason I moved this blog to a different host.
For a long time, the site was on an old shared hosting plan I grabbed during a limited promotion in September 2018. There were only ten discounted slots, and I managed to get one. The plan normally cost 98 RMB per year at the time, later dropping to 88 RMB, but with the lifetime 50% discount I only paid 49 RMB a year including renewals.
That host had three Hong Kong data center options back then, and I tried all of them. Anxun was the fastest. Broadband was close behind. The worst one by far was the CN Telecom Hong Kong room: painfully slow, then later it even started requiring user documents before service could continue, which forced a migration of customer data away from it. After that, only the Anxun location remained for the shared hosting service.
In most respects, that host worked well for me. The problem was one issue I did not take seriously until last month. I should also point out that I have not heard of other users running into the same thing, so I do not know whether my discounted plan happened to be subject to some separate restriction.
My blog uses a mail notification plugin that sends messages through a third-party mail platform over SMTP. I discovered that if the site made more than 10 SMTP requests in a day, the host would disable SMTP service. Looking back through my support history, ticket after ticket was just me asking for SMTP to be turned back on. If I submitted a ticket during the day, the wait was usually 1.5 to 3 hours. On May 5, 2021, I opened my tenth ticket just to have SMTP re-enabled. After that, the plugin made only one SMTP request, and by May 6 SMTP had been shut off again. I did not notice until after 9 p.m. I submitted another ticket, but support staff were already off work. Around 11 p.m., I started thinking seriously about moving the site.
So at 1:30 a.m. on May 7, I migrated the blog to SugarHosts' mini shared hosting plan in the Hong Kong location. Their higher-end shared plans were too expensive for what I wanted, so I chose the smallest one: 500 MB of storage, though both the backend and cPanel showed 1 GB, 50 GB of traffic, one domain, one database, and no dedicated IP. The price was 161.64 RMB for three years. Renewing at the regular rate would cost 240.84 RMB for three years. They offer renewal discount codes by lottery, so I can only hope to draw a decent one before the renewal date. Even without that, 241 RMB for three years is not especially expensive compared with many other shared hosting plans, so paying full price later would still be acceptable.
What surprised me most was support response time. No matter when I submitted a ticket, if I marked it high priority, the technical staff usually replied within 30 minutes.
After the move, I had a backlog of comments waiting for replies. I answered more than thirty in a single day, which meant more than thirty SMTP calls, and everything still worked normally.
I have no intention of moving this blog to a VPS. I do own VPS instances, but only for experimentation. In the past, I ran into a fatal problem on a VPS and lost data, which was enough to make one thing clear: I am not capable of independently managing important data on that level, and if something goes wrong, I cannot reliably solve it alone. For this blog, shared hosting is the safer choice. Years ago, support staff from another host said in a group chat that VPS is for tinkering, while an actual website belongs on shared hosting. That line stayed with me.
Once the hosting issue was settled, the plugin itself started misbehaving again. About three weeks after the migration, I found myself troubleshooting comment email notifications all over again.
How the plugin trouble developed
Over the years I tried a long list of email services: Tencent enterprise mail, QQ domain mail, NetEase personal mail, NetEase enterprise mail, SendCloud, and Alibaba Cloud's China site. I ran into all kinds of issues with them, some of which I had already complained about elsewhere before. In the end, what turned out to be the most stable option was an ordinary free overseas domain mailbox.
I also used several notification plugins over the years, including Comment To Mail, Comment2Mail, LoveKKComment, Notice, and Mailer. While the blog was on the previous host, it was running Comment To Mail 2.0.1. After some tweaking, it could send mail, though failures happened occasionally.
Once the site was moved, the plugin broke again. This had happened before too: when migrating from another shared host to the previous one, and when moving from shared hosting to a VPS. It did not matter whether the VPS used BaoTa, LAMP, or LNMP. I had figured out a strange workaround: disable the current plugin, enable a different notification plugin and configure it, disable that one again, then re-enable the original plugin. For reasons I still do not understand, this used to fix the problem on both shared hosting and VPS setups.
This time, that trick failed completely.
So I switched to Comment To Mail 3.0.1. This version abandoned sockets and used curl for asynchronous requests instead. It also logged sending activity, so the logs made it easy to see whether mail had gone out successfully. But a familiar problem remained: some requests simply did not send any mail at all, and resending required manually visiting the designated URL in a browser.
Figure 2 shows a typical portion of the send log. Two requests clearly failed to send. This was not rare; it happened often.
I even upgraded Typecho to the development build, 18.10.23, but that did not solve anything. I also tested the Mailer plugin made by a Typecho developer specifically for the development version, but email would not send when replying to comments from the backend. Then I tried the Notice plugin. In testing, it could send one email, but after that, new comments or replies triggered nothing at all.
Eventually I had to move on to Comment To Mail 4.x.
The version that finally worked
Comment To Mail 4.x had already existed for several years. It depends on either a cron job or an external domestic site-monitoring service to trigger tasks. I do not know how to write cron jobs myself.
I had used some domestic uptime monitoring services before, and the experience was awful. Even now, one of them still scans my site every two minutes from seven IP addresses and pulls some content, despite the fact that I deleted that account three years ago.
Then on May 24, it finally clicked: if domestic monitoring services could do this, overseas services should work too, and from past experience they did not scrape site content the same way. So I registered for StatusCake, a well-known monitoring platform. A free account can monitor up to 10 URLs, with a lowest check frequency of once every 5 minutes. Paid plans support more than 300 monitored URLs and checks as frequent as every 30 seconds. It can also monitor SSL certificate expiry and page speed for free.
Besides the web interface, it has a mobile app that handles many tasks as well, though with fewer features than the website. The app is refreshingly clean: no unnecessary clutter, no ads. Downtime alerts can be sent to multiple email addresses, and the app can push notifications too. It is easy to see why this service is often mentioned first in recommendations.
A blogger once pointed out that asynchronous triggers can fail at many different stages. PHP may be unable to access the site itself, or the connection may be closed midway through execution and kill the mail-sending process before it finishes. Those problems depend on the specific server environment. I was not able to identify exactly where they were happening in my case, so the only realistic approach was to avoid the whole chain of failure.
After switching to Comment To Mail 4.x and pairing it with StatusCake, the problem of missed email notifications finally disappeared.
The built-in template in Comment To Mail 4.x was more complicated than I wanted, so I replaced it with the template from Comment To Mail 2.0.1. Simpler felt better.
I really hope this is the last time I have to fuss over comment email notifications, unless I end up changing blog platforms entirely. I have already run several migration tests between WordPress and Typecho, and I even modified the style of the links page in a WordPress theme. That was all preparation for the possibility of moving platforms one day. Beyond that, I do not want to keep tinkering.
I am getting too old for this kind of thing.
A small hosting surprise
One detail did amuse me. When the announcement came out that the stable branch of CentOS was approaching end of maintenance, I started wondering what all these hosting companies were going to do about their systems. So I checked the server environment on both hosts with a phpinfo probe. It turned out they were using CloudLinux, a Linux distribution built specifically for hosting providers and bundled with cPanel licensing. So I had been worrying for nothing.
The other hosting accounts I once had with DirectAdmin had already expired, so I could not check what systems those providers were using.
Two small updates
-
A bug that prevented comments containing emoji from displaying properly has been fixed. Emoji can now be submitted and shown normally in comments, though the theme still has a rare bug under certain conditions.
-
Because GitHub had been experiencing intermittent interference this year, with disruptions every few minutes that made both access and submissions unreliable, the blog's related code and content were moved to Bitbucket on May 28, 2021.