Kitten

>Ah, now I remember why this didn’t work before.
>Remember, I have HTML data with quotes around attributes.

Why isn’t your data properly escaped? Then it’d be properly inserted into the database.

Make a post in WP with some HTML in it, dump it & look at it. Then you’ll see what the format should be.

Yeah, that’s kinda cool, ain’t it ??

It’s documented in the change log. It does 3 things:

1. Gives you more info about what processing was done.

2. Provides meta data about a comment’s ‘spaminess’ and could be extended by further processing of the comment, like Spam Assassin headers in your email.

3. Proves that it’s working to the skeptical.

Each character entity is treated as a point, so there has to be more than a couple to kill the comment. I’m thinking of changing the default to 2 points/per.

Also as I improve the admin page, the points for each kind of offense will be user settable.

Spaminator Checks for this sort of thing.

https://blog.mookitty.co.uk/wordpress/spaminator/

tmp $ tar xzvf wordpress-1.2.2.tar.gz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Read 938 bytes from wordpress-1.2.2.tar.gz
tar: Error exit delayed from previous errors

Just grabbed it off the site a few minutes ago. The .zip file is fine.

Databases aren’t mind readers, you have to tell them what is where. That’s done in the insert statements.

INSERT INTO wp_posts ( foo, bar, baz, etc...) VALUES ( one, two, three, etc... );

So that foo is one, bar is two, and baz is three.

Now you just have to have valid WP field names in the first set of ( ) (the ‘where’) and the post info in the second set, (the ‘what’). As long as the what is mapped to the where, and the where exists in your table, it’ll import and be where you want it.

Ok,

1. You can’t import HTML pages into a database as records. It’s not a field delimited format. Really. It isn’t.

2. Don’t try and munge it into MT format first. Why? Because it’s not necessary.

3. Convert the data into WP compatable SQL statements.

3a. How do you find out what WP compatable SQL statements are? Easy. Export your wp_posts table and look at how it’s formatted. (Don’t use ‘extended inserts’ format, it’s less readable.)

4. Then import those SQL statements into the database via phpmyadmin or the mysql command line.

5. Enjoy.

You’ll have to edit your feed generator files (wp-rss2.php/wp-atom.php) to do what you want. They have a loop just like the main of WP, so you can get a post’s content’s and process it to your heart’s content.

Save it as a new file, and point your feed reader at it.

Also, if you’re fixing something, there’s a good chance that you’re not the only one w/ the problem.

Check mosquito, and file a bug if it’s not been reported. Then upload your patch to the appropreate bug report so that devs and others can find it.

This is the best way, because not all the devs get the helpout@ emails, so if you’ve scratched someone’s itch, it’ll get committed straight from the bug report.

ok, thx, let me test it

Blame companies like Google for ruining the meaning of ‘beta’ by having gmail/groups/news/etc be “betas” for years on end.

Now it seems that the accepted meaning of “beta” is, “the cool new version.” Not “hmmm, this could be broken.”

Now that WP is in beta and out of alpha, the only thing that means is the API has stabilised, mostly. Any changes from here to release are going to be bug fixes.

Yeah, requiring PEAR would only break more things. Best to just comment out that section.

Tg,

That’s when you use mosquito and make useful, descriptive bug reports.

I would make Spaminator IIS friendly but don’t have access to one.

No hardware = no support. That’s how things work.

from your wordpress root directory, do:

cvs up wp-includes/functions-post.php

That will only update the one file.