Simple Machines Community Forum

Firstly, I'm well aware this should have been in 'Next SMF Discussion' but the board is set up so that I can't start a new topic there :/

Some people, it seems, are curious to know what I would make of SMF were I given the keys to the kingdom, especially as I have been critical of 2.1's developmental progress. (Please note that my issue with 2.1 is not the people doing it, because they're all good people. It's in the way the process has been handled)

And so, I found myself asking, what would I do? What would I like to see in SMF's future? We all know smCore is dead, and so we will ignore that, and instead focus on what SMF 3.0 - a pure forum software - should include, and the road to getting there.

Note that I am referring to building on top of current 2.1, and am only too mindful of what features were added in 2.1; things like auto-saved post drafts are already built in.

-- 2.1 --

I would declare 2.1 as it stands as feature frozen. Since no-one knows what should be in it or what it should be capable of, I'd just declare it feature frozen and concentrate on fixing up bugs. There are a number of bugs in it, as well as various theme issues especially related to some admin pages, where the theme just looks broken.

I would then concentrate 2.1 development on fixing the known issues and getting as much as possible just cleaned up with a view to a public beta by the end of the year. I do not see this as unrealistic given the manpower available to the SMF team should they actually get involved in trying to beta test things. As it stands, though, that kind of motivation is sadly lacking.

-- 3.0 --

I'd start 3.0 development on top of 2.1 while 2.1 is going through late beta/RC stages and use 2.1's build as basis.

There are a number of things I'd start changing. 2.1 has to retain a certain amount of backwards compatibility, 3.0 by definition does not (and smCore certainly wasn't going to in the first place)

1. I'd ditch the current converters. I'd build them into the admin panel as importers. This would encourage them being kept up to date more, and would actually be easier to use for users than the current organisation.

2. Facebook/XenForo like notifications system. It doesn't need to be as live as Facebook (and can't be done on shared hosting for the sheer server load issue) however the approach taken by XenForo and other systems would work well for this.

3. On the back of that, I'd move the Profile and Messages items out of the menu and place them up in the header area (much like other systems), and tie in the notifications to that.

4. I'd go UTF-8 only. Not needing multiple sets of language files, just one set of working language files. Everything gets a lot simpler under the hood, too.

5. I'd reorganise most of the current code into classes. I realise that going OOP is a big hurdle for modifications but for the core code it needn't be the headache that it sounds like it should be. Having the code organised by function, and more importantly organised in such a way that an autoloader will help you out is a big thing. Instead of loading a ton of code every page in case you might need it, load only what you need. You could save thousands of lines of code per page without any trouble doing that.

6. I'd overhaul the way news is currently handled. I'd move it to its own table, adding in visibility controls to it, making it clearer that bbc is allowed, and then I'd grab the entire thing, parse the bbc, then cache it. A surprising performance saving on every single page if news is in use. (Mostly like what I did for Wedge)

7. I'd rewrite the board index. All the board listing code relies on a quirk of MySQL that is no longer reliable. That needs rewriting to change the way it works.

8. I'd reimplement the ban system to be not based on triggers or groups, but simple linear bans. I would ditch the logging of bans and just flatten it out. (Like I did for Wedge)

9. I'd seriously give the warning system an overhaul (like I did for Wedge)

10. I'd phase out the Core Features page entirely. Half the items don't get any performance benefits from the actual page itself, so there's no real need for it.

11. I'd rearrange and streamline the admin panel.

There's plenty more but unfortunately I don't have time right now to deal with it.

EDIT TO ADD:

OK, let me go into more detail.

10. Core Features doesn't generate anything worthwhile, there is no performance saving in most cases because the individual 'core features' internally do other management themselves which the CF page just replicates.

11. There are a great many things I'd change in the admin panel. Lots of things in weird places; mostly historically 'where they would fit'. I already did a ton of rearrangement in Wedge for this, I'd replicate most of that.

In particular, I'd totally gut how Themes > Member Options works. Almost none of those actually needs to be a per-theme preference, it can just be a single preference with reset option, which would be a major improvement.

I'd also rejig how permissions work, I would be inclined to make them role-based rather than group-based (another reason for having the importer: by having even SMF 1.x and 2.x as imported rather than just straight upgraded)

12. I'd also seriously overhaul how plugins/addons work, I'd promote hooks to be even more significant, perhaps the only method by which add-ons can be used, getting rid of file edits. I did it for Wedge and I believe it's the way to do it - yes, it reduces flexibility. But on the other hand, you get a much more rugged and stable approach to add-ons, you get things like easy/safe removal of plugins by renaming a folder to disable them.

Some of the more complex arts can be mitigated by switching templates out of the current PHP approach and switching to something like Twig; plugins would be able to make changes to templates safely in that situation.

13. I'd also replace the jump-to system with one more flexible, like a popup of sorts. It would look nicer, and would work better with all the portals out there that currently have to fight with it.

14. I'd drop the facility whereby each post has its own subject, I'd move that all to the topic itself. Saves a ton of space, makes a surprising number of things faster.

15. Overhaul search to be able to handle other kinds of content as well as supporting Sphinx properly with real-time indexes, and also provide support for ElasticSearch. Ideally ship both of these with the core.

16. Paid Subs supporting other things (not just PayPal) and working with fewer issues in general.


I'm sure there's even more, but that's the immediate and more important stuff I'd do. I'd like to hear everyone else's thoughts.

Quote from: Arantor on September 22, 2013, 02:03:37 PM
Firstly, I'm well aware this should have been in 'Next SMF Discussion' but the board is set up so that I can't start a new topic there :/

Yep, it is/was supposed to be a board where the devs (or others maybe) move things that are "accepted" to be in the "next SMF".

Quote from: Arantor on September 22, 2013, 02:03:37 PM
Some people, it seems, are curious to know what I would make of SMF were I given the keys to the kingdom,

You would run as fast as you can. :P ...unless you are crazy (and probably you are, like most of us... lol)

Quote from: Arantor on September 22, 2013, 02:03:37 PM
I would declare 2.1 as it stands as feature frozen. Since no-one knows what should be in it or what it should be capable of, I'd just declare it feature frozen and concentrate on fixing up bugs.

Actually it was declared feature frozen (https://github.com/SimpleMachines/SMF2.1/issues/102) more than a year ago, except that add things it's easier than fix bugs.
And there were (http://www.simplemachines.org/community/index.php?topic=480569.0) (yes, I know hidden board to the most) a very clear set of goals for 2.1.

...oh heck, here it is the post:

Quote from: xxxxx on February 22, 2012, 11:38:32 AM
One important note is that we are trying to not needlessly break the ecosystem that surrounds 2.0 (mods / themes / etc).  By this we are avoiding making changes in some areas unless there is a security or true performance improvement to be had. 

Basically this implies not doing pedantic changes or any large scale refactoring.  2.1 is really 2.0 "classic" and not a first step towards 3.0, since as we found that was really not going to be a step but a monumental change. 

All that said, yup as with any release we will run an excellent chance to break mods, thats the nature of mods that make source edits, its inherently fragile.  Simply adding a hook to a high traffic area will "break" things, but we should all know the benefits of that break.

You can go to the bug tracker and use a tag filter, 2.1 as the tag, across all projects to see what's being reviewed at this time.  There are bugs/features across 2.0, 2.1, 3.0 in the tracker, bit of a mess really, so again being this is a part time job :) I used 2.1 tags to track for now.

So with that brief introduction, below is a simplified list of things being worked on.  I felt this was an easier way to view things than providing any long list of bugs, who / what / where.  Also note a majority of the items on this list was derived from previous 2.1 wish list threads.

---

Core Improvements:
•   PHP 5 - This version will require a minimum version of php5.0  PHP 5 was first release in 2004, almost 8 years ago, its high time we moved to update our minimum support requirements.  (really I'd like this to be 5.1 which was late 2005)
•   IPv6 Support - Specifically in posts, ip tracking and ban management.
•   Smartphone theme - Smart phones have come a long way since SMF came out, and its time to provide a better basic interface than WAP for those users.  2.1 will have a new basic theme for viewing on smaller devices.
•   Jquery library support - Many mods require the use of Jquery so 2.1 will include it as part of the base.  You will have the option to load Jquery from the Google CDN or from your local install.  Where and how much we make use of Jquery ourselves is not clear ATM (menus, modal windows, autoselect are some thoughts)
•   Mod/admin sessions. - Today you can enable the need to login to gain access to the admin functions, new will be the setting to also require this for moderators as well.  Both will also come with the ability to end the admin or moderation "session".  This improves security to these more sensitive areas of the site.
•   Form Tokens - The results of adding tokens are improved security, such as basically no CSRF (Cross-site request forgery) can occur, even if an exploit successfully gained the admins session var and value they would still not gain access.
•   Code Cleaning - In some places the code has been cleaned up, mostly to remove older php 4 support and take advantage of new functions that were first made available in php5.  Additionally some basic functions have been refined to improve their performance.
•   HTTP only cookies - With this optional setting cookies won't be accessible by scripting languages, such as Javascript. This setting can help to reduce identity theft through XSS attacks

Modification support improvements:
•   Hooks Proliferation - There now almost 140 new hooks in 2.1, almost 4X the number in 2.0.  Hooks greatly reduce the need for mods to make direct code edits and allow for much easier mod installation and upgrades.
•   PHP Doc blocks - All of the code in 2.1 will have improved documentation, or at least easier to find documentation.  Instead of the files having all of the documentation at the top, things have been moved to each specific function.
•   Emulation Version dropdown - Allows for easy selection of other SMF versions when you need to install in emulation mode.

Theme support improvements:
•   PNG icons.  The old gif icons are nice, but PNG icons are better.
•   Cleanup of the markup/css.  There are many areas that are inconsistent from page to page, 2.1 will clean up a lot of these areas to provide a more consistent look and feel across the various pages.
•   Add ability to add javascipt/css via hooks
•   Move much of the inline javascript functions to script.js

Bug fixes:
•   We wrote them, you found them and reported them, now we are trying to fix them!  2.1 will look to squash as many bugs as possible, but we will not get to them all.  Currently 2.1 has addressed 80 bugs and there are many more being worked on.

Login/register improvements:
•   Allow the forum to be set up for the login username to only be the email address.

Package manager improvements:
•   <requires> tag, for mods that need to have another mod installed to operate, that mods package id can be specified to let the package manager check for compliance
•   <license> tag,  Will result in a notification under the readme, displaying the content of the license tag.
•   <hook> tag, allow the adding and removing of hooks from the package.info file.
•   <credits> tag, allow the adding the mods details under the credits area of the forum.
•   Improved zip file handling to reduce the number of invalid zip files or improperly expanded files.

Attachment improvements:
•   Auto manage attachments, will create new directory's as needed based on number of files set in the admin panel
•   Attachment Error Enhancements - Instead of the generic "you have a problem" message, you will now be notified which attachment has cause the problem and still be able to post with those attachments that did not fail.
•   Improve/fix image attachments checks. (i.e. reduce the number false infection positives on valid files)

Search improvements:
•   Search drop down, this topic / board / site
•   Improvements (bug fixes) to the custom index, text highlighting, searching on special characters like & > <, etc

Other improvements:
•   phpinfo() is now available form the Admin area
•   Recount users posts maintenance task will re-count and update the post counts for your users.

----------------------- CUT LINE / Scope creep ------------------------
These items should be in the core, but have not been claimed (just yet) ;)
"Smart emulate"  Let the system figure out the best version based on whats in the package info file and use of compareVersions functions
"message preview on hover"
"moved topic enhancements"
"Go Advanced" Option should be in Users Profile > Look and Layout not Admin panel
"signature preview" ... As a start, Perhaps anything that can be previewed, should have a preview
"categories in add/edit membergroups pages"
"Hooks admin area"
"Make the custom avatar directory functionality a default SMF feature"
"Option to "deny access" to a board"

Interesting, then, that several people I've spoken to lately - including BOD members, didn't even know there WAS a roadmap of any kind. (Which is why they were talking to me in the hopes of trying to get me on board as a dev...)

And yes, in the 18 months since that post, pretty much everything has been implemented. In which case, perhaps it's time to call for a push on bugs by releasing a public beta...?

Good reading. Of course those are your personal perspectives but for most they make sense.

I would add (and I think you forgot) the need to have a responsive mobile theme.

Yup, I forgot that, bearing in mind I was largely writing in a hurry :P

Having decided against my usual Tl;dr with long posts, I took the plunge. :)

Obviously, with my severely limited talents, quite a bit of what you typed didn't make total sense. (My lack of knowledge, not your lack of explanation).

What I read, made me think "hmmm. what I would make of SMF were I given the keys to the kingdom... I like that analogy". :)

Then, I got down to your numbered points.

Pardon my use of the vernacular, here. But, I thought "****** my old boots!". They describe, almost word-for-word, what I happen to feel are major failings in the software, as it is. As most know, my forum's still on SMF v1, for most of the reasons you describe. The admin panel, in v1, is a bit illogical, in places. But, with v2, it got even more loopy, for reasons that I doubt I'll ever understand.

I don't know if the themes thing could be changed, on top of your other proposals, coz, again, the themes for v1 seem, to me, to be much more varied and more... well... well, some still have that "WOW!" factor, which not a single v2 theme ever has.

I guess that what I'm saying is...

Quote from: Arantor on September 22, 2013, 02:42:58 PM
Interesting, then, that several people I've spoken to lately - including BOD members, didn't even know there WAS a roadmap of any kind. (Which is why they were talking to me in the hopes of trying to get me on board as a dev...)

It's nothing new that people don't read many boards here around and then complain about something that happened "somewhere else". :P
This post was firstly conceived in a dev-only board (about January), then posted in a team-only board (the above date), and finally posted in July last year (2012) in the dev board open to beta testers and friends.
ETA: and explained briefly (http://www.simplemachines.org/community/index.php?topic=498276.0) in a blog post.

Quote from: Arantor on September 22, 2013, 02:42:58 PM
And yes, in the 18 months since that post, pretty much everything has been implemented. In which case, perhaps it's time to call for a push on bugs by releasing a public beta...?

Actually 6 months after that post everything was already ready (well, a new theme WIP came in because "SMF cannot be released without a new theme").
I tried to push a release twice, but my conditions (like have it live here) for it were never met, so now it's up to Oldiesmann. He mentioned it twice recently, so I suppose he wants to have a release.

See, I can complain about things I don't know - the roadmap isn't public and thus as far as I knew...

Wait, so a full year ago it was basically ready to go?

Except for what it was added outside the scope and at the time it was not ready (and as you pointed out is not yet still fully ready), yes, everything else was done and ready for testing.

Hey Arantor... Not sure which members of the BoD were talking to you - but we've had a roadmap in place for 2.1 since before I resigned in 2012. Spuds and emanuele (and Suki for a little while) were working that while others started working SMCore.

And yes, technically it has been feature frozen (as emanuele points out) and we should have been working on fixing the bugs and getting the stuff out - especially since the alpha was released. (do note, I am not criticizing the devs who have stuck around, turn over has been a huge cause for delays)

I will say this:   Actually, the fact that BoD members don't know details of what is going on within the project is not specifically a problem or even concerning. The BoD should have nothing to do with the project on a day-to-day basis... Except as some members of the board overlap into the team (who should be aware - because, as emanuele says it has been posted to the team boards...) and, of course, the PM for the project is supposed to report "status of the project" to the board (which probably wouldn't include details, but should have included the fact that the roadmap exists).

As for getting you on board...  Come on in, the water's fine. :P (and the kool-aid is tasty)

Well, it does seem there has been some crossed wires. Mind you, the people I asked, I didn't ask "is there a roadmap" because that's not a smart question.

The way it was phrased is much more relevant: does anyone know what is supposed to be in 2.1? The general consensus I had in answer to this question was no. The fact there is a roadmap, which was largely complete a year ago, still suggests there is a very large management problem on the project. (And not all the people I spoke to are 'merely' BOD but active project members too)

I'm getting a bit off track at this point. We agree that 2.1 has a roadmap and that it is largely complete, that save for bug fixes and some theme fixes, there is no real reason why it can't be moved onto the next phase of the process, i.e. an official beta release. (I wouldn't consider 2.1 RC status yet, but YMMV)

The real question I'm getting at in this topic is... once 2.1 actually rumbles along, does anyone have any actual idea what to do next? That's why I posted what I'd do were I leading 3.0 development. Call it a suggested roadmap for 3.0.

Note, it is with extreme trepidation that I even consider the possibility of getting involved. The fact that as evidenced in this topic, that there are quite significant communication issues, the fact that there's still a fair amount of mudslinging going on from what I hear, and you know I've always had concerns over my contributions actually getting taken on board. I find it hilarious that I fixed the wrong dates in the calendar a full month ago and despite producing a complete set of updated files for 1.1.x, 2.0, 2.1, the full upgraders and a mod package to fix it for interim users, not a single file was downloaded from the bug reports board. I realise the calendar is a thing that people don't really like but still... if a legitimate, albeit minor, bugfix is produced and not even *looked* at for a month, what hope does that give me about legitimate bugs? I am still very reluctant to get involved with another group project after the events of the last month and I need to be absolutely sure that it is the right thing for both me and SMF were I to properly get involved. (The fact that Git totally does not follow my workflow does significantly impede potential progress, too.)

That said, I have poked my nose in around Github a few times. I do not like what I see. I do not like legitimate usability concerns being ignored as 'I like the current behaviour' and that a legitimate solution to users who don't like how SMF 2.1 does things is that they should just edit the template. I'm sorry, that is not a legitimate solution to a viable criticism. (Mind you, I think 2.1's theme is ugly anyway and the use of popups on profile areas just doesn't work the way it's implemented)

Personally, I get confused with github so I can't comment on the posts there, except when people have specifically linked me.

And yes, we should definitely be moving toward addressing the remiangn bugs and getting a beta release done.Not sure about your bug report/code....   I'm sure, now that you've pointed it out, emanuele or oldiesmann will take a look at it.

Yeah,there are always problems with communication... Less with mudslinging, IMO.  One of the things I am trying to work on for the next three months is improving the communication so the next pm to take over can have a smoother transition and a better motivated team. :)

as for beyond 2.1... That is also something that needs to be worked in. ;)

Thanks for starting this topic--as a very wet-behind-the-ears newbie, it's answered a lot of the questions I've had these past few days since joining the forum and installing 2.0.5 in my own little realm.

That said, I've still got questions galore, and one that stands out more than most of the others at this point in time has to do with trying to figure out what works and what doesn't, from a release perspective, without (e.g.) having to wade through the results of the searches through the mods sections (1.x.x and 2.x.x), and their respective forum topics. By that, I mean if a mod says it works with 2.0.5 in the mods section, is it safe to assume it was tested to at least some degree using that version?

Also, what might be handy someday (and I know the mod developers and/or others may or may not like this idea), would be a user ratings system of some sort [read: ratings provided by users in the know; yeah, I know not all users are in the know] that would allow newbies like me to quickly determine if I want to take an in-depth look at a mod and try it, or whether I might want to get myself a 10 foot stick. The way it stands right now, the only things a user has to go on are the comments of others in the forum itself, and/or the number of times the mod has been downloaded by others (keeping in mind that mods that have been around a long time will have a much wider user base). Oh, and then there are those mods made years back, perhaps updated through 2011 or even 2012, whose developers seem to have flown the coop and may have lost interest in them and since moved on to other things. Again, a number of those mod release notes at least imply that they're compatible with 2.0.5, but such leaves me wondering if that's truly the case.

Just some very subtle input from a new kid on the block, who's trying to cut some corners ;) , who really does appreciate the hard work that myriad of open-source developers contribute to the furthering of ::::cough:::: Al Gore's Internet.

QuoteI have tea, I have a cheese sandwich, I'm unstoppable  :D

I have a beer, but that's only because beer comes in a defined quantity. Maybe I should switch to tea. ;)

QuotePersonally, I get confused with github so I can't comment on the posts there, except when people have specifically linked me.

Github is very confusing, even to a seasoned developer, but maybe I'm doing it wrong. I do know there are latent issues with Git itself, and judging by the responses to my thread on it, I'm really not the only one. When you have a version control system where people are complaining that it 'messes up their repo', something is very wrong.

QuoteYeah,there are always problems with communication... Less with mudslinging, IMO.  One of the things I am trying to work on for the next three months is improving the communication so the next pm to take over can have a smoother transition and a better motivated team.

This is one of the major problems. The fact that no-one I spoke to seemed to be aware of the actual developmental state of 2.1 is very concerning. The mudslinging is far less of an issue than it used to be, but I'm very much in the 'twice bitten, thrice very shy' camp right now.

As far as beyond-2.1 is concerned, I've laid down what I'd do. The next steps are: 1) Is this what, generally, people would like to see SMF become? 2) Assuming it is, who wants to step up to do it? I know I could step up but I'm very worried about the situation I'd be stepping in to and the people I'd be working with, for reasons that I'd hope some could understand only too well.

---

QuoteThanks for starting this topic--as a very wet-behind-the-ears newbie, it's answered a lot of the questions I've had these past few days since joining the forum and installing 2.0.5 in my own little realm.

If you have questions, ask them. The odds are that someone here knows the answers.

QuoteIs it safe to assume it was tested to at least some degree using that version?

Yes and no. When a mod is first released, it is tested by the Customization Team, on the version(s) the mod author lists, and that is known to work. Subsequent updates are not reviewed, though.

What is certain is that there is a decent range of compatibility for most mods; most mods that work on 1.1.0 will work on 1.1.18 without any changes. For 2.0, almost any mod from 2.0 RC3 upwards will work on 2.0.5. Sometimes they need a little encouragement, as per How can I install a mod that doesn't work in my SMF version? (http://wiki.simplemachines.org/smf/How_can_install_a_mod_that_doesn%27t_work_in_my_SMF_version)

If in doubt, run a test site and try it. Mods are essentially just a list of find/replace codes. Sometimes the find/replace codes will trip up over each other.

A rating system was previously in use, and was abandoned due to inappropriate use, e.g. 'mod does not install 1/5' when there's nothing wrong with the mod at all, just that it clashed with something else already in place.

That said, mod development is not entirely something the core SMF developers should necessarily be thinking about, at least not for 2.1 (compatibility isn't bad actually, much better than I expected), but for 3.0 I'm a strong advocate of breaking all compatibility and building something more reliable and flexible that doesn't have the same historical issues; having something that generally allows mods to co-exist and be mostly version independent seems like a great way to go forward to me, and it is in that mindset I suggest the things I suggest for future development.

I should add, for those watching from the sidelines, the concept of a much more rugged plugin manager, along with a support system to handle it, is nothing new, and certainly not new to me. I have built such a system, and oversaw some of the support systems being built, on an SMF derivative and I know just how well it actually works in practice - much better than you might expect. But there is a very legitimate question about how much flexibility such a system provides and I know a number of people are very concerned about mods being given less flexibility; I'd personally rather have a system with better reliability and let flexibility be the price paid.

Big version numbers are the time to do backwards-incompatible changes, and I'd suggest 3.0 is the time to do it. There are plenty of backwards incompatible changes in 2.0 vs 1.1 and the knowledge base around SMF has grown - along with PHP's capabilities - to sufficiently enable a much stronger and more efficient methodology than what we have. There are also very legitimate security concerns that are raised with the current methodology, not to mention very large support requirements (between mod conflicts/installation errors, and permissions issues) and I know that can be avoided - but the price is flexibility.

---

Quote from: mashby on September 22, 2013, 10:18:39 PM

QuoteI have tea, I have a cheese sandwich, I'm unstoppable  :D

I have a beer, but that's only because beer comes in a defined quantity. Maybe I should switch to tea. ;)

Well, if you want to get picky, I have a mug of tea, I have a cheese sandwich and I'm unstoppable :P

Quote from: Arantor on September 22, 2013, 10:35:40 PM

QuoteA rating system was previously in use, and was abandoned due to inappropriate use, e.g. 'mod does not install 1/5' when there's nothing wrong with the mod at all, just that it clashed with something else already in place.

I'll buy that. I've been doing Wordpress sites for years for clients who refuse to ask the question before clicking Update. That said, again, lots of good info here. That's essentially coming from one segment of those sidelines you implied.

Oh sure, the entire ecosystem of third party developers absolutely revolves around the decisions made by the core developers - and everything flows from that. Support systems for third party developments (like the mod site) are really a separate concern.

Most of the issues, as I see them, that are currently present are present because of the way SMF itself handles add-ons (which includes themes). I believe a complete upheaval of the add-on systems will allow for smoother development of 3PD and more importantly ensure reliability and stability for users. This to me is more of a goal than any amount of flexibility; WP has flexibility but it causes so much trouble.


EDIT: I should have also said that I'd drop XHTML and use HTML5 for the doctype, which would allow for all kinds of subtle goodness.

I noticed mention of a new, separate theme for smartphone users, in the roadmap above. With respect to moving forward into 3.x and beyond, has there been any discussion about the possibility of integrating what's needed for smaller screens into the default theme instead of creating a separate theme for (e.g.) smartphones? Only asking because of how other platforms deal with smaller screens, and I'm especially interested in what might need to be done as far as image resizing is concerned (I know what's done elsewhere which, depending on your POV, can have its caveats).

Nope, there has not been any discussion of it as far as I know; most of the effort that has gone into it (which for SMF itself is not that much), was on a separate dedicated theme using jQuery Mobile.

There is so much more than just CSS juggling - in a mobile environment you potentially want to be doing more than just hiding elements, because if possible you want to avoid sending them to the user in the first place - lower bandwidth use for mobile is definitely an improvement.

Mind you, SMF ships with 3 oldschool mobile systems built in which are *extremely* low bandwidth.

I must say I got a good chuckle out of this thread ....

QuoteSome people, it seems, are curious to know what I would make of SMF were I given the keys to the kingdom,

Translation: You need to get some sunblock on your nether regions, your going to get a nasty burn with all that sunshine :D  Not that there is anything wrong with some warm sunshine in the nether regions,  I must say it feels delicious.

QuoteInteresting, then, that several people I've spoken to lately - including BOD members, didn't even know there WAS a roadmap of any kind. (Which is why they were talking to me in the hopes of trying to get me on board as a dev...)

Ooopsie ... yes realizing there was a roadmap/goals thread would actually mean people would have to be involved in a positive sense, moving things forward, helping, supporting, however all of that is a less creative outlet :D ... Do note that those goals were generated from other very long threads where *gasp* the team was asked what they would like to see ... and then those long threads were culled down to what was requested and how often etc etc ... it was not a list pulled completely out of thin air.  Then posted for *gasp* feedback. 

QuoteI'd start 3.0 development on top of 2.1 while 2.1 is going through late beta/RC stages and use 2.1's build as basis.

Do note those 2.1 goals were developed when smCore (3.0 if you like) was alive and had a timeline, team, repo, etc  So yup that was (eventually) the plan arrived at, just with a bumpy road to get there.

QuoteWait, so a full year ago it was basically ready to go?

Indeed, but at that point most folks working on it had moved on for various reasons so it kind of wallowed around.  Also smCore died around that time so the future roadmap needed to be re-invented.

QuoteActually 6 months after that post everything was already ready (well, a new theme WIP came in because "SMF cannot be released without a new theme").
I tried to push a release twice, but my conditions (like have it live here) for it were never met, so now it's up to Oldiesmann. He mentioned it twice recently, so I suppose he wants to have a release.

We even got through most if not all of the cut line items .. several items/goals we specifically asked for help in order to get others involved, in the end one customizer came forward to lend a hand.   I even remember there were a couple of drama threads about WTF are we doing with 2.1, no one tells us :'(  cuz the developers all live in an tower and are evil (thats the nice version  O:)) ... then things are pointed to the thread of goals and help lol.  But thats just standard stuff that tends to go on in projects, you know all  the fun in dysfunctional distractions ...

Anyway yup, it was to a lets get a beta out mode a long time ago, meaning the bulk of the goal work had been put in place (not saying 100% complete nor bug free, just at a stage point).  There were also some good contributions early on that were included outside of said goals.

Quoteand the kool-aid is tasty

LOL .. don't worry kids, that really *is* lemon/lime kool-aid

Quotelots of items in the first post

Those goals are pretty much what you will find, in one form or another, in several of the forks but you know that ...  I would guess the forks are not necessary SMF ideals centric, not that I'm 100% certain what that means to the end user.  Its also rumored that another fork is on the horizon as well, but you know that too  :D

QuoteGithub is very confusing, even to a seasoned developer, but maybe I'm doing it wrong.

Your crazy ... GitHub rocks ... Damn now I need some sunshine :P

Hmm, I'm not entirely sure what point you're trying to make up there :P

And yeah, in a lot of ways this seems like rumination on the state of play, and how far some of the SMF forks have already gone in terms of implementing some or all of the things I'd love to see in SMF core. I also forgot proper timezone support. It's not enormous a job but it's enough hassle that you can't just do it in an afternoon, at least not properly.

Github doesn't rock - but here's the thing. Several people who do like Github - and Git by extension - have complained about local repos being damaged. This doesn't sound like a good system to me. The other thing as mentioned is that I have a much more iterative style and the whole fork/branch thing doesn't actually work so well for how I build stuff.

I can't say Github rocks either, though it does work for the purposes we're currently using it for. It can be complicated to use, especially for the inexperienced, and it's usually because of such folks things get damaged.  I've seen chunks of a repo lost, usually because of people who have access to it. For instance, git's Windows client can be especially quirky to use if things aren't set up correctly (or if the client isn't used properly), and for whatever reasons there are those who continue to insist on using such tools even though there are more reliable ways to accomplish things like repo updates, pushes, etc. Fortunately, we've been a small group during the projects I've been working on these past few years, and when it's choked on something, we've been able to repair the damage quickly.

I have bricked a repo about a dozen times. And Github certainly does not rock. Its developers keep changing it for the worse. I liked it best in early 2012. Now it's too social...

Turning into Git-Book...

And this is why I much prefer SVN. It isn't as shiny and flashy but it works reliably and just great for my needs ;)

OK, so I think this topic has served its initial purpose, which is to establish what I'd do were I in charge of SMF development for 3.0. And, pleasantly, the take I have on things seems to be consistent with what everyone else seems to believe 3.0 should be.

So, the question then is 'what happens next?'

We've seen what the state of play for 2.1 is, and I'm a bit hesitant to jump in with that; 2.1 is two years in and I wouldn't want to significantly disrupt things. I'd like personally to see 2.1 emerge in its present form sooner rather than later and just get it out.

But that does raise the question of 2.2 or 3.0 and who's going to do what. I could, legitimately, just run off and do my own thing; this is not unheard of. But I don't believe that's best for either me or this project.

And sure, this shouldn't be taken as a definitive 'SMF 3.0 must be these things', nor a definitive 'only these things' list, but as a set of things I think should be in 3.0 or shortly afterwards. I have the skills to implement most of these myself, it's only things like the responsive theme I couldn't just do myself.


So, this really raises the question of how everyone (and I strongly invite team members, especially Devs and Customizers in this; they're the ones primarily working with code) wants SMF 3.0 to occur. I take the view that now is the perfect time to start implementing - 2.1's patches can be rolled into 3.0 as they occur, where relevant, but I'm aware that some people might want to see 2.1 further along than it currently is (to which I take the view that this is unnecessary; a major point release necessarily means major changes and thus only relevant patches need including). You may of course disagree; please do let me know if this is the case.

I'm having this debate in public because I feel the future of the software is important and it affects many people - and I believe there should be openness and honesty about that. I believe SMF's future is uncertain as it stands and I want to get people involved with its future to remove that uncertainty and put SMF back where it belongs. I've heard - and added my own input - about what I believe the next iteration of the SMF we all know and love should contain.

Now I'm asking how we get there. I could just go away and build it, and have my own little fiefdom where I'm the little king and call the shots all the shots and serve no-one but myself. It's extremely practical but a little unrewarding at times because you end up having to do everything yourself rather than working with others to share the load a little better.

I'm willing to get involved to help make 3.0. I'm even willing to step up and lead that endeavour, but I don't want to undermine anything in the 2.1 line, and while I would contribute bug fixes and such to that, I don't see my being heavily involved in 2.1. I don't want to do another fork, I've done that and while it is rewarding in some respects, it's an enormous mountain in others. It's not something I really want to entertain at this point in my developmental career, so to speak.

From my perspective I don't like Git, and to be honest I don't really like the idea of committing substantial changes with it either, so I'm positing the suggestion of building it on an SVN repo myself for the big stuff and committing it to Github down the line when I've done the really big stuff and then let everyone have a crack at it for improving and polishing. I'm aware this sounds arrogant; it's not meant to be. It's an awareness of myself, I work best when I'm able to iterate over and over before sending a commit off and I don't tend to do branches and piecemeal units like Git promotes. So in a private repo I'd be able to make bigger changes and then iterate on them quickly as issues arise before submitting something with the big stuff done, that I see as important, before opening it up to everyone. I am, as will be known, very protective of my work - I put a lot of myself into it.

So, I guess what I'm asking is, is this an acceptable situation for me to dive in and start working or do we need to find some other compromise(s) (or developer(s)) to get this stuff moving? The stuff outlined in this topic is really out of scope for 2.1 and should not be introduced in it; for all purposes, 2.1 is feature locked and that no changes other than bug fixes will occur. But we need to get this stuff moving now; even with the best will in the world, we're still talking a year away to make the changes as outlined, possibly more, and that's from right now without any real feature creep or suchlike, or changes when truly great ideas get suggested.

How do people feel about all this? I am very wary of treading on anyone's toes, because I really don't want to undermine the work that has gone on thus far, but I'm just very concerned that the road doesn't seem to be going anywhere from 'here' (it's a road to 2.1 and nothing at all beyond it) and it needs to start looking forward - and I'm willing to start off and head up that particular journey if others are willing to come with me because I can't (nor would I try again to) do it alone.

I'd note, there was a time when SMF 3.0 / smCore and SMF 2.1 were developed in tandem by two separate groups. I don't actually see this as being any different on a practical level. The changes I'd be inclined to introduce in 3.0 would be substantial at the code level, meaning they would quickly become two separate code bases, tied together by all the things we know and love SMF for: elegance, effectiveness, power and freedom. That's what I'm offering with this. And you know we can do it, if you'll join me in the effort.

How about we get this party started?

I'm good with that -- and, hey, for the next 3 months, I wear the red badge (which just demonstrates that I was stupid enough to let them vote me back into a leadership position)...  GDitall....  (how'd I get sucked back into this, myself?)


Anyway...   I like the idea. Some folks will squawk about SVN vs GitHub, but if you have some good way to accept submissions into SVN and roll it into GitHub eventually, I can't see any major issue.

If you are serious, I am even willing to give you a badge (gods help us all) and I don't see many (if any) of the current team disagreeing.
As the current dev team, Oldiesmann and emanuele would be the ones I'd have to hear from for sure - if they could work with you.

and yes... SMF3 was always intended to be radically different - code-wise - from the 1.1 and 2.0 streams.

I'd like to see Arantor in the team, for the 3.0 project. :)

Sounds cool :)

Quote5. I'd reorganise most of the current code into classes. I realise that going OOP is a big hurdle for modifications but for the core code it needn't be the headache that it sounds like it should be. Having the code organised by function, and more importantly organised in such a way that an autoloader will help you out is a big thing. Instead of loading a ton of code every page in case you might need it, load only what you need. You could save thousands of lines of code per page without any trouble doing that.

I do love when people talk about this :) One can hope it's not far off!

I think this is a great Idea, let's get something going in a positive way.

As a newbie here who both understands what you guys have gone and are going through, and the nature of what I think most of you want to achieve, I'm glad to see this also. I say that because I conducted a fairly exhaustive review of what's out there with respect to forum platforms (free and premium), and found smf to suit my needs best out of the box.


Please keep up the great work.

iamjanco,

I'm sure I can speak for all the team on this:

Thank you for the kind words. :)

Good luck Arantor, you need it.
But maybe now the team is desperate enough to accept that 2.x is dead and let the devs work on what they wanted is the way to go. :P

OK, to answer some of the concerns raised.

1. Yes, I'm serious. In the time since I stepped out of Wedge, I started off another fork and realised that while my ideas are grand for it, they're not achievable by myself using SMF 2.1 as a framework. Putting my energy into SMF itself is more worthwhile. And yes, I have great trepidations about contributing - but I'm willing to put that aside for the successful outcome of this project.

2. As I said, I'm thinking that 3.0 would run parallel, not on the end of, 2.1. They would quickly become two code bases that would be very different, and I'm essentially thinking there would be little overlap for the first few months while SMF 2.1 gets polished off and SMF 3.0 takes form, and if there's little to no overlap, there's less direct interaction. But that's just how I see it. This is why I'm interested in what everyone has to say.

3. I'm aware that people dislike my temper and public attitude; naturally under a team badge this would get toned down, additionally I'd be prioritising my time on the code not the public forum ;)


@ziycon: Realistically we're talking about a restructure of the code over about a year.

@emanuele: Interesting comment, and I know I've been involved in that little debate before (and it is, of course, mildly relevant even to here, but careful observers will understand why I'm less bothered by that right now ;)) I take it then that you're not opposed to my insane plans above? :P

so, just one thing in defense of 2.x and the "plans"

When SMCore was proposed, we looked and said - that is a greta idea, but it's at least 3 years out, more likely 5
As an experienced PM with knowledge of marketing and moving products to market, it was clear to me (and I tried to make it understood to the others) that another 5 years before a release would be unacceptable and I pushed for the parallel (but ultimately diverging) development tracks with "quick" releases using small updates and low-hanging fruit in 2.1, 2.2 etc . and the larger re-write track in 3.0 for the long term. Spuds and emanuele (and then Suki) stepped up to work on the 2.x track, discussing with the rest of the team what "features" could be considered for the .x releases (and I appreciate both the stepping up and the request for input!)

Now, of course, we're 2 years in and still don't have a full 2.1 release (it was intended to be a much faster release cycle since MOST of the updates were going to be tweaks and twitches, with a few more major items (like the revised WYSIWYG replacement). Unfortunately, the best laid plans of mice and men...

I don't think that 2.x is "dead". I'd love to see someone take on some additional point releases (after all, several folks have pointed out non-critical bugs or desired tweaks in 2.0 and 2.1 - come on folks - if you want to see it, BRING IT! The code is sitting there in GitHub.)
At the same time, I agree that, at this point, the majority of the Dev and other team focus should be on getting 3.0 under way along with the revised customization site.

Just stop the work on 2.1, why have any debate at all?

1) its late
2) no one is working on it
3) no one wants it, (including the now new smf lead developer) plus its scope and position were positioned for a release a year ago when there was an SMCore as the follow on, where it made some sense.
4) fewer will even use it in beta or rc's or ga if those fall on top of some 3.0 milestones which you said a year to something?  No one wants to thrash their forum around like that.

QuoteGood luck Arantor, you need it.
But maybe now the team is desperate enough to accept that 2.x is dead and let the devs work on what they wanted is the way to go. :P

Clearly part of the dev's evil plan all along  :P

I have never said 2.x is dead. That's the point of running a parallel track is so that 2.1 - and indeed a 2.2 etc if desired - can be implemented without affecting 3.0, and the improvements built in 2.1 (and 2.2 etc if desired) can be implemented in 3.0. If what I'm proposing occurs, the ability to reuse code between 2.x and 3.0 is severely limited at best anyway.

@Spuds: I personally disagree on the 'kill 2.1' line. Sure it's late, but that doesn't mean stillborn. It just means late, and it is a viable upgrade with new facility that 2.0 doesn't have.

I believe a year to a public release from right now is feasible, taking 2.1 and making the changes I propose, barring any unforeseen improvements/changes along the way. Yes, that would realistically tank 2.1 in itself, but the practical reality is that a year to public release doesn't mean a year to final release, it means a year to a public beta - so we're still talking probably 2 years to final/stable release, being all told. We all know what can happen in the polish phase when everything is examined and pulled apart and this can easily take longer than the original build takes.

just to be clear - my denial that 2.1 is dead was directed to emanuele's comment. :)   

I like your ideas Arantor and they are in line with my own expectations at this point. :)

No worries, just my thoughts.  Not saying it would be the popular choice with everyone, but perhaps the most effective long term one given the conditions / constraints of the situation ... history has a funny way of repeating, just like nature.

After reading the whole topic, this two things caught my attention:

- The customization site been revamped.

This has been on my radar since I was given the lead role and it will keep hunting me forever. I don't know whats the current state nor I really care that much about it to be honest. When I started to visit this site again I was hoping to see some news about it and be able to help and if I didn't see any then I will personally offer my self to help out, I suppose this is a good time to properly build such an offer.

- SMF 3.0 development.

Yes, I can start a futile fork that will lead me exactly no-where or I can help out the very own project that I always care about, reading this topic made me realize some things (I've been thinking about it for a while anyway), for instance, if Arantor is willing to step in, why can I? certainly the issues I had in the past pales in comparison with his :P  so yes, if anyone doesn't have anything to say about it, I'm offer my help too.

I'm a newby, know nothing about writing code ...well maybe some very fundamental bigger picture things from when "they" made me learn fortran, cobol and basic way back when...so I'm not qualified to even look at any corner of this kingdom :)

But I have been in business for many years, (yeah, I'm advancing into geezerhood) and served on my share of boards of directors.

Let me start by saying that "missing deadlines" is the norm for any volunteer driven organization, it's simply the nature of the beast. People are involved in their own lives and living, and what they do in their spare time or less is a pure labour of love...entirely driven by "character", and personal motivations.

It does cause some friction, as some get frustrated by the lack of progress, but nothing that well adjusted adults cannot get past.

So as a user and admirer of this product and this community, I just want to (and man I hoped this does not come across as condescending) congratulate all those driving this bus, and to Arantor, for how this thread developed into a constructive ....what appears to be....decision.

As a business person, let me add I think that beginning 3.0 while moving to some end point on 2.X makes a lot of sense. I presume 1.1.18 will also see some more minor tweaking should something be deemed necessary. Like K@, I'm a fan. It is stable, works well, and I know it. I operate a place on 2.05 as well, and though it takes a little getting used to, works just as well IMO and I suspect that as I learn it more, I will begin to appreciate it as much.

I know very little of what goes on under the hood...as they say, I know as much about coding as a cow knows of climbing trees (well it's a translated Dutch expression :) ), but I do know what GITHUB does. What I have heard ABOUT it is more negative than positive, and that does not only come from here.

So once again relying on business instincts, I have to think the problems folks have are real, and that an alternative deserves a good look. The logical time to adopt it would be starting with the development of 3.0, so that should be a decision made sooner than later.

I hope I've added a little business perspective from an objective user. I cannot really contribute any other way.

Except to also add my thank you's to everyone who makes this software and supports its user base. I hope you know you are appreciated very much.

To demonstrate this, from here I am going straight to the contribute area  to make my donation.

 

Quote from: Arantor on September 22, 2013, 02:03:37 PMI'd start 3.0 development on top of 2.1 while 2.1 is going through late beta/RC stages and use 2.1's build as basis.

I hope this is joke. Semantic Versioning (http://semver.org/) says that if you've major changes to release, you can +1 MAJOR part. So SMF3.0 should hopping era, should offer radical changes. Just as smCore's promises.

You know that Software Technologies are rapidly developing and changing. PHP's approach to OOP improved since the first releases of SMF. And OOP is not just converting procedural codes into classes. We should seperate this. Interfaces and Design Patterns must be used and tests should be written.

Novadays RESTful HTTP requests and API based single-page apps are using. These should be considered. SMF could use them. SMF3.0 must have module system and event mechanism, like in smCore.

In a nutshell, smCore project shouldn't die! If it is should be revived. Even SMF2.0, built based on SMF1.1, SMF3.0 shouldn't.

SMCore is dead. Sorry.

If you feel up to reviving it, please contact the Board of Directors for Simple Machines.

In the mean time, the rest of us will move on.
I agree completely with what Arantor has outlined. (and you need to read a little closer, I think, since some of your "must not" and "must" statements directly contradict or actually match what Arantor did outline.)

QuoteI hope this is joke. Semantic Versioning says that if you've major changes to release, you can +1 MAJOR part. So SMF3.0 should hopping era, should offer radical changes. Just as smCore's promises.

It's not a joke, why would it be a joke? The changes I'm promoting are massive changes.

Breaking entire compatibility with all mods, rewriting everything to use classes... yes this is a major change. But I'm not starting from scratch, I'm doing it on top of known working code. Just because it's written in one style that I don't believe is correct for current web applications doesn't mean I should throw it all out and start over (and have to battle test it all over again).

QuoteAnd OOP is not just converting procedural codes into classes. We should seperate this. Interfaces and Design Patterns must be used and tests should be written.

Hello, Zend certified engineer here. I do understand what's involved in this, probably better than most. But still the point stands: it doesn't suddenly mean that all the code is fundamentally wrong.

Also note that trying to fit a solution into one or more design patterns isn't necessarily for the best. Sometimes patterns fit a problem, sometimes problems fit a pattern. But trying to bang the drum that patterns must be used is wrong.

It also depends to a point whether your goal is correctness or performance; in a performance environment you're not going to use interfaces for most things, you're just not. (It's all code that has to be loaded, parsed, executed. For a lot of things this just doesn't actually warrant it.)

QuoteNovadays RESTful HTTP requests and API based single-page apps are using. These should be considered. SMF could use them. SMF3.0 must have module system and event mechanism, like in smCore.

RESTful suits some things. It does not entirely suit SMF.

QuoteIn a nutshell, smCore project shouldn't die! If it is should be revived. Even SMF2.0, built based on SMF1.1, SMF3.0 shouldn't.

Shouldn't die? It already did. Check Github for the time of the last commits - heck, even the smcore.org website has been defunct for months.


The problem with writing from scratch is that everything has to be rebuilt. This means it all has to be designed, tested, etc. and then debugged. As opposed to using code that is already mostly bug free.

If you don't agree, fine. Except there's one crucial difference. I'm the one offering to stand up and actually DO SOMETHING. You don't like it, fine, go do what you believe is right, come back to me in a couple of years when you've caught up to where SMF 1.1 was a decade beforehand (that's the other problem with building from scratch, it takes you at least a year to get to where you were before you started). You can stand and say how you think it should be done but unless you're actually going to DO it, none of what you think matters to anyone except you. Blunt, sure. Rude? Possibly. But doesn't change the fact it's true.

and hence my initial estimate that SMCore would take at least 5 years to come to fruition, even when we had several folks working on it regularly.

I was more generous, I was saying 3 years ;)

Building a core, then a forum, from scratch - which is what smCore was - is a truly massive amount of work. Far better to take what is already established and working and refine it.

See, here's the thing. Most of the logic won't actually suddenly change. It'll be rearranged, tweaked, sure but it won't significantly be changed unless it needs to be. So you just end up reinventing the wheel for the sake of doing so. There's no need for a clean room implementation, no matter how pure it might be perceived to be.

yup.  As long as we had someone working on the 2.x series, the rest of us were willing to accept that Norv and Fustrate wanted to try to build the smCore concept design...  and not push them...  but yes, it is a MASSIVE undertaking that I am not sure they actually understood the half of when they started. :)

Fustrate may not have, but I'm sure Norv did. One only has to look at ElkArte to understand this. And note, ElkArte is being remodelled around the same concepts I talk about with OOP, it reorganises to controllers and models (and while I don't entirely agree with the hardline MVC stuff, there is a certain logic to it) and that's built on top of SMF 2.1 as well.

The argument about throwing out the old entirely is nonsense.

I should also add, July 2010, Nao and I were talking about doing our own thing and he's the one who persuaded me not to build from scratch but invest in refining what already works and is pretty damn good, and three years later I see exactly why he was right about it. Seriously, back then I was going to do my own from-scratch forum system - DragonBB it was to be called - and I didn't appreciate the amount of stuff we all take for granted with SMF's existing code.

Quote from: Suki on September 25, 2013, 01:34:21 PM
- The customization site been revamped.

Oh don't worry, the work is still all there, nicely described. :P

Quote from: Suki on September 25, 2013, 01:34:21 PM
- SMF 3.0 development.

Good luck to you too. :P

Given the luck I'm having today, I am not seeing this as a problem :P

Quoteso yes, if anyone doesn't have anything to say about it, I'm offer my help too.

Cool! I'm slightly surprised and very happy to see that, Suki :)

I meant to reply to this earlier and somehow missed it :(

Quote from: Suki on September 25, 2013, 01:34:21 PM
- SMF 3.0 development.

Yes, I can start a futile fork that will lead me exactly no-where or I can help out the very own project that I always care about, reading this topic made me realize some things (I've been thinking about it for a while anyway), for instance, if Arantor is willing to step in, why can I? certainly the issues I had in the past pales in comparison with his :P  so yes, if anyone doesn't have anything to say about it, I'm offer my help too.

Yeah, the fork thing is great if you have the drive, momentum and direction to make it work. I lost a lot of all of those with Wedge for various reasons.

You and I haven't actually worked directly together, and I know we've had our differences in the past, sure, but I think we can make it work to collaborate on something like this :)

I won't deny I was surprised to see this, but I'm very pleased of the positive vibe being generated here :)

And the answer will always be the same: when it's done and ready to go and not a moment sooner. Yes, I outlined what I perceive viable dates to be should this go ahead (it is, after all, still in discussion) but they could be changed if major new things come along.

I knew what you meant ;) Just wanted to get in before we did get people asking that sort of nonsense. You know what it's like around here... *shifty eyes*

If this occurs as outlined, you'll see regular threads about how it's going, maybe even screenshots of new features. I did always enjoy doing that elsewhere.

Quote from: nightbre on September 25, 2013, 07:34:00 PM
I was thinking maybe a simple progress graph to stop this happening and also save Arantor putting up with my crappy humour! ;)

Read it all... A little excited to read this thread.. Also the quoted above would be a good idea I think. Just to save the stress level of it all. (posted updates like on wedge were nice to read as well). I can't code php worth a darn but if you need any help with other stuff lemme know. I can always try.. ;D

well, grafitus is right and his idea is cool, smcore and smf3.0 top of smcore but Arantor is right and more than grafitus, because none of us here can guarantee that we can work on SMF and/or smCore for 5 years (or whatever it takes).

and whom wants to know when the SMF 3.0 released please send mail to [email protected] ([email protected]) (which is redirect to Arantor's personal inbox j/k)

Quote from: Suki on September 25, 2013, 01:34:21 PM
so yes, if anyone doesn't have anything to say about it, I'm offer my help too.

Awesome :)

/me sends mail  I WANTS IT NAO DAMMIT >:D

Also, bug report: > is eaten when /me is used.

Where was the > exactly?

Thanks everyone for their kind replies. There are much appreciate :)

Quote from: Arantor on September 26, 2013, 09:26:23 AM
Where was the > exactly?

On that smiley.

But I see the smiley and it works fine for me, both posted from quick reply and full reply...

/me does evil testing >:D

M'kay, must just be me then.

/me thinks live simply forgot to add a space before the smiley. :P

yeah yeah yeah, whatever. It was 3 in the morning. Big deal.

What an interesting topic. Shows a side of Pete I knew would eventually resurface.
I'm glad I was pointed out to it.

::)

We are all waiting in anticipation now, Nao. :D Will SMF 2.1/2 be..a Wedge derivative or something else? In any case, forgive and forget and all that I guess.

Well things just got interesting haha.. Either way I am glad to see things moving forward again :).

SMF 2.1 will likely not see any substantial changes other than bug fixes - as we've seen in this topic, all the stuff that 2.1 was supposed to be, it is. So right now 2.1 is all about the bug fixes.

The future of SMF... it would be remiss of me as a developer to just ignore everything I learned while working on Wedge, however I don't see 3.0 being a Wedge *derivative* as such. Wedge got the benefit of everything I'd seen and learned up to that point, SMF 3.0 will benefit from everything I've learned up to *this* point.

And it's nice that you feel vindicated in your feelings.

I have to say I'm skeptical about the developments in this topic but I might as well be the only one feeling that way. In any case, I hope it turns out the best for SMF.

Quote from: onepiece on September 27, 2013, 06:56:59 AM
I have to say I'm skeptical about the developments in this topic but I might as well be the only one feeling that way. In any case, I hope it turns out the best for SMF.

May I ask why?

Quote from: Arantor on September 27, 2013, 06:43:33 AM
SMF 2.1 will likely not see any substantial changes other than bug fixes - as we've seen in this topic, all the stuff that 2.1 was supposed to be, it is. So right now 2.1 is all about the bug fixes.

The future of SMF... it would be remiss of me as a developer to just ignore everything I learned while working on Wedge, however I don't see 3.0 being a Wedge *derivative* as such. Wedge got the benefit of everything I'd seen and learned up to that point, SMF 3.0 will benefit from everything I've learned up to *this* point.

And it's nice that you feel vindicated in your feelings.

When I think bug fixing, I usually think public beta ;) ;). 

While I agree with just about everything you've said, I have a different approach for what you've said on #14

Quote from: Arantor on September 22, 2013, 02:03:37 PM
14. I'd drop the facility whereby each post has its own subject, I'd move that all to the topic itself. Saves a ton of space, makes a surprising number of things faster.

Basically, I think titles for posts are cluttering as well, as they almost always repeat the title of the topic with RE: prepended to it.  BUT what if this was thought out to be handled differently?  What if titles of posts were actually handled as tags instead?  The database wouldn't need that much changing to it, just, basically, the code in the source files and templates would need changing.  But, what if you could than select a tag (perhaps a section of the forum somewhere all tags can be displayed) and than output all posts that relate to these tags?  Possibly even selecting multiple tags.  If you've seen stackoverflow.com, you can get an idea of what I'm talking about with Tags and how they are used.  I'm sure this is nothing new to anyone.  And than this concept can even be utilized within the search function as well.  This could even be expanded on moreso, like perhaps the Administrator can select who is able to create new tags, and so forth.  And those without permission to create tags can only assign posts to a current tag that already exists.

Also, I would like to see a near future version of SMF use the HTML 5 DOCTYPE since we are entering a new age of web development and HTML 5 has been around for a few years already.  This will also help for mobile support as well.  And in the upcoming years, as HTML 5 matures even moreso, with 5.1 being recommended in 2016, it should prove more stable and robust.

Just my 2 cents on this.

QuoteThe database wouldn't need any real changing to it,

Yes it would. You really, really wouldn't do it that way, and you certainly wouldn't continue to store it uniquely every single post as a non indexed text string that cannot be efficiently used for *anything* else.

What you're talking about is topic data, not post data, the two are very, very different.

I'm very wary of adding a tag system to the core; it's only any use if it's used frequently and used consistently by most of the members. Almost all the forums I've seen doing this end up doing this either by fairly enthusiastic moderators or only a subset of users bother, making it less useful for everyone else.


However... if you want to write it up and submit it, please do feel free and we'll review it for inclusion, without any guarantees that it *will* be reviewed - but we're far more likely to consider something already written and tested rather than speculatively writing a new feature.

Tag system would need to be on a per post basis in order to be useful.  If it were on a per-topic basis, it wouldn't be very useful would it?  The problem with posts in topics is that many times you have posts within a topic that relate to many different things, not just that topic.  This is where tags would be helpful.

Other systems that do this do not agree with your assertion.

Seriously?  Tags are used in tons of platforms in exactly the same way (if not very similar) as I am saying here. Wordpress has a module for them here:  http://en.support.wordpress.com/posts/tags/  Drupal also uses a tagging system.

In facebook, tags can be used on Photos to identify the people in them and than you can than sort all photos by tag(s).

And many other platforms use them for specifics, which is what I am talking about specifics.

Like I said, this is nothing new.

but tags for WP are not done on comments - only on posts and pages (aka threads)

which is what Arantor said....

Who said anything about comments?  I am referring to posts/threads.

The tags you refer to 1) are generally per topic, not per post, and 2) not in a general environment where user created content is the norm.

WordPress is largely irrelevant in this debate, as it happens, because a typical WordPress installation does not allow any and all members to create topics. WordPress is primarily one/few authors and many commentators; it is natural that the one/few authors will create a taxonomic structure that fits the site and adhere to it during content creation. The same is not true when you expect all forum users to adhere to such a structure.

As far as StackOverflow goes, the tags are very sparingly used; the number of questions I've seen just tagged jQuery or javascript doesn't really evidence your support of them being particularly useful for taxonomy. But again there they are per topic not per post.

Try looking at the other forum systems that implemented this and how they are used. The majority of forums that even have them available out of the box do not use them.

How is Facebook relevant? We're not a social network, nor do we have a lot of images, but even then, the tags are only useful when they're from a set pool (i.e. your friends list) and all too often I've been tagged in totally irrelevant pictures, or mis-tagged or not tagged when I should have been. As I said, the tag system is only truly relevant when *everyone* who can add content will tag and use the same structure and taxonomy for doing so. The *vast* majority of situations do NOT follow this.


However, if you're convinced it's appropriate, write it and submit to Github and we'll review it. Nothing is more encouraging than someone who has not only suggested an idea but put some work into implementing it and trying it out for real; after all, it's very easy to have ideas, but very hard to implement and refine them from real experience.

Yeah, I see what you mean.  Perhaps Tag is not the correct term for what I'm talking about.  I'm looking for a way to organize all posts within a forum with groups of 1 or 2 more words to make it easier for searching, instead of looking for those words in either the title or the body of the post (since they are not exactly helpful many times).  This group of words would be defined by the person who created the post, thus making it more definitive to it's pupose.

In any case, it's whatever.  I've been spending more time designing these days rather than coding.

Cheers :)

P.S. ->  On the other note that I've mentioned, I haven't seen anything stating that SMF will change it's doctype to HTML 5.  Is this something that will be introduced soon?

QuoteThis group of words would be defined by the person who created the post, thus making it more definitive to it's pupose.

Yes, I realise this. I believe I already stated what the problem with this was. It needs everyone to make the same tags for the same things and people just don't do that. Heck, enough people can't find the right *boards* to post in a surprising amount of the time, let alone per topic or per post meta data.

All this meta data is great but when you have each person inventing their own tags, it won't work. If you'll notice, on WordPress the admin(s) set the tags, on StackOverflow they have to be added through a community consensus decision - to try and get people to be consistent and even then it doesn't always work.

As far as HTML 5 is concerned, there was a pull request on Github that was incomplete for a conversion inside 2.1. It seems a little unlikely that we will overhaul Curve II (the 2.1 theme) to be able to make the change but it will be done for 3.0.

I reiterate: SMF 2.1 in its current form is in a public repository on Github. You are more than welcome to try it out and see things like that for yourself. And you are even more welcome to submit pull requests for us to look at for things that you feel should be included.

Quote from: Bloc on September 27, 2013, 02:10:20 AM
We are all waiting in anticipation now, Nao. :D Will SMF 2.1/2 be..a Wedge derivative or something else? In any case, forgive and forget and all that I guess.

There is so much to say.

I don't want to elaborate too much, because it's been a while since I've wanted to start a flame war, and I'm not going to start one now.

I'm just going to make it clear that I didn't realize there were two ways of reading through my post. I'm afraid I was on the ironic side. Back in 2010, rejoigning the dev team required a team vote; it was a big deal. Here, Pete says he wants in -- and the next day, he's in. So... Mixed feelings. As for Pete, he's been even more unstable and unpredictable than last year -- and at least then, he had a good reason to be so.
While he repeatedly maintained to several of his friends that the last thing he'd do is re-join the SMF team, now he's a developer. And now he's speaking with the proverbial 'we'.

That's a lot to take in, if you'll allow me... It's even a bit heart-breaking. I did work alongside him for 3 years.
Don't worry... It'll pass.

PS: Pete, I received your package this morning, thanks! Was I not the one supposed to send you a present? Welcome to the 30s, BTW!

Just to clarify, Nao 尚, there was a vote.

Yeah, I can see how it might've made you go (https://www.simplemachines.org/community/proxy.php?request=http%3A%2F%2Fwww.katzy.dsl.pipex.com%2FSmileys%2Fwtf.gif&hash=b72b52cf600a31cd9dfc290bf7a92b27160ee155)

But, life's kinda weird, like that, innit?

QuoteHere, Pete says he wants in -- and the next day, he's in.

And there was a team vote. I was as surprised by the result as anyone else (because of course I've seen the comments now)

QuoteWhile he repeatedly maintained to several of his friends that the last thing he'd do is re-join the SMF team

Things change, circumstances change. Like me finally being fed up of feeling like you weren't listening to me.

I wasn't happy about going back into the fold while certain things were the case, then things changed that made a lot of difference. Most of this occurred in private.

I said that in the event of forking Wedge, I'd end up going back to SMF because I don't possess the skills to do it all by myself? I initially didn't because I didn't like the way things were at that point but then they changed somewhat. Not to mention the fact that in the meantime I went off trying my own thing and realising that it was too big a job for me, even though I got 70-odd commits and a patch of quite a few thousand lines of code into it and that I don't have all the skills necessary to do it properly.

I realised that getting involved here was the best for me and in my view the best for this project, and it seems that, broadly, everyone else was interested in going in the same direction - and while there have been some bumps in communication (including some very vocal concerns on my part!), I feel like the team and I are generally communicating better than the team ever did in the past and for the most part it's on par with how we used to be. But a lot of that is about being prepared to accept that change is coming because I know only too well how people dislike change (myself included)

QuotePS: Pete, I received your package this morning, thanks! Was I not the one supposed to send you a present? Welcome to the 30s, BTW!

I hope it's useful to you, it taught me a great many things.

Just something to add here.  Something that I've seen Drupal make a huge mistake on...  Drupal is sort of stuck with jQuery 1.8, and doesn't fully function well even with jQuery 1.8, really it is stuck using jQuery 1.4 to jQuery 1.7 for full functionality of the system.  The reason is that it has built it's core around these jQuery versions, and now it will be forever stuck in the past because of this.  There will be too much work needed to switch over all Core Modules to support anything higher than jQuery 1.8.  Not to mention all of the contrib modules....

Let's not try to make the same mistake with SMF 2.1.

2.1 is shipping 1.7.1 right now only because no-one's been bothered to update it in ages, not that we're making huge use of it right now IIRC.

But what does going 1.9 or higher give us?

Quote from: Arantor Beeblebrox the First on January 01, 2014, 06:37:25 PM
2.1 is shipping 1.7.1 right now only because no-one's been bothered to update it in ages, not that we're making huge use of it right now IIRC.

But what does going 1.9 or higher give us?

Quite frankly a better, overall build of jQuery.  You read up on all of the changes here:  http://jquery.com/upgrade-guide/1.9/

Also, jQuery 1.9 redefines many of the jQuery functions, changes/removes many of these in earlier versions that have had them deprecated, and is a solid base/foundation to use for the future of jQuery.  Anything below version 1.9 will not have a future for any new features that get added in jQuery 2.x and beyond.

Building your script and general UI around JS is a bad idea so I don't see us doing that.

Although we chose jQuery, in reality most of the UI functionality still relies on custom js built for SMF, a complete change to whatever jquery version is highly unlikely. If anything, it should be done gradually, one feature at the time.

Well, most of the UI functionality still uses SMF's code originally for compatibility for modders and the like. And the amount of work required to rewrite it is not trivial either.

But because our usage is so slight right now, it should be possible to switch them safely.

"...a complete change to whatever jquery version is highly unlikely"

And I'm saying that in jQuery 1.9 such a change exists.  Perhaps I am not understanding what you are saying here...?

Quote from: Arantor Beeblebrox the First on January 01, 2014, 09:05:53 PM
Well, most of the UI functionality still uses SMF's code originally for compatibility for modders and the like. And the amount of work required to rewrite it is not trivial either.

But because our usage is so slight right now, it should be possible to switch them safely.

Awesome, that is good news!  Just don't want to see SMF go down the same path as some...

Cheers :)

It doesn't matter what jquery version we use, at this very own moment, everything vital to the functionality still uses SMF own code.

I really, really don't see what is the issue here to be honest. There are far more important issues to take care of.

Ok, well I do not follow the development of SMF 2.1 that closely TBH.  The issue is the future of whatever program you are building, which can become a very huge issue.  Ya know the 5 P's:  Proper Planning Prevents Poor Performance.

Our biggest use of jQuery in 2.1 right now comes from the editor. If I get a chance in the coming days I'll take a look at what would need to be done to upgrade to jQuery 1.9.

Quote from: Oldiesmann on January 02, 2014, 02:52:02 PM
Our biggest use of jQuery in 2.1 right now comes from the editor. If I get a chance in the coming days I'll take a look at what would need to be done to upgrade to jQuery 1.9.

Sam Clarke has already upgrade the SCeditor to jquery 1.9(a few versions up from what SMF is using I think), so it's a manner of upgrading the editor itself, which has some changes that I would consider time consuming? I haven't looked at the code myself, so I'm not sure. I know the way he orders is buttons has changed, from what he explained to me in an email awhile back.

I don't believe that you used an entire plugin (Superfish) for the menu to do something that can be done with less than 10 lines of jQuery.

Which is ironic seeing how Superfish is a jQuery plugin.

lol, there's a plugin for everything!