Topic: [3.0] My Thoughts on Features for SMF 2.1

[Antechinus]

All it does is annoy legitimate new members.

Even if it's set to simple/very simple?

ROFL. If you use that setting it has absolutely no security benefit anyway. However, it is still a minor irritation for genuine users.

[Labradoodle-360]

If it has absolutely no security benefit, why is it still on the base of the software?

[Antechinus]

Legacy code, in my humble opinion. It was useful until fairly recently, and some people might be worried if it wasn't there.

[live627]

ROFL. If you use that setting it has absolutely no security benefit anyway. However, it is still a minor irritation for genuine users.

/me thinks of ArantorCaptcha...

[青山 素子]

In my opinion, SMF should just support MySQL, or have the option to select their database type on the installation.

I have a concern over dropping everything except MySQL support. Oracle is pushing MySQL towards an "open core" model where only the very core of MySQL is open source. Everything else is closed-source and possibly heavily licensed and expensive if it's not for personal use (e.g. hosting companies would need to pay).

I'm not against using commercial software. Rather, I'm concerned about locking up a product which has had significant effort expended to support multiple backends when the one "chosen" backend is being produced by a company that has a direct interest in monetizing that backend and making sure it never eats into the company's main product.

Personally, I think more effort should be made to either extend the multi-database support into a proper db abstraction layer, or even an ORM. That, or finding a lightweight, license-compatible multi-database ORM that can be used.

All old browser support should be dropped, such as IE6. There are quite a few limitations supporting old browsers cause, and there has to be some point where developers can develop Web 2.0 code without worrying about old browser compatibility and having to code a lot of extra lines to keep it compatible with ancient browsers.

Agreed, especially given the declining relevance of that version on public sites. However, it would be useful to somehow get statistics on the browser makeup for SMF users to make sure it's fully a wise choice.

jQuery is most definitely in the future of the web, it is highly extensible and at the same time lightweight. If for no other reason, it should be included on a boolean variable for mod authors to enable if their mod uses it.

In my opinion, the default theme should also contain some nice attributes that CSS3 has to offer.

Supported as long as an eye is given to proper degradation. No breaking functionality to where stuff doesn't run simply because JS isn't being processed by the browser.

Most modern browsers contain some form of spell-check built in, or an addon for it. SMF's also requires a third party script to run. So in my opinion, it's not even practical.

Although I do believe it could be updated, and provided as an official addon/modification.

SMF uses PHP's built-in aspell support via the pspell module, so it's not third-party. However, pspell has been deprecated in favor of enchant. PHP 5.3 doesn't support pspell at all. Effort should be made to either move to enchant or drop server-side spell checking.

I believe the Calendar should not be a core-feature. I think it should be removed from the SMF Core, and completely re-written to have an AJAX/jQuery fancy interface, provided as an official addon/modification.

Agreed. The calendar has long been neglected and it's tangental to the purpose of a discussion forum. An officially supported modification would be the best way to go along with enhancing the calendar to make it more useful. Please do note my comments above about not breaking if JS isn't being run.

Plus some more automation such as auto-data type with the ability to over-ride? For instance, with $smcFunc in 2.0, you have to declare each columns data type, such as 'field' => 'int', and so forth, but this can be figured out with PHP very easily, with no need to declare each column.

I think that was done for data protection so that if a variable gets data that doesn't match the assigned type, it wouldn't be used. Can this be done automatically? My understanding is that it couldn't be easily done.

I believe bloated profile fields as "MSN" - "ICQ" - "AIM" - "YIM" should be removed. With the addition of Custom Profile Fields in SMF 2.0, why provide some fields, but by no means them all? What about Skype, Google Talk, Facebook? I think it's much better to remove all un-necessary fields but allow them to be added easily through Custom Profile Fields. You could even have "Custom Profile Field Templates".

Agreed. At least two of those messanger services are barely used today. Moving to custom profile fields would be a great way to avoid having to pick services, especially when ones like QQ are popular regionally (and useful for forums serving people in that region) but not globally.

The buddy list is very limiting, and practically useless. This should be moved to an actual database table, and the features expanded.

What kind of features are you thinking?

The profile sections of SMF are lacking, and very behind today's technology and social aspects. Inline editing, more social such as visitor messages / comments / notifications / etc.

I guess. I never use those features on other boards, but I am sure some people spend 60%+ of their time in those areas.

Recaptcha to replace SMF's default captcha?

Third-party external service that requires WAN connection. Probably won't happen. It's also widely targeted by various spambots, so just changing around the custom functionality would probably be more effective. (I say this, being the maintainer of the reCAPTCHA modification.)

Note that several human-backed services such as CAP****bot (censored as I'm not giving them free publicity) are widely used by spamming tools. These services use real humans to solve image puzzles, nullifying the purpose of having them on your site in the first place.

Oh, if you try to look up the solving service I mentioned, do be careful. It's run out of Eastern Europe by the same type of people that do scareware and drive-by infections. The site has the potential to be dangerous.

Personal Messages should definitely have the ability to include attachments.

There was some concern over this when it was suggested before. Not only do you now have a potential problem of attachments taking up space on your site, you have some potential legal issues as well. For instance, you may get two people trading child pornography via PM (rare, but it sadly does happen). Now your website is hosting illegal material. You also may get some adult sending a child nude photos (sadly, probably less rare than the first scenario), creating more issues. Then you also have the problems of someone sending malicious files and trying to get users to run these files - kinda like what happens in e-mail now.

Without a way to monitor these files, you're opening yourself up to some big problems with this feature. Since these are ostensibly personal, monitoring these things isn't really a solution.

The possibility of completely removing the actual "post" page and making something similar to Quick Reply be the main form of posting, with BBC editor obviously, and attachments. (Attachments powered by AJAX?)

There should always be a post page if only for those users running in constrained environments (mobile, for example) where heavy JS would not work well. Likewise, the ability to hide all the editor "chrome" is useful for reducing data transfer size and just removing clutter when the user knows how to type bbc.

Provide a more intuitive Newsletter system, with a more advanced news system being an official addon/modification.

Agreed, kinda. It would be nice to have a newsletter archive without needing to manually make one. Also, some thought should be given into what to do with the news system.

Who doesn't have a smartphone today? Provide jQuery Mobile for smartphones. "Posted from iPhone" or "Posted from Android" (very simple to addon, but a neat idea imo)

Just using JS to add a line of text?

Provide a simple but customizable interface to modify email templates? Probably better kept out of core, and added as an official modification.

Agreed.

The ability to "blacklist" an address, when the link is clicked, warn the user that the link is blacklisted, ability to proceed or stop. Let users know that they are clicking a link that is external. Enable or disable...possibly a modification rather than core.

I see a lot of ways of going around this. There are tons of URL shorteners that can obfuscate an address. Having an external modification that can treat external links specially might be interesting.

[Labradoodle-360]

I have a concern over dropping everything except MySQL support. Oracle is pushing MySQL towards an "open core" model where only the very core of MySQL is open source. Everything else is closed-source and possibly heavily licensed and expensive if it's not for personal use (e.g. hosting companies would need to pay).

I'm not against using commercial software. Rather, I'm concerned about locking up a product which has had significant effort expended to support multiple backends when the one "chosen" backend is being produced by a company that has a direct interest in monetizing that backend and making sure it never eats into the company's main product.

Personally, I think more effort should be made to either extend the multi-database support into a proper db abstraction layer, or even an ORM. That, or finding a lightweight, license-compatible multi-database ORM that can be used.

At least make the install script smart enough to delete the other database system files.

Supported as long as an eye is given to proper degradation. No breaking functionality to where stuff doesn't run simply because JS isn't being processed by the browser.

There has to be some point when the people without JS just need to turn it on. The majority of people do have JS on, the people that don't will need to eventually or the web won't be able to advance. Same thing with old browsers really.

I do agree some noscript stuff should be implemented, but not to the point of restricting the functionality of jQuery and what it can do.

I think that was done for data protection so that if a variable gets data that doesn't match the assigned type, it wouldn't be used. Can this be done automatically? My understanding is that it couldn't be easily done.

You can use functions such as is_int(); or is_string(); to determine whether it's an int or a string, and there are others for different types of course, so yes, it's easily possible. Just some validation and error throwing if it's not inside of one of those.

What kind of features are you thinking?

Just some more friend settings, the ability to add a friend with requests and so forth.

I guess. I never use those features on other boards, but I am sure some people spend 60%+ of their time in those areas.

Whether everyone would use it or not, a lot of people would, SMF is behind in my opinion socially.


Despite the whole personal message issue, I still think it's not a huge deal if you have a disclaimer. Especially with the report to admin PM function.

- Not having a post page wouldn't decrease the performance?

- Posted from a Smartphone could be a line of JS...or it could be a line of PHP that would determine the OS. (Which is already implemented in SMF)  [I actually think I might write this mod up shortly]

Although there are a lot of link shorteners, Facebook still has a blacklist check afaik.

[Kindred]

I actually dislike the idea of the "posted from my phone" line. I remove that crap that the phone auto-adds by default as soon as I get the phone. I don't want people to know if I am posting from a phone or a computer unless it is specifically relevant, in which case I'll mention it.

[Labradoodle-360]

I suppose it's all in taste.

* Labradoodle-360 decides to add a user toggle for "Posted from my iPhone" - "Posted from my Android".

[Illori]

i would rather not even have it as a option and just not show it. i dont care if they are posting from a cell phone yet what phone it is.

[Labradoodle-360]

Then don't install the mod I write, and forget it from my thoughts on 2.1 features Thanks for being positive and encouraging.

I actually really like it, and I'm sure there are others who would find it useful.

[Illori]

then it should be an option from the admin panel AND an option from the users side as well if it were to be a default feature.

[Labradoodle-360]

That's exactly how Look and Layout settings work...

[Illori]

not all of them can be locked by the admin so they can not be changed by the user at all.

[Antechinus]

Some of the other ideas are good, but I honestly can't see why having extra text declaring what phone something was posted from would be either useful or desirable. Personally, I find it slightly annoying when I see it attached to a series of posts. It's just useless clutter IMHO.

Lab: you posted your ideas. Other people have their own ideas. There's no need to get snarky if someone else expresses their views. Giving an honest opinion should be seen as being positive.

[N. N.]

Just to clarify quickly a small thing here,

SMF will continue and improve support for other database systems. While $smcFunc is not really a too nicely designed database API, that doesn't mean that is multiple databases feature's fault. . We're looking into improving it. I played with a possible alternative, will see how it goes. Personally, I cannot even imagine a package with the intended userbase, (relative) generality of a forum system, and its upcoming years (yes, also considering the conditions of questions about MySQL's faith itself, though afaik MariaDB is an option), hard-coding a single database system. Not that it can't be argued that it - still - does "hard-code" MySQL, in 2.0, but IMHO the way to take is forward, not backwards.

As a small example, we have users who honestly hate MySQL, and love Postgres. SQLite support is quite painful, but as possible, we will try to keep it for those hosts that don't offer MySQL... there seem to be a few out there, still, or personal webservers.

[青山 素子]

At least make the install script smart enough to delete the other database system files.

I thought it already did. I guess I'll have to double-check.

I do agree some noscript stuff should be implemented, but not to the point of restricting the functionality of jQuery and what it can do.

I don't mind requiring JS for extra functionality, but basic functionality shouldn't break just because something went wrong with the JS. That adds a whole ton of fragility and dependency on the client being sane with JS. It also can hurt search engines indexing your site.

You can use functions such as is_int(); or is_string(); to determine whether it's an int or a string, and there are others for different types of course, so yes, it's easily possible. Just some validation and error throwing if it's not inside of one of those.

I believe that's what is done at the deep level, but how do you know what datatype to check? Wouldn't it be simpler to pass the object through a validation function that checks the data is of the type of which it is tagged as being? I wouldn't want to have to add a ton of those types of checks everywhere the data is used. Also, by experience, developers are lazy. If it's not enforced in the framework, data type validation will be overlooked simply by forgetting to handle it.

Although there are a lot of link shorteners, Facebook still has a blacklist check afaik.

Sure, but they have a ton more resources than most forums. Also, if you wanted to be extra-safe, you'd have to look at what's behind the shortened URL, but a lot of shared hosts restrict the kinds of functions and access that would be needed to do so.

[Labradoodle-360]

I believe that's what is done at the deep level, but how do you know what datatype to check? Wouldn't it be simpler to pass the object through a validation function that checks the data is of the type of which it is tagged as being? I wouldn't want to have to add a ton of those types of checks everywhere the data is used. Also, by experience, developers are lazy. If it's not enforced in the framework, data type validation will be overlooked simply by forgetting to handle it.

No, just for database insert queries, it would run each variable through a check for data type, which it already does...you can just automatically find out it's type, rather than having to declare it.

It's really not a huge deal, just a small change really. Not a ton of benefit, but there is some.

[青山 素子]

No, just for database insert queries, it would run each variable through a check for data type, which it already does...you can just automatically find out it's type, rather than having to declare it.

But if you don't know what type it should be when handling it, looking at what type it is currently is pointless. Type checking isn't just about avoiding SQL injections. It's also about maintaining data integrity and avoiding other security issues due to the weak typing PHP has. If PHP was strongly typed, this wouldn't even be a discussion.

[Bloc]

In regards to Labradoodle's replies: I understand the reaction well lol, as there is no fixed view on what SMF should be..its not "simple", not anymore anyway, nor is it bloat-free, lots of things not related to forums have been added since 1.0. So i guess its more "add popular mods and optimize" sort of thinking going on.

In that respect anything goes, as long as its popular as mods ..so, do we see a gallery, Online users Today, Facebook integration etc..?

And having a smartphone template-set, please. It might not be important to show which phone you posted from, but it IS important to have a better experience on smartphones. Going with sidebars (as posted elsewhere) will only make it even WORSE to surf SMF sites on a smartphone.

[Antechinus]

Yes I know the sidebars are quite horrible on a smartphone, but the drops just don't work at all with touchscreen. Curve itself was never designed for smartphones and wont scale well to very small screens anyway. I agree we need something better.