XML Parsing Error at. Error

After moving a site to a new server I found this error in the backend - at least one error per page, but casually even more.

XML Parsing Error at. Error

No error number, no line number... What a heck!

Of course, my first stop was the error log files, but all I found was this:

[16-Dec-2011 12:30:22] PHP Warning:  xml_parse(): 2189 is not a valid XML Parser resource in /home/*****/public_html/libraries/joomla/utilities/simplexml.php on line 234
[16-Dec-2011 12:30:22] PHP Warning:  xml_get_error_code(): 2189 is not a valid XML Parser resource in /home/*****/public_html/libraries/joomla/utilities/simplexml.php on line 236
[16-Dec-2011 12:30:22] PHP Warning:  xml_get_current_line_number(): 2189 is not a valid XML Parser resource in /home/*****/public_html/libraries/joomla/utilities/simplexml.php on line 237
[16-Dec-2011 12:30:22] PHP Warning:  xml_get_current_column_number(): 2189 is not a valid XML Parser resource in /home/*****/public_html/libraries/joomla/utilities/simplexml.php on line 238
[16-Dec-2011 12:30:22] PHP Warning:  xml_parser_free(): 2189 is not a valid XML Parser resource in /home/*****/public_html/libraries/joomla/utilities/simplexml.php on line 243 

The next logical step: Google which returned 3.530.000 plus hits - leading nowhere. The only usable info was one link from one of hits which explained why packing up your template files for Joomla from a Mac can lead to some similar error - the shadow XML file added to the package. So I learned couple of things about Apple Double format too:

The AppleDouble format was developed by Apple Inc. for storing file metadata and resource forks in a Unix-like file system. The format's most notable aspect is that for every original file, it adds a second file with a name consisting of the prefix "._" followed by the original file's name. Thus for an original file "templateDetails.xml" it adds a file named "._templateDetails.xml". This second file can contains metadata (data describing the original file) and a resource fork (a second part of the original file, used in the Macintosh file systems).

And this was the bit of information which helped me to solve the issue. The later discussion with the site owner confirmed, what happened. Read it, you can learn a lot from!

Here's the detailed story:

After her site was hacked several times, despite my countermeasures, I advised her to abandon her cheap hosting company, and move the site to a proper host, one which uses PHP's su_exec library, as is recommended. she listened, but to cut down costs, he moved the files "to help me". Of course, the site had problems after the move, and here I did my part of the mistake: I leaved the files moved by her and moved the site again using Akeeba Backup.

The site worked fine this time, just this annoying error popped up.

What happened? When she moved the files, her FTP client asked her if all filenames should be changed to lowercase. And she clicked on "YES". When I moved the site again, all files/folders with uppercase letters in them, as for example:

/administrator/language/en-GB/en-GB.xml

(this one was the main culprit) ended up to have multiple copies, like

/administrator/language/en-GB/en-gb.xml

and

/administrator/language/en-gb/en-gb.xml

After deleting these un-neded "shadow copies" the site began to act as expected.