Plugin Author
Chouby
(@chouby)
I don’t know what could happen. Basically strings translations are stored in an option ‘polylang_moxx’ where xx is a unique number for each language (the term id in the language taxonomy). I hope this information will help you to get this back.
Well, so it happens!
Cause in OPTIONS table I’ve the correctly imported registers, as you can see (this is an screenshot from localhost! After importing! And the registers are allright, with the right translations):
View post on imgur.com
And the translations are inside the DB, with no problems at all, they’re correct.
BUT, they don’t show on Admin page and of course, they don’t load, as in Admin page, only var_names are loaded.
Look:
– What should be on localhost AFTER importing via .SQL executing against DB (this is a screenshot form the online version, the right one):
http://i.imgur.com/8IlKGxC.png
– What on localhost really is AFTER executing the .SQL file (after importing). This is a screenshot from the local version after the import. The BAD one:
View post on imgur.com
And as I said, I’ve done nothing more than simply executing an IMPORT on Navicat or in PHPMyAdmin from a previously EXPORTED file from the online host!
Any idea?
Plugin Author
Chouby
(@chouby)
Are the term_id of languages in the ‘wp_terms’ table the same in both exported and imported databases? Are they 34 and 35 as expected from your first screenshot?
As it’s a FULL exporting of a DB, from PHPMyAdmin on my online host, and then an import from this very same file to localhost via Navicat software, it’s should be obvious that they are.
And yes, they are!
WP_TERM:
localhost: http://i.imgur.com/StOAZWP.png
online: http://i.imgur.com/mTB6vZx.png
WP_OPTIONS:
localhost: http://i.imgur.com/yxiVHUY.png
online: http://i.imgur.com/oSULSRm.png
So I encourage you to test it by yourself if you can, please!
I really need to know how to solve this, as if anything happens someday, I’ll need a DB copy, and with this, we really have a problem!
Just EXPORT a DB from an online host WP you have with Polylang, and simply import the DB copy from a local WP copy you have. Just watch! 🙁
Plugin Author
Chouby
(@chouby)
Yes of course both DB should be the same. But since you have a problem, I was just making a suggestion to help you find where it is. Of course I made the test. And I have no such issue.
Did you look if db fields in wp_options are exactly the same in both exported and imported DB? Have you errors logged on your imported site?
Ok.
I’ve seen what could be the problem:
– I’ve installed Black Studio Widget, and this guy added automatically a lot of strings on “Strings Translate” page on Settings.
Those strings get imported correctly on the file, but they don’t show on the panel when imported on Localhost! There only appears the normal strings (functions.php ones + the exsiting ones on Polylang).
So in localhost, if I modify some of the strings and Save, suddenly the DB gets cleaned and only appears the visible strings, deletting the black studio ones from DB (as I said, those were on the DB, but they didn’t show on the administration panel!). From now on, everything works fine.
So I need to delete those strings from this page, but this is not possible. Those are “ghost strings” that are not propperly shown on panel, but they exists inside wp_options on polylang records! As so, cleanning DB it’s not useful!
I’ve tried to do it manually agains DB record. It’s not useful, because when you save on Polylang, indexes on JSON string got rewritted, as I’ve seen.
So this is a dead end!
On the remote host I SEE those strings on administration panel.
I’ve emptyned’em and tried to save cleaning the DB. Stills not useful.
Even deactivated the widget, and uninstalled it.
Nothing!
How do I proceed?
Oh, I’ve forgot to say, that what Black Studio TinyMCE Widget had, was a HTML rich text strings inside, so maybe there is a problem with codification and bad quotes escape on reading from DB on the plugin?
As the data is propperly inside the DB, but it doesn’t show on Admin Settings page, I think this could be a problem based on the reading/escaping quotes from DB in the plugin behavior’s.
Could it be?
Plugin Author
Chouby
(@chouby)
I have made a test with the latest version of Black Studio Widget 1.2 and the development version of Polylang 1.1 and got no issue. But in fact, Black Studio Widget registers only two strings, not a lot.
Polylang registers the strings for translations in two ways:
* the native way: the string is registered each time the admin panel is displayed. If the plugin which registers the string is disabled, the string disappears from the admin panel. The translations are kept in database (wp_options/polylang_moxx) unless you check the option “Clean strings translation database” and save changes.
* the WPML compatibility mode (used by Black Studio Widget): the string is registered in database at the 3rd party plugin initiative (here when you update the widget options). The strings are stored in database (in wp_options/polylang_wpml_strings). Thus the strings are kept in database (and displayed in the strings translation panel) even when the plugin which registered them is deactivated. I was obliged to do so as WPML does something similar.
Starting from Polylang 1.1, it is possible to delete the strings registered in WPML compatibility mode (as you experienced, it is currently not possible in Polylang 1.0.4). Two steps are needed:
1. check the string(s) and choose ‘delete’ in bulk actions, click on apply -> This “unregisters” the string from wp_options/polylang_wpml_strings
2. check the option “Clean strings translation database” and save changes -> This deletes the translations from wp_options/polylang_moxx
So testing the development version may help you to delete the strings registered by Black Studio Widget. You can also directly delete the option ‘polylang_wpml_strings’.
http://downloads.wordpress.org/plugin/polylang.zip
Thanks god!
Polylang 1.1 & it’s widget group removing feature on Administration Panel, solved the problem!! Now everything runs fine!
Thank you so much for all your efforts and attention! 🙂
‘Til next time!
