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:
if (!defined(SMF))
die("Hacking attempt!");
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?
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.
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.
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.
Quote from: Arantor on April 29, 2010, 01:12:38 PM
On OOP, it would basically kill the modding community here.
Indeed it would. I thought I put that in my post above.
Quote from: Arantor on April 29, 2010, 01:12:38 PM
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.
Yeah, it's not a panacea, but it would prevent certain types of problems from occurring. Unfortunately, it has its own negatives.
You did, I just wanted to make it clear that we weren't talking about a reduction in the community, it would basically die, because the number of programmers around here that can build something in OOP generally is far too low, and I don't see it encouraging experienced programmers from outside the current ecosystem much either.
The other side of the coin is that people like me, who knew absolutely zilch about php, learn from such things. I knew BASIC, AMOS and a bit of REXX, though, so I had a bsic (No pun intended) feeling for program structure and stuff.
The people that piss me off are those that don't even try anything, before coming in and asking/demanding help.
*nods* BASIC, AMOS and REXX are great languages in their own way - and you can learn some of the techniques that underpin PHP from them (particularly AMOS, with its Procedures that are very much the same as PHP functions, right down to passing values, scope and everything else)
Quote from: Kat on April 29, 2010, 01:49:35 PM
The people that piss me off are those that don't even try anything, before coming in and asking/demanding help.
Those are the people that get me so irate - and they're the people who get abusive if you encourage them to help themselves first.
In a way, it's a shame that the old "Type code in from a magazine" days are long gone.
Quote from: ArantorI 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.
I think the days are long past when people would put up with
having to learn coding in order to get a site up. Most people want a canned solution, and either can not or will not learn programming. I understand their point -- I use Linux to a degree, but I'm no fanatic about it. I don't care to devote all my waking hours to studying and extending it and compiling kernels. It's just a tool to get a job done. Likewise, they see a forum like SMF as a tool to accomplish some task, not a hobby in and of itself. They want to run a community of some sort
and talk to other people, and couldn't care less what the tool is.
To continue with your automotive simile, in the old old days you
had to be a mechanic to keep a car running (
chauffeur comes from the French for "fire stoker", the guy who shoveled coal into a Stanley Steamer's boiler). Over the decades, cars became more reliable and automated, until today you rarely have to pop the hood/bonnet to do anything (and most car owners would be totally lost trying to find their way around all the gizmos/hoses/pipes of a modern engine compartment). Hell, I majored in mechanical engineering, and I leave almost all the maintenance on my car to the local garage, as I don't have the tools, manuals, or specialized training to confidently tackle most things. If I had to be in there twiddling the points on a weekly basis, I might reconsider.
Where do web sites come in on the automotive timeline? I think they're still back in maybe the 1920s or 30s. Much of the time they'll get you from Point A to Point B without trouble, but if something goes wrong, you have to really dive into its innards. And routine maintenance can still be an adventure, requiring intimate knowledge of the site's coding and inner systems. Unfortunately, that's in conflict with the SMF-as-tool viewpoint. We need forum owners to be part-time mechanics (programmers), but they're not interested. As long as that's true, I think that will limit the appeal of SMF.
The whole point of my opening post was that we require forum owners to have some familiarity with programming in order to modify it, or do anything but the most mundane day-to-day operations. And most forum owners do
not have such skills (or the desire/capability to learn them), so what can we do to lift the burden? Of course, this brings up the matter that people are used to taking their cars to a mechanic, and paying dearly for the privilege, but just try charging for service on a piece of free software!
Quote from: KatIn a way, it's a shame that the old "Type code in from a magazine" days are long gone.
The ones where they actually gave high level (BASIC) or Assembly code, or the ones where they fed hundreds of numeric byte code values into a BASIC utility to create a file? At least with the former, you had a chance to study and understand the code, and maybe learn something. With the latter, the premium was on very careful typing. In neither case did you particularly
have to know any computer science in order to get the thing running.
Actually, you citing Linux is a great example.
I'm the kind of person that would probably go off and learn to compile kernels etc (been there, done that, in fact) but my point is that people don't even want to look at the command line, much less get in and look around, and that's something I think needs to change.
What I'm getting at is that while SMF is a tool, and largely a well built one, any tool needs time and energy to get used to it, to get the best out of it, and if it's a tool you plan to use on any kind of basis, surely you'd go and invest some time in getting to know it better? That's the part I have trouble with - too many people want to use it as a tool but don't want to invest the time in getting to know it.
Result: you have people using the digital equivalent of a hammer on the digital equivalent of a nail and complaining when the nail bends.
True, the internet, and user expectations, have come a long way since I got into building websites, when technical skill or at least the willingness to learn was a requirement, not a bonus. And now, anyone can set a site up in minutes. Great, fantastic. And indeed all the time you can get from A to B that's great.
Another example, borrowing from the car analogy again: changing a tyre. It's not an arduous task and most people that drive a car can manage it. Except the idiot-proofing of the internet generation means people will run screaming before they'll attempt the digital equivalent of jacking the car up and changing a tyre.
You invest time and money in a car, you learn how to do some minor things on it - the average person won't try and understand every little component but the absolute basics they can manage, like when it says it's out of petrol, it's time to put new petrol in.
Yet, here, you have the digital equivalent and people come and ask for help without taking a moment to do the digital equivalent.
I don't think idiot proofing is the answer - it hasn't really helped WP IMO, all that happens is you raise the digital equivalent of a group of car drivers that *won't* learn how to change a tyre, not because they *can't* but because of some other factor.
Instead of idiot proofing the software - which, I'd point out, is what successive iterations of Windows have tried to do, and ended up making it harder to do anything outside of the absolute basics with each successive iteration - I'd encourage a program of helping users to do things, so that instead of encouraging a 'OMG THE SITE IS DOWN HEEEEELP' culture, we can start to encourage something of 'OK, the site is down, it isn't x, it isn't y...' and helping users to develop their skills. The end result is users that feel more confident with things, which is actually a win-win.
Classic case of this - only this week I saw a user asking for free mod installations, on a per mod basis, with no mitigating factors other than user inexperience. As one person stated - why not instead of doing it for them, teach them how to do it so they'll be empowered?
There's no such thing as an idiot-proof software unless you write it in word and you can make mods, themes and stuff in word ;)
Word isn't idiot-proof. In fact I lost count of the number of times my bosses gave me things to do in Word that were beyond their skills...
Quote from: Arantor on April 29, 2010, 05:00:26 PMWord isn't idiot-proof. In fact I lost count of the number of times my bosses gave me things to do in Word that were beyond their skills...
Well, it's something that the microsoft staff did, what can you expect? :P
I think the typing of code from a mag helped, because you ALWAYS screwed-up something. So, to get it working, you had to go through the code, line by line, figuring-out what did what, so you could get it working.
Maybe just keeping the noobs out of the mod site is a good idea. Maybe some type of test you have to pass in order to access it.
Well, you need to have a licence to drive a car...
Basically the same idea, the same would also be a good idea to stop them from editing themes through smf.
It is not possible to make software idiot-proof as someone will always build a better idiot. Rather than nobbling the software methinks it would be easier and more rewarding to exterminate the idiots. ;D
Ant: EXACTLY MY POINT! Well, almost...
There is an app for the ipod I think its called the idiot test or something. Basically tries to find out if you have common sense. Alot of people here lack that.
Quote from: Arantor on April 29, 2010, 04:50:07 PM
any tool needs time and energy to get used to it, to get the best out of it, and if it's a tool you plan to use on any kind of basis, surely you'd go and invest some time in getting to know it better? That's the part I have trouble with - too many people want to use it as a tool but don't want to invest the time in getting to know it.
I'd go even simpler than the car analogy. I'm going to go with a toaster. It's a pretty simple machine, really. You put bread in, push down the lever, and then if it is plugged in, you get toast in a little bit.
However, even the simplest person will know a few things about the toaster. They will know that they need to adjust the dial to change the darkness of the toast. They will even know how to cancel the toasting cycle (pull the lever up on older models, or push the eject button on newer ones) and that the crumb tray needs to be emptied occasionally to prevent problems.
These same people that know how to operate a toaster will refuse to learn even the basics of how to maintain SMF. They want something even simpler than a toaster. They want a box where they press a button and something happens. No maintenance, no remembering to plug in the power cord, no adjustments, nothing. They want a single button.
They won't be able to get that without paying someone a lot of money to be that "button" for them and to hide the dials and levers. You can only simplify something so much, beyond that it becomes even less than an appliance.
http://stupidfilter.org/wiki/ ;D
Do they need any developers? I'd be willing to write an SMF mod (for free) for that.
I fully agree with the point that a software meant to be distributed to so many people of all cultures, should respond to their expectations. After all, it's out there for the community, for the users, not for us and what *we* might think of it. If it targets programmers or curious into programming, yes, then you could say they *should* get their hands dirty (it's a little difficult to learn otherwise :) ). If we target non-programmer web sites owners, then IMHO, we should NOT expect them to deal with ALL coding innards just because we like doing so, nor impose it to them. Yes, they have to know some things. No question there. But from the entire feedback we're getting, if we find that they feel too often that we're asking for too much, then maybe we need to reconsider.
Remembering the target, and I think we can agree SMF does have or tries to have a rather diverse target, including websites owners which don't know or want to delve into code, I think we should seriously consider to improve usability and non-coding demanding customization alternatives in the future. Maybe that's only me, but this is my stance.
On a side note, I do not think that making available an object oriented API one day, in addition to what SMF already does, could possibly kill the community coders, on the contrary. For some reason, object orientation (in its basic ideas) seems to be easy to grasp by beginner coders (at least in my experience, and I've trained both classes and professionals), and notoriously difficult by coders which already have their coding thinking modeled by another paradigm (procedural or else). Of course, there are exceptions. But like any paradigm for that matter, it should be taken in its own right, not through the perspective of another one. Views through another one can be biased.
Back to the topic, it has been brought out elsewhere that adding a plugin system may be closer to the non-coding-demanding means of customization, as it would alleviate the risk of conflicts that direct modifications of code have. At a price, of course, nothing comes otherwise, and the known price to pay here can be performance.
That's not to say we will do anything of the kind. But personally, I am really grateful for the discussions about what could be done or wished to be done, and I thank you all for taking part in it. This software is here for the community, and IMHO it should, in the measure of possibility and careful consideration of trade-offs, work towards responding better to their expectations.
Quote from: Arantor on April 29, 2010, 06:57:16 PM
Do they need any developers? I'd be willing to write an SMF mod (for free) for that.
I'm seriously thinking of installing it myself, with or without a mod. I think they'd be rapt about that idea though.
I didn't see anything in the way of downloads though :S
Quote from: Norv on April 29, 2010, 07:03:05 PM
I fully agree with the point that a software meant to be distributed to so many people of all cultures, should respond to their expectations. After all, it's out there for the community, for the users, not for us and what *we* might think of it. If it targets programmers or curious into programming, yes, then you could say they *should* get their hands dirty (it's a little difficult to learn otherwise :) ). If we target non-programmer web sites owners, then IMHO, we should NOT expect them to deal with ALL coding innards just because we like doing so, nor impose it to them. Yes, they have to know some things. No question there. But from the entire feedback we're getting, if we find that they feel too often that we're asking for too much, then maybe we need to reconsider.
Remembering the target, and I think we can agree SMF does have or tries to have a rather diverse target, including websites owners which don't know or want to delve into code, I think we should seriously consider to improve usability and non-coding demanding customization alternatives in the future. Maybe that's only me, but this is my stance.
I'm all for improving usability but as you say people will still have to know, or be prepared to learn, some things.
QuoteBack to the topic, it has been brought out elsewhere that adding a plugin system may be closer to the non-coding-demanding means of customization, as it would alleviate the risk of conflicts that direct modifications of code have. At a price, of course, nothing comes otherwise, and the known price to pay here can be performance.
This is where we may hit problems. The core philosophy of SMF has always been to keep a simple core that can be easily extended. This keeps the development and security side of the project as simple and lean as possible. It also means default installations are efficient in terms of performance.
The current system of modifications, while not perfect, offers virtually unlimited flexibility in terms of rewriting the core to meet personal requirements. Keeping that flexibility, and I think it would be a great shame to lose it, and minimising performance degradation may make it difficult or impossible to have software as idiot-proof as we would otherwise like it to be.
I highly doubt it will ever be taken into consideration to drop or truly impede the modifications system. (and with it, all flexibility that people desire). So yes, I agree, obviously, but it is not exactly my point.
What *could* be thought about, is to see about adding ways in which customization is possible without necessarily being in the form of direct modifications only.
Of course, discussion is most welcome. That is the point of it. :)
Quote from: Norv on April 29, 2010, 07:19:02 PMWhat *could* be thought about, is to see about adding ways in which customization is possible without necessarily being in the form of direct modifications only.
Seems like a tricky proposition, unless you want to have both the existing system
and a WP-esque plug-ins system.
Don't forget, there is already the foundation in SMF for a hook system: the integration hooks. The framework needs an overhaul, the ability to only run one function per hook point is incredibly limited.
True, but the integration hooks are broken in RC3. ;D
Not all of them, just some of them ;)
SlammedDime's SimpleSEF proves some of them work, as well as we use some of them on SimpleDesk.net for cool stuff.
Quote from: Antechinus on April 29, 2010, 07:22:54 PM
Quote from: Norv on April 29, 2010, 07:19:02 PMWhat *could* be thought about, is to see about adding ways in which customization is possible without necessarily being in the form of direct modifications only.
Seems like a tricky proposition, unless you want to have both the existing system and a WP-esque plug-ins system.
:D
Actually, not really that tricky. Imagine (it's just an example) the following
hypothesis: that a feature like a menu editor is indeed written for SMF, be it by default or not - otherwise available (like it seems it is asked so many times, adding a tab in a menu, modifying a tab from the menu). With drag and drop perhaps, I don't know, just an example.
There would nothing stopping people from going to the code and hardcode their menu themselves, instead of using it. It would work also a little little bit quicker, since it passes through no more layers than strictly necessary. But in the same time, it would allow people who don't want to edit their PHP files, to select/insert/customize their menu through it. For those who do it through it, of course SMF building the menu might have to load a few additional files to have this little system do its job. I doubt it would matter much for some basic implementation of it (well it depends what you do), but if you insist, it can be called performance loss.
Yet, the point is, each can have their way.
Of course, if we go into details, adding such little system would require at the very very least a call or a few somewhere to see if it's enabled. Meaning you get something added to the core. Yes. It may be a good idea, it may be a bad idea.
As I said, there have to be trade-offs. There always are.
My point is: in some cases it might be only a call (a few calls) somewhere, in order to have a non-coding-demanding means of customization. Or, in other cases there would be required a rewrite of the core which is doubtfully too much of a good idea.
On this note, what I am trying to say is that I don't know beforehand what is a good idea and what is a bad idea, to make SMF easier to use for non-programmers. Some may be, some may not be. I am simply glad to see such topics and I try to watch them, to hear what people have to say.
I don't know. Maybe some things are far-off. Maybe some aren't.
---
Another little example (a bit different this time, this is for programmers in fact): in order to use another gateway for subscriptions, than PayPal, what you need to do is to write a single file, following the same conventions used by the PayPal file in SMF (meaning how to name functions, variables, classes), but of course adapted to your new gateway API. Nothing else... You put that file (if you wrote it correctly) into the SMF sources folder, and you should have your new payment gateway available.
Now, yes, of course, it takes a programmer to write that file, according to the API specifications of the specific gateway. Yes, definitely. However, this programmer doesn't need to know anything about SMF, in order to do it: just have documented somewhere that this is the way to add a gateway to SMF's 2.0 subscriptions. I can be a site owner which wants to hire or poke a programmer, and this programmer doesn't need to know anything more about SMF and its internals, he/she doesn't need to have any SMF learning curve: he/she can just sit down and write the calls to that gateway API in the format required.
Now, I wonder... You come with the file written following the conventions, and put it in a directory, and you have SMF automagically give you the new functionality. Doesn't that sound ... like a mini-plugin system of sorts, built into SMF 2.0 already? O:)
:D :D :D
Now some may argue that's too bloated. Honestly, it's not my opinion, there's not much in it to be, but, well, maybe it is. Open to discussion. I just want to make another point here: talking about a plugin system of sorts, doesn't mean AT ALL similar to Wordpress, in all its huge and bloaty and yes, VERY slow for all I've seen even myself (and I'm not necessarily for performance at all costs myself).
Wordpress' system and its behavior is only an extreme case of it. Like many other things, it depends on design and implementation. ;)
Quote from: Motoko-chan on April 29, 2010, 06:54:01 PM
However, even the simplest person will know a few things about the toaster. They will know that they need to adjust the dial to change the darkness of the toast. They will even know how to cancel the toasting cycle (pull the lever up on older models, or push the eject button on newer ones) and that the crumb tray needs to be emptied occasionally to prevent problems.
Have you seen the troubleshooting instructions for any electrical equipment that plugs into a wall socket?
1. Plug a
working lamp into the socket, to make sure it has power. If it will not light up, try another outlet. Once you have confirmed that there is power at the outlet...
I wouldn't count on the average person remembering to clean the crumb tray, either, until it catches fire. Let's not even talk about warnings on cups of coffee and microwaveable dinners: "Caution, contents hot! Handle carefully to prevent burns." Or is this strictly an American affliction?
Quote
These same people that know how to operate a toaster will refuse to learn even the basics of how to maintain SMF. They want something even simpler than a toaster. They want a box where they press a button and something happens. No maintenance, no remembering to plug in the power cord, no adjustments, nothing. They want a single button.
They want an appliance, in other words. No muss, no fuss, just press one button and you're there. Web browsers are
almost there.
Quote from: Antechinus on April 29, 2010, 07:11:42 PM
I'm all for improving usability but as you say people will still have to know, or be prepared to learn, some things.
OK, how about splitting SMF into two directions? One (SMF Pro) would be more or less what there is today -- a very flexible, extensible, and powerful system for programmers who know what they're doing, and an SMF Lite for the unwashed masses -- relatively few features, minimal customizability, basically locked down tight so that even a Pointy Haired Boss can operate it? If someone who clearly has trouble operating a toaster asks a stupid question about the SMF Pro version, they are to be ridiculed mercilessly until they go away. The Lite version will be so simple and foolproof that there should be very few questions ever raised about it. (Of course, the fools will do their best to find problems to ask about...)
Would this approach work?
Some great comments so far on this topic!
My view on this is similar to Arantor's in this thread, at least from what I understand of it. The adage "Give a man a fish and feed him for a day, teach a man to fish and feed him for a lifetime" comes into play.
Personally I think that SMF functionality is very simple currently. The installer might not be the simplest thing around for newbies, but what can you do? You have the OM which helps, you have your host that you can ask, and if worst comes to worst you can always ask in the Support boards. The resources for users is vast, but the main problem is that they just go straight to the support boards if a problem comes up.
A lot of what the current expectation on the internet is becoming is "Build a Website in 5 minutes! No coding knowledge required!" instant-creation sites. It's as if they think you can just add water and a site is made. The commercials that air advertising these insta-sites don't help with the situation either.
But it's not just internet. A lot of business models are trying to appease the "increased simplicity" phenomenon that is occurring.
If we're going into appliance analogies here, then lets think of a microwave. In the beginning you mainly only had the time buttons to input the time the microwave was going to cook for. But for the sake of simplicity, we added a "popcorn" button (amongst many others now) in order to eliminate a lot of the hassle in the process.
So in a sense, the cause can be attributed much to society's changing expectations of how things are done. Maybe we're just being too pampered these days, who knows?
Though, to provide a counter-argument to this whole thing, for a new user going through all of the pages and pages of code, learning about database structures, figuring out phpMyAdmin, understanding SSI.php....it can be pretty damn intimidating to someone just learning the ropes.
Let's face it, as simple as the Package Manager is, and as simple as the Installer is ****** does happen and code does break on forums. I can certainly understand if someone is scared that their forum broke, and is panicking. Of course they don't want to try to go into the code and break something else or make the situation worse.
If your gas line broke or something, and you're trying to fix it.....you'd be pretty damn scared to go in yourself lest you end up damaging the carburetor...or something.
It's like you said Phil, you'd still trust your mechanic to fix your problem for you. But having a knowledge of how suspension works, or what horsepower calculations stand for, or even the basic idea of how an engine works can leave you better informed about what does happen to your car and the best way to have someone else fix it.
Though Antechinus' idea of killing all the stupid people would do wonders for the world...
But what is the point of this? Not sure, myself. I'm just "talking outloud" and providing input to this. It's almost midnight, and I had a long day, but some input is better than no input at least.
SMF should look like this
(https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Frandazza.files.wordpress.com%2F2009%2F02%2Feasy-button.jpg&hash=53ad14d83cfc0b2c4c94d2308aff48c56e55b2b0)
Then it would be idiot proof.
It should look like a broken image?
To be idiot proof you must first get rid of these: http://www.simplemachines.org/community/index.php?topic=379045.0
kinds of stuff.
1. It's basic spam
2. Wrong board
3. Pretty sure the person doesn't really understand being a webmaster :D
Please note that while comments, ideas and opinions, are welcome, attacks and basically insulting of other members is not. I'm afraid your post is at the edge of it, Royalduke. Please consider posting your opinions with a friendly and non patronizing tone, or don't do it at all.
Thank you for your understanding.
I may not be as smart in developing as some or most of the people in this thread, but I do know quite a bit I would like to think. Back then however I thought I knew quite a bit, boy was I wrong. Currently my development skills include in order they where learned, BASICs, BASICA, QBASICs, VB, PHP, ActionScript, JavaScript. Isn't it strange how when your younger you don't believe that old saying that the older the wiser. ;)
It does bother me when people fail to look for their problems and expect a answer for a question without any details. What upsets me more is when they figure out their problem and fail to respond they fixed it. >:(
But I myself have made dumb mistakes, even as a skilled developer. Allot of my mistakes however have to do with typos. Time consuming though, but it happens to us all.
And a toaster is not idiot proof when it comes to people and forks.
I'm one of the Kill-SMF-when-modifying-files people :P
Like stated in my signature,
QuoteI'm a batch (MS-DOS) programmer, don't ask me questions about PHP or CSS or your forum will be doomed.
And that's true.
Let
me modify PHP files and the software associated with it dies.
Quote from: Yoshi2889 on July 15, 2010, 11:30:36 AM
I'm one of the Kill-SMF-when-modifying-files people :P
Like stated in my signature,
QuoteI'm a batch (MS-DOS) programmer, don't ask me questions about PHP or CSS or your forum will be doomed.
And that's true.
Let me modify PHP files and the software associated with it dies.
Don't want to rain on your parade but batch as in batch file in MS-DOS is not programming. It is some pretty basic stuff and all us older generation say that used computers in the early 90s and before know how to write batch files. Come on we needed them until a good enough OS was made to sort all the junk out.Even made a virus, dumb youth. Something that was asked from me and I made it.
Quote from: nend on July 15, 2010, 12:18:52 PM
Quote from: Yoshi2889 on July 15, 2010, 11:30:36 AM
I'm one of the Kill-SMF-when-modifying-files people :P
Like stated in my signature,
QuoteI'm a batch (MS-DOS) programmer, don't ask me questions about PHP or CSS or your forum will be doomed.
And that's true.
Let me modify PHP files and the software associated with it dies.
Don't want to rain on your parade but batch as in batch file in MS-DOS is not programming. It is some pretty basic stuff and all us older generation say that used computers in the early 90s and before know how to write batch files. Come on we needed them until a good enough OS was made to sort all the junk out.Even made a virus, dumb youth. Something that was asked from me and I made it.
Even if it was used in the early 90s why can't it be used in 2010?
I'm sorry but I like working in batch.
I'm actually having "fun" when writing those batch files and see that they are working.
Take a look at SMFTools (http://smftools.comlu.com/about.php), entirely written in Batch and still works pretty well.
I don't know if you want to ruin my fun but that is not gonna happen.
Quote from: nend on July 15, 2010, 12:18:52 PM
Come on we needed them until a good enough OS was made to sort all the junk out.
Scripts are still useful today. I create and manage several for my job to repeat tedious tasks. The other day I wrote a BASH script to automate the dumping and compression of Subversion repositories for backup of snapshots. I've also coded Perl scripts to create DNS zone files and re-build named.conf files for automated DNS management and wrote a file to parse a list of domains and sort out based on various criteria like non-existance, using NS other than what I want, using MX other than what I want, etc.
Just because Windows has a sucky script environment (I know no Windows server admins using WSH) doesn't mean scripts are useless. If anything, because of the modern complexity of computing, they are more useful than ever.
No don't want to ruin your fun. :D Just stating the obvious of how basic writing a batch file is and also I find your quote funny. Bringing down a site with a batch, not saying it isn't impossible though with the appropriate resources you can probably run a good DOS attack. I would recommend other ways though.
Don't want to poke much more about this. I had my ignorant youth days with something to prove and that is what your quote sorted reminded me of. I seen your sig before and just didn't mind it, but you quoted it in this post so I had to say something since apparently you feel so strongly about it. The ignorance of taking down a site with a batch file when there are allot better ways and talking about all this being illegal.
Quote from: 青山 素子 on July 15, 2010, 02:00:10 PM
Quote from: nend on July 15, 2010, 12:18:52 PM
Come on we needed them until a good enough OS was made to sort all the junk out.
Scripts are still useful today. I create and manage several for my job to repeat tedious tasks. The other day I wrote a BASH script to automate the dumping and compression of Subversion repositories for backup of snapshots. I've also coded Perl scripts to create DNS zone files and re-build named.conf files for automated DNS management and wrote a file to parse a list of domains and sort out based on various criteria like non-existance, using NS other than what I want, using MX other than what I want, etc.
Just because Windows has a sucky script environment (I know no Windows server admins using WSH) doesn't mean scripts are useless. If anything, because of the modern complexity of computing, they are more useful than ever.
Scripts are always useful, I know the usefulness of them. I can make them either in BATCH, BASH, Basics, Basica, GW-Basics, Q-Basics, VB, JavaScript, ASI, ASII, ASIII & PHP. I haven't learned Perl though, no plans at this time to learn.
Um, folks, can we sort of get back towards the original subject of making SMF as idiot proof as possible? Reminiscing about past glories as scripters is all well and good, and batch scripts (with a real, powerful scripting language) are of course very useful, but perhaps that should be over in the Chit Chat board?
Quote from: MrPhil on July 16, 2010, 10:13:19 AM
Um, folks, can we sort of get back towards the original subject of making SMF as idiot proof as possible? Reminiscing about past glories as scripters is all well and good, and batch scripts (with a real, powerful scripting language) are of course very useful, but perhaps that should be over in the Chit Chat board?
Yes you are right.
Maybe you can change the text to "If you see this message you are hacked!" or something.
the problem with making things "idiot-proof" is that the idiots keep coming up with new ways to break things.
Quote from: Kindred on July 18, 2010, 05:22:53 PM
the problem with making things "idiot-proof" is that the idiots keep coming up with new ways to break things.
That mean idiot proof is not the solution, but easy to use is the solution.
Speaking of "idiot proof" I recently made a suggestion (which much to my surprise got booed to hell and back) for an emergency back door.
I would like to suggest in the alternative that any helpful "unjamming" queries be posted to the FAQ and/or manual. See my support topic on IP banning myself for a specific example.
One of the ways to "idiot-proof" something, apart from making it hard to break in the first place, is the next best alternative of making it easy to fix in the second place.
I agree with that as well, shentino. :)
Having good documentation, and perhaps good tools to help a broken case, is the next best thing.
I think that is a much better solution and yes, we should do that. :)
Good coding in the first place would help ease the burden on this forum. If my fixes for the SMF 1.1 Settings.php-being-emptied were implemented in 1.1.12, that would be a big help. Look through the forum for other common problems that keep getting reported (e.g., the ALTER TABLE ORDER BY LENGTH bug, the spurious "database upgrade required" warning, the problems with the database dump, etc.) and fix them, which would make SMF look so much better, and greatly reduce the number of problems reported here.
Part of the effort of building a good product is to pay attention to commonly reported problems, and make an attempt to fix them and get them out of the stream. It's a shame that the SMF developers refuse to fix very common problems in SMF 1.1, all because they want to drive users to 2.0 when it finally goes Gold. That's not the right way to do it. True, the idiots who won't bother to search for a problem and its fix in the forum are a royal PITA, but that's life. Part of making SMF more idiot-proof is to take the common bugs out of the product, so the common rabble won't keep encountering them. That's the core of "idiot-proofing" a product.
Add: The "eval disable" button must be part of the base code, so we don't have to keep telling people to add the mod when they report a bug.
MrPhil: I understand your points of view, and agree with most of it. The focus HAS to be on 2.0 though, and it is a practical impossibility to do much in the way of maintenance for 1.1.x (- though we are going to take into account certain backports of major bugs) given the constraints the development team is facing.
The ALTER TABLE ORDER BY LENGTH issue has been solved in svn for 1.1.x as well, it should be available in 1.1.12.
I believe the Settings.php emptying issue is also taken into account for 1.1.x as well.
Incidentally, I do consider MS-DOS batch files to be programming. Just with a feature sparse language ;)
Ah, and the disabling eval feature is part of the core SMF in 2.0. :)
Quote from: shentino on July 19, 2010, 05:44:49 PM
Incidentally, I do consider MS-DOS batch files to be programming. Just with a feature sparse language ;)
It matters what you consider programming. Yes it is a simple programming language, but to consider yourself a programmer by knowing how to code a couple simple lines in a bat file IMHO does not make you a programmer.
Quote from: Norv on July 19, 2010, 03:28:39 AM
I agree with that as well, shentino. :)
Having good documentation, and perhaps good tools to help a broken case, is the next best thing.
The documentation is there but not enough. More advance stuff would be nice, maybe some simple code snippets. Maybe a full function database, I would like that allot :D.
Most of all the one thing I dislike about the online manual is the layout. I think the manual would benefit more if it was more of a wiki style manual allowing contributions from the whole SMF community. The doc writers should have a final say though and should be the moderation/proofing team, still able to make contributions but able to control the whole documentation project. I think it would be good idea to pilot this and see how it goes, there is mediawiki which will be a quick setup. ;)
Simple. Tie it into membership on the forums, and simply let the mods be admins there, admins here bureaucrats/stewards there, and let anyone edit if they register here and make it to rank 2.
The topic is too long to read at the moment, but to comment on the OP, I really don't think we should even think about making stuff idiot-proof,
what probably should be worked on though, is to make things more idiot-friendly - that is stuff like a wysiwyg editor for themeing sound good,
but wasting time on actually preventing inexperienced users from making mistakes is actually a bad idea IMO.
That is how we create more mindless idiots.
Quote from: nend on July 20, 2010, 12:13:39 AM
Quote from: shentino on July 19, 2010, 05:44:49 PM
Incidentally, I do consider MS-DOS batch files to be programming. Just with a feature sparse language ;)
It matters what you consider programming. Yes it is a simple programming language, but to consider yourself a programmer by knowing how to code a couple simple lines in a bat file IMHO does not make you a programmer.
I don't know, I've seen some pretty sophisticated batch files...
Though you do have a point that DOS's limited batch file language does preclude a lot of more "mature" programming that you can only get with a fully featured language such as C or Perl.
However, to be quite frank DOS batch files are what I started programming in when I was a lad of 10 or so. They were my bread and butter, until I moved up to GW-BASIC.
A baby penguin's gotta cut his beak on something.
Quote from: shentino on July 20, 2010, 03:06:16 AM
However, to be quite frank DOS batch files are what I started programming in when I was a lad of 10 or so.
Batch files and basic ;D Yeah - familiar story...
Quote from: nend on July 20, 2010, 12:13:39 AM
Quote from: shentino on July 19, 2010, 05:44:49 PM
Incidentally, I do consider MS-DOS batch files to be programming. Just with a feature sparse language ;)
It matters what you consider programming. Yes it is a simple programming language, but to consider yourself a programmer by knowing how to code a couple simple lines in a bat file IMHO does not make you a programmer.
Quote from: Norv on July 19, 2010, 03:28:39 AM
I agree with that as well, shentino. :)
Having good documentation, and perhaps good tools to help a broken case, is the next best thing.
The documentation is there but not enough. More advance stuff would be nice, maybe some simple code snippets. Maybe a full function database, I would like that allot :D.
Most of all the one thing I dislike about the online manual is the layout. I think the manual would benefit more if it was more of a wiki style manual allowing contributions from the whole SMF community. The doc writers should have a final say though and should be the moderation/proofing team, still able to make contributions but able to control the whole documentation project. I think it would be good idea to pilot this and see how it goes, there is mediawiki which will be a quick setup. ;)
Have you been talking to people? ;)
Quote from: Kindred on July 18, 2010, 05:22:53 PM
the problem with making things "idiot-proof" is that the idiots keep coming up with new ways to break things.
I'm sorry but I was lolling at this
QuoteIt matters what you consider programming. Yes it is a simple programming language, but to consider yourself a programmer by knowing how to code a couple simple lines in a bat file IMHO does not make you a programmer.
I just call it programming...what word do I use else :P
Quote from: Yoshi2889 on July 22, 2010, 11:38:09 AMQuoteIt matters what you consider programming. Yes it is a simple programming language, but to consider yourself a programmer by knowing how to code a couple simple lines in a bat file IMHO does not make you a programmer.
I just call it programming...what word do I use else :P
MS-DOS coder?
PLEASE folks, can we get back on topic? Yes, DOS batch is programming, albeit at a very simple low level. You're telling a computer how to do some task, which is by definition programming. Now, can we talk about how to make SMF less vulnerable to, uh, "idiots"? And how to make it simpler and more straight-forward for unsophisticated non-programmers to use, while not crippling its power?
I don't want to have to ask the moderators to start removing off-topic postings. If it's really important to you to discuss whether MS-DOS batch files are programs, can you move that to a "Chit Chat" topic? Thank you.
/me agrees with above post
Well, uhm, with quick thinking:
1. Add shortcuts for admins in topics/other places
2. Make the Error Log more simple (like it just says "Needed file "/folder/file.php" not found. Please reinstall the accosiated package.")
3. Add integration options (like if it found WordPress a button with "Integrate WordPress" will show)
This is just quick thinking...
Make it so that the install.php script can unjam the board by removing bans or creating admin accounts.
Quote from: shentino on July 23, 2010, 07:10:35 AM
Make it so that the install.php script can unjam the board by removing bans or creating admin accounts.
Actually.... To allow any tool to easily create admin accounts isn't too wise IMO, but that's not a completely crazy idea, for example clearing bans and reactivating existing user accounts could
be made insto a stand alone tool - or what do people think about this? :P
Quote from: LexArma on July 23, 2010, 07:14:03 AM
Quote from: shentino on July 23, 2010, 07:10:35 AM
Make it so that the install.php script can unjam the board by removing bans or creating admin accounts.
Actually.... To allow any tool to easily create admin accounts isn't too wise IMO, but that's not a completely crazy idea, for example clearing bans and reactivating existing user accounts could
be made insto a stand alone tool - or what do people think about this? :P
You could make the tool so that it digs into the database and clears the table that holds the bans...
Maybe add a note to each page in the Sources directory like
// The code of this page should not be modified unless installing a package or if you need to do some serious maintenance.
Quote from: LexArma on July 23, 2010, 07:14:03 AM
Quote from: shentino on July 23, 2010, 07:10:35 AM
Make it so that the install.php script can unjam the board by removing bans or creating admin accounts.
Actually.... To allow any tool to easily create admin accounts isn't too wise IMO, but that's not a completely crazy idea, for example clearing bans and reactivating existing user accounts could
be made insto a stand alone tool - or what do people think about this? :P
This is the same idea that got booed to China, somewhat. In that case though my suggestion was misinterpreted as creating admin accounts, whereas I meant removing obstructive bans.
A tool, perhaps disabled by default and requiring shell access to the install files to enable, to remove bad bans would probably be helpful.
I recently had the embarrassing experience of pushing the wrong buttons and permabanning 127.0.0.1, making it impossible for me to even log in as admin.
Quote from: shentino on July 23, 2010, 01:28:39 PM
I recently had the embarrassing experience of pushing the wrong buttons and permabanning 127.0.0.1, making it impossible for me to even log in as admin.
You shouldn't be using a server as a desktop. It's a very bad idea.
Why is it a bad idea?
Because if a flaw is found in your server security settings or the web apps you are serving, an attacker can get access to your personal information. If you have personal accounts you log into (online banking, other financial sites, PayPal, e-mail), and save any kind of credentials, an attacker could gain access to those sites. Partitioning is a core part of proper computing security.
That's easy, run the server inside a VM.
Quote from: shentino on July 23, 2010, 08:41:49 PM
That's easy, run the server inside a VM.
Not every computer can handle that.
For example my desktop runs Ubuntu at average speed, now lets try Windows Server 2008...
COMPLETE
FAIL CRASH
Quote from: Yoshi2889 on July 24, 2010, 11:56:29 AM
Quote from: shentino on July 23, 2010, 08:41:49 PM
That's easy, run the server inside a VM.
Not every computer can handle that.
For example my desktop runs Ubuntu at average speed, now lets try Windows Server 2008...
COMPLETE FAIL CRASH
Why would you want to run Windows Server? It's an expensive license anyway.
Also, yes, a VM is an option if you don't have separate physical machines.
Quote from: 青山 素子 on July 24, 2010, 12:25:58 PM
Quote from: Yoshi2889 on July 24, 2010, 11:56:29 AM
Quote from: shentino on July 23, 2010, 08:41:49 PM
That's easy, run the server inside a VM.
Not every computer can handle that.
For example my desktop runs Ubuntu at average speed, now lets try Windows Server 2008...
COMPLETE FAIL CRASH
Why would you want to run Windows Server? It's an expensive license anyway.
Also, yes, a VM is an option if you don't have separate physical machines.
Didn't I say "example"?
Wow, we're getting off topic again.
Back to SMF being idiot proof, I think that basic sanity checking can go a long way.
Like, for example, displaying a warning before implementing an IP ban that will affect the current user.
Quote from: shentino on July 24, 2010, 11:39:41 PM
Wow, we're getting off topic again.
Back to SMF being idiot proof, I think that basic sanity checking can go a long way.
Like, for example, displaying a warning before implementing an IP ban that will affect the current user.
No that was not off-topic. I was pointing him out.
For example add a warning like Nintendo, "Are you sure you want to leave blablabla? Blablabla is not responsible for the content of the linked site.".
Quote from: MrPhil on July 22, 2010, 06:26:26 PM
Now, can we talk about how to make SMF less vulnerable to, uh, "idiots"? And how to make it simpler and more straight-forward for unsophisticated non-programmers to use, while not crippling its power?
It's impossible... by coincidence you'll find an user that read the install instructions...
Make documentation? Useless, if it has more than one paragraph most of them won't read it.
Make videos? If it last more than 5 minutes everyone will skip it.
Make audios? No-one would heard them.
Make help tips? Most of the people find it extremely annoying.
Make a SMF guide tour? I'm sure most of the users will skip it.
It's hard to make people READ or PAY ATTENTION to something that's instructional (even i don't pay attention... :P ). So idiot-proof would be a miracle (from my point of view).
Quote from: DoctorMalboro on July 25, 2010, 10:19:57 PM
Quote from: MrPhil on July 22, 2010, 06:26:26 PM
Now, can we talk about how to make SMF less vulnerable to, uh, "idiots"? And how to make it simpler and more straight-forward for unsophisticated non-programmers to use, while not crippling its power?
It's impossible... by coincidence you'll find an user that read the install instructions...
Make documentation? Useless, if it has more than one paragraph most of them won't read it.
Make videos? If it last more than 5 minutes everyone will skip it.
Make audios? No-one would heard them.
Make help tips? Most of the people find it extremely annoying.
Make a SMF guide tour? I'm sure most of the users will skip it.
It's hard to make people READ or PAY ATTENTION to something that's instructional (even i don't pay attention... :P ). So idiot-proof would be a miracle (from my point of view).
You're correct.
Personally, I think that refusing to read documentation that's clear and well written should be considered suicide.
Quote from: shentino on July 26, 2010, 05:29:33 PM
Personally, I think that refusing to read documentation that's clear and well written should be considered suicide.
I think being lazy requires suicide...
Y'know I did suggest in the team boards once that we include an intelligence test in the installation pack. The plan was to weed out the idiots in advance. ;D
That's cheating.
Copping out and preventing idiots from using the software isn't the same as being robust.
It's idiot immunity, not idiot prevention.
Quote from: shentino on July 27, 2010, 12:40:11 AM
That's cheating.
Copping out and preventing idiots from using the software isn't the same as being robust.
It's idiot immunity, not idiot prevention.
The first step to immunity is to prevent idiots from doing stupid things.
And why is it cheating?
Quote from: Antechinus on July 26, 2010, 07:50:03 PMY'know I did suggest in the team boards once that we include an intelligence test in the installation pack. The plan was to weed out the idiots in advance. ;D
If you make that test... some boards would be full of "Can someone pass me the third question?" or "I'll pay someone to do this test"... ::)
How 'bout a little less flaming and a little more constructive brainstorming (or "thought showering" for our English friends :) ).
Sure, you can lock your user into a straitjacket, and not let them do anything potentially harmful without asking permission from Mommy, but that will drive away all but the most simpletons. I see the basic problem as being that if you give enough flexibility (to do "interesting" things) for the experts, the idiots will hurt themselves. The question becomes: "How do we make at least the routine operations just about goof-proof for the dumbasses, while not keeping the mavens from doing what they want?" In almost any operating system, there is a lead-you-by-the-hand GUI to do 95% of most anything you want, while there is also a Command Line Interface to let you do that by hand, plus the other 5% that's missing from the CLI. In an idiot-proof GUI, you'll never figure out everything that a user (customer) might reasonably want to do, so you let experts use CLIs and directly edit PHP code and tweak the database via phpMyAdmin. All you can do is discourage those with lesser abilities from playing with such sharp knives.
Now, it appears to me that most support questions with SMF involve mods that fail to install completely, only partially install, only partially uninstall, or fail to uninstall. Usually this is because the install/uninstall package manager is looking for code patterns to match, to find where to delete lines and add lines, and is failing to match those patterns, due to intervening changes (due to other mods). If we left mod installation/removal to the experts, we'd just say, "OK, here is the place in vanilla SMF to change. Figure out where and how to do it in your modified copy. Have fun!" You can't do that with your average user. They're not computer scientists -- they want to use SMF as a tool to do something useful, not be a new hobby in and of itself. The first step in a solution is refuse to do any installation (or removal) of a mod unless all the patterns can be matched. Never ask permission to do some of the changes, while leaving the others to be done manually, because they won't get done. Leave it to an expert to manually edit the files. The second step would be to find a different mechanism than to try to match patterns. Should SMF have "hooks" (see Drupal) for loading in new code in specific places? The problem with that is you don't know in advance all the places that a user might need to add code (or disable existing code).
What if the user gave the package manager a list of mods that they want installed, and the PM checks prereqs and then installs all of them at once against a vanilla copy of base SMF? Mod removal would involve starting over from the vanilla base, and installing all but the mod(s) to be dropped from the list. There's at least the possibility that two mods that want to go into the same place will both go in, in the order specified, without the first one "spoiling" the location pattern of the second. I don't know how that will work if one mod wants to change a different, overlapping range of lines than "earlier" ones do (or a mod is to modify another mod) -- there may have to be some restrictions. How about trying to apply mods to anything but the default theme? Should different themes (skins) be confined to having different CSS files, and the same PHP code? Finally, is a purpose really served by restricting a mod to certain version numbers? It seems that this forum is forever telling people to ignore or bypass the version check -- why bother with version checks? If the code pattern cannot be matched, the mod will not install, right?
Most of the remaining questions (after the mod installation/removal problems) seem to pop up again and again -- how do I change the logo, how do I change this color, how do I _____? Instead of answering each question anew, what if SMF made an effort (if a "how to" question has come up more than once) to pop out a quick mod to do that? Or, a CSS editor that knows how to find certain class or ID definitions and change values via a GUI? E.g., "I want to change the window background color" -- you tell them to tell their CSS editor to find such-and-such a class, and click on "background color" and select/enter the desired color. The editor could add new entries where none exist. Anyway, the idea is to keep users from having to hand-edit PHP or CSS code for almost anything they want to do (many users find quite creative ways to screw up). Put all mods into a FAQ or some other way to more easily search than the current mods index. Evidently most users can not or will not do a search of the mods library before asking a "how do I" question. Give them several ways to find an existing way to do something.
Have at it...
Quite honestly, I think that most of those "examples" fall into the realm of an FAQ/WIKI rather than having the team spend time making a "mod" to do it.
As for mods writing into specific sections of code... MUCH of the "problem" has to do with mod AUTHORS not respecting the full coding solution. So, either we reject 60% of the mods, or we put up with users having issues. Yes, the idea of "hook points" has been brought up (and is not a bad idea)... but then again, we run into the problem of THEME authors having to change the way they code every theme and making sure that any template file which is in place for that theme maintains all of the hook points. Again, we'll probably have to reject 60% of the submitted themes.
Your idea of a base install is not a bad one... if the site only has one or two mods... but you get a site (as I have seen) with 30-40 mods installed and it becomes unworkable. Heck, even 10 mods would make it unrealistic. :(
Our best bet is to improve the documentation and point users to the proper FAQ rather than trying to think of all the stupid things they COULD do.
Just tossing it here, how about this: http://www.simplemachines.org/community/index.php?topic=392338.0
I wonder, would having different "distributions" of core SMF and a few official mods help with a number of (presumably) widely used mods? It's just a question. :)
Norv...
for the same reason that the supermod was a bad idea, so is that... Any mods that the teams want to work on - on their own - is fine, but having team supported "super mods" means that we have teams spending less time working on or supporting the core product and more time supporting idiots who don't use search, don't read and can't install a mod, even with the package manager.
That depends on what mods we're talking about. If the core can be made more light, and other extensions to it (currently monolithically included in it) can be distributed optionally, fully optionally, then you can have practically no additional support.
Though admittedly that was not all my intention.
Mods have their own licenses so the mod authors will have to approve them for distribution in a package with SMF.
I am not supporting this idea though, I actually do not like the idea and think my main point stands. We need better documentation, what is so wrong with a user contributed WIKI.
People do not easier scripts, they need to learn how they work, if not then in my opinion they shouldn't have that script on their website.
Working on the wiki ;)
I would propose that popular mods would possibly be an indication of a feature widely used enough to consider including into core.
They are, IMHO. However it is definitely not the only thing to consider.
Quote from: shentino on July 26, 2010, 05:29:33 PM
Personally, I think that refusing to read documentation that's clear and well written should be considered suicide.
Well........... how often have you found documentation that's clear and well written and complete and well organized? Damned rare, in my experience, especially with Open Source projects.
Let's look at it from the viewpoint of a user. An "idiot" user. They want to do something, so they fire up the Admin section, or whatever, and try to do what they want. They are
not necessarily going to go searching for documentation first. Even if they
do find documentation, did they have to hunt for it, or was it easily available? If they could find it without too much trouble, was it clearly organized, so they could find what they wanted without having to read
War and Peace from cover to cover? Some sort of "help" buttons linked to the appropriate documentation sections should ideally be scattered throughout a page. Help is at hand, and you're taken directly to the pertinent help, and you have the ability to start browsing around via links to other help text. That would be the most useful documentation, and the most likely to be used (even by idiots). You don't want to clog up a task with instructions mixed in with everything else, but you don't want a user to have to drop everything and get into a different mindset to go looking for answers. By the way, documentation of any kind should always include a "task oriented" or "cookbook" section -- that's where most users will head first when confronted with a task they need to do.
Quote from: 青山 素子 on April 29, 2010, 12:41:26 PM
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.
+1
"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
Douglas Adams