Posts by Alexander Ebert

    It's a bit difficult to explain: This issue is cased by the way the language system currently works. Each language item is resolved itself, first it tries to guess the language category multiple times (each time with a bigger range of possible values) until it finds one. If the language system was unsuccessful it displays the raw value (the language variable itself).

    But when it actually finds a valid category it assumes that every other language item would match the same category, whereas it might not. An example:

    • WBB Portal 2 uses the language category "wbb.portal"
    • Some 3rd party developers used the category ""

    In this situation the language system first resolves "wbb.portal" as valid category and loads the appropriate items. Next it encounters a variable which is not available within this category and tries to guess the right category, ending up with "" with a successful match. The next item which starts with "" is now assumed to be located within "" but it actually resides within the category "wbb.portal" which is not assumed to be valid anymore, thus this (and any similar variables) cannot be resolved successful anymore.

    I hope this explanation was helpful, if not feel free to ask a specific question - at least English is not my mother language (even though this topic is not even easy to explain in German!) ;)

    Edit: This issue is solved in WCF 2.0
    Edit2: Which language category did you pick for your language variables?

    You cannot simply remove a user option from a plugin, without modifying the plugin properly. In most cases other parts rely on it's existence and thus change the overall behavior. You might instead want to change it's visibility to hide it from users, this way it is not entirely removed but in general unreachable for an user.

    I would recommend that you create a second user for testing purpose, then create a thread and subscribe with your primary user. Next log out and reply to this thread with your testing account, if there are any major problems you will see them now. If the email is not sent (or received), double-check your spam folders in case you just missed it.

    If it's still not working you might want to pick SMTP as method for sending emails and try again. Since the subscriptions work fine in general, it has to be a problem related to your server and/or mail account.

    There are several ways of achieving this, if you already have a PHP file you might want to look for the template plugin "includePHP" (not pre-installed!) which allows you to include PHP files on runtime. The other solution is far better but isn't that easy: create a package which uses event listener to hook in and modify the output the way you like (but this is pretty advanced).

    Your solution would be based upon some JavaScript and exactly one PHP class behind. The overlay with your message input can be easily accomplished with jQuery and, you can simply install both packages in your Burning Board and these libraries would be ready to work with (pay attention to their descriptions!). I'm not going to deep into all this fancy AJAX stuff, there are loads of pretty fine tutorials on this case.

    Following on the PHP class would primarly consist of a simple validation (input not empty, user is not a guest, etc.) and sending the PM. The last things is almost child's play:

    If you have further questions on this case, feel free to ask - I will be happy to help you :)

    Unfortunately we cannot provide you with an importer for Invision Power Board 3.2 for now, you might have a chance by converting to another software first (e.g. phpBB).

    I realised that with OOP too but it's seems to be much more complicated...

    It is not. If you're familiar with PHP you might know about variable scope, which means that you cannot access a variable defined outside a function unless you import it with "global" or pass it as argument. Try the example below, it works and shows you how to carry variables across different functions.

    This is an interesting approach and I'm happy to tell you that this is possible without even modifying the original source code. Our system offers a bunch of features (e.g. an event system) which allows you to change the software's behavior without ever touching the source files, thus you can always update Burning Board to the latest version and would not suffer from any problems, for example modified files being overwritten etc.

    One last note: The approach above requires programming skills, especially object-oriented programming in PHP5. If you're not a programmer or don't know anyone who can create such a plugin for you, you might want to get in touch with us and we would be happy to create such a plugin. Simply send us an email to for a proper quotation.

    I would recommend to re-download this file, in rare cases the file might be not entirely downloaded causing a corrupted archive. Furthermore if your system's defined temp folder is full the pre-installation routine may fail too.

    In general the easiest way would be modifying the forums theme to match your website which can be accomplished pretty easily with our shipped style editor.

    If you want to integrate certain features of our software (e.g. the login panel) on your standalone website I must say it is not possible that easy. Burning Board is based upon our software "Community Framework" which provides features like user management etc. In our case our website is an application based upon "Community Framework" too which enables us to easily integrate the user panel into our website.

    You might want to adjust your forum's style first and evaluate if you're satisfied with that. If you want other features (e.g. integrating the user panel) you might hire us at any time so we can create such a feature exclusively for you: contact us for free via email to

    We provide a plugin which enables you to query a 3rd party database (e.g. Drupal) for user credentials, this way your users may authenticate against your existing Drupal database. Please beware that there's always a possible problem with password encryptions (everyone uses his own way), thus you might have the plugin modified to match Drupals encryption.

    Is the "#profileContent" at the end of the permalink just a comment, or does it have any significance?

    The content after the hash ("#") tells the browser to jump to a specific section. In case of the user profile the section "profileContent" is the container right below the user data, this way your browser will load the page and scrolls down so you can directly view the image. If you omit the hashtag the page would fire up but you have to scroll down yourself. Like Netzwerg said before, the hash tells the browser which part of the page he should focus.

    While the ones you list are just a directory path, is there a reason for this difference I should be aware of?

    Both links are the same, but the "directory path" is just simulated. In real it points to index.php?page=Thread&…, this is done by the search engine optimization (SEO) plugin which rewrites links to be better readable. After all you can treat this as a cosmetic change, there's clearly no technical difference between both.

    To given an example, the following links will both point to the same page and the same image:

    If you open the second link your browser will be redirected to display the first link, but they're still pointing to the same location.