grantbarrett

Sorry about that. Thanks for the reminder.

That’s too bad. It would stop many of our false positives.

Sorry, that’s ugly.

I solved the problem and have pasted the solution here: https://github.com/WordPress/gutenberg/issues/19552#issuecomment-1758798993

This is where I derived my answer: https://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8

• This reply was modified 1 year, 5 months ago by grantbarrett.

PS: Following these instructions solved the issue for me: https://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8

I didn't have sufficient privileges to just run a SQL command in phpMyAdmin, so I did a modified version of what is given there.

I logged into my server via the shell, then generated a list of tables with this:

mysql -e "show full tables where Table_Type = 'BASE TABLE'"

Then I converted that output to a .sql file (which I named "change_charset.sql") where each table gets a line like this:

ALTER TABLE ReplaceWithTableName CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

At the very top of that file put this line:

ALTER DATABASE DATABASENAME CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Then I uploaded that change_charset.sql file to my server and figured out its path, then executed this command:

mysql -u awww -pPASSWORD -h HOST -P PORTNUMBER DATABASENAME < /sites/user/change_charset.sql

If you are going to follow my steps, replace PASSWORD, HOST, PORTNUMBER (if needed; if not needed, remove "-P PORTNUMBER"), and DATABASENAME in the above MySQL command with the equivalents for your own server. You can find these in your wp-config.php file in your root HTTP/web directory.

This emoji problem appears to be occurring to other users and sites: https://github.com/WordPress/gutenberg/issues/19552

Hmmm, perhaps something did work. The WordPress.com settings page shows a full sync in progress. I will keep an eye on it.

PS: For others who come later, I followed these directions for checking if/how the sync was progressing

https://www.techcoil.com/blog/how-to-get-jetpack-to-resync-your-self-hosted-wordpress-contents-with-wordpress-com/

• This reply was modified 3 years, 4 months ago by grantbarrett.

I ran it through its paces in troubleshooting mode. Using the WordPress 2021 theme with only the Jetpack and Site Health plugins activated, clicking on the link to manually activate the sync did do something this time, but after a brief page load, it returns the same error message and the problem does not seem to have resolved.

• This reply was modified 3 years, 4 months ago by grantbarrett.

PS: Extra Web Security was already enabled for both domains.

a large .htaccess file will make your site slow.

Yes, of course.

I will look into the Extra Web Security. Thanks!

Same here. Borked. Trying to revert to the last version now.

I’m having this same problem. The “Canonical Settings” under the “Permalinks” section of Yoast SEO is set to “Leave default.”

Here’s an example page of where the title isn’t working as it should:

Title: “Discussion Forum – A Way with Words, public radio’s lively language show” — it does not contain the topic name! https://www.waywordradio.org/discussion/topics/doozy/

Here are two images that may help: “Yoast WordPress SEO: Titles & Metas” settings page and “Simple:Press Administration: Components” settings page.

https://www.waywordradio.org/yoast-settings.PNG
https://www.waywordradio.org/SP-settings.PNG

I am also discussing this on the Simple:Press site, but I am thinking this will require developer cooperation.

I’ve got the same problem. Very annoying. It happens in every custom field, every time I created a new one, for any post.

Thanks, Donncha. That’s exactly what was needed.

Iridiax, when I examined the files I used BBEdit and turned on “Show Invisibles” which displays grey symbols for spaces, tabs, and the like.

I’d like to confirm that after a thorough comparison of my directories to a previous download, and after a line-by-line inspection of core files, that this hack was done without changing a file on my drive, without inserting a new file, and without special access.

As I wrote above, I believe this is simply a failure of WP to sanitize search input and output.

Aside from the ideas I gave above, this hack can also be nullified by removing all instances of <?php echo $s; ?> from your search results page (which should be “search.php” in your “themes” folder in wp-content).

In my search.php I had the php echo of the search term in three places: in the sidebar.php file that is called for inclusion by search.php, where it would auto-fill the search field there with the search term the user had just searched for; at the top of the page (but not in between the <title> tags) as a headline for the page, and right above the search results listing.

Yes, I have looked high and low for anything suspicious. So far, I’ve come up with naught. Still looking, though.