Building a migration engine so I could actually test the new player properly
I have been looking at reducing the number of different video players I use across my sites. I already have Presto Player licences, and I also have access to other players, but what I really wanted was one base player I could standardise around without having to think about which licence I had available for which site.
That is what led me to TruePlayer. I bought the unlimited lifetime licence, but I want to make one point very clear at the start. This is not a recommendation for TruePlayer. I have not used it for long enough to recommend it, and moving TechArticles across is actually part of that test. TechArticles has a decent number of videos, most of them YouTube embeds, spread across a lot of posts and added in a few different ways. That makes it a much better test than installing a player on a clean demo site and clicking around for half an hour.
The bit that normally stops a migration
The player itself was not really the difficult part. The thing that had put me off moving before was the migration. I did not want to manually recreate a library of videos and then work through old posts, replacing blocks one by one.
While looking through the TruePlayer code I found the beginnings of Presto import functionality. It was not exposed as a complete migration tool, but enough of the structure was there to give me a sensible starting point. So rather than write a one-off database script, I built a small WordPress plugin around it.
The important bit for me was that it had to be repeatable and safe enough that I could run it on a copy of the site, see exactly what it planned to do, and then run the same process live when I was happy.
Stage 1: migrate the video library
The first stage deals with the Presto Media Hub. Presto stores reusable videos as its own post type, and the migration plugin reads those entries, pulls out the player source and the settings that have a sensible equivalent, and creates matching TruePlayer videos.
For the reusable library items, the migrator keeps a link between the old Presto ID and the new TruePlayer ID. It uses TruePlayer’s own import marker format, so an imported item can be recognised again rather than duplicated if the process is run more than once.
Example import marker: _trueplayer_imported_from = presto:{PRESTO_ID}
On the TechArticles migration I had 66 valid Presto videos. I ran Stage 1 as a dry run first, checked the detailed output, then ran it live. Once complete I had 66 mapped TruePlayer videos ready for the second half of the job.
There was also one useful edge case while testing. One Presto library entry had no usable player content in it at all. Rather than inventing a source or creating a broken TruePlayer item, the migrator simply reported it as skipped. That is the sort of behaviour I prefer in a migration tool. If it does not know, it should tell me rather than guess.
Stage 2: replace the embeds in posts
Migrating the library is only half the problem. The old posts still contain Presto shortcodes and Gutenberg blocks, so Stage 2 scans the WordPress content and replaces those references with the matching TruePlayer block or shortcode.
The first version handled the common reusable Presto block and shortcode references. During the real migration I found one direct YouTube block that had been added differently. That post was not picked up because it used presto-player/youtube rather than a reusable Media Hub reference. I extended the migrator so direct YouTube, Vimeo, self-hosted video, audio and Bunny blocks can also be detected.
For a direct inline video there is no existing library ID to map, so the plugin creates the TruePlayer video when needed, stores its own import fingerprint, and then replaces the inline Presto block. That also makes the operation idempotent, which is a horrible word but an important feature. Running the migration again should not keep making duplicate videos.
Dry runs, output and logs
I originally built the migration around WP-CLI, because it was the quickest way to test the logic. It worked, but once I started using it properly it was obvious a GUI was going to be easier to explain and easier to use.
The current plugin therefore has a Tools page in WordPress with buttons for each stage. Dry run is enabled by default, detailed output can be switched on, and each run can be downloaded as a log. Before changing anything I can see the exact post IDs, titles and replacement counts the migration expects to touch.
On my full run, Stage 2 reported the posts it intended to update, zero unmapped references and zero failures. After the live run I simply ran the dry run again. It came back with zero changes, which is a very simple sanity check that nothing known to the migrator was left behind.
Backing up the original post content
One thing I did not want was a migration that left me with no easy route backwards. Before Stage 2 changes a post, the original post_content is saved into post meta:
_ptt_original_content_v1
That backup is deliberately kept after a successful migration. It takes very little space compared with the value of having the original block markup available if I find a problem later.
I have since added a third stage to the plugin for this. Stage 3 can dry-run a restore, restore selected post IDs or all backed-up posts, and separately remove the migration backups when I am finally happy I no longer need them. Deleting the backups is a separate action with an explicit confirmation because cleanup and rollback are two very different things.
A WordPress quirk I hit while testing
The testing site also threw up a problem that had nothing to do with Presto or TruePlayer. A cache purge handler on the site was hooked into normal post saves. When the CLI version updated a post using wp_update_post(), the purge routine printed an HTML response and interrupted the migration.
For the GUI migration I changed the Stage 2 writer so it updates only the post content directly, updates the modified timestamps and then clears WordPress’s post cache. That avoids firing unrelated save_post behaviour while still making the content change cleanly. It is a good example of why I wanted this to be a migration engine rather than a blind search and replace.
What the migration currently handles
Presto Media Hub reusable videos into the TruePlayer library.
Presto reusable-display Gutenberg blocks.
Presto Player ID shortcodes.
Direct YouTube blocks.
Direct Vimeo blocks.
Self-hosted video and audio blocks.
Bunny video blocks.
Dry-run reporting before writes.
Detailed in-browser output and downloadable logs.
Original post_content backups for rollback.
Stage 3 restore and backup cleanup.
This is still a test, not a recommendation
I want to repeat this because it matters to me. I am not moving TechArticles to TruePlayer because I have decided it is the best player or because I am recommending everyone else should buy it. I bought it myself, this is not sponsored, and I am not being paid to use it.
I am moving TechArticles because I need a real site to test it on for a prolonged period. There are enough videos here, enough older posts and enough different ways I have embedded things over the years to expose problems that a clean test site probably will not.
That has already happened. During the migration, I found the one direct Presto YouTube block that the first Stage 2 logic missed, and after migration I found a TruePlayer facade colour issue where the initial play button did not use the configured accent colour until the full player loaded. A small CSS override fixes that for now, and I have treated it as a product issue rather than hiding it, and submitted a bug report.
That is really the point of this whole exercise. The migration plugin gets me past the boring part, which is moving the data and updating old content, and lets me spend the next few weeks or months finding out whether TruePlayer is something I actually want to standardise on.
Where the plugin goes from here
The plugin started as something I needed for one site, but it has turned into a reasonably useful little migration tool. I will put it on GitHub so anyone in the same position can look through the code, test it on a staging copy and use it if it fits their setup.
As always with something that touches post content, take a proper database backup first and use the dry runs. The rollback data is there for a reason, and I would keep it until you have spent enough time checking old posts and different video types.
For me, the interesting part is that the migration turned out to be far less difficult than I expected. Once the two data models were understood, the job was mostly about mapping IDs safely, dealing with the different block formats and making sure I had a way back if something went wrong.
Now the actual test starts.
I will update this article when I have released the public repo
