Docs

[Rad]

Hi there,

I did some research from the old listing of bugs and confirmed that ® issue is one of them. It’s around 1.0.6 version of the cornerstone and should already be fixed in versions greater than 1.0.7.

The proposed temporary solution is to replace ® with ® before saving. Adding ® directly will destroy the content due to encoding and other contributing factors.

You can try cloning the site and update it, though, that doesn’t mean that ® will be converted to ® automatically. HTML entities are safer to use since they don’t have to be encoded as special characters.

You can check their equivalents here https://dev.w3.org/html5/html-author/charref

Thanks!

[Chris Stovall]

Well. Previously in this thread, I had done that the to GTG site. Unfortunately, there are 2 issues here.

1) The site in question does have any “®” on the pages.

2) This is from a earlier in the thread

April 24, 2016 at 10:09 am #897468
REPLY

Chris Stovall

I spoke too soon. The pages that had the ® on them broke. I even used the HTML tag for the ® but it didn’t help. The theme converted the HMTL to the actual ® on page and in the DB. Once I ran the script, those pages were toast. The cornerstone data was present on the page but I could not edit the page. I had to rebuilt it. I have the files and DB of you guys would like to look at them.

I’ve now removed all ® from the site. I think this will fix it.

Attachments:
Screen-Shot-2016-04-19-at-2.46.56-PM
Screen-Shot-2016-04-19-at-2.46.56-PM.png
April 25, 2016 at 1:10 am #898130
REPLY

Rad

Hi there,

Thanks for sharing, I’ll check that too could be related to html_entity_decode().

Thanks.

I really hope we can find the cause of these issues. On the GTG site, it happened 2x. I had to completely rebuild the site each time.

Again, it seems to be on import to a MySQL DB.

Can you please test this. Import these two versions and see what’s happening?

CDS

[Rad]

Hi there,

Sure, would you mind letting me know the MySQL encoding from source site and destination site? It has a big role in special characters and character issues are always related to encoding. WordPress also changes database encoding upon upgrading, hence, if you recently upgraded then it’s converted to utf8mb4 instead of usual UTF8 encoding. That’s my only guess, for now, and if that correct then you’ll have to manually re-do the content to match the encoding. As of now, I’m not having the similar issue on my installation that uses special characters.

Thanks!

[Chris Stovall]

Oh well. Thought I’d try again. Back to redoing cornerstone sites. There was a person on the FB group that had lost over 2000 pages for the same reason.

Is there no way to make sure your code is able to handle the WP DB update?

[Rad]

Hi Chris,

The database update is done through WordPress core or manual transfer. Themes and plugins have no way to preventing it since that update will bypass everything. It may even stop you from logging in just to confirm the update.

As for the manual transfer, WordPress, theme, or plugins as nothing to do with it, since we, the user, are the one doing it manually. Any issue caused by that process will, of course, affect the themes or plugins that are dependent to those data.

I had the same issue even from my old projects and it happened regardless of theme or plugin. Cornerstone is more on data processing and rendering (compared to just displaying the content) and that’s why it’s highly affected.

We’ll always improve cornerstone, but there is always a limit it can do especially it only uses the resources given by WordPress. I can only recommend that not to automate all your update and have multiple backups. And always check database source for comparison to the destination’s database.

Thanks for understanding.

[Author]

Posts