Finally I’m on vacation. Which ironically finally gives me time to migrate my website, something that I have been wanting to do for several months. While you might think that I spend too much time with WordPress, I have to say that there is nothing stressful to me about doing some of the things that I wouldn’t be able to otherwise – rest assured that I’m spending enough time sitting in the sun, dining and doing nothing. \u2600\ufe0f<\/p>\n
Alright, the reason I’m writing this post is simply that I would like to share a tiny bit about what I did. This website as well as all my other sites, more or less related (for example I have a cocktail blog<\/a> y’all should follow) are now hosted on SiteGround<\/a> ( <\/p>\n There were several reasons I chose SiteGround: Many friends from the WP universe had recommended me to go with them, so I compared them to other hosting providers. In the end, their amazing dev-oriented features in the GoGeek plan convinced me. I get SSH access with WP-CLI, Git, Composer and other neat command line tools available, a modern environment out-of-the-box with PHP >= 7.0 and automated Let’s Encrypt certificates. My personal favorite though is that they include Memcached in that plan, an external object cache that makes your website incredibly faster as it results in way fewer database requests. Something like this is a must-have for bigger websites and also if you have your own server to manage (like I did before on GCE). However, it’s very rare to find in a shared hosting plan, I personally didn’t see any other provider that offered this in a plan that cheap.<\/p>\n So yesterday night I migrated everything over. Since I have my entire setup in a multisite (more precisely a multinetwork) that uses Composer to manage all of its dependencies, this was a rather straightforward process. The other things I did were mostly the common migration tasks. I took care of exporting the database from Google Cloud SQL and importing it over to SiteGround’s MySQL server manually, and the media files I copied over as well. I added my domains in SiteGround’s cPanel and generated Let’s Encrypt SSL certificates for it. The last thing was to switch the nameservers for my domains (which I manage through Namecheap) from Google’s to SiteGround’s – and then it was done.<\/p>\n Something else that I’ve been wanting to do for a while is outsourcing my image files to an external object storage and CDN. The reason is improved performance on the other hand, a decentralized location for my media files on the other hand: If I ever migrate again, I don’t need to migrate my media; if I ever grow that I need multiple servers and load balancers, my media is already prepared (the latter is probably less important at this point, but don’t destroy my dreams! ?). Regarding the service to use, I trusted the quality of Delicious Brains’ WP Offload S3<\/a> plugin and decided to go with Amazon S3<\/a> and CloudFront<\/a> for storing the data. It took a bit of time to set this up properly (mostly a fault of Amazon though, not the outstanding plugin), so now all my media is located at a nice custom subdomain that points to CloudFront.<\/p>\n For completeness, let me list the most important plugins I’m currently using for my setup:<\/span><\/p>\n Now, there needs to be at least a very tiny bit of negativity in this post: Since I’m using a very custom WordPress setup (composer-managed, core in a subdirectory, custom wp-content directory, several must-use plugins and dropins), some of SiteGround’s advanced features do not work for me, such as its Git or Staging modules. However I handle these differently anyway, so I didn’t care too much.<\/p>\n That’s pretty much it already. The reason why I shared all this is that it is something major I’ve been wanting to do and now finally managed to do and that I hope to give you some inspiration, ideas or simply influence your decisions for hosting providers and plugins. Let me know if you wanna get more details on a specific topic!<\/p>\n","protected":false},"excerpt":{"rendered":" Finally I’m on vacation. Which ironically finally gives me time to migrate my website, something that I have been wanting to do for several months. While you might think that I spend too much time with WordPress, I have to say that there is nothing stressful to me about doing some of the things that […]<\/p>\n","protected":false},"author":1,"featured_media":962,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[69,97],"tags":[],"class_list":["post-963","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-updates","category-wordpress"],"yoast_head":"\ncapital_G_dangit()<\/code>!). Previously I had all these sites hosted with Google Compute Engine<\/a> for a little more than a year. This was an interesting experience for me that I had wanted to do, since it allowed me to learn a little more on how all the internals of maintaining a web server setup works, without being too<\/em> complicated. If you don’t know about Google Compute Engine, it’s basically a lot similar to Digital Ocean, however it runs on Google’s infrastructure and is part of Google Cloud Platform, which can be compared to Amazon AWS. Anyway, all of this helped me learn a lot, but it was also obviously more work than usually, so I’m happy I’m back at a regular host now that keeps things for me simple. Another reason that I’m happy that this experiment is now finally over is that it was quite an expense and oversized for my needs – at this point I’m good moving back to a shared host for this. I would have done that sooner, but then again, I needed a relaxed environment and time to do it.<\/p>\ngit pull<\/code> and composer install<\/code> on the new server, and the data was there. There were very few changes I had to make in the codebase: For connecting with the external object cache, I’ve been using the solid\u00a0WP Spider Cache<\/a> plugin by my friend JJJ. I had to tweak my object-cache.php<\/code> and advanced-cache.php<\/code> files a bit in order to set the correct port for my new environment. Furthermore the plugin expects you to have both the Memcached and the Memcache PHP extensions available, however SiteGround (as well as many other hosts) only provides the Memcached<\/code> class. Both classes are basically a variant of doing the same thing, with Memcached<\/code> being the more modern and better maintained one. Since the plugin only uses Memcache<\/code> for gathering detailed cache insights, I was quickly able to hack the requirement out there (please don’t do it, this was an “emergency”) – of course I also submitted a pull request for this in the WP Spider Cache GitHub repo<\/a>. While SiteGround provides its own plugin<\/a> for doing all the cache-related stuff plus a few other things, I didn’t want to use it as I think the way it works is pretty much terrible (it manually writes the object-cache.php<\/code> file for example!). So if you’re on SiteGround and are interested in using WP Spider Cache on it, feel free to ask for more details. Other things I did included removing my own WP Encrypt<\/a> plugin which I had used before to generate Let’s Encrypt certificates (obviously not necessary any longer since now SiteGround handles this).<\/p>\n\n