durruti

When someone makes a trackback or pingback, it appears on my blog like this:

[…]This is the excerpt from the trackbacking blog[…]

Which is fine, but when I tried to validate any pages with the […] bit using the W3C validator, I got a validation failure apparently due to unrecognisable non-UTF8 characters. Changing the validator’s encoding option from automatic to ISO-8859-1 allowed me to validate the page (which it did perfectly) and check the source code. […] appears in the source code as […], and it was this that seemed to be the cause of the problem when trying to validate using the UTF-8 option. As far as I know it’s valid UTF-8 encoding so I couldn’t figure out why it was causing a failure.

escdotdot, adding your single line of code has sorted it out completely. The source code still reads exactly the same but the W3C validator now automatically recognises it as UTF-8 and validates it – no more unrecognisable characters. I have no idea why it works but it does, so thanks for sharing the info.

OK, this has sorted out the issue for me.

I’ve set the permissions for the css in the current theme folder to include ‘write’ for group permissions, which allows me to edit the css through the admin area, something I normally only do whilst actually editing – I’ve always reset group permissions to read only afterwards. Having done this I can now use the rich text editor without checking the ‘compress’ box AND the site now validates perfectly at the same time. So it seems all I need to do is leave group ‘write’ permission on all the time for the css, which is no big deal.

I don’t know why that’s the case but hey ho, it works and I’m happy.

UPDATE: I’ve think I’ve worked out what’s causing the problem and how to sort it out (rather inelegantly), but I don’t know why it’s happening.

In order to use the rich text editor I have to check the ‘WP should compress files’ box under options>reading in the admin area. If I don’t do this I can only see the HTML editor buttons (and yes, I have checked both the ‘use rich text editor’ boxes). If I then try and validate my site with the ‘compress’ box still checked, it seems to cause the above validation failure. Unchecking the box then revalidating shows my page as valid XHTML!

The only plug-in I’m using at the mo is Askimet (although I’ve tried it with no plug-ins and the same still happens). I’m using the latest version of FF and IE to test my site and the same thing happens in both browsers. I’ve also done a few completely clean installs of WP but the problem remains.

Anyone know why this happens (and ONLY on the main page and ONLY with the blogroll part of the page!), and have you got a more elegant solution than repeatedly checking and unchecking the ‘compress’ box every time I want to use the rich text editor? I’ll leave the ‘compress’ box checked for the next few days so you can view the validation error message.

Anyone?

HTH = hope that helps ?? Looks like it did!

Change your browser ‘character encoding’ settings to UTF-8 – in Firefox, go to View > Character Encoding > Unicode (UTF-8). You’ll need to do this for each new page you view. This will allow you to view your webpage / admin login page, which means you should be able to get in and change the code that’s screwing it all up.

HTH

Odd isn’t the word for it…

I’ve just clicked on the ‘next page‘ link at the bottom of my main page. This page and all subsequent ones also include my blogroll in the sidebar, just like the main page. Guess what? These pages validate perfectly!

Arrgh!!!

One other thing – the point in the source code that validation fails at varies every time I close down and re-open my browser (Firefox, natch). And the failure appears to be due to the validator reading a ‘0’ at this point.

Too weird for my little head!