The CW Corner – WordPress loading images – blank thumbnail issue

by | Nov 12, 2020 | Do-It-Yourself, Technical Help, The CW Corner, Website Development, Website Updates, WordPress

Sometimes in a WordPress website an issue develops where when loading images into media library, only a blank thumbnail shows. It appears a space is created in the database for the picture but there is no content in it.

After testing compatibility of plugins, themes, php, etc., the problem persisted.

To resolve this, one can navigate here logged into WordPress as an administrator:
Go to Dashboard > Settings > Media

Make sure the correct default file path is showing there. When troubleshooting this issue on a site that was unable to upload media files, the file path was shown as:

/home/username/domains/thedomainname.com/private_html/wp-content/uploads

Note that the “username” and “thedomainname.com” in the above and below path examples will be the Linux username and the actual site domain name respectively that you are troubleshooting.

The fix

When this path was removed, the image file upload worked normally again and the problem appeared to be solved.

Possible Reasoning or Causes

In the DirectAdmin path structure, there are two places the website’s servable coding (like WordPress or HTML sites or Joomla, etc.) might be stored:

/home/username/domains/thedomainname.com/public_html

or

/home/username/domains/thedomainname.com/private_html

The “public_html” folder is where DirectAdmin normally places the website’s code (again, referring to all the files and programs that make up the actual WordPress or HTML or Joomla site’s coding, etc.).

The “private_html” folder is where DirectAdmin normally tries to place the website’s code when its content is encrypted. That’s why there is an option in DirectAdmin’s site control panel that allows one to “Use a symbolic link from private_html to public_html”. This option allows for using the same data in http and https.

The suspicion here is that a setting got changed or an update occurred causing the WordPress system to use the private_html setting when the site resides in public_html. Removing the file path from the settings forced WordPress to use where the system actually defaulted to – which cleared the problem.

We may never know how the setting actually got bunged up, but it is an easy fix once it is.

FacebooktwitterredditpinterestlinkedinmailFacebooktwitterredditpinterestlinkedinmail