In a recent discussion I outlined that (sorry for the autoreference):

(plugins) use hardcoded directory name inside .php files

I say that since many plugins that I've seen use this approach:

include_once(PATH_PLUGINS.DS . 'MyPluginDirectoryName' . DS . 'class.myclass.php');

Not so clean, since you can use (beware of yourself):

include_once(dirname(FILE) . DS . 'class.myclass.php');

Views paths

When you need to set a view, you can use a similar approch:

$Sender->View = dirname(FILE) . DS . 'views' . DS . 'myview.php';

$Sender->Render();

or a (better? I found it just now) method form the class.plugin.php

$Sender->Render($this->GetView('myview.php'));

Note: Please contribute below with your own tips or with your critique.

Thank you to @hgtonight for this discussion.

• Problem 1

  public function CacheUnread($CountUnreadComments){ $this->CountUnreadComments=$CountUnreadComments; }

  public function GetCacheUnread(){ return $this->CountUnreadComments; }

If I get the answer to this I'll fix an existing plugin

• Problem 2

In 2.0.18 I could also store an array of variables (but not in 2.1)

via the following in an event in a plugin

$Sender->MyData[DataItem1] = "blahblah"

and then using the following in a view and retrieve the variable.

$thedata = $this->MyData[DataItem1]

I'm just curious what would be the correct way to do this in vanilla 2.1.

https://github.com/x00/Gdn_PScaffold

Requires php >= 5.2 to run

For those that already have IDE templating and automation regimes, you probably don't need this. You might want to look at the utility methods though.

What it is NOT for:

• Plugins that only have one or two files and a few lines of code (as it will create extra files).
• Plugns that already have a more specific organised structure

You can use on a plugin that needs some organisation, or a new project.

It is a scaffold it does not make your plugin automatically work, you need to implement along the lines suggested.

Treat it like beta software. It does backup within the plugin file, but it is not substitute for an external backup regime.

This is a tool/helper, don't trust it to be perfect.

i noticed a couple of things while playing with it tonight: 1. the url when clicking on a badge does not use a prettified url syntax 2. i get some crazy formatting with my theme on the badge information page

http://homebrewforums.net/badges/index.php?badgetype=LikedBadge

I'll be poking around later this week, but i thought i would ring it to your attention.

As some of you may or may not know by now, I'm pretty darned nit-picky when it comes to organizing my code and having nice, semantic directory structures. However, the Garden autoloader is rather limited to only searching a couple of default directories when you're coding applications, plugins and themes. Everything in the base dir gets loaded and so does stuff in library, controllers, settings, locale, views and perhaps some others folders I've forgotten about.

I did however finally read through the Gdn_Autoloader class as I wanted to find a way to autoload stuff within sub-directories of my library folder without having to write my own autoloader, which I'm doing in Vanilla API (will change in 0.0.3-dev). Turns out it's pretty straight forward registering recursive autoloading of this directory (and of course other directories too):

$Map        = Gdn_Autoloader::MAP_LIBRARY;
$Context    = Gdn_Autoloader::CONTEXT_APPLICATION;
$Path       = PATH_APPLICATIONS . DS . '[foobar]/library';

$Options    = array();
$Options['Extension'] = '[foobar]';

Gdn_Autoloader::RegisterMap($Map, $Context, $Path, $Options);

These are the accepted $MapType and $Context constants:

const CONTEXT_CORE            = 'core';
const CONTEXT_APPLICATION     = 'application';
const CONTEXT_PLUGIN          = 'plugin';
const CONTEXT_LOCALE          = 'locale';
const CONTEXT_THEME           = 'theme';

const MAP_LIBRARY             = 'library';
const MAP_CONTROLLER          = 'controller';
const MAP_PLUGIN              = 'plugin';
const MAP_VENDORS             = 'vendors';

Just a helping hand to people looking to do the same thing!

So I decided to write a proper and useful Vanilla API. So far it's going pretty well: I've created APIs for the category and session controllers (only GET methods so far) and got the API controller to respond in both JSON and XML. Also created a documentation and visualization layer using Swagger so exploring the API is super easy and fun. You can find a couple of screens here: http://imgur.com/a/zvMB8/embed

However, I'm a moron when it comes to more advanced stuff like SSL, auth and tokens. What I'm doing now with the GET requests is pretty darned simple: Get data from Vanilla using default methods, turn the data into arrays, render the data and deliver it using either XML or JSON.

My question to ya'll devs is therefore this: Is there anyone out there who'd be interested in joining in? I think this could be a pretty awesome project and definitely be of great use to a lot of people out there.

I think that was my 50 cents for today :-)

All the best as always,
Kasper Kronborg Isager

So let's face it. There are a lot of addons on the Addons site that just don't work. There are several reasons why this is the case. Maybe a plugin was developed by an inexperienced developer. Maybe someone developed against an old version of Vanilla. I'm not casting judgment here it happens. But the fact of the matter is that addons that don't work or of low-quality are bad for Vanilla.

This is an important point. Vanilla has grown a lot in the past years and we have to start working towards more quality in the addons on this site. At the very least we need to give people that come to the addons site more information about an addon before they try and go installing it.

Here's the thing though. We here at Vanilla HQ can't go through everyone's addons and make sure they work. What we can do is give better tools on the addons site and give some better guidance on addon development in general. Here are some thoughts on that front.

Keeping Addons Current

1. I want to move from addons being approved/unapproved to being "works with". Rather than having us approve addons we'll have the community say whether an addon works or doesn't work with certain versions of Vanilla.

2. Using the above information we will mark plugins as abandoned if they stop working with newer versions of Vanilla. Addon authors have a responsibility to fix their addons, but if they aren't notified then it's really not their fault.

3. Abandoned plugins will be removed from the addon site. This means that the addon will be gone and someone else that wants to pick it up can re-upload it and start maintaining it themselves. This is a bit of a clunky workflow so I'm not sure if I'm decided on this. Philosophically though I'm not against changing the maintainer of an addon if the original author abandons it. As a courtesy the original author should be given credit for their work.

Using Gith(hub) to Develop Addons

1. I really want to start encouraging people to develop their addons on github. We totally know that github can be difficult to get into, but you are doing yourself a disservice by not learning how to use git. And yes, I even think theme developers should be getting into git.

2. Having your addon up on github allows others to collaborate with you and help fix issues. People can fork your repo and give you pull requests or you can even give other people commit access to make changes directly to your addon.

3. I think that you should create a seperate repository per addon you develop. This makes it easier for people to fork just your one addon. If you develop a lot of addons you can create one master repo that contains all of your addons as submodules.

4. If enough people start maintaining their addons through github then we can build some nifty tools into the addons site that will automatically grab updates directly from the repo.

Addon Ratings

I'm in favor of adding a simple five-star rating system to addons. There are a lot of addons and having some way to help people decide on which ones to install is becoming more important.

Commercial Addons

We are not interested in creating a site that allows people to sell commercial Vanilla addons. Changing our minds is in the realm of possibility, but is highly unlikely.

Vanilla 1 Addons

We'll most likely stop supporting Vanilla 1 addon downloads at some point.

Here's the thing: A write a s**t-load of Vanilla themes - I absolutely hate writing boilerplate, I hate setting up a project structure and I hate having to rely on desktop applications for compiling my code. I want to be able to boot up my terminal, my text editor as well as my browser and then simply start working. But what about all the cool stuff? What if I want to use CoffeeScript and SASS? Then I can simply install Austere and I get the power of some of the most awesome preprocessors out there right in my hands. Problem solved!

But... what if I'm too lazy to actually switch to my browser and reload it every time I change my code? What if I want to compile assets and manage dependencies from a separate server to make things more efficient? Sure, I could download and install applications such as CodeKit and LiveReload but again, I don't want to rely on desktop applications for stuff like this as it greatly complicates multi-author projects. Plus, I want to be able to easily share my code without people having to buy applications to actually use it! What if I could simply sit back, write a couple of lines in my terminal, write some CoffeScript and SASS, save it and then see the changes instantly in my browser without even having to lift a finger - all without the power of funky desktop applications?

Right, enough with the sales speech - let's get down to business! Over the past couple of weeks I've written a scaffold called Ninja that allows you do the all of the stuff I've been talking about and even more. It's heavily inspired by Yeoman's scaffolding component, Yo, and also includes the two other main components that Yeoman uses: Grunt and Bower. Here's a short introduction to Ninja:

Ninja is a super sneaky Node.js, Grunt and Bower powered scaffold for building superb Vanilla themes. Ninja allows you to easily use your choice of preprocessors and languages in your themes and enables you to write kick-ass build processes using the many plugins available for Grunt.

Ninja will also stealthily do browser sniffing and feature detection using Conditionizr and Modernizr and will also reload your assets whenever they change using LiveReload - like a true shinobi!

Sound good? Trust me, it is! Ninja is my personal workflow in a neat and tiny package - it combines all the stuff I use for building Vanilla themes and enables me to scaffold out new themes in mere seconds. Furthermore, Ninja bundles with an example Bootstrap-ish theme and a bit of other good stuff to get you started. Ninja hasn't "officially" dinged 1.0.0 yet, but feel free to take it for a spin: https://github.com/kasperisager/Ninja

I'm still documenting stuff but have included installation and usage instructions in the README. If you have any thoughts about Ninja, feel free to share them - and now go write some cool stuff!

All the best,
Kasper Kronborg Isager
http://webhutt.com

Under versions detail, 3.1 is after 3.03.

1) Open .htaccess file from forum root folder in any text editor

2) **Add ** below changes that suites you -

# ----------------------------------------------------------------------
# Better website experience for IE users
# ----------------------------------------------------------------------

# Force the latest IE version, in various cases when it may fall back to IE7 mode
# Use ChromeFrame if it's installed for a better experience for the poor IE folk

<IfModule mod_headers.c>
  Header set X-UA-Compatible "IE=Edge,chrome=1"
  # mod_headers can't match by content-type, but we don't want to send this header on *everything*...
  <FilesMatch "\.(appcache|crx|css|eot|gif|htc|ico|jpe?g|js|m4a|m4v|manifest|mp4|oex|oga|ogg|ogv|otf|pdf|png|safariextz|svg|svgz|ttf|vcf|webm|webp|woff|xml|xpi)$">
    Header unset X-UA-Compatible
  </FilesMatch>
</IfModule>




# ----------------------------------------------------------------------
# Gzip compression
# ----------------------------------------------------------------------

<IfModule mod_deflate.c>

  # Force deflate for mangled headers developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping/
  <IfModule mod_setenvif.c>
    <IfModule mod_headers.c>
      SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
      RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
    </IfModule>
  </IfModule>

  # Compress all output labeled with one of the following MIME-types
  # (for Apache versions below 2.3.7, you don't need to enable `mod_filter`
  # and can remove the `<IfModule mod_filter.c>` and `</IfModule>` lines as
  # `AddOutputFilterByType` is still in the core directives)
  <IfModule mod_filter.c>
    AddOutputFilterByType DEFLATE application/atom+xml \
                                  application/javascript \
                                  application/json \
                                  application/rss+xml \
                                  application/vnd.ms-fontobject \
                                  application/x-font-ttf \
                                  application/xhtml+xml \
                                  application/xml \
                                  font/opentype \
                                  image/svg+xml \
                                  image/x-icon \
                                  text/css \
                                  text/html \
                                  text/plain \
                                  text/x-component \
                                  text/xml
  </IfModule>

</IfModule>


# ----------------------------------------------------------------------
# Expires headers (for better cache control)
# ----------------------------------------------------------------------

# These are pretty far-future expires headers.
# They assume you control versioning with filename-based cache busting
# Additionally, consider that outdated proxies may miscache
#   www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

# If you don't use filenames to version, lower the CSS and JS to something like
# "access plus 1 week".

<IfModule mod_expires.c>
  ExpiresActive on

# Perhaps better to whitelist expires rules? Perhaps.
  ExpiresDefault                          "access plus 1 month"

# cache.appcache needs re-requests in FF 3.6 (thanks Remy ~Introducing HTML5)
  ExpiresByType text/cache-manifest       "access plus 0 seconds"

# Your document html
  ExpiresByType text/html                 "access plus 0 seconds"

# Data
  ExpiresByType application/json          "access plus 0 seconds"
  ExpiresByType application/xml           "access plus 0 seconds"
  ExpiresByType text/xml                  "access plus 0 seconds"

# Feed
  ExpiresByType application/atom+xml      "access plus 1 hour"
  ExpiresByType application/rss+xml       "access plus 1 hour"

# Favicon (cannot be renamed)
  ExpiresByType image/x-icon              "access plus 1 week"

# Media: images, video, audio
  ExpiresByType audio/ogg                 "access plus 1 month"
  ExpiresByType image/gif                 "access plus 1 month"
  ExpiresByType image/jpeg                "access plus 1 month"
  ExpiresByType image/png                 "access plus 1 month"
  ExpiresByType video/mp4                 "access plus 1 month"
  ExpiresByType video/ogg                 "access plus 1 month"
  ExpiresByType video/webm                "access plus 1 month"

# HTC files  (css3pie)
  ExpiresByType text/x-component          "access plus 1 month"

# Webfonts
  ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
  ExpiresByType application/x-font-ttf    "access plus 1 month"
  ExpiresByType application/x-font-woff   "access plus 1 month"
  ExpiresByType font/opentype             "access plus 1 month"
  ExpiresByType image/svg+xml             "access plus 1 month"

# CSS and JavaScript
  ExpiresByType application/javascript    "access plus 1 year"
  ExpiresByType text/css                  "access plus 1 year"

</IfModule>


# ----------------------------------------------------------------------
# Prevent mobile network providers from modifying your site
# ----------------------------------------------------------------------

# The following header prevents modification of your code over 3G on some
# European providers.
# This is the official 'bypass' suggested by O2 in the UK.

# <IfModule mod_headers.c>
# Header set Cache-Control "no-transform"
# </IfModule>


# ----------------------------------------------------------------------
# ETag removal
# ----------------------------------------------------------------------

# FileETag None is not enough for every server.
<IfModule mod_headers.c>
  Header unset ETag
</IfModule>

# Since we're sending far-future expires, we don't need ETags for
# static content.
#   developer.yahoo.com/performance/rules.html#etags
FileETag None



# ----------------------------------------------------------------------
# Suppress or force the "www." at the beginning of URLs
# ----------------------------------------------------------------------

# The same content should never be available under two different URLs -
# especially not with and without "www." at the beginning, since this can cause
# SEO problems (duplicate content). That's why you should choose one of the
# alternatives and redirect the other one.

# By default option 1 (no "www.") is activated.
# no-www.org/faq.php?q=class_b

# If you'd prefer to use option 2, just comment out all option 1 lines
# and uncomment option 2.

# IMPORTANT: NEVER USE BOTH RULES AT THE SAME TIME!

# ----------------------------------------------------------------------

# Option 1:
# Rewrite "www.example.com -> example.com".

<IfModule mod_rewrite.c>
  RewriteCond %{HTTPS} !=on
  RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
  RewriteRule ^ http://%1%{REQUEST_URI} [R=301,L]
</IfModule>

# ----------------------------------------------------------------------

# Option 2:
# Rewrite "example.com -> www.example.com".
# Be aware that the following rule might not be a good idea if you use "real"
# subdomains for certain parts of your website.

# <IfModule mod_rewrite.c>
#   RewriteCond %{HTTPS} !=on
#   RewriteCond %{HTTP_HOST} !^www\..+$ [NC]
#   RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# </IfModule>

At the moment the version check for addons is:

version_compare($NewVersion, $Version, '>')

this is ok but it is limited in a way, it always assumes that it is compatible with future versions.

You can actually put additional logic in setup, but it would be good if could be integrated.

I will be doing a lot of development into the future and I want to be flexible, especially as I will be developing quite atomically.

I can think of a number of scenarios:

1. One version only, exact match, stop gap solution perhaps.
2. Quite often you see stuff like this >=2.0.18 it would be useful if it could detect those operators an plug into into the function since it has that capability to be exact.
3. in other cases you need an range you could have for instance >=2.0.17,<=2.0.18

Another scenario that I personally faced was I wanted to require one plugin or another. Actually EXOR. I think it fair that I put my own logic in the setup, which I did. However I think it would be good to give some clue in the Requirements. Perhaps a way to put a requirement that is ignored.

I suppose you could always unset the key, before it gets checked. All scenarios have hacks, but might as well make it sleek.

I figured out a strange issues on the Activity page in my installation (latest 2.0.18.4): myself and no other Users are able to post or modify to the Activity page? Just nothing is being updated in the database. Strangely there is also no error message - so I have no clue what could be going on.

Does anybody have a possible hint on this issue?

Thanks for any help, Oliver

but within a plugin it won't remove an application theme css.

public function Base_Render_Before($Sender) {

all of the following
$Sender->RemoveCssFile("custom.css") 
$Sender->RemoveCssFile("vanilla/themes/mobile/design/custom.css")
$Sender->RemoveCssFile("/vanilla/themes/mobile/design/custom.css")
$Sender->RemoveCssFile("themes/mobile/design/custom.css")
$Sender->RemoveCssFile("/themes/mobile/design/custom.css")
$Sender->RemoveCssFile("http:example.com/vanilla/themes/mobile/design/custom.css")
$Sender->RemoveCssFile("http:example.com/vanilla/themes/mobile/design/custom.css?v=1.1.1")
$Sender->RemoveCssFile("var/www/vanilla/themes/mobile/design/custom.css")
$Sender->RemoveCssFile("var/www/vanilla/themes/mobile/design/custom.css?v=1.1.1")

and with a few other events.

The only way I could remove it was via js. But it would probably be better if it worked with php. Any ideas how to remove the themes/mobile/design/custom.css from within a plugin via RemoveCssFile() or with another php function.

on a side note - it seems that $this->GetResource('examplefile.css', FALSE, TRUE) called from a plugin will not really do an absolute call it is always relative to the plugin path. And I thought the second variable makes it absolute instead of relative.

/bootstrap.after.php. what would be an example of something you would do in bootstrap.after.php rather thanbootstrap.before.php. And why?

https://github.com/vanillaforums/Garden/commit/f7f348b419b6a3600d00ac9d66bc279f469db99e

As some of you already know, I'm currently working on a theme called "Apptastic" scheduled for release when Vanilla 2.1 hits the deck. It's currently being tested by a bunch of awesome community members who have already helped eliminate a heap of bugs - thanks for your help guys! What most of you might not know, is that "Apptastic" is the reincarnation of my previous theme, VanillaBootstrap, and a whole bunch of code from that theme can actually be found within "Apptastic". As with VanillaBootstrap, "Apptastic" is a proof of concept - a crazy idea that sprung out of my messy mind last week. This means that it's not a theme for the mainstream user, as it requires a whole bunch of customization to work with a lot of plugins - and customizing it requires knowledge about Assetic, SASS and Compass.

Therefore, with the birth of Apptastic comes the death of VanillaBootstrap - at least the death of the theme some of you have come to know. Now comes the "little something extra": Besides working on Apptastic, I'm also working on version 1.0 of Bootstrap - hooray! I released version 0.9 of Bootstrap (which is known as VanillaBootstrap on Github) back in April and since then I've released 4 other version as well - all being proofs of concept like Apptastic. All these versions will be deleted soon-ish and the code cast into the abyss and version 1.0 will mark the end of the beginning of my Bootstrap theme for Vanilla. I'm coding it using Compass and the SASS version of Bootstrap and it will include no markup-altering js and will rely entirely on the default Vanilla markup (almost, a few extra divs are added here and there) - this meaning that it will be exactly as "default" as Baseline, the official default theme, and therefore also be a theme perfectly suited for any type of user.

tl;dr
Bootstrap 1.0 will be an alternative to the default Baseline theme and will be fully extensible using SASS. The old VanillaBootstrap code will be deleted as it's causing more problems than it's solving. Parts of the VanillaBootstrap code will live on in a heavily modified version in Apptastic. All of this will hopefully be ready for release when Vanilla 2.1 comes out.

I think that was about it! From the looks of it, I won't have any time off for the next few weeks...

// This will work
Gdn::PluginManager()->EnablePlugin('SomePlugin', $Validation);

// This will not work if, while being enabled, the plugin uses anything  from SomePlugin. 
// In my case, ChildPlugin uses SomePlugin, who, in turn, needs one of its models to carry 
// on. In such case, the error "Class not found" is returned
Gdn::PluginManager()->EnablePlugin('ChildPlugin', $Validation); 

If the same tests are run immediately after the first fail, they will succeed. In short:
phpunit sometests.php // This will fail with "class not found" phpunit sometests.php // This will run correctly

It seems, to me, that EnablePlugin() doesn't expose the plugin to the various classes until next bootstrap. However, this is a speculation, as I haven't found an explanation for such behaviour.

If anyone has any suggestion, it would be very welcome. Thanks. :)

As I heard rumors that Vanilla 2.1 is going into beta soon, I decided to create something awesome for its release. I've been using Vanilla for about half a year now and although I love the platform itself, I've always hated its interface. I don't really feel like it justifies the pure awesomeness that is Vanilla. I've tried doing something about it with my VanillaBootstrap theme but however great it has grown to be, it still doesn't quite cut it. I've searched far and wide and have noticed one particular thing during my adventure through UX: Desktop-like interfaces built on CSS3 simply are some of the most beautiful and modern UIs one can find.

What I'm therefore doing as you're reading this, is write a super modern, top-notch, mega shiny and totally awesome interface for Vanilla based on the interface of the great OS application "Sentry" (http://getsentry.com/). Sentry's interface is based on Bootstrap so I've been able to reuse a whole bunch of stuff from VanillaBootstrap. Currently, my architecture is a cluster-f*** to say the least, as I'm building the theme using Austere as my asset manager and Compass as my SCSS framework. This means that the source code consists of a huge mix of both plain CSS, SCSS, SASS, LESS and Javascript. Hopefully, I'll be able to clean it up a bit so customizing it won't be too difficult.

Anywho, here's a little sneak peek for the curious:

Being a desktop-like interface it will be fluid-width with completely fixed content. This means that the header, toolbar and footer will always stay in place while the content and sidebar while be scrollable. Grooveshark (http://grooveshark.com) is a good example of how this works. I've just started writing the theme today, so there's still a long way to go before it's ready to release. I'm very open to sponsorships and donations though as well as other developers who might want to join in on the project.

Hope you like it!

Edit: Actually, I'd really like some help with this one, especially from someone experienced with UX as I'm facing quite a few problems regarding usability.

For the past few months I've been fighting a bit with development of themes for Vanilla as I like to utilize time-saving supersets of different languages to enhance both the quality of my code as well as syntax, readability and... well, time spent developing! As I also like to implement a heap of different jQuery plugins and other scripts, managing all this stuff quickly became next to impossible using Garden. I quickly found that while usage of stuff like LESS, SASS and CoffeeScript was indeed possible, it didn't work out quite as I had hoped it would.

So far, I've mostly relied on Coda and CodeKit for managing, compiling, concatenating and minifying stylesheets and scripts. For a long time though, I've wanted to be able to do all this using PHP so others could benefit from it without having to buy the third-party apps I use. What I therefore did yesterday, was write a small theme "framework" of sorts called Austere, that uses Assetic to manage all its assets and Composer to manage dependencies. These are some of the things Austere enables you to do:

• Compile LESS, SASS, SCSS, Stylus and Compass to CSS
• Compile CoffeeScript to JS
• Concatenate stylesheets and scripts and store them in custom.css and custom.js respectively
• Compress stylesheets and scripts using Google Closure or YUI Compressor
• Optimize JPEG's and PNG's

The cool thing about handling assets in this way is that it creates a strong separation between the production and development environment. All the production code of a theme lives within custom.css and custom.js, just like it was originally intended to, while the development code and its dependencies can live elsewhere and are not required for the theme to function. This ensures a clean and optimized codebase and folder structure for the final and release-ready theme. All of this without having to spend a single dime on fancy software!

For more advanced uses, say where you need to include certain stylesheets and scripts in certain parts of Vanilla, you can combine Assetic and Garden: Doing asset management with Assetic combining stylesheets and scripts into packages and then loading these packages only where needed using Garden. Neat and easy!

You can find Austere here: https://github.com/kasperisager/Austere. I'll be writing some documentation later today and hopefully it should be ready by tomorrow. I know Austere might be overkill for most theme developers, but I wrote it for people who, like me, are super lazy and want to write as little code as possible whilst still maintaining high standards for their code and architecture. I hope it will be of use to some!

// Kasper

$this->DiscussionData->Result()

is pulling the discussions. Where would I go about changing what Result() returns.

I was helping someone and the error that is presented in some browsers (e.g. firefox 14.0.1 on linux) and a few other browsers.

TypeError: rowStates is null

for (var i = 0; i < rowStates.length; i++) {

graph.js line 163

any ideas why rowStates is null

the outline of the graph appears - but the lines (datapoints) are not visible.

@Todd

It will probably undergo some major refactoring in the near future, but I welcome any feedback about current version so that I can add any request to the "to do" list. Enjoy!

public function DiscussionController_AfterCommentFormat_Handler($Sender) {
$Object = $Sender->EventArguments['Object'];
$Body =   $Object->FormatBody;

.... now I want to modify $Body and truncate. works fine

Ideally if there is a way to do something like this (I know it is incorrect code)

$Object->FormatBody = ""; $Sender->EventArguments['Object'] = $Object

But I don't want to have the original $Object->FormatBody; printing

short of modifying the helper functions and commenting out

// echo $Object->FormatBody;

Any other ideas of what can be done?

First of all, a little background-stuff would be in order: I'm an 18-year old developer with a passion for UX currently living in Denmark. For the past 3 years I'm been coding, scripting and hacking my way around the web just for the fun of it. This means that what I'm about to say might seem somewhat trivial to you hardcore-devs, I can't tell for sure. However, I'd like to share some of my ideas and findings regarding Vanilla themes, as I believe that functionality (The Vanilla software itself...) and usability (...its UI) should go hand-in-hand. Here we go!

I had a little talk with @422 a few weeks back (http://vanilla.ungdomsrod.dk/discussion/55/few-questions) about my Vanilla / Bootstrap integration project and how it wasn't anywhere near as optimized, as it could be: The client-side LESS compiler caused dreadful loading times and the compiled CSS was way to huge to be any good. Having to use a static compiler might speed up the loading, but then you'd have to upload the compiled CSS each time you made a change and this also wasn't any good. He really got me thinking: How on earth would one use technologies such as LESS without slowing everything down?

I had tried earlier using the CSS version of Bootstrap and jQuery to add classes to the core markup of Vanilla, but this would in most cases cause a FOUC on each page load as the JS wouldn't fire until the DOM had been built. Fair enough I thought, a new solution is required. I therefore tried using the LESS version of Bootstrap and mixins and it worked perfectly! ...or so I thought. I was running the dev installation locally and a CSS file of 500 KB wasn't really a problem. Until it went online... Let's just say that at a loading time of 12 seconds (tested using Pingdom) it kinda sucked.

As of now, a lot of you might be looking like this...

I know, I was just fooling around with stuff I didn't fully understand (still don't probably). But I wanted it to work. I wanted to be able to use LESS and I wanted others to benefit from its simplicity and ease of use too. As it looked, I was in fact actively slowing down a lot of awesome sites that used my code.

Now to the point: I want theme developers to be able to use technologies such as LESS to create awesome stuff in no time. What I therefore did was combine all the stuff I had done earlier:

1. LESS Mixins was a no-go. I had to resort to the jQuery solution as pointed out by @422 but also had to avoid a FOUC on each page load. I therefore placed all jQuery related to changing the DOM according to this lovely article: http://www.learningjquery.com/2008/10/1-way-to-avoid-the-flash-of-unstyled-content. Voilá, problem solved! (Again, "You don't say?". I'm still a newb!)

2. LESS had to be compiled server-time to avoid the horrible client-side compiling as well as static compilers. I therefore resorted to the LESS PHP Parser and blam! ...I am now able to write LESS and have it compile into beautiful, minified CSS without lifting a finger. All I have to do, is refresh my browser.

Fast, easy and beautiful. That's what I'm trying to say. Constructive criticism would be very welcome, especially if you know of a way of better doing some of the things I've been trying to do :-)

If anyone wants to have a look at the latest version of VanillaBootstrap, you can find it here: https://github.com/kasperisager/VanillaBootstrap/tree/development

// Kasper

Any comments by the vanilla developers or any others?

also a question about this statement. Where and what does default reference? And can you explain this statement a little bit better.

$Sender->MasterView = 'default';

I've always been a little annoyed by the limitations of the default category selector as it becomes impossible to work with once you have a ton of different categories. I therefore decided to write a plugin that utilizes "Chosen" by Harvest but in the process I ran into a small problem. I've written a script that turns the default options list into sorted optgroups in case top level categories are used as headers. The thing is that I'm having trouble copying the header text and using it as a label attribute in the optgroup; only the first word of each header gets copied. I've set up a Fiddle here: http://jsfiddle.net/KasperIsager/3x2TV/

If someone with a better understanding of JS could help me debug it, it would be greatly appreciated!

// Kasper

Perhaps get more activity from posters on the forums too.