dandick

I’m getting errors regularly on simplexml_load_string
Some seem to happen because nothing comes back, but others produce
something but simplexml_load_string still does not seem to be able
to parse what’s coming in. But, even if nothing came back, it would
seem that the $string variable should be empty or perhaps it should
be matched against a string that would be used to indicate an empty string. I haven’t taken apart the output of what came back from google’s blogsearch other than to pull it up in firefox and it looks like normal XML.

Dan
=================
godsblogs

Warning: simplexml_load_string() [function.simplexml-load-string]: Entity: line 17: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0x93 0x57 0x65 0x20 in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: <content type=”html” xml:space=”preserve”>?We spent the second half of life in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: ^ in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115
There are no results for this keyphrase

GodsBlogs

Warning: simplexml_load_string() [function.simplexml-load-string]: Entity: line 17: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0x93 0x57 0x65 0x20 in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: <content type=”html” xml:space=”preserve”>?We spent the second half of life in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: ^ in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115
There are no results for this keyphrase

godsblogs.com

Warning: simplexml_load_string() [function.simplexml-load-string]: Entity: line 15: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xBB 0x20 0x57 0x61 in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: <title type=”html”>Blogs ? War Gods</title> in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: ^ in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115
There are no results for this keyphrase

dota

Warning: simplexml_load_string() [function.simplexml-load-string]: Entity: line 15: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0x96 0x20 0x57 0x6F in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: <title type=”html”><b>DotA</b> ? WoDotA Funny 10 Vol.1 ? America in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: ^ in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115
There are no results for this keyphrase

danieljdick

Warning: simplexml_load_string() [function.simplexml-load-string]: Entity: line 27: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0x96 0x20 0x4C 0x65 in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: <title type=”html”>Charlotte Divorce Lawyer ? Lee Rosen ? Why do couples div in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: ^ in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115
There are no results for this keyphrase

“Daniel J. Dick”

Warning: simplexml_load_string() [function.simplexml-load-string]: Entity: line 29: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xBB 0x20 0x57 0x68 in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: J. Dick. Did you like this? Share it: Related posts: ArticleCite.com in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115

Warning: simplexml_load_string() [function.simplexml-load-string]: ^ in /var/www/html/godsblogs/wp-content/plugins/reputation-management-for-wordpress/reputation-management.php on line 115
There are no results for this keyphrase

I noticed that some automatic plugin updates and most WP upgrades seem to finish without removing their stuff from the upgrade directory, and when that happens, it seems that upgrades get stuck with a long delay followed by an error. I see that happen now and then on my C-panel based sites.

I don’t think that is the case with this plugin, but what I did notice with this one and one or two others is that they seem to try to copy a file from a path that is hard-rooted to /public/… I haven’t looked deeply into this to find out why. But, I did do the manual install and it seemed to work. The only gotcha is that it’s on a C-panel system which means that the directory will be owned by the C-panel userid rather than the userid that Apache is running under.

It’s funny but when I wanted to remove the old one, I couldn’t remove it in C-panel, so I ended up scratching up a PHP program to remove the old directory and run it by going to the eraseit.php file I created on the website. arrggghhh. I’m using a VPS for my other sites, and I love being free to work within Linux as I’ve been a Unix geek since the early 1980’s. It’s my home ??

That reminds me. Rather than looking around on this silly old C-panel setup, I should just find and grep a WPMU install on my VPS. Much easier and faster.

I ran automatic updates on all my wordpress-mu sites residing on my VPS from 3.0 to 3.0.1 without a hitch.

However, on my plain WordPress sites on a c-panel setup, I ran into this problem only it wasn’t icon_redface.gif that appeared in the error message. It was something else.

I noticed some people had problems doing the manual update, and I posted something to that other page which makes me hate to post something like it here, but since it will probably help someone, here’s what I did to have good luck with my manual upgrades:

I didn’t remove everything. I kept wp-config and the wp-content and images directories. This is probably obvious to anyone who works with the internals of WP all the time, but I’m sure many people have probably blown away those files and directories thinking they were supposed to delete “everything” first. Or they could have backups…

I think copied everything from the 3.0.1 distribution back into the websites directory. Everything, that is, except wp-content, images, and the wp-config file (which isn’t there when you unpack the new installation anyway)

I then ran the upgrade.php as the readme file says to do, and voila. Of course, if you’re running WordPress as WPMU, you’ll probably need to press the update button to update all the blogs.

And just to feel good and consistent, I cleared my caches (Super Cache, or W3 Total Cache, or whatever).

——————
All in all, I’ve had great luck with the automatic and manual upgrades. I think my problem that caused me to have to do the manual upgrades on the C-panel system is that I’m dealing with two different user-ids: one for the C-panel login, and one that that apache runs as.

I got the public_html/x/wp-admin/css/theme-editor.dev.css message
when I tried to update https://www.save-your-marriage.org automatically. However, the manual update worked fine for me.

What I did was basically what I remembered doing when I upgraded to 3.0.

I deleted the old files first, keeping
wp-config.php as it contains the configuration data
wp-content as it contains the themes, plugins, etc.
images as it contains pictures I uploaded

Then I selected everything but those three items from the new wordpress directory and recursively copied those into the root directory of the website. Also, if the .maintenance file was there, I removed that, too so that the website wouldn’t keep coming up with the maintenance message.

I then ran the upgrade.php, clicked the button to update the database, and everything came up working fine.

Anyway, this site was set up to be a plain WP site and not WPMU.

I just ran an automatic update on https://save-marriages.com which I set up as a WPMU site on a VPS, and the upgrade went almost perfectly.

I say almost because it came back saying the upgrade was successful. However, when I pressed the dashboard button, I got a white screen! Yikes. I held down shift and pressed the refresh button on my browser and the dashboard came back.

Just to make sure things were consistent, I cleared my caches on the sites after doing the upgrade.

Joel, thanks for the good news. Did you get an idea from your friend what the root of the problem finally was?

Here’s a concise run-down of my experiences with some of my WordPress 3.0 installations (not WordPress-mu) under C-panel in case it might be of use to anyone.

Dan
————————————–
Backups, of course
I disabled my plugins
I deleted any leftover junk in wp-content/upgrade
I ran automatic update to WordPress 3.0. (may take several minutes)
Sometimes it would hang and then give the “Briefly unavailable”
I would remove the .maintenance file from the website’s
root directory.
I would do the upgrade manually.
I would run https://mysite.com/wp-admin
If it worked, great. If not, I’d try to see if I failed
to follow the instructions somehow and correct.
Most of the time, it finished with success.

After the core upgrade, there may be plugins or themes to update.
Again, I delete any leftover junk in wp-content/upgrade, and for me,
the core upgrade has always left behind some stuff there.
About 25% of the time, I found my automatic theme updates worked.
The rest of the time, I found they failed, so I would delete and
reinstall.
Upon doing any automatic update, I found a failure of any kind could
leave behind a .maintenance file which i would remove,
and then sometimes I would just do a shift-refresh to redo the
update or try to bring up the desired page again without losing
the data along the way.

Once the plugins and themes are updated, I would attempt to
turn the plugins back on.
I would also clear the cache for DB Cache, Super Cache, or on my
VPS without C-panel, I would clear the W3 Cache and turn it back on.
I would then go to phpmyadmin and optimize any tables with overhead
and analyze all the tables again.

I might then go back and pre-populate the caches and log out just to see if everything runs fast and looks good.

Does this sound like a healthy and effective approach?

Ipstenu, thanks. Yes, I actually did overlook setting php_value memory_limit to 64M in my .htaccess files.

Part of the problem with the glitches in, say, upgrading the themes was that I did not empty them out and reinstall from within WordPress 3.0. Perhaps that would be a good idea. It’s a little bit of a pain, but not much as I don’t generally keep around many themes I don’t use, and I don’t generally use many themes as it is a bit of a security pain to track them all.

But, what I seem to run into with the theme updates is that it may be running into a permission problem (or it could have hit a memory shortfall and died without an error message). But, when it failed, it sometimes left a .maintenance file in the root directory of my website, causing me to get the “Briefly…” message once again.

I’m starting to wish I could copy the things I found along the way, summarize it, and replace all my responses with one concise summary that would be able to benefit others who may run into this problem. Sorry for all the hyper-verbosity.

I did the manual update and got the “Briefly…” maintenance message again and running wp-admin seemed to get that “Briefly…” message.

I renamed my .maintenance file to .maintennceold visited
https://save-your-marriage.org/wp-admin and I got my dashboard with no error messages. Automatic theme updates was a great idea. I still find updating atahualpa seems to take a long time and failed. Probably another C-panel vs. Apache permissions thing.

I’m way too chatty. I’d better catch up with my wife and hit the sack.

This is weird. After getting the “Briefly…” message in wp-admin and the upgrade/update programs, I just pulled up the website at
https://save-your-marriage.org this time (sounds the same as the earlier one, but it’s different.

What happened is the site came up looking normal, and then when I went back to the wp-admin page, it seemed to work. I think I’m in the twilight zone…

One of my regular wordpress upgrades is being a bit of a pain in the butt at this time. upgrade.php said it was already updated and update-core.php gave the old “Briefly unavailable…” message. I may have to do the manual installation myself ??

One thing I experienced many times with automatic upgrades is that if there is anything in the wp-content/upgrade directory, the upgrade will delay for a long time and then give an error. I also noticed that automatic upgrades of the whole wordpress version will often leave behind a file that won’t get deleted when the upgrade is done. I also noticed that some plugins like gd press tools seems to leave behind upgrade files when it is finished upgrading. I found deleting them allows other upgrades to go through fast and successfully.

However, I’m having a little trouble with one of my normal wordpress upgrades under C-panel again. It seems upgraded but it keeps telling me the upgrade failed and that I need to retry. Retrying leaves a failure message. Yet it says I’m already upgraded to the latest version.

I hope your problem getting database connectivity was easily resolved for you.

By the way, if you try to create the file by hand, usually if your web server and database server are on the same machine, your server name may very likely be “localhost”, and many people limit database access to connections from local processes to keep hackers from hacking in from the outside.

Joel,

I wonder if Step 1 of the Manual Update might have thrown you off when it said that if you copy the upgrade files into your installation that wp-config.php won’t be overwritten.

If somehow you removed the wp-config.php file, that would wipe out the file that tells wordpress how to log into your database.

Do you have an old copy of your wp-config.php file? If not, are you able to log into your database, say, using phpmyadmin via the web or mysql from the command line? Do you have backups?

Dan

Do you have a copy of your old wp-config.php file?
If so, you should be able to find what your database settings were from that. When people have the web server and the mysql database on the same machine, they often set the server to “localhost” and even limit access to the database to localhost to keep people from hacking the database from outside.

I hope this helps and doesn’t hurt…I don’t know why an automatic upgrade should clobber your wp-config.php file though. If you copied in a new one, I think it loads in as wp-config-sample.php and doesn’t normally overwrite your wp-config.php file.

If you did overwrite everything, you may end up back into a fresh install I think, and the system may ask you for all the database information as though it were going to do a new installation from scratch.

Do you have backups where you can just quickly start from scratch and attempt the upgrade from the beginning again? Sorry, I hope I’m helping and not hurting…

Joel, it seemed to come back to normal.

I really need to mention something very important, and that is that the flailing and hacking I do is on my own personal hobby/blogging websites and they are not on business critical production websites. So, I can afford to tangle things up without having a CEO and four VP’s looking over my shoulder ?? If I were working with a business critical production site, I would be many times more cautious making sure change control policies and procedures were established and followed.

I don’t want to lead someone down a dangerous path by telling them how I hacked my way to something that worked for me. But, what I did seemed to bring me to a good, quick solution for my needs.

Dan

Another note:

Updating WPMU 2.9.2 to 3.0 was a piece of cake on Linux where I had full control. Upgrading my one site that was on a C-panel setup posed one slight pain in the rear, but it was not difficult to solve it. The only question is whether I’m really comfortable with the solution.

Upon upgrading, I was told to install the nonce line into wp-config.php.
The problem I ran into is that when I logged into C-panel to administer my web environment, functionally my login (internally my Linux login) was different from the login that the webserver runs under. That means files created by the wordpress-mu environment was, say, “apache” while I was logged as “dan”.

Solving the problem involved renaming wp-config.php to wp-config.old and then copying it back to wp-config.php. That made wp-config.php owned by “dan”, and now I could edit it. However, that also means “apache” may not be able to edit the file later.

Just a hiccup you might run into along the way.

Dan