SMF Development > Next SMF Discussion

How idiot-proof can SMF be made?

(1/21) > >>

MrPhil:
Face it. SMF is easy enough to install that just about anyone with a pulse can get a forum going. Unfortunately, it also means that there are people out there who shouldn't be let near the innards of a forum. That is, they have absolutely no programming skills, yet they are trying to modify PHP code and often failing. Then they come here screaming HELP!!! (all caps) with

"I think I've been hacked!!! There's this code in my file:

--- Code: ---if (!defined(SMF))
   die("Hacking attempt!");
--- End code ---
What do I do? What do I do??????!!!!!"

or failing to realize that if a PHP string starts with a single quote (apostrophe) ' you can't put an unescaped apostrophe in the middle of the string! Etc., etc. ("What's a string? What's PHP?") And most can't be bothered to do a basic search of the forum for the answer. And many need extensive hand-holding because they just don't get the concepts in programming or databases. I.e., you can't explain a concept once and send them on their way -- you have to hold their hand step by painful step.

It never ceases to amaze me that some of these people actually can remember to keep breathing. OK, perhaps that's a bit unfair to them -- I probably can't do some things that they can do with ease. But the fact remains that many forum operators should not be let near code. So, to focus this rant, can SMF (or any other PHP-based web application) be made absolutely idiot proof? That is, they should be able to install/remove mods or update text without ever having to touch raw PHP code. Ever. Can it be done? It's like welding the hood shut on their car, if they're more likely to do damage fiddling with the engine. Among other things, it would take a built-in editor that can detect text strings and how they're delimited, and look for unescaped quotes (possibly by storing all text strings in the database? what a performance hit that would be!). If would take something more elementary than phpMyAdmin to deal with the database.

Of course, those of us who understand programming will still want to go diving into the code to do custom stuff, but those who can't program should be kept away from code. Can they be locked out/given adequately smart tools to do most jobs for them, without interfering with programmers? The prime example would be a fool-proof mod system. I'd say that at least half the topics on the Support boards involve mods that failed to install properly, or failed to remove properly, or refuse to install at all. We've got to do better than that! How radically would SMF have to be re-architected to make installing or removing a mod a painless, goofproof process? Is it a realistic goal?

The current process depends upon matching segments of code in a file, code that may be altered by another mod. At the very least, SMF should refuse to install a mod if any failures are reported in the pre-install search. Far too many beginners get into trouble because they tell the package manager to go ahead, and then fail to properly manually install the remainder of the code, or omit a database update step. There's also no protection against installing a mod twice. I suppose that mods could be limited to inserting function calls at specified points in the code, but that may be too limited in capability (and the question of mods interacting with each other, depending on the order they're installed, remains). As for removing mods, I think it would be better to build a list of mods being used, and always apply them in one go against a vanilla copy of SMF. If one mod refuses to install, don't install any -- make the admin first pull the failing mod out of the list.

For themes or skins, we need a smart WYSIWYG editor that can update the CSS for you when you drag components around the screen, select colors or background images to use, and perhaps even add new modules for new functions. Is there a plug-in for Firefox that would let you do that, and rewrite the affected CSS file(s)?

Browsing through the Support boards, I could probably come up with lots more specific examples. The question remains: can a PHP-based web application be made idiot proof to update and upgrade, without preventing programmers from doing custom work if they desire? The latter condition implies that source code is available in some format. A single fixed application (think canned software like Word) can be locked down, but something that permits upgrades/updates, skins, themes, language packs, and most of all, "mods", is open to all sorts of trouble when people who shouldn't be messing around with code are forced to do so.

Your thoughts?

Arantor:
Cue everyone pointing to WordPress.

It fits most criteria - friendly WYSIWYG editor, mods that don't require matching code segments and so on.

But 1) it's a lot simpler application in the scheme of things, 2) it pays dearly for such simplicity, both in terms of what can be customised and in performance terms.

It's all too easy to kill a WP installation with lots of mods which have to do their own DB work as opposed to using central resources, and the worst case I ever saw was a WP site running 400 queries Every Single Page. But it is a lot more restrictive in terms of functionality in what you can actually do with it as a result of modding; you can bolt quite literally anything into SMF with a little work, the same cannot be said so easily of WP.

I would also note that a lot of the discussion about mods vs plugins vs flexibility vs functionality and balancing all this was held months ago by the Phoenix/Yourasoft folks and I don't recall any really good answer coming out of it.

Even in a 'locked down' app like Word you can still get and write plugins for it (heck, I spent months engineering applet type stuff in Excel, including the primary stock control we had at my old company, though I only had the "joy" of maintenance)

I hear what you're saying but I don't see how to reconcile the need for simplicity with the power of true customisation.

In fact, I'm very much of the opposite side of the fence; I remember when to make a website you actually had to *learn* something, and to a point I'd actually like to see that mentality return somewhat.

It's like driving a car or riding a bike; you get to know it, and if it isn't performing right, odds are you'll pop the bonnet and have a look, or examine the thingamajigs and doodleflips. I'd love to see a similar mentality occurring here, really. I am a firm believer that if you're going to invest time and energy in something like a site, you really should invest some time and energy in understanding the mechanics at least a little.

I'm not suggesting that every forum owner learn advanced PHP and be capable of writing any mod known to mankind, but I do believe that forum owners/administrators should learn the absolute basics.

Kenny01:
You're right Arantor.

You can't learn without damaging, as you can't learn how to walk without falling.

I crashed several of my forums before learning the admin game, now i have a very big and stable board.

青山 素子:
One way to solve the problem is to go completely object-oriented. To add functionality, you can extend a class. Of course, this has a huge potential for killing modification developers since they would all have to wrap their heads around your object structure and most of the people developing modifications for SMF are not anywhere near experienced or dedicated enough to learn all the framework required for even a small change. With this method, you also have the potential for performance issues

The next possibility is to add "hooks" like other products do. Unfortunately, unless you design these smartly in the flow or add something for each line, it becomes restrictive as to what modifications can do when using that system. Heck, even with being smart in location or just scattering things over the place, you'll still likely run into situations where you need something else.

Yet another possibility is to support both "hook" and an inline-edit methods. The problem here is that you will get a lot of people doing direct code edits and you'll run into the same problems of conflicting code edits.

In conclusion, the best solution for flexibility without conflicts is going the object-oriented way, but you also cut down the number of people who will be able to work in that model. If you want to allow flexibility while encouraging beginners to customize things, you'll almost have to allow direct code edits and the possible issues that can bring.

Arantor:
MC: On OOP, it would basically kill the modding community here. And even then you don't really solve the problem, in fact. You just end up with multiple mods trying to extend the same class in different ways and get into trouble that way.

Navigation

[0] Message Index

[#] Next page