justdreamweaver

I think I figured it out. The server set the WP database collation to latin1_swedish_ci rather than utf8_general_ci. That would explain the inability to save the utf8 characters.

UPDATE: altered collation to utf8_general_ci on wp_posts table and it works fine now.

Exact same theme on both. The live site is just a “playground” with no user access. Tested with TwentyFifteen theme and no plugins installed with the same result. Code was replace by a ?. Multiple browsers same result.

You don’t need the plugin to duplicate it. I can duplicate it just by inserting the following dec html code (remove spaces)

& # 9 8 2 4 ;

https://www.w3schools.com/charsets/ref_utf_symbols.asp

That’s the spades character in the UTF-8 misc symbols. On localhost running 4.1 it shows on insert and is retained after save. On 4.2-alpha-31471 on a live server it shows on insert and switching back and forth between visual and text, but on save it is stripped out and replaced by a question mark.

I developed a plugin that allows for easy insertion of Font Awesome icons into the editor. It parses the CSS file and grabs the :before content string for each icon and makes a selectable list. For example, the android icon (fa-android) CSS :before content is “\f17b”, which is the $unicode variable below.

When the icon is inserted into the editor, I use:

str_replace(‘\\’, ‘&#x’, $unicode)

That results in the HTML for the icon being (semi-colon appended before insertion):

& # x f 1 7 b ;
(remove the spaces as the forum editor was rendering a boxed question mark)

The icon appears in visual mode, and will be retained when switching back and forth between visual and text modes. As soon as the page is saved, the icon code gets replaced by ‘?’ and visual mode just shows a question mark.

It works fine in 4.1 but does not in any of the latest alpha releases. DB_CHARSET is utf8 in wp-config on the server.

Download your entire site, including all WordPress files. Do a search for the term base64 within all files. Changes are if you find a match with a garbled string of characters behind it, that file either doesn’t belong or has been hacked.

I downloaded my SQL backup files as well, and by searching for base64 found one forum user had uploaded a PNG image encoded as base64 and used inline CSS styling to hide the image.

Update on my issues with this. 444 did nothing as the script returned to the header file.

Upon further scanning of my site files, I found a couple of php files in the uploads directory. One was named new.php and was a base64 encrypted c99madshell hack. Not good. I run a couple of plugins that enable file uploads into the uploads directory, so I’m thinking that may be how the files were uploaded.

WP and all plugins are up-to-date at this point and passwords are changed, but I don’t know if there are any legacy files that I haven’t found. We’ll see what happens.

I’m having the same issue on one of my blogs. Waited too long to update to 2.8.4 (then .5) so 2.7.1 got hacked. I’ve scoured my files looking for the js injection, and I did find an upload.php file inside one of my upload folders and removed it.

I removed the function KoiQBOL script and spam links from the header.php file, only to have them return the next day. I set permissions of 444 on the header.php file to see if that keeps it from writing the links in, but it’s not a solution. I still don’t know exactly where the script is being inserted from.

Just go into your header.php file and add the links manually following the navigation loop. Then any pages in WP will display before your links, but you can direct your links manually to anything.