greigner

Thanks for the response. I had already worked on it, although the solution isn’t ideal.

FYI – the problem seems to be related to a conflict between your Easy Accordion plugin and a hosting plugin at Siteground hosting called “Siteground Optimizer”. This conflict isn’t present in Firefox, but in all other browsers. It may have something to do with Javascript compression. Have your team look into it when you can. Keep in mind Siteground is a fairly popular host, so you’re likely to have other customers run into this issue eventually. As a temp fix, I disabled the Siteground plugin; this causes some feature loss inside my WordPress dashboard and some speed losses in visitor load times, but it fixes the FAQ opening issue below.

I hope this helps! Thanks again for your response.

I hadn’t seen any posts about this specific issue causing Premium WF to downgrade to Free WF without any notice. I understand now why your level of frustration is higher; if that’s what they are doing, there’s definitely a better way they can handle that for their paying customers.

All the same, please update your technology environments as soon as you are possibly able to. You’re not only protecting yourselves, but all of us in the community. This expectation that software from 2010 will work alongside software from 2018 isn’t correct.

The fix for this issue is above, as well as in a few other posts on this forum. If you have any further questions or technical details for those needing more assistance, post below. Thanks everyone!

@tombombadil69:

I understand your frustration; I also didn’t like receiving the error and having no idea how to correct it.

In this case, I believe you can’t blame a plugin for your web servers’ lack of health; it’s your choice, not theirs. You have WF installed to keep you secure – you would be furious if you paid money and it failed to alert you of a major security risk. It’s doing exactly what you paid it to do. Yes, it could have done a better job by making an actionable item (eg. “Update PHP to resolve”, etc.). But the alert is real.

It sounds like you may have on-premise hosting, or at least some private hosting somewhere. I would highly recommend moving to a hosting vendor that can handle all of this for you. You mentioned time and expense. All major hosting vendors will do OS, PHP, and OpenSSL updates for you for free and with no time spent. Side note: hosting with a vendor also happens to be far cheaper in the long term that self-hosting.

Good luck with the updates!

@scottl31:

No, I’m saying that OpenSSL relies upon PHP (they work together). You can’t update just one thing to a brand new version, and still have things function. It’s time to update both things to the same level.

Picture it just like other software. You can’t run the newest version of QuickBooks on Windows Vista. You have to upgrade Windows so that QuickBooks will work. You must upgrade PHP in order for the current version of OpenSSL to work.

– Your host supports the current version of OpenSSL (GOOD)
– WordFence supports the current version of OpenSSL (GOOD)
– Your PHP software does not support the current version of OpenSSL (BAD – WordFence alerted you to this, although not very clearly)

Time to Update PHP. Hope that helps!

Scott,

These forums are sort of community driven, so a response from the developer is sometimes hard to get. Did you update your PHP to version 5.6 or higher? PHP and OpenSSL have some type of reliance on each other, so although your host’s server might support a higher version, your installed language (PHP) may not – it could be where the report is coming from. Installing PHP 5.6, 7, 7.1, or 7.2 should provide WF with the correct data.
Good luck!

I just found from another post that updating to PHP 5.6 or higher under “Programming Languages” solves the issue I detailed above.

After the upgrade to PHP 5.6, WF diagnostices indicates:
OpenSSL 1.0.1e-fips 11 Feb 2013 (0x1000105f).

The alert is now gone. Hope this helps!

• This reply was modified 6 years, 10 months ago by greigner.

I had the exact same issue, and it does appear that updating to PHP 5.6 or higher under “Programming Languages” solves this issue.

My original details of this issue are a part of another recent post here, prior to me discovering this one.

After the upgrade to PHP 5.6, WF diagnostices indicates:
OpenSSL 1.0.1e-fips 11 Feb 2013 (0x1000105f)

Thanks for the help, @ideafusionmedia! Much appreciated. Good luck everyone.

Alerts can certainly be annoying, and they are customizeable.

Are you the administrator of the site or is someone else? Whoever that is should to receive at least minimal alerts in order to know if the site is hacked or otherwise being misused. That’s the point of having WordFence; it blocks the bad guys, or if it can’t block them, it tells you about it so you can keep your site up and working right.

Minimal alerts: to choose your alerts, Go to WordFence in your main menu, then All Options, Email Alert Preferences. Simply uncheck the ones you don’t absolutely need.

I recommend keeping at least 4 boxes checked. WF deactivation, Critical problems, Administrator access sign in, and Large increase in attacks.

Good luck!

• This reply was modified 6 years, 10 months ago by greigner.
• This reply was modified 6 years, 10 months ago by greigner.

I too am having this issue on multiple sites. I don’t have any record of OpenSSL at all, but WordFence indicates that my version is out of date. I don’t have an SSL cert in place, and nothing on my hosting account indicates I’m using Open SSL.

If I scan using the recommended 3rd-party tool (Qualys SSL Labs), I get the following for all affected websites:

Assessed on: Fri, 04 May 2018 11:57:00 UTC
Assessment failed: No secure protocols supported

According to WF diagnostics, it sees Open SSL in use:
OpenSSL 1.0.0-fips 29 Mar 2010 (0x10000003)

Is this a false error?

I tested this today with nearly the same results:

Tar Gzip job yields these results:

– Stalls at “beginning upload phase” (this phase reads stuck at 103%)
– Progress bar reads 75% , but job won’t complete; still running after 1.5 hours.
– Receive warning on text file “…is too long to be saved correctly in TarGZ archive”

• This reply was modified 7 years, 6 months ago by greigner.

No, this is not yet resolved. I haven’t been able to test yet, but I need it to work with .ZIP (client requirement, as mentioned).

I will test TAR for you anyway in case it helps you find the issue. Thanks!

• This reply was modified 7 years, 6 months ago by greigner.

Duong,

The backup job is much smaller than most of my other sites as it is brand new. I estimate it at around 100 MB. I’m backing up to a .ZIP format, which is required by the client. I have posted the log file below for your review:

[INFO] BackWPup 3.4.1; A project of Inpsyde GmbH
[INFO] WordPress 4.8.1 on https://alphabarsports.com/
[INFO] Log Level: Normal
[INFO] BackWPup job: Full Site Backup
[INFO] Logfile is: backwpup_log_a3eda1_2017-08-31_07-03-20.html
[INFO] Backup file is: backwpup_a3eda101_alphabar_2017-08-31.zip
[31-Aug-2017 07:03:20] 1. Try to backup database …
[31-Aug-2017 07:03:20] Connected to database f62d3355421692 on f62d3355421692.db.3355421.hostedresource.com:3308
[31-Aug-2017 07:03:21] Added database dump "backwpup_a3eda101_f62d3355421692_alphabar.sql" with 6.92 MB to backup file list
[31-Aug-2017 07:03:21] Database backup done!
[31-Aug-2017 07:03:21] 1. Trying to make a list of folders to back up …
[31-Aug-2017 07:03:24] Added "wp-config.php" to backup file list
[31-Aug-2017 07:03:24] 1311 folders to backup.
[31-Aug-2017 07:03:32] 1. Trying to generate a file with installed plugin names …
[31-Aug-2017 07:03:32] Added plugin list file "backwpup_a3eda101_AlphaBar-Karaoke-Social-Party-Sports-in-Indianapolis-and-San-Francisco.pluginlist.2017-08-31.txt" with 2.39 KB to backup file list.
[31-Aug-2017 07:03:32] 1. Trying to generate a manifest file …
[31-Aug-2017 07:03:32] Added manifest.json file with 6.73 KB to backup file list.
[31-Aug-2017 07:03:32] 1. Trying to create backup archive …
[31-Aug-2017 07:03:32] Compressing files as ZipArchive. Please be patient, this may take a moment.
 

• This reply was modified 7 years, 6 months ago by greigner.

Good morning! I was also having this same issue (timeouts, “job restart due to inactivity…”) starting around July 31st, 2017. I have had warnings since installation, but the job has always completed normally for several years.

Now I have errors and the job hasn’t run since.

TO FIX:

I never had “WordPress XML export” checked. Only Database, File, and Installed plugins list. However, in my BackWPup Settings –> Jobs –> Maximum script execution time, I had it set to zero. Set that to 20, and test again. Success. No warnings, no errors.

Should this perhaps be a default value of higher than zero during installation? Just a suggestion since this seems to be an extremely common issue, and setting it to 5, 10, or 20 doesn’t seem to negatively impact anything. Even overall runtime is about the same.

Thanks for a good plugin! This has saved me several times.

Site info:

HOST: GoDaddy
VERSION WP: 4.8.1
VERSION backWPup: 3.4.1

• This reply was modified 7 years, 6 months ago by greigner.

You can also use a plug-in like Global Content Blocks or Post Snippets. These allow you to write small bits of code, and then create your own short code with them. WP will never strip out short code.

I believe I’ve found at least some of the settings. For anyone else who may be looking:

– create folder inside your theme folder called ‘nggallery’
– find ‘View’ folder inside the galleryview2 plug-in directory. For me, the path was: /wp-content/plugins/nextgen-galleryview2/view/
– copy the gallery-galleryview.php file from that folder (View) to the folder you created (nggallery)
– Now open the gallery-galleryview.php file and edit to hearts content

So far, it seems to include things like slide transition time, size, filmstrip options, etc. Hope that helps.