Getting ready to move Monster Highway over to a new ‘production’ web server and restructuring the underlying ‘files’ system. (See note *). I realized I didn’t need a registration system there anymore (just a doorway for hackers and spammers) so I killed that off. (See note **).
Then I get the great idea to run a ‘Zombie’ user purge program on Monster Highway’s Pligg CMS based system. Don’t do that if you have users setup for Inbound RSS accounts. ‘Zombie Killer’ doesn’t show any list of it’s intentions (intended removals) and sure enough, it clobbered three RSS users.
By itself that’s not a real biggie! But…….the RSS import still runs and imports on the next feed. Then Pligg shows the post but attributes it to a random author in admin. And, on the public side, Pligg throws a cryptic error code to the user and refuses to run.
And….. this doesn’t happen until the affected account runs and finds a new post to import. That could be three or more months down the road. And…… you can’t see the problem…. and you forgot the cause… and you’re just gonna have to look at several hundred posts until you figure it out. In other words “You’re SOL”!
So the moral here is, “Don’t run Zombie Killer until you’ve got a good list of ‘system essential’ users like admin accounts and InboundRSS Users.
* We’re planning a Multi-User Multi-Site WordPress install with Domain Mapping and Multi-Pligg running all of the Monster Highway family of sites with lots of interaction between them. If I do this right the changes will be transparent to the users, easier to maintain, and faster on response.
** Since native Pligg CMS thrives on user input in the form of article votes, we allow anonymous voting but track those via IP, sessions, and cookies. This keeps users from voting more than once for a given article and artificially inflating/deflating the counts.