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.

Extension creation guidelines

edited July 2005 in Vanilla 1.0 Help
So I'm going to try and build an extension myself (I'm making a simple calendar), and I'm curious to how we should go about creating a table (by creating an install file for the extension, or putting it in through a conditional directly in the extension that would be triggered if no table exists ), what the naming convention would be (I like VEX_ personally, as it immediately points out that it's an extension), whether the table should be completely self contained to keep things neat, or if it's kosher to add to existing tables (for instance if there were an extension that only had a boolean it needed to add a field to the LUM_User table). Also, should extensions be contained in only one file, as I've seen so far, or can the extension have it's own folder/library that is accessed by a file that is in the base extensions folder? I sorta looked at the settings.php code that grabs extensions, but I'm not quite experienced enough to follow the mechanism completely.


  • I think LUX would be a better prefix - vex means an annoyance ;( - lux is more! I dont think adding colums to the user table would be a problem - though again its probably best to prefix the column name to stop overlap. As for the rest...mark?
  • a simple calendar! that's a good one! har! i've been waiting for the documentation to help illuminate this and several other database-type questions. i agree there should be some kind of standard as far as these things go, so good extension can have something to adhere to
  • mini - in general, adding columns to existing tables seems like a bad idea, but maybe you're just better at it than i am.
  • oh, yes LUX is much better. :) the table creation and the library/folder/multiple files for one extension are my biggest concerns really.
  • MarkMark Vanilla Staff
    edited July 2005
    I'm open to suggestions from everyone on this, but these are my thoughts:

    Database Changes
    I think that you should probably have an install script come with the extension. I think that having it check for a table every time a page loads and creating it if it doesn't is extra load that the application just doesn't need.

    I think that the table prefix should actually be as unique as the author of the extension so that we never get any naming conflicts on new tables. Like, it should remain with an LUM_ prefix, but then go further with the author's initials or something, like LUM_MOS_TableName.

    As for adding to existing tables, I think it should be done sparingly. Obviously there will be times when you just need to do it, but if you can keep it outside, then do it.

    Everyone should note that if you are looking at creating an extension that turns on based on user preference, you should hold off on altering the database in any way. I'm going to be writing the documentation on user preferences and everyone is going to love what I've done (no database changes should be necessary for adding new user preferences).

    Multi-File Extensions
    I think it is fine to create an extension folder with the extension name as the folder name. I imagine you'd have your ExtensionName.php file that uses whatever you've got in your ExtensionName folder. I think that's a lot tidier than dumping it into the extensions directory root.
  • well in my migration script i added a phpBBid column to the users table - i guess its slightly different cause that was before the forum was in use but it doesnt remove it (by default) afterwards and still works happily so i dont see it as an issue? There's almost certainly a good reason why not to though...i'm not very good at much so i imagine your reason is probably perfectly valid.
  • edited July 2005
    jsanders, I also agree that adding to pre-existing core tables should be a no-no, as the whole point of an extension is to add without modifying the core.
  • i have an idea of how the user preferences in the databases works (i have been closely scrutinizing the built-in shortcut keys extension), and i have to say that it is a stroke of genius.
  • MarkMark Vanilla Staff
    *tips hat*
  • edited July 2005
    Wow, quick answer! That's exactly what I was wanting to know, thanks Mark.

    I think then if an extension requires a table to be created, it have an install file in that extension's library. Regarding the structure and naming, I think it should go like so:

    extension.php - core extension file
    /extension - library folder, should always have the same name as the extension
    /extension/extension_install.php - install file, always has the extension name followed by '_install', to prevent install filename conflicts. Always located inside the library folder for the extension
  • i think the install script should be included in the library folder that has the extension name. it's not something that should ever be needed more than once or twice.
  • edited July 2005
    Anyone have any ideas on how to handle additional style definitions for page elements added through an extension? For instance, the extension I'm making will need to have some styles defined for the calendar it builds. I know there must be some way to link another stylesheet .
  • lechlech Chicagoland
    edited July 2005
    trabus, look at the yellowfade extension, i believe it throws a js file into the header area like some other extensions, replacing the js with a custom style sheet shouldn't be a problem then.
  • well, after poking around a little, I found the AddStyleSheet function in the Common.Controls.php file, but I haven't found where its used to add a stylesheet yet. I'll check into the yellowfade extension though, thanks.
  • edited July 2005
    Heres the stuff form YellowFade:

    if(in_array($Context->SelfUrl, array("index.php", "categories.php", "comments.php", "search.php", "post.php", "account.php", "settings.php"))){ $Head->AddScript("./js/yellowfade.js"); }
  • nice! this works:
    $StyleSheetLocation="extensions/calendar/calendar.css"; if(in_array($Context->SelfUrl, array("index.php", "categories.php", "comments.php", "search.php", "post.php", "account.php", "settings.php"))){ $Head->AddStyleSheet($StyleSheetLocation); }
  • lechlech Chicagoland
    good, now all you need to do is have that style sheet appear everywhere your calendar is present. :D
  • yep. I'm actually placing the calendar on the page using brady's custom html messages in the panel extension, which has an include of the calendar building function, which it calls and then places the result in the panel. I then add the stylesheet to the page using the AddStyleSheet function on the very next line.
This discussion has been closed.