On the other hand, I was surprised when I saw all the hubbub about the most recent exploit, because the fix for that problem had been released earlier. In fact, I had upgraded a week before to the version that everyone was suddenly squawking about. So vigilance on the part of the site owner is also required.

Market share attracts trouble. The inequity between Microsoft and Apple in number of attacks is indicative first and foremost of market share, not any inherent advantage or disadvantage in their OS code. As WordPress grows, it will be targeted more often. If the WordPress team is good, they’ll stay one small step ahead of disaster. If not, their incompetence will take a lot of people with them.

As for myself, I’m not overly concerned. Make frequent db backups, as well as a full backup of your site content (style.css, images, etc.), and you should be able to recover from just about anything as soon as WordPress itself is patched. Which means, in the end, that the blog/Wordpress platform is little different than a desktop, laptop, or handheld.

One of the reasons (I believe) so many authors pick WordPress over a CMS system is that CMS systems are typically designed to be workhorses for lots and lots of content and interaction, more than one writer can produce.

Nah, so many people use WordPress because so many people use WordPress.

But on your point about the developer community: yes, that’s a possibility that we’ll have to think about. I don’t have the foggiest on how to organize a crowd-sourced software project … =S

By contrast a writing collective, that is several writers publishing different stories on the same site, allows the writers to cultivate a fanbase individually as they would with a WordPress blog but also cross pollinate and pool resources. Readers in love with story XYZ might jump into story ABC by a different author. Promotion becomes easier, site maintenance becomes easier, helps standardize formatting… One of the reasons (I believe) so many authors pick WordPress over a CMS system is that CMS systems are typically designed to be workhorses for lots and lots of content and interaction, more than one writer can produce.

On a completely self serving note (cause this is the way we’re moving right now): perhaps the answer is not that webfiction should be host-vs-installed system, perhaps it’s that every single piece of fiction doesn’t need its own site? There is something to be said for getting writers together and maximizing resources.

Writing.com and FictionPress.com have that covered I think. Writing.com in particular, I posted a short story and received worthwhile feedback without any promotion on my part.

The problem with any CMS system …. really any system at all is that it is only as strong as the community of developers around it. As a web designer I’ve used lots of different systems (WordPress, Joomla, Dolphin, Dokuwiki the original blogging products like Greymatter, etc, etc, etc) the popular ones usually have to deal with a trade-off between having flexibility and having stability. It’s one of the perils of open source: you can find apps for just about everything and updates to the core software every month but you don’t know what bugs and vulnerabilities these hacks are going to open up.

Fluffy-seme runs on an extremely obscure platform, which drives me crazy half of the time because its table structure is absurdly complicated, counterintuitive, and its actual php is like a spaghetti dinner sometimes >.> But on the other hand it has a small community of very knowledgeable developers who charge $50, $60 bucks for their apps and mods. Coming from a WordPress world where most every mod/plugin is available for free it’s sometimes difficult to see the real advantages of this: it’s enforces a standard of quality. You know who the good developers are by the stats on how their products are selling in addition to feedback ratings or whatever. And those developers are also more responsive to doing freelance custom work and trouble-shooting issues with their products in a timely manner.

So it would be interesting to see a platform designed specifically for digital writing, but it’s success or failure would depend on the community of developers around it. It’s not just about adding more and more features, it’s about making sure the program can continue to provide a quality product as time goes by.

On a completely self serving note (cause this is the way we’re moving right now): perhaps the answer is not that webfiction should be host-vs-installed system, perhaps it’s that every single piece of fiction doesn’t need its own site? There is something to be said for getting writers together and maximizing resources.

How are you authenticating subscribers when only admins are allowed to log in?

-J

(the benefit of a really simple system is that sanitizing the non-admin input is less complicated, since there are only very limited things users can do within the system: request a book title (limit a-z, _, – etc) or chapter (0-9). The fewer server-level functions you do, the fewer opportunities there are.)

All I’m saying is that there’s no reason to believe you can’t make an extremely secure small-run CMS just because WP had a big exploit last week. If you juggle one ball, but do it well, you should be fine. Not PERFECT, but easier to track than WP is.

Yes, it’s kind of annoying that I can’t tweak things to make them exactly as I would want, but then again, I’m not sure I’d know how to tweak things much.

And yes, as MCM said, there’s a lot of manual labour involved. In that respect I think Digital Novelist is more streamlined a platform (but I don’t want to pay for it!).

Just my non-tech-savvy 2 cents worth. :)

IIRC, it was a malformed URL exploit for the forgotten password retrieval function that gave attackers the ability to gain access to the admin account. From the report I read, the exploit exposed information about the first account in the users table which was usually Admin, so even if you had no one else with access… especially if you had no one else… this exploit could get you.

The number of authorized users is one weakness. The more people who can get in and do damage, the more likely someone can guess, snoop, bruteforce, or social engineer an ID and password.

But the bot/worm exploits usually go after a bug in the underlying code: an improperly validated/sanitized input that allows the hacker to expose data, run code, or inject SQL commands.

It’s the one validation regex you, the coder, got 99.9% right that gets you because it passes every one of your tests.

If you can stop 99.9% of terrorists who try to blow up planes, that means you’ll lose a plane for every 1,000th terrorist who tries. And, going with the law of averages, you could have the first 2,997 fail, then have three planes in a row become falling debris.

If you think you can write an unhackable CMS, do it, then offer $500 to the first person who can hack it. You’ll be paying that $500 a lot faster than you think.

In theory, if you used subversion, you could drop a tarball into a directory and still be able to upgrade WordPress “around” your theme. You would still have to configure the database and activate the themes and plugins, though. If you were really keen, you could probably ship it with a barebones database extract and install that — a couple of queries would fix up the necessary database fields. That said, the normal WordPress install procedure is pretty painless — I’m not sure this would improve anything.

Chris.

I still think a streamlined experience is superior, but if you could make a wp-cron action handle the release changes easily, it might be an alternative.

I’ll look for the code, but to be honest, it’s been a while since I played with it, and I may have deleted the install that I applied the hack to. It was mostly that issue that drove me to write my own CMS in the first place… the itch that made me crazy, as they say…

The other thing I’m doing for my own site is modifying the WP admin screens a bit — by moving categories to the top of the heap and renaming the sections, then allowing it to be used as a configuration point (I had been using a plugin called Category Fields for that, before). Adding a scheduling property shouldn’t be difficult. I’ll add it to the list.

Of course, everything with WordPress looks fairly simple to me — I’ve been all through it’s guts while writing (and re-writing) WFG. However, my experience with the product *has* been mostly positive. Yes, there’s a paucity of documentation for some of the more useful hooks, but the source code is available. And WFG massively changes how WordPress works, and yet I’ve only had very minor problems (and mostly on the admin screens) with system upgrades. For the most part, everything just works from release to release.

Chris.

Anyway, this is the big difference between my ideal system and WP… I don’t mix the user types. Admins can edit stuff and play around with the settings, but regular users never can. It’s a different system entirely, so there’s no chance of someone hacking their way in through a glitch in the user admin.

The way I run it now, when you pay for a book, you get a unique ID that you use to access the content as much as you like. The big benefit of this method is that people can buy their friends and family “gifts” more easily than if it were tied to a user account. That appears to be one of the biggest uses of my system already.

I’ve considered extending the ID into a full-fledged user system, but I don’t see much benefit at the moment. There are probably lots of good reasons, but I live in an insular bubble these days :)

Have you considered releasing your “hack” on the chance that someone in the WordPress community could make it official? Sounds like you’ve got things almost there as it is!

-J

Okay, here’s where you kinda lose me…

If the only people who are allowed to log in are authors, then you have no way to identify an individual visitor to your site.

The most immediate problem with this: Forget subscriptions or paid content on the site. There are broader implications, of course, but I think that alone will be a dealbreaker for a lot of writers (myself included).

I’m hoping I just misunderstood, though… could you elaborate?

-J

I worked for a long time to try and make WP see posts the way I want, but it required a lot of MySQL hackery to get it done. Basically, you make a custom admin panel where you choose a category and then check off the release days (and start day and backlog etc) and hit “go” and it runs through the database and rewrites all the publish dates one by one. The problem is, that’s bypassing the WP engine entirely, so it usually doesn’t work without major errors, and it’s horribly DESTRUCTIVE. I’d much rather just load the chapters in dumbly and let a release engine handle the logic of when to publish. Less damage done, and easier on my heartburn :)