Open Thinkering

Menu

Tag: migration

One does not simply move off Substack

Posted on by Doug Belshaw

As I’ve previously mentioned, I’ve decided to move away from Substack for my Thought Shrapnel newsletter. This is due to a fundamental disagreement with the platform’s hosting policies, particularly its accommodation of Nazi content.

In my search for a different platform, I’ve noticed that many people are migrating to Ghost. This seems particularly true for those with some technical background. Unlike Substack (an all-in-one platform for writing blog posts, sending newsletters, and posting social network-style updates) other options such as Ghost require a more hands-on approach to configure.

After looking at different options, and being advised by my network, I chose micro.blog. It looked like a simple, indieweb choice that is compatible with ActivityPub and can automatically send out a weekly digest of posts. The $10/month plan seemed ideal, and I began by importing posts from WordPress.

However, I encountered several hurdles:

  • Importing: the sheer volume of posts on Thought Shrapnel meant that the exported file was too large for the micro.blog importer, so I had to find a tool to split the WordPress file into smaller segments.
  • DNS: after adjusting the DNS settings to redirect to micro.blog, I experienced issues with email settings.
  • Email: despite moving everything to Cloudflare in an attempt to fix things, a problem arose with receiving verification codes, meaning I could no longer log in to micro.blog and complete the migration.

These challenges made me question whether individuals with less technical expertise could easily navigate such a migration? It’s not just following instructions, but troubleshooting, and indeed having the mental model of what’s going on.

Faced with these issues, I’m contemplating a return to MailPoet, an email newsletter plugin for WordPress I used before moving to Substack. However, it’s not without its quirks, such as random unsubscriptions and the need to comply with new email sender requirements from Google and Yahoo.

I feel like using platforms like Substack is akin to driving a car without needing to understand its mechanics – you just fill it up and go. Migrating to a different platform requires a deeper understanding, which is like someone interested in the ins-and-outs of car engines and maintenance.

These experiences highlight the complexity involved in migrating from an easy-to-use platform like Substack to alternatives that involve some technical input. You can’t tell people to just move off Substack. There are network effects. For some people, we’re talking about their livelihood. While there are more technical people who can fix this themselves, and better-off people who can get others to sort it out for them, what about the majority in the middle?

Personally, I’m determined not to return to Substack, but I’m still exploring the best way forward. To be honest, I just want something that works. Finding time to post to Thought Shrapnel is challenging enough, without all this additional drama.

Climate ch-ch-ch-changes

Posted on by Doug Belshaw

I can remember as a child my mother picking blackberries while waiting to pick me up from school. They’d appear just before ‘blackberry week’ which was literally the name people gave to October half-term.

Now, 30 years later, blackberries appear around 10 weeks earlier here, ready to be picked in mid-August. That makes for tasty summer holiday desserts, but leaves me slightly concerned about the pace of climate change.

In the last week, we’ve had scorching hot weather in the UK, followed by intense thunderstorms which led to flooding that derailed a train.

Of course, things are worse on many fronts elsewhere; there are plenty of people, especially refugees, who are desperate to seek asylum in our country. Yet, instead of thinking in a joined-up way about the global climate emergency and the effect it will have on migration over the next 30 years, the inept UK government sends in the Royal Navy.

Within my lifetime, those in charge have missed so many opportunities to steer us of disaster, meaning that now we haven’t got long to avert climate catastrophe. I just hope that elections over the next few years replace the emotional toddlers we’ve got running the show with some grown-ups committed to action.

This post is Day 31 of my #100DaysToOffload challenge. Want to get involved? Find out more at 100daystooffload.com

How to restore a very large MySQL file without errors.

Posted on by Doug Belshaw

File this one under ‘geeky’ and ‘stuff that took me a while to find out so I’m sharing it with others’.

I *Heart* MySQL

Image CC BY-SA Kevin Severud @ Flickr

During the couple of days I’ve been off work ill this week I’ve transferred teaching.mrbelshaw.co.uk from a UK-based webhost to Bluehost (which hosts this, among other sites). It was about time my former blog (active 2005-2007) had some TLC as it was becoming progressively broken.

I had a 42MB MySQL database backup – the file that contains all of the blog’s important information (post and comment text, etc.) – but every time I tried to import this into a new database at Bluehost I kept getting timeout errors. It was then that I remembered I’d had this problem before and I’d managed to solve it with some sort of script that breaks the file up into smaller chunks to feed to the database incrementally.

After a while searching, I came across it again. It’s called BigDump and the process, if you’re familiar with installing WordPress manually, is fairly straightforward:

  1. Go into phpMyAdmin and execute DROP_TABLES on your target database.
  2. Download bigdump.zip from http://www.ozerov.de/bigdump.php and extract the zip file.
  3. Open bigdump.php using Notepad, TextEdit, or similar. Edit the relevant lines to point towards your database, username and password.
  4. Create a folder called dump on your web server and upload both bigdump.php and your MySQL database into that folder.
  5. CHMOD the folder recursively to 777 (i.e. give read/write permissions when accessed via the web)
  6. Access the script via (e.g.) http://yourdomain.com/dump/bigdump.php
  7. Follow the instructions!

This should lead to your database backup being successfully inserted into your new database. You can then use the data in whatever web app (i.e. WordPress) that you want! 🙂

css.php