anotherdave

It’s nothing to do with iThemes Security. You have mixed content on your site (that’s when some of the elements in your page are linked as plain non-secure http:// instead of https:// , and often this is fairly easy to fix).

In this case, I can see that your site is loading your logo file in your header as non-secure. Your site / theme is loading your logo as:

http://thelifestylejournals.com/wp-content/uploads/2020/04/logo-blog.png

Instead of:

https://thelifestylejournals.com/wp-content/uploads/2020/04/logo-blog.png

There are a couple of ways to fix that.

Here’s one easy solution to try – I can tell you’re using the theme Sitka , so you might want to first try going into your theme and removing the logo from the header and then re-adding it.

That’s easy to do and should fix it, because when you created / added the logo, you did so when the site was not using https:// SSL , so removing and re-adding the logo should now link it as secure https:// instead of plain http://

Disclaimers:
– Always download backups of your site and database before making changes.
– I am not affiliated with iThemes or WordPress in any way.
– Any solutions I suggest would be at your own risk (I know that sounds scary, but if you grab a backup of your database and a backup of your site files before you make changes to your site, you can restore it if something goes wrong).

I just wanted to share some input that I think is relevant and I hope this is helpful to someone. If the plugin author or mods feel that this doesn’t belong here then of course you can remove it.

It would be best for all users to get their PHP version upgraded to at least 7.1 if possible (some may have to contact their hosts, and of course first check to make sure all their Plugins and Themes are compatible with PHP 7.1 and up).

Reason – PHP 5.6 reached EOL (end of life) back in 2018 and is no longer officially supported, no longer receives all security updates, and is considered security risk. (Similar scenario with PHP 7.0). Many users are on a host running cPanel on their servers, and cPanel will be deprecating / removing support for 5.6 and 7.0 (actually any version lower than 7.0) in the near future, and cPanel has stated that users should update to PHP 7.1 or higher, and 7.0 and below are now considered a security risk.

Ideally everyone should try to get their PHP updated to 7.3 as that is quickly becoming the standard, and WordPress themselves strongly recommend it. PHP 7.2 is also a good option and will help some people who have Plugins that are not quite ready for 7.3 , but 7.3 is the way to go if possible. Some hosts provide a way for users to change their PHP version right from within cPanel (and if you do so, wait about 1 minute before testing your site, because most servers will typically take anywhere between 20 to 60 seconds to fully apply the change, so if you try to view your site immediately after changing PHP version in cPanel then your site will seem “broken” for a minute).

It’s also best for users to check with each Plugin / Theme provider to find out if their product is compatible with PHP 7.1 / 7.2 / 7.3 before updating PHP. This can be a little tedious for users with a lot of Plugins / Themes, but checking to make sure everything is compatible before updating to a modern version of PHP will save users headaches and avoid potential issues.

(I am not affiliated with iThemes in any way – I’m just a long time user and manage a lot of WordPress sites, have a lot of experience with hosting tech)

I don’t work for iThemes and I use the paid version, but I do know this – about a month ago they released a version that had this exact bug that you’re talking about and the same thing happened to me. They quickly released an update to fix the issue, so I’d suggest that you check your Dashboard > Updates section to make sure you’re updated to the latest version. Hope that helps, or someone else chimes in with some info on this regarding the free version, since I can only go by what I know from using the paid version.

• This reply was modified 7 years, 5 months ago by anotherdave. Reason: Typos

@war85ren – thanks for taking the time to post a solution that worked for you. So many people don’t come back after they resolve (especially if they found the source of the problem to be different) and it really helps when they do.

• This reply was modified 9 years ago by anotherdave.

You mean they didn’t blame your host yet?

Same problem here.

Thanks for the reply.

I took a close look at the developer’s site, and I’m both cautious and impressed at the same time.

Cautious – because there’s somewhat significant list of other plugin incompatibilities with it.

Impressed – not only because the developer goes into great detail about which other plugins & environments the script has had issues with (past / solved / currently existing) , but he even reaches out to the developers of other plugins that aren’t compatible in an effort to provide them with info that could help!

Perfect example is if you visit http://www.redsandmarketing.com/plugins/wp-spamshield/known-conflicts/ and then read item #3 where you can see a link to https://wordpress.org/support/topic/some-of-the-plugin-code-needs-fixing-it-disables-registration-anti-spam/ in which you can see the “WP-Spamshield” dev attempting to help the “New User Approve” dev fix some code in New User Approve that would clean up their code and make both Plugins compatible together.

So yeah… even though the list of known issues with WP-SpamShield is a bit intimidating, the fact that Scott (the developer of WP-SpamShield) is so tenacious, thorough, and willing to reach out to other devs with assistance is very impressive. Also Scott’s blog, while not super active, is quite full of a lot good information. He certainly has a lot of desirable attributes in a developer and a serious approach.

Overall a good find, thanks again for the tip!