Artistiana

I followed your suggestion: I deactivated the cache plug-in, logged out from Instagram then logged back in. The thumbnails appeared as expected.

I re-enabled the cache plug-in and the thumbnails disappeared again. I emptied all caches again, the thumbnails don’t show.

The cache plugin is W3 Total Cache.

Normally, deleting the plugin and reinstalling it should drop the tables and recreate them. I did not do it myself, so I cannot say for sure.

On a second thought, reading this thread, maybe it is a better solution to disable the plugin, manually delete all its tables, then re-enable it. The plugin’s author says this should recreate them. It is for you to decide if you need to keep old WF data or don’t mind starting from zero again.

You can find the wp_wfHoover table in your database, using phpMyAdmin. It is one of the tables created and used by the Wordfence Security plugin.

I suppose you can delete its records through an SQL query, but I don’t know if this action would not disrupt anything else related to the plugin.

You’ll need to edit the theme’s code, namely the functions.php file, function divina_post_thumbnail(), as described here, but you’ll also have to make some changes in the css file for this to work.

To set up the sidebar menu, you need to configure the “Primary Menu” option (Appearance/ Customize/ Menus/ Menu Locations).

To remove the bottom menu you need to clear the “Bottom menu” textbox, from the same customization page.

You can add/ remove menu options from Appearance/ Customize/ Menus.

Just retried this morning, and it works again. It seems the bug was fixed, good job Yoast team!

Anyway, I understand that the update to 5.4.2 did not address the “can’t authenticate” issue, or am I wrong?

Bugfixes:
Fixes a bug where our link tracking broke the content in case of multiline links.
Fixes a bug where it was no longer possible to dismiss the i18n module.

(Still can’t authenticate, except by manually entering code).

Not working, even after updating to version 5.4.1 of the plugin.
Using WordPress 4.1.2

Tested in:

• Firefox 34.0.5
• Chrome 42.0.2311.90 m
• Opera 28.0.1750.51

Could we downgrade to a previous, functional version?

Yes, something like that, or to be even more explicit, let the message say “[…] When unchecked, the default WordPress settings are enabled[…]”.

Actually, the confusing thing was the behaviour change without a visible notice/ warning to the users, so that they knew to go back and manually change the settings to all their previously published pages.

I also noticed this behaviour, and it is rather annoying to go on each page and un-tick the “Allow comments” checkbox, since we already disabled this through the theme’s configuration.

I think that at least this option should be removed from the config panel so that it doesn’t confuse users anymore.

Well, what do you know! I updated from WordPress 4.01 to 4.1 (I was delaying this operation until the translations issue was solved, but in the end I decided to update, just in case).

And after the WP update was completed, it prompted me to update the Automattic themes translations, TwentyFifteen & co. And when this update was done, MY translations appeared in the Polylang settings panel as they should have been from the very beginning.

Then, just in order to make sure that the WP update completely solved the problem, I rerun the database restore script. This time the restore went without any issue, the translation strings are there and the local site is finally all right.

Conclusion: the DB restore under WP 4.01 caused the translation to be lost; upgrading to WP 4.1 solved the problem.

A big thank you to the plugin author for the quality of the support he provided to us!

Hi,

I replaced in wp_posts the local URL with the remote one, but the problem persists.

Here is the debug log and the concerned posts in CSV format.

Hello,

Here is the link: debug log .

Thank you so much for going that deep into our problem, we really appreciate it!

All right, I deleted the option, and refreshed the Polylang settings page, but nothing changed. The strings are there, with their FR, EN and RO versions holding identical values, as before.