mat8iou

Hi

I only just noticed your query.

To be honest, I’m not sure what would be causing the problem, as the problem doesn’t show up for me on the latest version of WordPress with the current version of the plugin. Do you have any plugins installed that would be likely to affect this? What version of WordPress are you running?

I run the plugin on 2.3.3 & it appears to work. If I change the wp-config encoding to utf8 then the characters still appear wrong (quotes as a € for instance). So when I ran the plugin, did it do anything at all?

I finally emerged from a long period of university exams & began updating my site to WP 2.3

I spent a while working out how to update my own plugin – finally did it, only to discover that other kind people had already done it for me…

I guess I should have checked here first before spending time on it.

Thanks ??

Same thing (published on the same site) happened to my site a few days ago (spotted it yesterday).

The only thing that was changed though was the title on the pages. I upgraded to the latest 2.0.x version of wordpress & corrected a few directory permissions & changed my login password – I am unclear though if there is anything else that should be done. Not knowing how someone else got in means that it is unclear how to block them out the next time – how far should one go with regard to changing password for instance? Should the MySQL database password also be changed? It would be good if there was a guide to:
A. Secure the program to prevent such attacks happening in the first place &
B. Trace how attacks were made.

I just found the same problem with my site.

By comparing working & non-working themes, I noticed that my theme was missing the line:
<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />
Instead the reference to the stylesheet was writtne:
<style type="text/css" media="screen">@import url( <?php bloginfo('stylesheet_url'); ?> );</style>

Adding in the first lot of code to my header.php file seems to fix the problem. the file still validates fine & now it displays correctly. I don’t get why writing it as in the first line should be a problem though.

Thank for this solution to the problem – I din’t notice that I’d had any replies until just now.
The thing that I find strange is that it used to work fine on 1.5.x – it was only with 2.x that the code caused these errors.

There may well be plugins to do this – one thought though, is could you create a cetegory for each isue & then view the category to see that issue?

This is pretty awkward if it is the only way to solve the problem.

I’l probably end up writing my own function to try & fix this. It must be fairly simple to update how it works, as the title etc allready escape the ampersands correctly.

Doesn’t do it for me.

The problem that you describe (which I have seen before) is this one:
https://www.ads-software.com/support/topic/30278

Caused by white space at the start or end of a php file.

I never knew you could do that to make them all display like that.

I’ve updated it, at the same location as before, to detect whether the -1 value is being used.

Glad you think it is useful.

This code (taken & modified out of a plugin) should do what you want.

<?php
preg_match('#FROM (.*) GROUP BY#', $request, $matches);
$fromwhere = $matches[1];
$numposts = $wpdb->get_var("SELECT COUNT(DISTINCT ID) FROM $fromwhere");
if (0 < $numposts) $numposts = number_format($numposts);
?>
<?php printf(__('Your search found %1$s matching posts'), $numposts, 'edit.php'); ?>

Just two days after I went through the other poll plugin, tweaking various bits to make it appear the way that I wanted & then editing it to produce XHTML 1.1 valid code, I was looking for something else & discovered this plugin that did everything that I had wanted to do in the first place. (The reason I didn’t discover yours earlier was that I’d downloaded the other plugin months ago – actually modified it to work in 1.5, as at that time it would not.

Excellent

I’ve just been through my site this morning & updated a few tags so that it validates as 1.1
It didn’t really take that long (& was the first time I had tried to get anything to validate as 1.0 strict or 1.1)
Mainly it was moving a few deprecated tags & updating some tags that occurred in the wrong place – they needed to be inside other tags for instance.

Most of the code that gave problems was produced by plugins in the first place, but I also took the oportunity of going through the code to generally update a few bits of PHP, based on what I know now, but didn’t know when they were originally written.

It would be interesting if (instead of sites popping up messages saying – best viewed in MSIE) browsers would show a message in the title bar, or status bar whenever sites did not validate as the DTD that they were using & also made it clear which DTD was being used. (Would this help to get rid of any of the bad coding any quicker.)

You need a plugin like this one:
https://dev.wp-plugins.org/wiki/AuthorHighlight

& then you need to give it your details & alter the CSS accordingly.

Have you tried altering the CSS to see it in a font that you know contains the unicode characters?
If you try to edit the post does it show the correct character again in the edit field?