kintopp

You’re right – removing check and optimize fixed it (repair was never toggled). I suspect that at some point Dreamhost made some changes to their internal permission sets for MySQL databases because I started seeing the same error on all the WP sites I host with them.

Ha, yes – that’s true. I do know what you mean. I’ve been grumbling over obscure CJK encoding issues for weeks and it’s a good feeling to finally straighten it all out.

In the latest version of this table the problem is not reproducible. Previously, hiding the last column after the column with hyperlinks could trigger it. Here’s a link to the JSON export of the current version. Perhaps comparing it to the previous version which you already have will reveal something. The previous version also had some awful custom CSS but I guess it’s unlikely this would have made a difference.

https://dl.dropboxusercontent.com/u/1667511/tablepress-export-2014-08-20-14-43-56-json.zip

And the public version of this table can be viewed here:

http://kanjialive.com/214-traditional-kanji-radicals/

I’m going to mark this as resolved since I managed to work around (though without actually solving) the underlying problem. Also, the links to the above test pages and sample data are now defunct.

I believe I found the answer… In short, if there is a column to the right of the column with the anchors, then we get consistent behavior in Safari/Chrome and FireFox. If there is no column to the right of the anchor column, then the behavior diverges as explained above.

I’ve modified the contents of the two test pages to reflect this.

1. With a column to the right (i.e. “ok”)
http://kanjialive.com/new-radical-table-test/

2. Without a column to the right (i.e. “broken”)
http://kanjialive.com/more-tests/

Both tables use id to designate the anchor. Here is the JSON export for both tables in case you want to try and reproduce it:

https://dl.dropboxusercontent.com/u/1667511/tablepress-export-2014-08-15-00-19-06-json.zip

No, sorry I wasn’t expressing myself clearly. I meant that it works on the old table http://kanjialive.com/more-tests/ regardless of whether I use name or id. Row 5 uses id, the others name and both work.

Here’s one more test. The same data as in the original, problematic table (all using id) now re-created with all cells using name instead. Same problem. That’s what puzzles me..

http://kanjialive.com/yet-more-tests/ (all using name)

I think I’m going to just employ a simple graphical workaround to get this done: create a 72px high white background and then overlay my 52px high logo onto it appropriately. Then save that as a PNG for use on the site.

Thank you for the very quick response.

With the help of a friend, I’ve now got a solution that’s almost accomplishes what I had in mind. In the child theme / custom css area we added:

#masthead hgroup {
	background-image: url("http://kanjialive.com/wp-content/uploads/2013/10/fan_logo_104.png");
	background-position: right center;
	background-size: 52px 52px;
	background-repeat: no-repeat;
}

This centers the logo vertically in hgroup and would be perfect if the logo were 72×72. However, what I’d ideally like is for the logo to be placed so that its top aligns with the dot on the “j” in Kanji alive and the bottom aligns with the baseline of the site description. That height corresponds approximately 52px. Here’s a mock-up to better illustrate this: https://dl.dropboxusercontent.com/u/1667511/site-logo.png