davidhouse

I suppose it’s possible that an enormous amount of text could be larger than the 10-megabyte upper storage limit for TEXT, especially if containing thousands of font tags repeated over and over. You might find mySQL column types storage requirements useful.

You don’t necessarily have to change everything when a new version of WordPress comes out. I have a file in wp-content/plugins/ that contains all the functions I’ve hacked, all with a dmh_ (my initials) prefix to their name. So when I hack a function, I’ll copy-paste the code, rename it with the dmh_prefix and then change the code that I need. That way, I can continue to use (or not) these functions and the original files in /wp-includes/ remain untouched, ready for upgrade.

To answer your question: not likely, it’s probably you just had some CSS in places the fix authors didn’t realise. For the record, you could have used !important when changing the body font-family to get the right effect, but the solution you have is simpler, and therefore better :).

From plugins.php:
if ($user_level < 9) // Must be at least level 9
die (__("Sorry, you must be at least a level 8 user to modify plugins."));
So yes, you have a point. Simply change that block of code to read:
if ($user_level < 9) // Must be at least level 9
die (__("Sorry, you must be at least a level 9 user to modify plugins."));

bstovold: charle97 meant that hacking a function to make it return rather than echo is a simple process, not that it’s possible without hacking.
Yes, it’s simple, but I think that making WP simpler to use for hackers is something that needs to be addressed. Whether that’s having an annotated version available (maybe online), or by adding a customary $echo paramater, it’s a good idea.
Bottom line: it’s easy to hack, but in this instance at least it shouldn’t be necessary.

Amen. I hate having to hack functions just for that one extra parameter.

Check your errors.txt file. It’s normally caused by a parse error in the PHP. Most browsers will display an empty page with just those tags if it recieves no information.

IMG are inline level, they can be contained inside P.

And in that last post, that should have been &#92. Post preview would be nice…

Oops, in that last post, the ‘&amp#92’ should have been a backslash.

A couple of extensions:

//gets total number of characters posted
function get_charcount() {
global $wpdb, $tableposts;
$posts = $wpdb->get_results('SELECT post_content FROM ' . $tableposts);
foreach($posts as $post) {
$count += strlen($post->post_content);
}
echo number_format($count);
}
//gets total number of characters posted, excluding whitespace
function get_charcountexws() {
global $wpdb, $tableposts;
$posts = $wpdb->get_results('SELECT post_content FROM ' . $tableposts);
foreach($posts as $post) {
$text = preg_split('/\s/', $post->post_content);
foreach ($text as $tex) {
$count += strlen($text);
}
}
echo number_format($count);
}


I suppose you could create a new instance of the wpdb class, passing it the parameters of your other blog, then duplicating all the calls to $wpdb->get_results(), but I don’t know WP or mySQL too well and there’s probably an easier way.

Okay, when I print_r HTTP_GET_VARS on a search that only revealed a single result, ‘year’, ‘month’, ‘day’ and ‘name’ are set, but not ‘s’.

It should be. wp-comments.php looks the same, that’s the only file I’ve modified.
[Note to self: start downloading nightlies more frequently]

This is getting to be very strange. I’ve put print_r()s all over the place, but HTTP_POST_VARS always seems to be empty, even before any other php code has executed.