Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Wishlist for Vanilla 2.0

13

Comments

  • Come on , I know someone else said that before but the greatest feature in Vanilla that it comes without all the stuff you won't need, the same principle the Firefox folks trying to adhere to(not to include extensions in the base distribution) .... what needs to be done is making Vanilla extensible AND I think that it is already done ... just my opinion ...
  • I wasn't saying that Vanilla needs more stuff. I agree that Vanilla is great because it lets you build things up the way you want to. A lot of the functionality in Vox could easily be attained with Add-ons and with the future release of Swell. I was just saying (or trying to say) that Vox is an example of what you could do with Swell and Vanilla and a few addons.
  • dan39 is talking about the way Drupal does it. Its very vanilla. but comes with most used modules like Blog module. Its disabled by default. but u can just enable it. Preview Post is tooo essential. have it come with vanilla but disabled. Plus any extensions that should come default will have to be throughly checked for bugs and security.
  • I'm pretty sure I've never once previewed my posts..
  • dan39dan39 New
    edited October 2006
    Hmm. I didn't mean to suggest that Vanilla come with Swell. Vanilla and Swell are two different things in my mind. I was just showing how Vox is aiming to be the new MySpace killer. And how, if someone wanted to, one "could" combine Vanilla and Swell together to create an application along those lines. I probably should have created a new topic to point that out. But really think about how crazy that would be? An open-source version of MySpace/Vox that anyone could host.
  • " * MySchizoBuddy * CommentTimeOct 15th 2006 block userblock commentpermalink i don't understand why the need for blog. Don't we have enough of them already. Vanilla does things much better than traditional forums. Hence i see a need for it. i don't see why people want a blog system. can't u use existing ones. " why? I guess it is easier to express this idea with an equation forum = blog post(s) + comment(s) could you show one decent blog software that handles comments as a part of conversation. for example, search for " all posts\comments written by: ..."
  • dan, that would be crazy... the thought of it will give me horrific nightmares for a while. Templates... This is a biggie, really. The way it's set-up now isn't bad, and better than a lot of others out there. But getting real deep into a template engine or particular style could end up severely bloating the core. I like parts of how it is now, for example the separation of category.php, admin.php, etc. Granted that once mod_rewrite is enabled it's all for not, but for users that can't or don't choose to enable this, it helps some with seo and is one less thing in the url. For simplicity, a php file that's mostly html with a few php tags dropped in would be OK, but I personally like the mixed option. I like being able to control the display of an item from the template. For example, if something is output in the template in a while or foreach loop and it's something like data<br /> that repeats, what if I want to put it in a styled list? Easy. Modify the template. OTOH if it's a template tag, like in WordPress for example, you have to modify the core files to spcifically change the output. Sure you can add some options, but those options also increase the function size. As it is now, the defaults are in the main theme directory, but look for a counterpart in the theme name sub-directory. If I want to modify a template, just making a copy of the original in the particular theme directory is great. If I want to modify the entire thing, I can. Although that's quite a bit of work. Also with the display code right in the template, it's easier to modify the output. Call me nuts, but I like the rendered output in the source to flow nice, and if you create an entire new theme then most likely your tabs won't match up. I dunno, I guess it just bugs me to look through my source and see it all nice and tidied up, and then over to the left I see a ton of: p>this paragraph here.... /p> p>this paragraph here.... /p> p>this paragraph here.... /p> p>this paragraph here.... /p> or list items, whatever, that fall out of place in the overall composition of the source. OK, yeah. I'm picky. But for me it also makes it a ton easier to debug too, as I can see what's opening and closing, and if I'm missing something. Personally, I don't think the addition of SMARTY would be smart. It has its uses, but to me it looks like it would really bloat up the core. There could be an alternative though. A compromise of sorts. One where the main templates (header, panel, body, footer, etc...) used tags, and then those tags executed functions in sub-templates. Then in the sub-templates could be the functions with the display code. With this approach, the users that are less comfortable with digging into php would have a simple interface to be able to edit since it's mostly html, but the advanced user would be able to still retain that display control as well. OK, enough about templates. One option I would like to see would be the ability to select whether or not to use JS, without losing any functionality. If JS is enabled in the settings file, all is well. If it is turned off, then it would produce for example a page for editing the order of cats, confirming an extension was installed, etc. For the few functions that fully require JS, it wouldn't add too much additional code to the core to do an if to produce the proper link.
  • @MarkW and @Silverwing - "Isn't a blog just a forum with funny formatting?" or "Isn't a forum just a blog with funny formatting?"

    Yes and yes.

    If someone would give me an extension that would allow admins (and users, for that matter) to choose how many 'x' characters of a discussion's leading post to display, I'd be happy. By adjusting the textual prominence of the first post, we could define the perceived degree of bloggishness desired.

    Supporting switches for that per category, by date currency or other parameters would be sweet icing on the cake.

    I started blogging before it was a word but for any blog that seeks comments, I fail to see why a separate blog/forum package helps users (or readers). Vanilla's chief strength is that it reduces the 'felt' barrier to casual participation. Any conceptual separation into blog-forum (even if cunningly integrated) will raise that barrier, imho.

    'Seeks comments' (e.g., conversation) is key. I write stuff to publish that does not seek comments - a blog package outstrips Vanilla for that in many ways. This isn't about forums being better than blogs or killing off blogs.

    Anyhoo, please, please, please someone do that extension and end the debate, for a week at least ;-).

    (Apologies, know this discussion is about core, not extensions. On the ones at the top, I would vote: yes, no, deleted, yes, yes, not sure.)
  • I don't think prototype adds much to loading time, it is usually chached after the 5th view.
  • toivo. in other words ur saying that when ur reading a blog and u click on the name of the author, u DON"T get all his/her posts. nearly all blog system do that. blogs are not meant to be a conversation. Comments can be a conversation. hence blog system having threaded views of comments. Again nearly all blogs do that as well. ur basing ur arguments on a fictional product that doesn't exist. Swell might not even do what ur thinking of that it does.
  • NickENickE New
    edited October 2006
    @addicted: standardizing the js libraries isn't all about reducing the size (although it could also reduce the amount of js), it's more about having a standard API to prevent redundancy and to ease the addition of js functionality. For example, at the moment vanilla has two different autocomplete classes in its js files, something which could be prevented by building up only what's needed from one standard library. Of even more concern is extensions; I'll admit I've been using my own AJAX routines in my extensions -- largely because I found it simpler to use something I already knew about rather than figure out how to use prototype -- and I'm sure I'm not the only one who's been using seperate, redundant js files. By completing standardizing the API this would be avoided, and all the extensions would be able to (easily) use the provided library rather than using their own, saving a good deal of bandwidth and loading time.

    On top of that, there is the argument that the effects + prototype libraries vanilla is using are around 80kb, while jQuery (compressed, as provided) is only 15kb.
  • What about Moo.fx(1). The library is 3kb! Mootools(2) also has some ajax and dom libraries also. They are all really small as well. (1) - http://moofx.mad4milk.net/ (2) - http://mootools.net/ I havn't been following this thread really carefully, and I hope this is relavent in some way, but is there any reason these libraries can not be used?
  • from the site:
    moo.fx is a superlightweight, ultratiny, megasmall javascript effects library, written with prototype.js.

    so it still requires the 50kb of prototype
  • I think it is BASED on prototype. I just exported ALL of the mootools (all elements in the js framework) and it came out to be just over 10kb.
  • From the mad4milk blog, and the original release of moo.fx: -- moo.fx requires prototype.js, but the stripped down version included in the download is just enough, if you want to use effects only. -- I am quite sure it uses a cut down version of Prototype. I could be way off though, in which case, tell me to butt out.
  • Well but that's just the problem. Either you use a stripped down version of prototype for just effects, and are left without a standardized API and/or large amounts of redundancy, or you download the full prototype library and end up right back where we are now size-wise.
  • Script.alish.us (or however you spell it) is alot smaller when you combine everything and take out spaces and line breaks.
    I don't think prototype is a problem, it is normally chached and won't effect the page load, all you really have to do is say it was modified 5 years ago.
  • >> Speaking of a Vanilla/Swell suite... Have you guys seen Vox? It just got out of Beta today: >> http://www.vox.com/explore >> It's basically Six Apart's version of a Vanilla and Swell suite. Definitely worth a look Dan39, thanks for that post! Vox looks really nice. As I've said earlier in the thread, what I would love to see is a vanilla/swell type suite. And Vox looks really cool. I like it. Wish I could have it fo rmy site! :)
  • edited October 2006
    mootools is the same size as jQuery, if u include everything. Its just not effects we want.
    jQuery is very extendible, with over 80 plugins. no one has yet made an extension for mootools (i think, no mention of it on there website)
    Visual jQuery is kickass documentation. Mootools has code documentation which goes over my head. I need examples.
    jQuery has css style syntax. something we all know.
  • ToivoToivo New
    edited October 2006
    "in other words ur saying that when ur reading a blog and u click on the name of the author, u DON"T get all his/her posts.nearly all blog system do that. nearly all blog system do that." If someone *comments* on the blog post and I want see his\her other comments then .. show me one software that could do it ... "blogs are not meant to be a conversation." I disagree "ur basing ur arguments on a fictional product that doesn't exist. Swell might not even do what ur thinking of that it does." vanilla already delivers. it just needs couple of things like tagging
This discussion has been closed.