Abdalla
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: Client’s website Crashed/Critical ErrorYes. CSS goes in Appearance > Customise > Additional CSS, and for PHP use the Code Snippets plugin rather than functions.php.
Colours and fonts are the easy part though. The page content is tied to Enfold, so if you drop the theme you still rebuild every page by hand.
Abdalla
Forum: Fixing WordPress
In reply to: Client’s website Crashed/Critical ErrorPopup maker, that figures.
One thing before you go further though. 10Web’s own help pages say AI Builder sites shouldn’t be moved off their hosting — they say they won’t work properly elsewhere. https://help.10web.io/hc/en-us/articles/11594324041106 Might just be them protecting their platform, might be real. Either way you want to know before you give her a date.
So two roads. Point her domain at 10Web and leave the site where it is, nothing to migrate. Or bring it into Flywheel with the WP Engine Site Migration plugin and see what survives.
Either way do it into staging first. That’s what it’s there for, and it answers your original worry — her site stays up and the domain doesn’t move until you’ve seen the new one working.
Abdalla
Forum: Fixing WordPress
In reply to: Client’s website Crashed/Critical ErrorGood. Check which plugin it named though, it’ll still be sitting there deactivated.
On the theme — it isn’t WordPress that makes transfers hard, it’s the builder. Enfold uses Avia. Open a page in the editor, switch to text view, and if you see
[av_section]and[av_textblock]then that content belongs to Enfold, not WordPress. Swap the theme and those pages come out as shortcode text. You rebuild each one by hand. So count the pages before you give her a timeline.Also worth asking what she actually wants. If it’s just a different look, a child theme over Enfold does that with nothing to rebuild.
On staging, you don’t import. It’s a toggle in the Advanced tab of the Flywheel dashboard and it copies the live site for you. But that’s in the Flywheel account, not wp-admin, so you still need her in there.
One to watch. When you push back to live there’s a database overwrite tick box. Ticked, staging’s database replaces live completely. Unticked, files only. No merge.
What did the error say in the end?
Abdalla
Forum: Fixing WordPress
In reply to: Client’s website Crashed/Critical ErrorNo problem, happy to walk through it.
First thing before anything else — has she checked her email for the WordPress recovery message? When a site hits a fatal error WordPress sends one to the admin address, subject “Your Site is Experiencing a Technical Issue”. There’s a link in it that gets you into wp-admin while the site is still down, and it tells you which plugin caused it. Get her to search for that and check spam. If it’s expired, just load the broken site again and a new one goes out.
I’d try that before touching hosting at all. Most of the time that’s the whole fix — deactivate the plugin it names and you’re back up.
On Flywheel, don’t assume it’s lost. It resets by email like anything else. The usual problem is the account sits under the old designer’s email, not hers. Get her to search her inbox for Flywheel receipts — whatever address those went to is the account. And if the card is hers, Flywheel support will hand ownership over once she proves the domain and the billing are hers. That route works, it just takes a ticket.
Now the DNS part, and this is the one I’d stop and think about. Pointing the domain at 10Web doesn’t move her site, it moves the name. You’d end up with her domain showing an empty 10Web install, the real site still sat on Flywheel, and nobody able to reach either one. You can’t migrate what you can’t log into.
So the order is: get in first, take a full backup — files and database — then decide where it lives. Not the other way round.
One more thing worth asking: what does the error actually say? “There has been a critical error” on its own tells you nothing. Flywheel keeps PHP error logs in the dashboard and the last fatal in there names the file and the line. Nine times out of ten it’s one plugin after an update, or the host bumped the PHP version.
Post back what the recovery email says and I’ll help you through the rest. Better here than on a call — someone else will hit the same thing next week and find it.
Abdalla
Forum: Fixing WordPress
In reply to: Client’s website Crashed/Critical ErrorFlywheel changes my advice, so ignore the folder-renaming steps for now. Flywheel has no cPanel File Manager, and you do not need one.
Do this first. Flywheel backs up every site automatically, every night, and keeps 30 days. In the Flywheel dashboard open the site, go to the Backups tab, find the backup from before you started the migration, and press Restore. It asks for your password to confirm. Her site comes back as it was. Stop the bleeding first, then work out what went wrong with no clock running and no client waiting.
Now your actual question: yes, it is possible, and it is not really a transfer between two different things. A 10Web site IS WordPress. That is not where the difficulty is.
The difficulty is that a 10Web site leans on 10Web’s own plugins, and those expect 10Web’s servers underneath them. Move the site and they land somewhere those servers do not exist. That is the most likely reason this crashed, and it matches what I saw from outside: PHP dying on every request including wp-login.php.
So do it this way instead:
- Restore the backup, so the live site is up.
- In the Flywheel dashboard, Advanced tab, turn on Staging. It is free on every current plan. You get a separate staging site with its own URL and login.
- Do the migration into staging, never into the live site. Break it as many times as you like there.
- In staging, remove anything named 10Web, and any caching plugin. Flywheel does its own caching at server level, so a caching plugin or a leftover cache file from another host is the usual cause of exactly this crash.
- When staging works, use “Move staging changes to live site” in the Staging tab to push it over.
That last step is the whole point. You never touch the live site until you have already seen the new one working.
One thing worth knowing for later: if you ever do need to get at files on Flywheel, it is SFTP rather than a file manager in the browser. The credentials are in the site’s Advanced area, and you would use something like FileZilla or Cyberduck.
Forum: Fixing WordPress
In reply to: All plugin, theme and translation updates fail with error -1“Update failed: -1” is not a disk, file or permissions problem. That bare -1 is what admin-ajax.php answers with when a request fails its security check. It is WordPress saying “this request did not pass”, before it ever tries to fetch or write a single file.
Your own evidence already points that way. It fails instantly, it affects inactive plugins, and it affects translations. Those all travel through the same admin-ajax.php endpoint carrying the same security token. A storage or permissions fault would let the download start and then fail later with a different message, like “Could not create directory”.
I had a look at your site from the outside and ruled two things out for you:
- Site URL and Home both read wonderfulcreations.nl with no www, so the usual cookie and domain mismatch is not your cause.
- Your server clock is accurate to the second. These tokens are time-based, so clock drift would have done exactly this, and it is not that.
The test that settles it. Go to Dashboard > Updates (not the Plugins list), tick Elementor there, and press “Update Plugins” on that screen. That route is an ordinary form submission, not the AJAX one your other attempts used. If it updates from there while the one-click button still fails, the fault is proven to be in the AJAX path and not in your files or your hosting space.
Then to see the cause. Open your browser’s developer tools, go to the Network tab, and press the update button once. Find the admin-ajax.php request and tell me two things: the status code, and whether the response body is literally just -1 or a page of HTML. A bare -1 is WordPress’s own security check refusing. A page of HTML means something in front of WordPress, a firewall or a caching layer, is intercepting the request. On managed hosting with its own cache in front of wp-admin, a stale cached admin page hands the browser an out-of-date token and every update then fails exactly like this.
To get Elementor updated today regardless: download the Elementor zip from wordpress.org, then Plugins > Add New > Upload Plugin, and choose “Replace current with uploaded” when it warns you the plugin is already installed. That path does not touch AJAX at all.
Forum: Fixing WordPress
In reply to: Client’s website Crashed/Critical ErrorI had a look at corewell365.com just now and it narrows things down a lot.
Your files are fine. wp-includes/js/jquery/jquery.min.js still loads normally, all 87KB of it, so nothing was lost in the migration. What is happening is that PHP fatals on every request: the home page, /wp-admin/, /wp-json/ and wp-login.php all return a 500.
The useful part is wp-login.php. That page does not load your theme, and it is dying too, so the theme is not your problem. Don’t spend time on it. It is something that loads on every single request: a plugin, a must-use plugin, or a cache drop-in.
One thing worth saying about the error text you pasted. Where it tells you to check the site admin email inbox, that is not filler. After a fatal error WordPress emails a recovery mode link to the admin address, and that link logs you into wp-admin with the broken thing paused. Check that inbox and the spam folder first. If no email ever arrived, the fault is probably loading too early for recovery mode to catch it, which points at step 2 below.
From your hosting File Manager, in this order:
- Rename wp-content/plugins to plugins-off and reload the site. If it comes back, rename the folder back, log in, then reactivate plugins one at a time until it breaks. That one is your cause.
- Still dead? Look directly inside wp-content/ for advanced-cache.php and object-cache.php. These are drop-ins, not plugins. 10Web leaves them behind, they expect 10Web’s own hosting, and they load before plugins and before recovery mode, so every normal fix misses them. Rename both.
- Also check wp-content/mu-plugins/ if it exists. Anything in there runs whether it is activated or not.
- If it is still down, open wp-config.php, set define(‘WP_CACHE’, false); and look at the last few lines of that file for anything the migration added.
Which host is the site on? Tell me and I will point you straight to the File Manager and the PHP version setting on that particular panel.