Today I’m troubleshooting an issue on a site that I just migrated across from another server. The site is fine but when my client tries to upload anything to the Media manager, she gets this error:
Unable to create directory uploads/2022/05. Is its parent directory writable by the server?
Here’s the checklist I ran through in order to resolve this issue for her.
Check the sizes of the files that are being uploaded.
In this case the files are 195 KB (a jpeg) and 685 KB (a PDF) respectively.
Attempt to upload these same files to recreate the issue
On doing this the error is as shown above. The max file size is current 512 MB so no issues with a limit set on the file sizes.
Check the media folder settings
Go to Settings > Media and check the setting for the Uploads directory. Check it matches the location of the Uploads folder on your server (the default is/wp-content/uploads).
NOTE: Sometimes the media folder settings field isn’t visible in the Dashboard, in which case you need to use a code snippet to add a short section of code to the functions.php file defining the uploads directory location.
Lucky for me in this case it was all sorted by Step 3: the upload directory referred to a folder structure from the old server that did not exist in the new one. However, I did have a moment of panic when, after changing this, the uploads were still failing with the same error. If this happens… clear your cache! I have LiteSpeed cache running on this site so did a full clear and then tried the upload again: all good (phew.)
Additional steps to check after this (if Step 3 hadn’t resolved my issue) would have been to check the Uploads folder had read/write permissions.
Check the folder permissions
You do this via FTP or directly on the server. In cPanel, click on the File Manager and select the folder then click Permissions. Change the settings to that User, Global, and World are all set to have full permissions (Read, Write, and Execute with the code 777). Test this by attempting the uploads again. Revoke the permissions by resetting so that only the User has full permissions (Read, Write, and Execute with the code 755.)
NOTE: You must reset the permissions to revoke full access for the Global and World settings or you are leaving your site wide open to attack.
Sometimes, after adding installing an SSL certificate or migrating a site from one platform to another, it doesn’t behave as expected. There are several fixes for this so, if your site isn’t functioning properly after applying an SSL certificate, read on.
Generally the issues are caused by problems with your page links; that is, links to your site that were listed as http but are now https. Sometimes these slip through the cracks. The three main steps to try are:
Running the Really Simple SSL plugin
Updating the URLs in the WordPress database
Updating the site’s permalinks
Let’s get started.
Run the Really Simple SSL Plugin
This plugin is really simple to use, just like it says! You can install it from the Plugins library, then Activate it.
Once activated you will see a message box like the one below. Just click Go ahead, activate SSL and you’re done! (Yes, there are a few more configuration options but essentially that’s it!)
Update URLs in the WordPress Database
This is a bit more technical because you have to go into the database via PhpMyAdmin and use SQL searches to hunt down any old instances of the HTTP address and replace them with the HTTPS versions. I’ve found that whenever it gets to this stage, the find/replace usually does the trick and it’s one of the first things I check after finding any migration issues.
I usually run a search first to see whether there are any HTTP address lurking in there, and usually there are. To do this:
Click the Search tab in PhpMyAdmin (make sure you’re in the correct database!)
In the Words or values to search for (wildcard: “%”) field, type the search term, in this case the full website address using http://, e.g., http://www.mywebsite.com.
Copy and paste the results into a text file. If you have any instances of the search URL in your database you will want to run the SQL statement to change them.
Rerun the search using the variant of the URL without the www prefix, for example, http://mywebsite.com.
Again, copy the results into a text file so you have a record you can refer. These search results give you the correct table names to use.
Now you’re ready to replace the URLs. The SQL statement to use is:
UPDATE wp_options SET option_value = replace(option_value, 'Existing URL', 'New URL') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET post_content = replace(post_content, 'Existing URL', 'New URL');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'Existing URL','New URL');
UPDATE wp_usermeta SET meta_value = replace(meta_value, 'Existing URL','New URL');
UPDATE wp_links SET link_url = replace(link_url, 'Existing URL','New URL');
UPDATE wp_comments SET comment_content = replace(comment_content , 'Existing URL','New URL');
To use it:
Click the SQL tab in PhpMyAdmin (make sure you’re in the correct database!)
Copy and paste the SQL statement above into the SQL Query field.
Modify the original statement so that it shows your URLs (old and new) and amend the table names, if yours are different.
Click Simulate. Then, if it all looks good, click Go.
That should have changed all the URLs.
Sometimes you’ll have a table or two not covered by the SQL statement above, or there may be another field in the table that is not listed. In that case you’ll need to add additional statements to cover those tables and/or fields. If you’re not happy to do this yourself, contact me for help.
If the above still hasn’t fixed your site, there’s are still two more things to try. Next we’re going to change the permalink settings, then we’ll try reinstalling the template from a download.
Update the Site Permalinks
In the Dashboard, click Settings and then Permalinks. You see a list like the one below.
By default you probably have your site set to use the Post name for links. Whatever setting you have, these are the steps to follow:
Click Plain then Save these amended settings.
Click Visit Site to see whether the sites is back on.
Go back into the Permalink settings, then click Post name (or restore to whatever setting you had before, if different.) Click Save.
Visit the site again. Is it fixed?
If you’re still having issues there’s one more thing to try: deleting and re-installing the WordPress theme. This will create a little more work as all your customisations are likely to disappear, unfortunately, but at least it should get you back up and running again!
The steps for completing that task are in a separate post. Good luck!
Generally, things go smoothly when you update your WordPress theme, but sometimes they don’t. When this happens the way to fix it is often to completely delete the old theme and then reinstall it using the theme files direct from the developer. This post walks you through this process step-by-step.
There are several ways to remove an old theme: from the Themes menu in the Dashboard, or from the File Manager on the server, of via FTP. In this tutorial, we’ll stay within the WP Dashboard.
Visit the theme developer website and download the files for your chosen theme. These will be available for download as a zip file.
In your WP Dashboard, select Appearance and then Themes.
If you haven’t already changed to a theme that works, do this now as you won’t be able to delete a theme you are using. Choose a “safe” default like Twenty Twenty or Twenty Fifteen.
Find the theme you want to replace and click Theme Details (this flashes up when you hover of the image.)
At the bottom of this page you should see two buttons (Activate and Preview) and a red text link saying Delete. Click Delete.
Now your site is ready to be updated.
Back in the Themes list, click Add New then attach and upload the zip file containing your theme files.
Wait for this to upload (you’ll see a % indicator at the bottom of the screen while it uploads) then Activate the theme.
Thanks to Google everyone is now familiar with the secure site padlock in the browser address bar. It’s pretty easy to setup thanks to some great tools like Let’s Encrypt (that generates free SSL certificates) and (for WordPress) plugins Really Simple SSL. But it’s not always plain sailing! Sometimes, despite using these tools you get mixed content and SSL errors> There’s plenty of info online about how to find and fix these (again, using plugins) but this is how I was able to repair a site that had just one page layout that was showing as HTTPS in the address bar but still listed as Not Secure.
Finally! I’ve been trying to figure out why a client site, one with no SSL issues (until now) has been showing just one page of the blog as Not Secure. I Googled, backed up the site then tried changing the URL using Elementor Tools (using the http version of the address and changing it to https). Nothing found.
Then I went into the SQL database and ran query on the http version of the site. Nothing found. Hmmm…
Another check on the incredibly handy Why No Padlock site (which should have been my first port of call) and an old non-HTTPS URL, actually to a development copy that I hosted locally, was flagged up for one of the images used on the page.
Next step: check the source for the offending image file.
Next setback: no file with that name is listed in the source.
So back in the SQL database I ran a search on the path of the file and found that there were 107 instances of it in wp_postmeta and another 27 in wp_posts. It’s definitely there!
A quick URL find and replace later using this query and it’s all back to being padlocked and secured.
UPDATE wp_postmeta SET meta_value = replace(meta_value, 'OLD URL', 'NEW URL');
UPDATE wp_posts SET guid = replace(guid, 'OLD URL', 'NEW URL');
UPDATE wp_posts SET post_content = replace(post_content, 'OLD URL', 'NEW URL');
WordPress is a fantastic CMS with so many plugins and ways to extend the functionality, there’s not much bad to say about it – which goes some way to explain why so many of us are using it to build our own and other’s websites. That said, it’s a technology like any other and sometimes things go wrong. Of course, they only ever go wrong when you least want them to, so here’s a quick summary of the three most common errors that I come up against when moving WordPress sites.
Why would anyone be moving a WordPress site you ask? Well, you might be moving hosts (yes, that can be done!) or you might have been working on a local or development copy so you can test and verify a major update without disrupting the main site. For those of us working away on the backend, moving WordPress sites is just one of those day-to-day things.
But that doesn’t mean it’s foolproof! Three most common issues I see are:
Plugin issues causing conflicts, resulting in the illusive error: “The site is experiencing technical difficulties.”
Images not being displayed on pages, even when you can see they’re there in the media library and nothing has changed (except for the site having moved, of course.)
Redirect errors and stray URLs preventing the site from loading or displaying correctly.
Problems with the links in the database or connection info in the wp-config.php file resulting in the “Error Establishing a Database Connection” error.
Let’s address these one-by-one.
Fix the WordPress Error: “The site is experiencing technical difficulties.”
This one, while utterly terrifying (it literally says nothing useful about the issue you are facing) is actually one of the easiest to fix. If you get this error you will often find that you can login to the admin dashboard but not see any of the pages on the site. To test this, type /wp-admin after your domain and see if you can login. Usually you can – which is good because it means the fix I’m about to describe will work.
If you get this error, you need to be able to access the WordPress files on the server OR to be able to access the admin dashboard.
If you can access the dashboard, you need to deactivate all the plugins. Then reactivate them one at a time. Each time you reactivate one, test the site (I usually have this open in a separate tab and refresh the page to see) then continue, adding them one at a time until the site breaks. When you find the offending plugin(s), you can usually resolve the issue by uninstalling then reinstalling the plugin. It’s super easy to do.
Another way – and by far the fastest and easiest (given the number of plugins you could be facing) to deactivate all the plugins is to change the name of the plugins folder, which you can get to via cPanel file manager or via FTP. Just rename it – it doesn’t matter what, but logically “pluginsOFF” or “zplugins” works – then test the site, see if it works (see if you can login to the admin dashboard, if you couldn’t before) then rename it back to plain old “plugins”. Once this is done you do exactly as described above: activate them one at a time ’til you find the culprits, then remove and reinstall them.
Not so bad, eh?
Now for the next one.
Images Don’t Display After WordPress Site Migration
This is one of my favourites; Okay, it’s not, but whenever this happens it always takes me a few minutes to remember how easy and fast the fix is.
First, navigate to Settings and then Permalinks, then change the selection from whatever setting you have (usually Post name) to Plain.
Save this setting (scroll down and click the button to save) then change it back to Post name. Check your site (refresh the page or check in an Incognito browser, if you’re not sure it’s refreshing) and many times out of 10 this will have fixed the issue.
But sometimes it won’t! In this case you may well find the issue is some stray links in the database – so onto the next fix.
Fix Redirect Errors and Stray URLs that Stop Your Site Loading or Displaying Correctly
Now you’re into database editing territory, so you might want to call on tech support (via your host) or a friendly techie (like me) to get this part done. But it can be done and it needn’t be terrifying – just as long as you make a backup first.
With your backup in place, login to PhpMyAdmin and find the database you are using for your live website. Then just search EVERY table for the URL you used for your development site (or the old site name if you’ve changed the location of it) and the live site. There are some simple SQL queries to use for changing the URLs, but do remember to try every permutation of the URL you can think off. I once had a problem with a site and found a bunch of old URLs addressing my local installation (localhost), which had long since been deprecated! Work your way through these and you should find you’re on your way to a fully functioning site, unless…
Fix a WordPress “Error Establishing Database Connection” Issue
First up, don’t panic. Despite being monumentally unhelpful this message is also another relatively simple fix. You need to check that your database details in wp-config.php match the details of your actual database and with those two things syncronised, usually you’re good to go.
You’ll find the database name in PhpMyAdmin and the wp-config.php file in your site’s WordPress folder. If in doubt try changing the user password, which you can usually do through MySqlDatabases in cPanel. Make sure your user has full permissions too.
If you get this far and your site still isn’t loading, it’s definitely time to reach out for help, even if the “IT Guy (or Gal)” that comes online to fix it does just one of the four things above and they work (yes, this often happens!)
If you need more detailed explanations for any of the fixes above I can do more step-by-step description, but if you know your way around WordPress this should tell enough to get your site up and running again. I know it’ll be a useful reference for me the next time a site migration goes “pop”!
Store your docs in the Cloud, they say. And we do. And some of us like it so we have multiple accounts. So when we’re using Google Drive to store docs online and then cannot download them, it’s a real pain! The particular error I’m referring to is this one:
It’s caused by a conflict between the account containing the files and your default account. For example, your main account is called firstname.lastname@example.org and your files are stored in one of the Drive folders for email@example.com. Google doesn’t like you downloading to another account, which is what it thinks is happening.
It’s a problem that’s been around for a while (I found bug reports going back to 2018) but not one Google seem to have fixed. So what to do? Unfortunately, banging your head against the wall will just give you a headache, so lucky for you I’ve already tried that and found a workaround.
Download your Google Drive Files
The workaround to this annoying 403 error is:
Total Time:5 minutes
Share the folder or file with your default Google account.
Right-click on the file or folder, select Share, then enter the email address for your main account.
Login to Google Drive on your default account.
Click on the list of accounts on the upper-right side of screen. This shows your list. Click on the default account to change to.
From the default account, find the shared file or folder.
Select Shared with Me from the list on the left of the screen.
Download the files.
Right click on the file or folder and select Download.
Languedoc 121 Tech is a registered Amazon Associate Affiliate and also subscribed as an affiliate for MacPaw and PiriForm products. Affiliate links are used within blog posts and in the shop area. Languedoc 121 Tech only promotes products that they personally use and endorse. You don’t pay a penny more and we get a small commission for our referral.