here is where we put all our ideas for the next generation. forget about 4.0, forget about vBulletin… we create a new engine.
one idea per post please, so we can track them all.
grab screenies of existing stuff if needed, add urls for examples of existing stuff on the web, this is useful to compare.
Views: 300
Style:
CSS engine, built with selective structure, CSS3 and using engines like MooTools, not YUI, because Mootools is using classes and ids instead of inserting javascript codes in templates.
with selective structure, you can have any UI, like jQuery, YUI, Mootools installed, and they are not competing within the site… actually, the vB structure make it impossible to add Mootools, because occlusive codes.
Editor:
Pluggable platform independent web based Javascript HTML WYSIWYG editor… so we can switch from TinyMCE to anyother, listed here:
Genii Software | WebEditors
So a complete selection of pluggable editors can be released, coders can use a more powerful editor for their need, and the BBcode parser become useless…
BBcode parser, will now be used for customized elements inside vBulletin instead of the TextEdition.
RSS and Feed for update:
Update, Install, everything can be done without any file on the site. we can have an installer that would force each client to be identified by their domain, so when the client install vBulletin, he receive a « install.php » file that have to be uploaded to his server where the engine will be located.
http://yoursite.com/install.php
… the script verify the compatibility and then start uploading the files from our main server to the new location, and do the proper installs and edit the php.ini when needed. this makes the usage of a backdoor verification completely useless, as each call of install.php would verify the domain where it is located.
Also, making this the right way would activate file safes and proper chmod for anything we need to be done. the install would be simple, clean and small, as the main goal is simply to grab the content of the repository and unzip it the right way… if the install fail, the client can still download/upload the files by hand.
same for each update of product… a cronjob do the very-check for each product once a day or something, like displaying a RSS feed showing what product was updated lately, and the client simply click « update » to make it so… like in WordPress.
as an addition, a « receipts » system like in Unix is good, making it simpler to check the version onsite and the one available… this can also be used by vBulletin core to compare the files to see if something was edited wrong.
MTF:
not only integration, but complete management of the engine have to be MTF. with a load of default types, and a new structure in the admincp so instead of a forum manager, we have a « section manager » that we start a new type and a sub-section manager with the proper depths…
As it’s a multi-levels engine, and a per-category engine, you do not have a unique album, you can create as much as you want, having a different style for each, different settings per style etc.
We need to avoid the post/threads field manager… it’s a bad idea after all, but we need something like this for the « Enhanced manager », so coders and designers can create new entries etc… for custom fields we need something smaller and simplier.
Forum Types:
Every Forum Type is class that extends a default class. The default class loads the data using a function from the forum type class. The forum type classes would also have functions for extra thread and forum fields that way custom more dynamic fields can be made.
Core Components:
Instead of having the FAQ and calendar come with vb they are different forum types that can easily be added if the admin wants therefor making it more lightweight and easier for the admin to choose what he wants on his forum
Core CMS:
Have every page be built on a widget/block system where the admin can add core widgets such as « Forum Display » and « Thread Display », to make it possible to have the admins News Forum’s Threads show up on the front page along with any other pages they choose. Pages like showthread, forum display, etc. would have widgets that can be removed that do that pages functionality
Payment System:
Tons of sites use some sort of points system or deal with purchasing (even for just subscriptions), Why not have a default points system? It can be turned off but it would allow users to purchase points to buy anything on the site such as a subscription.
Products Cart:
instead of purchasing subscriptions one by one, we use a Cart to enter everything we want to purchase, and we use the integrated Payment System, and only one currency is used.
Access to groups and albums permissions can be driven by products, instead of permissions per usergroups, so a member can purchase the access to album creation, instead of being member of a specific usergroup to have it.
Payment currency: we can even set per-user currency so the points/credits in the Payment System are normalized. so instead of paying per points, the clients always see the value of their purchases.
Navigation:
breadcrumb: history based, give access to important locations visited since new window opened.
Design Toolbox:
on the fly edit the design elements, like sidebar.left, sidebar.right, which are usually different in weight and content… why making them the same?…
Skeleton Based templates, instead of blocks and targets.
Less Permissions, More Access Levels:
permissions are actually cumbersome, to have access to feature X, you need at least X permissions, which is pointless.
a Moderator have to have « moderation » level, and a super-moderator have to have « higher level of moderation ».
so feature X have to be accessible for level X, not the opposite.
ex: userid is levelx in mtfid
right now, you can do it by applying a user the moderator level in forum x without giving him a usergroup, so why having a moderator usergroup?… duplicating functions only to be backward compatible is not good anymore.
Seperate Privileges and Roles:
right now, a usergroup can have a role, a privilege, or a permission, without seperating them. the usergroup manager is too heavy.
Serverside Optimization, Install:
what need to be cached, in what situation, and how the server will be able to deal with that?
so in the install/update, the install script will handle all these details by detections of the PHP/MySQL features.
Most admins know nothing of how their server is set, so how can they set their software properly, they need a webmaster or they break everything. An automated process to set everything properly is easy, like using GD or ImageMagick, can be detected automatically, and PHP already know the location of IM, so instead of inserting its path to make it work, the install set it properly.
Also, as it can be possible that the server is updated or changed, we need a switch in the admincp to verify the new settings, or cronbased.
AJAX/Feed based Alert Popup:
ajax or something else based, a popup can be set to alert the member of new messages, new pm, online friends etc… can be faster than the actual engine which is slow and html based.
a simple popup with your friends/contacts list, like for msn/aim, which alert you when you receive a new pm, or when your subscribed threads receive new posts.. this is easy and can have multiple addons — like alert on new album comments, visitors messages etc
No more Profile, welcome Personal Page:
the profile of all the forums we know are bloated with pointless features and usages.
with a personal page, each user activate/deactivate it at will, give access level *(guests, members, friends, nobody)
instead of having the blogs product, the personal page can become a blog, contain albums, etc. rarely a user will need each elements detached, so why not merge everything.
global pages for listing albums?… pointless, so it become a secondary feature instead of being the door to access the albums. same for the blogs.
Members lists?… click on a username only when that user have a personal page.
Forum URL Chooser
Not a big feature but the ability to have custom URLs for forums. For example a news forum could be http://mysite.com/news/
@Drew 22737 wrote:
We could use the WordPress Permalinks engine: Using Permalinks WordPress Codex
Each custom page is required to have a permalink and this is editable in the page editor.
Yeah that would work..
Statistics Viewer
Have a new admin cp page where advanced stats can be viewed about the forum. The stats would be a graph with a table it could show stats about users, posts, threads, etc. over any period of time the admin chooses.
hum, you remember me of something here!
Private Messaging => vbMail:
now, emails are everywhere, and the best engine to deal with personal communications are email engines. the private messaging is pointless, it does not bring anything new, is not flexible, and it does not permit to send external messages.
so we replace the whole PM system with a vbMail system, which permissions applied will let you send internally to the community, or externally also, with quota and queue.
Forget about stupid permissions to be able to use bbcode x or y. emails does not contain bbcodes, but can have a html editor, which logically would let the user have access to all these features which are filtered anyway.
try hotmail or yahoo or gmail etc, they do not restrict people from using signatures or html emails, the only restriction is the space used. stupid permissions are just making the engine bigger and the cache heavier.
and btw, this engine have to be a plugin, if you do not want it, just do not install it. you can even choose what system you want, as for all plugins, you can choose a PM system, vbMail, VoiceChat, etc
historical postcount:
it’s a known fact, people want to know when they posted this message and where it was in history. above the idea of a timeline for each user which can be found in the members page, you can also see it in the postbit…(member have 345 posts, this post is the 344th)… that count have to be based on the posting moment, not relative to moderation and posting deletion.
historical avatar:
avatars are already stored with their own versionid. instead of deleting them, the user will nowhave the choice to keep them stored, like we see in AIM, MSN etc. so we can choose any back.
also, this can be modified to fit posting history, as each avatar is tagged with dateline. so between avatar X and avatar Y, we have two datelines which can be associated with the posts made between these dates. members can activate historical avatars then and their old posts are associated with their old avatars they had when posting these posts.
a simple usecp panel to manage old avatars and upload new ones without applying them is good too.
Multi-Sites Manager for Webmasters:
the system is easy, webmasters simply have to enter their own panel to manage server-side features of each sites, and they are redirected to each site’s admin panel on the fly.
This is needed these days, as a lot of webmasters own or manage multiple forums for themselves or their clients. An interface to deal with each internal sites can be additionned to hyperlinks to external sites… frames are easy to deal with.
Moderation Log:
each thread, post, album etc have moderation events logged, but nobody have any idea where that information goes, even the admins most of the time.
So instead of hiding all that information, a button can be accessed the same way the post history is done, and we can add moderation notes when needed, so instead of always editing a post, you can put a sticky on a post, like « check this guy if he cause more trouble »… the note is stick to the post but also the member, so when browsing a member page, an admin can read the notes. usernotes can be switched to that.
Post/Thread history:
like here, which is a FirstClass posting log… since 1990:
[IMG]http://www.skola.gotland.se/__Help/Web%20Help/0C40DDDE-004C5174.25/152006_63352_3?src=.PNG[/IMG]
if they can do it, why not vB!
this log engine is applied to private messages, forum posting, articles, etc… and link to each reply etc
Multi-Sites Centralized Authentication:
keylogged, authentication between multiple sites can be done easily, and have to be integrated in the core, you simply have to enter each url details you want to plugin.
other authentications are to be plugins… these systems did not pay their due to be part of the engine, so why give them priority…
Multi HD/Server Structure:
having attachments stored in a different HD is actually cumbersome, and having a split or mirror server is really a problem due to the complexity of the script which not permit to have that. We need an absolute solution.
Global Widget Templates
Going with the CMS idea there needs to be a base template for all widgets that can be changed to change the look of the entire forum. This would make it possible for an admin to completely change the look of his forum with one template change.
Generic Shell Template
A generic shell template me already exist but it is almost never used. A new generic shell template needs to be used globally on every page to (again) allow the admin to completely change his/or her forum by changing one template, this would also help with layouts as you could just take a site layout you made put in the generic shell template and you have a new forum.
Search Power:
sphynx or anything, we need a complete core based engine for search indexing… i would suggest a custom engine based on the Google API/which is available when you search a little.
making the search engine a complete google on itself, the engine can seperate any MTF-type in the display, so you can see seperated the forum posts, articles, blogs etc. each result linked to their own keywords and preview, exactly like in google results, with relevence %.
MTF Types and Features:
we actually have « Answers » as a type, but would be better as a feature. like the karma or digg feature to rank a post/thread.
MTF Types have to be skeletons of structure, nothing more. Articles are different in structure than a forum, same for a links directory.
MTF features are options we activate per section, can be permission based, but we’re ahead of permissions here, activation of features in a website are now way above giving permission per function.
MTF features are mandatory fields, instead of thread/post fields. so we drop part of the MTF Fields manager, each field is linked to a function or more, and is built as a plugin instead of a simple field. each feature can be activated per section;
ex: Articles
features:
— rate firstpost
— digg replies
— thanks author
options:
— permit comments
— permit multi-pages of article
permission per usergroup:
— can comment
— can rate/digg/thank
..when options are activated, they act as global permission « ON »
@nexia 22762 wrote:
Going off this in the search results (just to clarify) would display like:
Aritcles
article results.
Answers
answer results
The types would be organized by most relevant
APIs Rather then features
Instead of having all forum types have the rate post feature (for example). The rate post functions would be a separate class that could be added in forum types classes, if the thread rating class isn’t called none of its data would be pulled. This same API idea could be used for attachments and post icons. Going a little further on this APIs could also be things like first post on all pages. Then in the forum types classes an array or an init function would say pull apis rate post and first post on all pages. APIs would be made for things that could be used on more the one forum type and would be useful for developers and developing standards.
Ok cleaned it up a little sorry i write all my ideas as i think them instead of thinking then writing
i could not have used better words… 🙂
what did he say?… lol
lol ok what i think i am trying to say is that for features that multiply forum types could use but not all (like rate post, first post on every page, post icons, and attachments). Then forum type’s classes would call these « features » to be used.
Link Function
Instead of in templates having $vboptions[bburl]/blah.php?fddsfd we have a function that can be called (with the new vb 4 template engine) that would be some thing like $vb->url_format(script name, quesry string) this would make SEO modifications extremely easy to make.
No More Podcast Or Rss Forums
Both Forum Types, it would clean up A LOT of code.
Not sure if this is still going but I thought of this and thought it should be added…
Key Phrases
Certain key words that would show up a lot through out a forum like user, post, and forum can have just one phrase then any other phrase that uses this word can access it by {user}. That way if an administer wanted Users to show up as « Clients » they would just have to edit one phrase. Also the construct phrase would have another parameter that is something like « Overwrite Key phrases set up » then an array of the « Overwrites » (not sure why it would be needed but somebody would have a special case)