Brak

I wholeheartedly agree. I used CSS before anyone was, and hell – I didn’t even know what I was doing really. It just made more sense to me than tables. I learned tables after I learned CSS (We’re talking back in ’97 or so). It’d probably be worth your while to learn it. Just a matter of opinion of course.

If you are comfortable with PHP, it should be no problem. If you’re proficient in either PHP or CSS, no problem. Neither, you’ve got issues.

It spams wp-comments.php with random post ID’s, so it’s completely random on which posts it appears. You can rename wp-comments.php to solve the problem, or blacklist him ??

Keep in mind that while that will work for /about/ it won’t work for /about ?? Need to get the question mark in there I believe (or add a separate rule without the trailing slash..) Also, you shouldn’t start off with a / I don’t think it’ll work that way.

It’s the check for pingbacks feature. Are you disabling it under options (not the checkbox when writing a thread)?

/%category%/%postname doens’t work, it throws the entire thing into a full loop because of subcategories.
So we have structures like:
/category/subcategory
Which is the same as:
/category/postname
It throws it into an endless loop directing it two (actually about 4) different places at once. If you don’t use subcats – no problem. If you do – you’re screwed.
My solution: /archives/category/postname. It’s meeting it halfway.

WP handles this a lot better. I’ll explain why:
With MT, your pages are “re-created” each tim you post. This results in a big surge of CPU power, and then a lot less during normal traffic. If you have multiple postings per minute, it takes up a LOT of CPU power. However, if you post once a week – MT in this regard is actually ‘faster’ or less harsh on the CPU.
With WP, each pages is “re-created” each time someone view it – however it takes far less CPU power. So, whether you post a new entry or not – the same amount of CPU power is used. It’s more dependent on traffic. In this regard – WP is much faster than MT.
So, if you were to break it down:
MT’s CPU usage is dependent on amount of postings/comments
WP’s CPU usage is dependent on traffic.

Umm.. it’s quite simple.
ob_clean() // Get rid of anything that was already spit out
include "file.php";


Hmm, thanks for pointing it out – that’s what I remembered seeing a while ago. Unfortunately, this doesn’t do much to solve the problems I was encountering. Seems like this hack just adds FULLTEXT search capabilities. I think I’ll go ahead and write my own little function to encorperate the stuff that I want in it ?? If I get somewhere with it, I might just release it as a plugin.
If anyone’s wondering what I’m looking for, I wrote down a few notes last night:

• Support for “+” (must have) and “-” (must not have)
• Search title, content, excerpt, or comments (or any combination thereof)
• Search within a date
• Search for at least one word in phrase
• Search exact phrase
• Search for combinations of exact phrase and any words

Mostly, the basic functionality of google searches. And of course, relevancy scoring (going to have to think about this one for a while).

Aye, there are a few very minor bugs (mostly revolving around the change of querystring entities) in the code, but overall 1.3 is damn stable. It’s also cleaning up quite nice while keeping backwards compatibility to 1.2 template functions.
I’ve used it on my main blog (link in my profile) since august and still have no issues with it. I’ve run into no show-stoppers.

You would have to do some kind of bandwidth limiting, no matter your fleet of servers (because that’s what you’d need) you can’t sustain hundreds of thousands of hits per second on the same file constantly.
If you developed a smart algorithm for getting rid of rouge submissions it could work. Maybe if you had to register, and you check the submissions by IP of blog and IP os poster, compare those to overall and give it mandatory X submissions before it’s on the blacklist. It wouldn’t be too bad, might take a night to develop the formula. In fact, the whole project is going to be pretty easy to make if someone makes it, the hard part is going to be putting it into WP transparently.

Sounds like a good idea to me. A regularly updated XML file would do the trick. Then just have the plugin download a new XML file every day or by request (to alivieate server load).
But how would you deal with people submitting bogus information (real posters)?

/%category%/%postname%/ does not work. It causes issues everywhere throughout the site. Namely, you can’t access /wp-admin/ or any subcategories for that matter. The rewrite rules need to be re-thought, because to me, /%category%/%postname%/ is by far the best choice.

Do you mean generating the HTML? I’ll take a small excerpt from my index.php:
<h1><?php the_title(); ?></h1>
<cite>Published <?php $entry_datetime = abs(strtotime($post->post_date)); echo time_since($entry_datetime) ?> ago by <?php the_author() ?></cite>
<?php the_excerpt(); ?>
" class="more">read more
<p class="details"><span class="commentlink"><?php comments_popup_link(__('no comments yet'), __('1 comment'), __('% comments')); ?></span> | posted to <?php the_category(' | ') ?>

Notice how it’s set up differently from the default install? All of those <?php tags are in essense the stuff that WordPress is spitting out. So I could do something like this:
Expand Details
<div class="expand">
Author: <?php the_author() ?>

Category: <?php the_category() ?>

</div>
After some CSS styling and writing my doSomething() function in javascript, I would have the same effect that he’s had. Just use the template tags in WordPress to manufacture your HTML.
I hope that helps a bit…

In 1.3 there’s a plugin that comes packaged for creating static versions of pages automatically. Staticize? I think that’s what it’s called – basically caching of pages.
I’d imagine it scales pretty well, although if you start to suffer performance wise, might as well just enable the plugin ??