akc

Apparently this is not possible in 2.0.x. And the bug tracker shows its priority is “lowest”. That’s embarrassing…. See https://trac.www.ads-software.com/ticket/1540

Yeah, recently I started co-editing a blog with someone I hired. In Movable Type there’s a built-in activities log that records edits. Would love to see WP have something similar, either built-in or via a plugin.

CamWheeler’s right (thanks!): I was unknowingly running a “hybrid” version of 1.5 and 2.x. What happened was that some of the 2.0.3 files had dates older than those on my FTP directory.

Just upgraded from 1.5 to 2.0.3. At first I suspected my Connection theme had compatibility issues, but now it seems 1.5 themes should generally work with 2.0. I’ve opted for the default link structure, to no avail. Hosting company did upgrade to MySQL 4.1.19 recently — don’t know if this is an issue with PHP (caused me a lot of problems with Perl).

PS: Deactivated all plugins — same problem.

Look for “rss_language” in the wp_options table.

I did just that, but boy, it really added a few minutes to the famed 5-minute installation ?? Details like this make me keep my MT for a while longer.

snowgoon,

No, this fix is specific to the localisation problem mentioned above. The problem you mention (HTML named entities mistakenly being included in feeds) should be easy to fix but I’m not familiar with the issue. A good solution would be for WP to convert all HTML entities (named or numeric) to their real Unicode characters (this has the advantage of being human-readable). In my blog I also use “special characters” for Taiwanese romanization, but I input them directly.

Hi,

The devs have fixed it: https://trac.www.ads-software.com/changeset/2366

It’s too late for me to explain it for those who need it boiled down, sorry ?? if u’re on the other side of the world, please help, thanx

ps: might have to add a test entry to force browser to get a fresh feed so u can see the fix in action ( i was puzzled by this for several minutes). time to bed!!

I’ve encountered the same thorny problem. What happens is that the hosting company decided to use something like mod_security to deflect possible spam-tainted data before it reaches the Apache server. Problem is, when people have a list of ban words and try to update WP’s options (../wp-admin/options.php), mod_security sees that list and thinks it’s spam-tainted. This occurs even when you’re not trying to change the blacklisted words, because the form sends out all the data including the list. Deleting the list should solve the problem but at the cost of bloggers not having control over what to ban.

In my case I tried to get Total Choices Hosting to help me, but got a “well, that’s the way things are” response.

Would it be possible for our great WP developers to issue an advisory to the hosting companies on the Right Thing to Do? (As for me I’m starting to contemplate moving to another service.)

The plugin (as included in WP 1.2) does not work with languages that don’t use space to mark word boundaries, such as Chinese, Japanese. This can be fixed most easily by removing the \b from instances of

/(\b$term\b)/i

Basically just forget about trying to detect word boundaries and just highlight all matching terms. This could cause “mail” to also highlight “Gmail”, “email”, etc. But hey, this could be a feature, too.

Caveat: above hack not yet tested, so….

Me, too. I’m currently trying to figure out how to make WP (or is it Textile2?) not convert “accented characters” into HTML character entities. It’s really unnecessary.

I added some filters to Textile2 but the resulting feed had HTML entities that made it invalid. Does any one know how to skip entity conversions?

Update: I moved up applyfilter and that seems to solve the problem. The entities remain but are now properly escaped for XML. I think they shouldn’t have been converted in the first place, though, but that’s another story.

Today I noticed the redirected link (which had a whole bunch of querystrings) got chopped off by Google. So I’ve turned off the plugin pending investigation. Probably some characters not being escaped?

Oh, btw, since WP is by default Unicode (UTF-8) encoded, there really isn’t much of a reason to use HTML numeric entities to refer to Unicode characters (e.g. &# 36453). (Little reasons include: some old, buggy browsers, maybe? Using numeric entities to call up hard-to-type Unicode characters.)

And I guess we could be a bit more precise by dissing only those author fields having entities for *low* ASCII (i.e. the usual alphabet, numbers, punctuation marks). This will let through Chinese spammers spamming in Chinese, for example. But that hasn’t been a problem on my blog (only my email!)

I’ve been plagued by this problem too (I’m on 1.2.1). Following Lucky1/bjoern, I’ve made slight modifications in the functions.php script (under wp-includes) to

1) stop processing comments where the author field has the characters &#. (On an English blog those characters are not necessary at all and are a reliable indicator of spam.)

2) stop processing comments where the author field matches a spam word: I got tired of disapproving spam.

By “stop processing” I mean the script stops running right after spam has been submitted but *before* it enters the database. Comments not fitting the above cases will be processed as usual.

I added the following as the very first line of function check_comment:

if(ereg(“&#”, $author)) die( “Oh…it’s a spammer…” );

(Note that even if you have comment moderation and/or link counts turned on, comment like this will still not be submitted for consideration).

I also changed

if ( preg_match($pattern, $author) ) return false;

to

if ( preg_match($pattern, $author) ) die( “Oh…a spammer…” );

Again, it tells the script to stop further processing if the author field matches a spam word. This is strong stuff, so you may want to leave this out.

See also: https://www.ads-software.com/support/topic.php?id=20843

bjoern, you are right. Sorry I didn’t look more closely.