Much more to the point, and while I honestly fail to understand why you feel my self-deprecating comment is “needlessly insulting”, your professional network job is but another link in a large chain of specializations involved in keeping the intertubes humming along, together with the likes of server admins, server OS specialists, security specialists and so on. I respect, appreciate and acknowledge all and everybody as necessary, vital contributors.

But this isn’t about “respect”. The topic here was inspired by Michael Krotscheck’s overall fairly decent remarks, precisely from a non-coder perspective (although he’s a gifted and highly experienced designer, so not entirely clueless either, isn’t he?). With one exception: when he (in my opinion) gingerly stepped over the issue of security, with his pertaining hardly seriously pitched comment.

Needless to say, as is certainly and very understandably the case when “big guns” like Matt and Anil get involved in a discussion on the merits of their respective “baby”, some giving and taking is to be expected. But it’s terribly disingenuous and dangerous when a topic as important as security becomes snowed in / painted over in a PR piddling match.

Again, I claim defense in my dangerous ignorance of anything intertubed. But that doesn’t mean I’m bereft of logic, either. As expressly subjective as Krotscheck’s piece was, Anil had a point when he referred to CERT. Just as Matt has a point when he argues that core code and plugins ought to be separated, as the comparison between MT and WP clearly limps in that regard provided your evaluation criterion (also) hinges on a perspective of direct liability. If some independent author’s plugin creates a vulnerability, it’s harder to argue “weakness” than in the case of a problem with the core – which is what Matt (again, rightly) points out in his latest reply to me.

The thing is, because WP has become enormously popular, there’s a greater risk in vulnerabilities in much the same way that Microsoft’s efforts toward security are critical: popularity attracts bad guys’ attention. And it’s bad guys that we all (both authors and the intertube pros) should work hard for to deny them as much as we can. Belittling existing, real-world issues is an act of irresponsibility, pure and simple; it’s highly unbecoming to see the enormous efforts and contributions to increasing security made (e.g. by WP and its developer community) reduced to “oh but that’s their problem” type remarks.

After all, security of “our” blogs is a shared and immensely complex problem, where even Dan Kaminsky’s “recent” find of a DNS cache poisoning vulnerability comes into play. Let’s keep the discussion honest, is my closing statement here.

If I’m a fanboy because I like a system that works and is easier for me to learn, then call me a fanboy. God knows, I’ve been called worse. And, I’ll say this, in spite of Matt actually discouraging me from donating money to WordPress, I did, because when I changed from MT to WP due to licensing issues, I said that if I ever found a blogging platform that did what I wanted and needed it to do, I would pay for it. WordPress kept its promise to me, so I kept my promise to it.

http://codex.wordpress.org/CVEs

… the number 42 for vulnerabilities in 2008 pops up, straight away. Rinse and repeat, the number remains the same.

But even taking your statement as the gospel here, so: assuming that indeed the “actual” CVEs – i.e. those on which the statistics were compiled – do allow for a differentiation among three presumably real and thirty-nine apparently less real vulnerabilities, I’m curious as to why such a seemingly critical clarification isn’t mentioned on the pertinent page. Or has DHS nefariously blacked those out, too?

Anyway – I searched for the CVE’s on NIST here and searched for “WordPress” using the same criteria (i.e. Jan 08 – Dec 08, leaving all else to “Any”) – lo and behold…

…44 vulnerabilities pop up this time (perhaps two have been added?). More curiouser yet, of those 44, none is labeled as “Low” risk according to the CVSS Severity ranking, while 27 are “Medium” risk and 17 as “High” risk vulnerabilities.

So, either my fingers hit the “operator dumbify” button, or the DHS has been secretly awarding no-bid contracts to Six Apart to run the NVD, or: we’re looking at very dissimilar things here.

WordPress is just a clean mix of HTML and PHP, both languages that are really extensible and usable, and WordPress has taught me 10% of PHP that I now use to code websites (yes, I’m a 11 year old. Get over it).

Being an avid web programmer, I don’t like proprietary templates that call things. I like WordPress’s way of doing things the safe way with functions, and Typepad’s way of making people learn something new is just confusing.

Typepad does offer support for PHP, something we should all praise, but I still like WordPress, and I think that Sitemaps is a great idea.

However, to calm everyone dawn and bring the competition into a more equal space, I’m going to have to say something pro-Typepad: The way they do it will probably be more customizable.

In WordPress, I have looked for a page or tab in the administration for customizing my Sitemap, like changing the importance, etc. There was none.

That was just to make Typepad and Anil (who’s comments are backfiring, no offense) feel a bit better, but I still love WordPress and the way it is.

I had a live journal and wanted a self hosted blog – more flexibility, more ability to put everything I wanted in one space. I looked around at the blogs I was reading and saw that they used Movable Type, so I attempted to get my blog set up with Movable Type. I struggled with it for days before giving up and wondering if there was something easier out there for someone like me who knew nothing about Perl or PHP, and just some of the basics of html. Enter WordPress. I had my self-hosted blog up and running in one afternoon. In the years that I’ve been using WordPress I have learned some PHP, plenty enough to know how to modify my blog when I want/need to. The forums have been invaluable in helping me learn. It has always worked for what I need, and am planning on using WP as I continue to expand my site because I know it will work.

However, as a not-excessively-technical type I found it extremely difficult to customise to my needs and wants. So much so that I started to look elsewhere.

At the time I subscribed to several blogs which used wordpress, so I thought I’d give that a go instead. I’ve never looked back. It may not be the prettiest or most technically advanced blog ever, but I’m happy.

Just a bit of an input from a regular user here via the ‘Other WordPress News’ link.

Thanks Matt.

No, WP’s key strength arises for me from the simplicity in the chores of deploying and maintaining a blog, both out of the box and overall. Applying a different theme in WP is pretty much a point, click, and “oooh!” process. In MT, templating has undoubtedly come a long way, but the strength of MT comes after deployment: its creation of static pages.

Creating a fun and useful blog is, in my subjective opinion, very, very straightforward in WP, and only somewhat more cumbersome in MT, counting in steps for tweaks and customization. But once you have the misfortune of fame (via Digg or Slashdot or Boingboing) your chances of survival on a self-hosted blog are much better served with MT.

Seriously, I think competition is healthy and it’s also very healthy to favor one’s own baby (mine’s are prettier than yours combined by the way) but there are differences that in some respects make WP preferable, and in others give MT an edge.

I say, feud on in development – the clueless non-coding crowd adores you both all the more for it. And: thank you for the ongoing effort.

The implication is that MT’s templates are easier to learn and modify than WordPress’, which are PHP-based, which has been made explicitly elsewhere.

I think this is bull — they both have a learning curve but at least at the end of WP’s you know some PHP, which is highly applicable other places. In fact MT’s templating only recently became as flexible as PHP:

So what you end up with is a pale imitation meta-language that is only useful in the context of a single application, hence proprietary.

Oh come on now, Matt, that’s just plain silly. The drive to make MT’s templating language “turing complete” was simply to allow users to use ONLY MT templating language constructs to do things like variable assignment and create control structures if they so choose.

You know full well that PHP is and has been for 8 years completely supported in MT templates so that if you are a PHP geek, you can use that. But of course, MT makes it easy for those who aren’t as well.

And I’m disappointed by your implication that one has to learn a whole language to modify templates. Learning PHP syntax is a hell of a lot harder for a newb than <&MTEntryTitle&> and the like.

In any case, all of this is rather silly. Quibbling over things like this and who makes it one step easier to create a Google sitemap makes everyone look like an ass.

I’d like to once again appeal to everyone’s maturity here. Stop with the bullshit quibbling on all sides and get on with creating the best software for your users. This is getting old.

http://mskempster.com/2008/06/18/wp-vs-tp-a-silly-comparison/

I’d love you to look at it and maybe comment because I really want to know what YOU think on my opinion.

Can I cite this to the “WP templates are not PHP!” crowd? Totally honest question. That denial has been a point of absolute confusion to me for some time.

they both have a learning curve but at least at the end of WP’s you know some PHP, which is highly applicable other places.

You skipped a step here. Every templating language has a learning curve; you’re stating the obvious. But let’s clarify: Are you in fact equating the two curves?
The side-benefit of picking up some PHP is irrelevant to the actual topic at hand, and can be applied just as well to MT templating if the person wants to learn that, as well as any other language that may be of interest given their output format is not limited to it.
(All: note I’m not saying either is simpler/harder here. I’m asking for clarification of Matt’s claim.)

meta-language that is only useful in the context of a single application

Two, actually, though they don’t share the complete breadth of the language.

True, but also, the universe of PHP developers is almost certainly much larger than the universe of MT developers, which means if you get stuck it’s much more likely you’ll be able to get help. (This of course is the benefit of any non-proprietary language.)

Long Live WordPress.