wpress2010

Weird, weird, weird!

I am working on a site where unfortunately the previous “maintainer” put all of his custom CSS into the primary theme file, instead of using a child theme or an additional custom CSS file.

I traced the problem to a single line of code he had added, thus:
#comments { width:100%; }

I just commented it out (ironic…) and everything went back to normal.

The typical bag of plugins, together with inevitable problems when something gets updated (and breaks something else…), is always fun with WordPress!!

Thanks for your help.

Thanks – the re-build did the trick! The problem was that sometimes Relevanssi found the string, sometimes it did not, and the failure was specific to a certain group of posts – by age. I assumed that it was some kind of indexing thing, but couldn’t figure out how to re-index. I took over site administration from someone else.

Bad typing! It was 3.5.1, but now is 3.6.1, as I just updated WP.

The Permalink problem persists. I am delaying updating the Twenty Eleven theme itself from its current version (1.3) until I can make sure I know what the previous admin did to customize it, if anything. I have updated all of the plug-ins, tho’, without incident.

Forgot to mention: WP 2.5.1, twentyeleven theme. I just “inherited” site management from a former admin.

I was going to try de-activating all of the plugs, since that’s the most obvious source for possible conflicts.

Can’t try anything that would render the site “funny” until the wee hours when traffic is likely to be sparse, but I will get to it soon, I hope.

Oddly enogh, I had enabled WP Super Cache, and then changed the Permalinks to Pretty. When all ^%$#!@+ broke loose (i.e., the Continue reading” links were broken…), I deactivated the cache plug, thinking that was the conflict, but the links problem remained.

Conversely, when I reset Permalinks to Default and Activated WP Super Cache, the caching worked fine and the links problem went away.

No cache plug that I can find.

I went into the WP dashboard, went to Posts, found the Post I was trying to edit in SQL, edited it via the Dashboard Edit button, and immediately saw my changes when I viewed the site.

But when I tried the same thing in myPHPadmin, and the UPDATE reported success, the changes were NOT seen on the site, even after a browser cache clear and logging off the site, logging back on.

Investigating further, I found what is the probable – but weird – source of the problem.

The post titles (H1 elements) are rendered in the Google font, Della Respira. In some titles, the author used the single quote character (&#0146) (‘) which in some cases is interpreted as the single prime glyph (&#0139) – they both render the same in this case.

The Della Respira font LACKS the prime glyph! So, the system tries its best to render something, and what it substitutes is the right quote character. Sometimes this character appears properly, sometimes it appears in a different font, i.e. the default. This is because the single right quote glyph is BROKEN in the Della Respira font! I tested this on Google’s own font site.

The upshot, strangely enough, is that when the Categories list (which is styled with the default sans-serif font) is drilled down to the individual post containing the glyph problem, instead of rendering the missing prime character as a right quote, it instead spits out the ASCII for the prime glyph – &#0139. Totally weird!

The solution? Just change the buggy/missing Della Respira glyphs for ones that work, in this case the left and right “grave” marks, &#096 and &#0180, respectively, in the individual post titles. Looks OK in that font. Once this is done, the Categories list, drille down to the individual post, displays the post’s title just fine.

Just to cover all the bases, I went in to the site’s PHP configuration, and it turned out to be running PHP 5.2.something, a version that still supports magic_quotes. But magic_quotes was properly set to off.

Fun!