The free forums are no longer in use. It remains available as read-only archive.
Topic RSS12:19 pm
December 5, 2010
OfflineHello,
I have cloned perfectly my wordpress site to another location, an managed the double-slash issue (u should explain that in the clone form for people not familiared with editing files manually) to connect to admin, but I have one last little problem with my TEXT WIDGETS only : they are empty !
All the other dynamic widgets (gallery, youtube, so on) are ok.
The Text widgets areas do exist but are not populated "inside".
Did I miss something during the cloning phase ?
I had to do the clone step manually on my new loation because the ftp connection wasn't working.
I can copy/paste my text widgets from my old location to the new one in 5mns, but I'm curious to know where the problem comes from ...
THX for any help 🙂
Hi there! The text widget value is stored inside the wordpress database table wp_options, the option_name name is widget_text.
Â
You can use this mysql query in phpmyadmin to retrieve it:
Â
SELECTÂ *Â
FROMÂ `wp_options`Â
WHERE option_name = 'widget_text'
LIMIT 0 , 30
Â
Try and check if the value of that record matches the original site one, if not, try and match them by reimporting the data of that record.
Hope it helps. Ovidiu
Thanks! I also had problem with this kind of issue when I clone 4 sites and i'm annoyed coz the cloning is successfull but the text widgets are not showing, what I did is just copy the widgets one by one. but thanks sharing this solusyon it really works I just reimport it from the database 🙂 - pinoyscreencast
1:11 pm
May 18, 2011
Offlinehi everyone,
i encountered the same problem. after a clone was created successfully, no text widgets were displayed. a look at the widgets in wordpress admin area showed, that all text widgets were gone.
(i am using xcloner v3.0.3)
after that i had a look into the database, table wp_options, option widget_text. the serialized php array contained data, that said that there are no text widgets. the data was not corrupted or anything missing. it was the serialization of a valid php array. just no data about any text widgets in there.
so i took a look at the same option, right after the completion of a cloning operation and all the data was there! just for some reason wordpress can not resolve the data anymore. so if the frontend is loaded, the data from option widget_text can not be resolved and no text widgets are displayed. on the other side, if you have a look at the widgets in the admin area, again the data can not be resolved, and all text widgets are lost. but this time - thanks to wordpress ajax functionality in the widget area - the configuration without the text widgets is immediately saved back to the database. hence the observed serialized valid php array with no data about any text widgets.
so far so interesting.
next question: why can wordpress not resolve the data from option widget_text?
i was able to narrow it down to different line endings. if the mysql dump contains windows line endings (\r\n) in the serialized php array in option widget_text then the bug occours, if it contains linux line endings (\n) then the data in option widget_text can be resolved.
interestingly in my installation xcloner can make backups with the one or the other. this and the following observations is as far as i could go on my own:
1. backups which contain a mysql dump with the malicious windows line endings (\r\n) in option widget_text only happen, if they are made by cron jobs.
2. backups which contain a mysql dump with the friendly linux line endings (\n) in option widget_text can be created by chosing the option XCloner>Actions>Generate Backup
3. in my case a malicious mysql dump starts as follows:
Â
4. in my case a friendly mysql dump starts as follows
#
# Powered by XCloner Site Backup
#
# Host: abc-house.at
# Generation Time: Oct 24, 2011 at 10:27
# PHP Version: 5.2.17
# Mysql Compatibility:Â
# MYSQL protocol_version: 10
# MYSQL version: 5.0.92-1~ui40+1
# MYSQL version_comment: (Debian)
# MYSQL version_compile_machine: i486
# MYSQL version_compile_os: debian-linux-gnu
#
# Database : `db351553688`
# --------------------------------------------------------
Â
thanks in advance,
arthur
Hi Arthur, it might be best if you would post this question on the main Wordpress forums, i am sure you will find there somebody more experienced with Wordpress to help you with this, from what i know, the widgets serialization issue is related to the url change, so you might want to look for a wordpress plugin that could do this conversion.
Â
Regards, Ovidiu
3:25 pm
May 18, 2011
Offlinehi ovidiu,
sorry to keep nagging you. this time it is not for help but about a possible bug which i think is responsible for the misbehavior documented above. Please have a look at XCloner-file cloner.functions.php, lines 2055 & 2056 and tell me how they affect a sql field of type text or varchar which contains a serialized php string.
INSERT INTO 'table_x' VALUES (33, 'a:1:{s:13:"Hello\nWordl\n!";}');
will become
INSERT INTO 'table_x' VALUES (33, 'a:1:{s:13:"Hello\r\nWordl\r\n!";}');
regards,
arthur
1:49 pm
May 18, 2011
Offlinevery true, as i recall the code. my fault. i focused just on line 2055. shame on me.
someone should take a look at the dumps again and count the characters, to make sure this is not the cause. because what i know for sure is that the working dumps just have \n as linefeeds in php-serialized strings and the not working ones have \r\n.
ah yes, another question that might lead to an answer would be, why xcloner makes sql-dumps in two different ways? i noticed that by the dump headers (see post above) and have seen it in the code when i searched for the header's words. (the dumps of one cause the problem, the dumps from the other don't.)
as you may have noticed i am very into this forensics stuff, but i did not get far enough and quit my job at that company to focus on freelancing. so most likely i will not pursue this matter any further.
thanks for your time, regards and the best,
arthur
1 Guest(s)
Log In