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.
Options
Extension creation guidelines
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.
0
This discussion has been closed.
Comments
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.
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
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"); }$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); }