Wordpress Migration Debacle - "All-In_One" (Surprise! _not_ all in one)

Phase 1: Files, Imports, and Table Prefixes

The migration process began with a manual approach: extracting a proprietary .wpress archive to isolate the core WordPress files and the SQL database dump. In modern WordPress architecture, the wp-content directory houses the actual unique site data. The first step was uploading the extracted plugins, themes, uploads, and languages directories to the new Hostinger environment. Extraneous developer files like package.json, redundant security lock files, and the default index.php were intentionally bypassed to maintain a clean file structure.

With the file foundation established, the focus shifted to restoring the MySQL database using phpMyAdmin. This immediately presented the first technical hurdle: the #1046 - No database selected error. This occurs when a raw SQL dump does not contain a USE database_name; directive. The database server receives the data but lacks the routing instruction on where to store it. The solution was strictly procedural: explicitly clicking the target Hostinger database name in the phpMyAdmin navigation tree before initiating the import.

Once imported, a critical structural conflict emerged. The Hostinger auto-installer had provisioned default tables using a wpwl_ prefix, while the imported tables carried a SERVMASK_PREFIX_ placeholder generated by the All-in-One WP Migration tool. To ensure future compatibility, the database required standardization to the default wp_ prefix. During the cleanup of the dummy wpwl_ tables, a #1090 - You can't delete all columns with ALTER TABLE error was triggered. This is a common phpMyAdmin interface trap; attempting to drop a table while viewing its internal columns causes the system to attempt a column deletion rather than a table drop. Navigating back to the root database structure view resolved this, allowing the safe removal of the dummy tables. Finally, a batch SQL RENAME query was executed to convert all SERVMASK_PREFIX_ tables to wp_. The resulting "empty result set" notification confirmed that the structural schema change was executed flawlessly without returning unnecessary data rows.

Phase 2: Configuration and The White Screen of Death

With the database schema corrected, the WordPress configuration file (wp-config.php) required manual alignment. The site initially returned an "Error establishing a database connection." This critical failure indicated that the DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST constants were still pointing to the legacy UK2 server environment. Updating these variables to match the new Hostinger credentials restored the connection, but immediately resulted in the infamous White Screen of Death (WSOD).

The WSOD is a deliberate security mechanism in PHP and WordPress designed to suppress fatal error outputs on production environments, rendering a blank page instead of exposing sensitive server paths. Standard diagnostics commenced: renaming the .htaccess file to rule out legacy Apache routing conflicts, and testing PHP version downgrades to rule out deprecation errors with older plugins. When neither variable resolved the issue, the investigation targeted the wp-content directory.

By systematically renaming the plugins and themes folders to force WordPress to disable them, the root cause was isolated. Disabling the active theme triggered a visible PHP notice, proving that the silent fatal error was originating from the theme layer. Furthermore, the wp-config.php file contained residual execution code from the Really Simple Security plugin, which was attempting to enforce strict session cookies on a mismatched domain state. Stripping this legacy code from the configuration file was a necessary sanitation step.

Phase 3: Bypassing the Missing Theme

Further inspection of the server directory revealed the precise cause of the WSOD: the custom theme folder was entirely absent from the extracted backup. The themes directory contained only default WordPress fallbacks (like twentytwentyfour and twentytwentyone). However, the freshly imported database was strictly instructed to load the missing custom theme. When the core software attempted to call functions from a directory that did not exist, the PHP execution crashed entirely.

Because the site was inaccessible via the standard /wp-admin dashboard, the active theme had to be overridden directly at the database level. WordPress stores the active theme configuration inside the wp_options table. To bypass the crash, a targeted SQL update was deployed:

• UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';

• UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';

By forcing the template and stylesheet variables to explicitly reference a default theme that verifiably existed on the server, the fatal error loop was broken. The front-end rendering engine successfully loaded the fallback architecture, bringing the text and database content back online.

Phase 4: Restoring Admin Permissions and Routing

With the site rendering visually, the next objective was dashboard access. However, authenticating via /wp-admin resulted in a restrictive "Sorry, you are not allowed to access this page" error. This is a notorious post-migration authorization failure directly tied to the earlier table prefix modifications.

WordPress user permissions are managed via a complex array of capabilities stored in the wp_usermeta and wp_options tables. These meta keys are strictly bound to the database prefix. Because the database was migrated from an environment using a unique numerical prefix (and temporarily held a SERVMASK_PREFIX_ label), the user account's administrative capabilities were orphaned. The core software recognized the username and password but failed to locate the wp_capabilities key, effectively demoting the administrator to a baseline subscriber with zero dashboard access.

To rectify this without manually searching for the exact legacy string, a wildcard SQL query was utilized:

• UPDATE wp_usermeta SET meta_key = 'wp_capabilities' WHERE meta_key LIKE '%capabilities';

• UPDATE wp_usermeta SET meta_key = 'wp_user_level' WHERE meta_key LIKE '%user_level';

• UPDATE wp_options SET option_name = 'wp_user_roles' WHERE option_name LIKE '%user_roles';

This operation dynamically located any legacy permission keys and forcefully realigned them to the standardized wp_ prefix. Dashboard access was immediately restored.

The final operational anomaly was a site-wide 404 error affecting all subpages, a direct consequence of the .htaccess file being renamed during the WSOD diagnostics. Apache relies on this file to map clean URLs (Permalinks) to the internal WordPress routing index. Navigating to the Permalinks settings page in the dashboard and executing a blind save forced the application to dynamically generate a pristine .htaccess file with correct Hostinger routing rules. The subpages resolved flawlessly, completing a rigorous, manual, end-to-end server migration.

Why Toroidal Transformers Hate Long Cables (and Kettles!) - Subwoofer Death 1.0

If you mess around with DIY audio long enough, you're eventually going to let the magic smoke out of something expensive. Recently, my trusty Intimidation SUB-15A active subwoofer decided to give up the ghost mid-session, letting out that unmistakable, gut-wrenching smell of burning electronics.

What followed was a deep dive into pulling amplifiers apart, the brutal reality of voltage drops, and figuring out how to fix the problem so you don't have to waste time or money doing the same thing.

The Autopsy: Melted Copper and Silent Assassins

I cracked open the back plate of the sub, hoping for an easy fix like a blown fuse. No such luck. Instead, I found the massive, heavy toroidal transformer completely melted. The copper wires were charred black and the whole thing looked like a total bag of spanners.

But transformers rarely just commit suicide for no reason. Usually, they melt because something else downstream has gone wrong and is pulling crazy amounts of current. The real culprit? The IRFB4227 power MOSFETs. Even though they looked absolutely pristine on the outside, they had likely failed silently, melting internally and creating a dead short to ground. The transformer tried its best to push massive current into that short, overheated, and literally roasted itself to death in the process.

Unrelated Environmental Consultancy Services: 

Flood Risk Assessment 

Lux Contour Map 

The Eureka Moment: The 50-Meter Voltage Drop

I was scratching my head as to why the MOSFETs shorted in the first place. Then I took a hard look at my power setup. I was running a 2000W peak audio rig (two 500W subs and four of my usual TPA3116 2.1 boards) over a single 50-meter, 1.5mm² extension cable. Oh, and someone occasionally switching on a 3000W kettle on the exact same circuit.

Here is the brutal math:

• Running that much current over a 50m cable (100m of total copper wire) creates about 1.33 ohms of resistance.
• During heavy bass drops, the system pulls almost 9 Amps.
• When the kettle clicks on, the total draw spikes to over 21 Amps.

That massive current draw over a thin, long cable results in a severe voltage drop. The 230V mains power from the wall was likely falling into the 190V range by the time it actually reached the gear. Not good. . .  and something I had never even considered. 

Why the Top Speakers Survived (And the Sub Didn't)

So why did my top speakers (powered by those cheap TPA3116 boards) survive just fine, while the heavy-duty subwoofer died?

The TPA3116 boards run on recycled laptop power bricks. These are Switch Mode Power Supplies (SMPS) designed to accept anywhere from 100V to 240V. When the kettle kicked on and the voltage dropped to 190V, the laptop bricks actively regulated themselves and kept pushing a perfectly stable 24V DC to the boards. They didn't even notice.

The Intimidation subwoofer, on the other hand, relied on that old-school toroidal transformer. A toroid is basically just a dumb coil of wire. When the mains voltage sagged, the internal amplifier voltage sagged right along with it. The amp was starved of power, started violently clipping the audio signal into square waves, and forced the MOSFETs to overheat until they shorted out and took the transformer down with them.

The Fix: Bodging in a TPA3255 Plate Amplifier

I could have dropped £100+ on a replacement toroidal transformer, but there was a 99% chance the shorted board would just blow the new one up instantly. Instead, I decided to abandon the burnt board entirely.

The solution? A drop-in TPA3255 Active Plate Amplifier. Here is why this £40–£50 upgrade is a much better option for a DIY mobile rig:

• Built-in SMPS: Just like the laptop bricks, this plate amp has a digital Switch Mode Power Supply. It can handle voltage sags on long cable runs and won't completely melt down if someone fancies a cup of tea.
• Perfect Power Match: It's rated for 600W at 2 ohms, or 300W at 4 ohms. Because my 15" driver is 8 ohms, it naturally scales down to deliver about 150W of clean Class D power. Perfect for keeping up with the rest of my setup without blowing anything up.
• Plug and Play: It has XLR inputs and an adjustable low-pass filter, so it’s basically ready to go out of the box.
• Lighter: Ditching the massive iron transformer makes the whole thing way easier to lug around.

All I need to do is cut a bit of plywood, do some frighteningly ugly woodwork with a jigsaw to make it fit the back of the box, and wire it straight to the speaker cone.

The Takeaway: If you are running long extension leads at DIY gigs, keep an eye on voltage drops, and maybe reconsider heavy iron transformers. Modern Class D chips and SMPS are much better at handling sketchy power. And for the love of god, plug the kettle in somewhere else!

---

More Questionable DIY from Dorky Thorpy

• Check out more of my DIY Audio and PA hacks
• Smoke and Sparks: More Electronics Autopsies
• Want to see some sketchy welding? Check out my Long Tail Cargo Bike Builds!