(El)Burgo

This might sound daft but just check the Yoast plugin is actually still active – when we upgraded it set itself to inactive.

Just Solved it!
We’d always used Hestia – used it for a while now. We’ve never had the error message before. Looking at the revisions log we added the FAQs as a Yoast FAQ block on 8 May. The other pages with FAQ blocks also showed the same error message as well now. So went to add a new page, and add a FAQ block and saw the Yoast structured Data blocks weren’t shown as an option. Went back to the Plugins screen and then saw the plugin was not active. Activated it and all is back to normal. It looks as if the upgrade script when it updated from 14.8 to 14.9 didn’t re-activate the plugin after the upgrade had run.

p.s FYI – Are you aware that those pasteboard links throw a “ERR_SSL_PROTOCOL_ERROR” error and are blocked by Malwarebytes as having a Trojan within them?

• This reply was modified 4 years, 6 months ago by (El)Burgo.

+1 The change log shows compatibility has only been tested up to 5.4.2. so we’re holding fire on it. Anyone know if this plugin still being maintained?

How do you stop the editor re-setting to full screen mode every time you log in?

+1. This is a total PITA and the editing view keeps flipping back to full screen mode as well. Please, please, fix this.

FWIW, if it helps anyone else, we needed to delete the wp-forms folder in wp-content/plugins via FTP, as we couldn’t re-install the wp forms lite plugin due to the folder already being there.
We then validated the licence key, but when installing the wp-forms full plug in the install kept failing.
We downloaded wpforms.zip from our account page, and manually tried installing it. It took around 1 dozen attempts before it eventually run, as our server has a 60sec script execution limit on it.
Activated it and we were back in business.
No form templates were lost (as these are stored in the db, I presume).

I can see more and more issues in the future with hosting packages with time limits on script run times, unless plugin developers are aware that long running scripts to update without a break to “re-set the clock” will time out – and unless these timeouts are handled gracefully then it’ll be a problem.

No replies, so we eventually managed to get it sorted. In case it helps anyone else we did the following:
We couldn’t do a install from WordPress as Yoast failed with message that the installation already existed.
Eventually sorted by deleting the wordpress-seo folder in wp-content/plugins using FTP. Then reinstalled and reactivated a new copy of the plugin.
It looks most of the data has been kept as well which is a bit a bonus (suspect it was all in the DB).

• This reply was modified 4 years, 9 months ago by (El)Burgo.

The issue seems to be this CSS:
border: none;
padding: 7px 0;
font-size: 14px;
Which is being applied by /wp-content/themes/hestia/style.min.css?ver=2.5.6. Are these a default hestia setting or are they something that is end user editable – if so where were they set???

The correct CSS applied by WP-Forms should be
padding-right: 6px;
padding-left: 52px;
Rgds
IEB

V3.4.3 has now worked for us on our development (localhost) sites apart from 2 sliders, which had somehow lost one image each. These were easily fixed. Hopefully this now brings this to a close. One good thing is that it did prove to us the value of updating on a development environment and doing our own regression checking, rather than just relying on a live environment. Thank you for the fix.

V3.4.3 has now worked for us on our development (localhost) sites apart from 2 sliders, which had somehow lost one image each. These were easily fixed. Hopefully this now brings this to a close. One good thing is that it did prove to us the value of updating on a development environment and doing our own regression checking, rather than just relying on a live environment. Thank you for the fix.

So much for regression testing and and checking backwards compatibility!
Luckily we hadn’t put the upgrade onto any live sites.
@farazfrank – How about pulling the update so there is no danger of anymore live sites being impacted until the bug is fixed?

Recover old slides does not work for us on localhost development site. We enter the slide ID, for example “1132” and hit “Recover Slider” but nothing changes.
Create a new slider does still work – it is just that all the old ones no longer work.
Workflow was:
Updated plugin to version 3.4.1
All media linked to existing sliders now appeared blank
Navigate to UR Image Slider / All Sliders
Select a Slider and Edit
Media is blank
Take note of Slider ID (eg: “[URIS id=1132])
Select “Click to recover old sliders”
Enter ID “1132”
Select “Recover Slider”
No change – Media still blank.

• This reply was modified 5 years, 2 months ago by (El)Burgo.