Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
6361
Features / Re: New revs - Public comments
« on September 19th, 2011, 10:31 AM »
Also, I'm thinking that the menu notice style could do with tweaking.
.menu strong declares padding: 2px 4px, but I think it might look better (does to me, at least) with padding: 2px 6px.
.menu strong declares padding: 2px 4px, but I think it might look better (does to me, at least) with padding: 2px 6px.
6362
Off-topic / Re: PC hotline
« on September 19th, 2011, 10:11 AM »
I haven't experienced that, but I don't have that many cores, or hyperthreading, and I turn my PC off at the end of the day.
I'm guessing it's related to having a lot of uptime and something leaking memory causing Windows to thrash and have to swap.
I'm guessing it's related to having a lot of uptime and something leaking memory causing Windows to thrash and have to swap.
6363
Features / Re: New revs - Public comments
« on September 19th, 2011, 02:01 AM »
In other news, I found a bug in the new blocks code. I'll dig into it shortly (if I get time, I have other stuff I want to finish first).
Specifically, if you activate the popup in any place (be it my crude use of it in the add-on manager for readmes, but also for normal help popups) you get the RSS block appended to it...
Specifically, if you activate the popup in any place (be it my crude use of it in the add-on manager for readmes, but also for normal help popups) you get the RSS block appended to it...
6364
Off-topic / Re: Been away for a while..
« on September 19th, 2011, 01:50 AM »Had a heart attack then a quad bypass. so I have been doing cardio rehab since getting out of the hospital.
Good to see you around and about, though :)
Yes, there is a lot out there, a hell of a lot has happened (but then again, it always does around here), but take your time, there's no need to bury yourself in stuff. Take it calm and steady :)
6365
Features / Re: New revs
« on September 19th, 2011, 01:47 AM »
(3 files, 10 KB)
Revision: 1011
Author: arantor
Date: 00:46:20, 19 September 2011
Message:
+ Add-on manager can now call for a script to execute when enabling or disabling an add-on. (ManageAddons.php, ManageAddons.english.php)
+ New hook in the help popup, lang_help, so that the help popup can make use of an add-on's language files without the add-on having to do anything too complicated like hijacking the help action, or having to load a file just to contain a single load call. (Help.php, ManageAddons.php)
----
Modified : /trunk/Sources/Help.php
Modified : /trunk/Sources/ManageAddons.php
Modified : /trunk/Themes/default/languages/ManageAddons.english.php
Revision: 1011
Author: arantor
Date: 00:46:20, 19 September 2011
Message:
+ Add-on manager can now call for a script to execute when enabling or disabling an add-on. (ManageAddons.php, ManageAddons.english.php)
+ New hook in the help popup, lang_help, so that the help popup can make use of an add-on's language files without the add-on having to do anything too complicated like hijacking the help action, or having to load a file just to contain a single load call. (Help.php, ManageAddons.php)
----
Modified : /trunk/Sources/Help.php
Modified : /trunk/Sources/ManageAddons.php
Modified : /trunk/Themes/default/languages/ManageAddons.english.php
6366
Development blog / Re: The saga of the Add-on Manager
« on September 19th, 2011, 01:34 AM »
OK, as a heads-up in case you didn't see it in the revision log: the first version of this has been committed. It's capable of enabling any add-on in the addons folder, provided that it only does simple DB changes (new tables of its own, updating those tables only, and not adding columns/indexes to tables that aren't its own), hooks, scheduled tasks and settings.
As of right now I'm about to test enable/disable scripts (much like SMF's code and database blocks in the package-info.xml file, with the difference that they should only be for very specialised jobs, like inserting rows into tables, or doing complex install-time logic)
After that, I'm going to work on the ability to add arbitrary columns and rows to existing tables (like a new column in the members table, for example)
I am, I have to say, quite proud of the updating code here; when you call create_table for a table that isn't one of Wedge's own (i.e. from an add-on) and the table already exists, it tries to manipulate the table to add new columns and indexes[1] so that the table is updated. The cool part is that it does it all in a single statement per table.
While that might not seem important, it can be if there's multiple columns to add: the way MySQL handles an ALTER TABLE to add columns is that it will perform a temporary table creation, with the new schema, and copy the existing data into it as it goes - then switch the tables around after it's done.
On top of that, consider also that the setup may not only require 2x the space (for the old and new tables) but potentially a third copy, and while it's doing all that file I/O, it is hampering the possibly DB queries it could be serving instead, so doing it once if possible is much more efficient in the long run.
Anyway, that's where I'm up to with it so far, and I'm planning on building a few very simple demo plugins, not so much for download and distribution (after all, they won't be any use to you without Wedge!) but for those with access to the source to see how they work and all the stuff that goes on, because there is a lot of it behind the scenes.
As of right now I'm about to test enable/disable scripts (much like SMF's code and database blocks in the package-info.xml file, with the difference that they should only be for very specialised jobs, like inserting rows into tables, or doing complex install-time logic)
After that, I'm going to work on the ability to add arbitrary columns and rows to existing tables (like a new column in the members table, for example)
I am, I have to say, quite proud of the updating code here; when you call create_table for a table that isn't one of Wedge's own (i.e. from an add-on) and the table already exists, it tries to manipulate the table to add new columns and indexes[1] so that the table is updated. The cool part is that it does it all in a single statement per table.
While that might not seem important, it can be if there's multiple columns to add: the way MySQL handles an ALTER TABLE to add columns is that it will perform a temporary table creation, with the new schema, and copy the existing data into it as it goes - then switch the tables around after it's done.
On top of that, consider also that the setup may not only require 2x the space (for the old and new tables) but potentially a third copy, and while it's doing all that file I/O, it is hampering the possibly DB queries it could be serving instead, so doing it once if possible is much more efficient in the long run.
Anyway, that's where I'm up to with it so far, and I'm planning on building a few very simple demo plugins, not so much for download and distribution (after all, they won't be any use to you without Wedge!) but for those with access to the source to see how they work and all the stuff that goes on, because there is a lot of it behind the scenes.
| 1. | It won't add or change primary or unique keys. If you ever need to do that for any reason, apart from the fact it generally means your design was flawed... do it in the enable script, that's partly what it's there for. |
6367
Off-topic / Re: I am looking for a favour
« on September 19th, 2011, 12:26 AM »
It's probably more logical than English grammar, which even though I'm a native speaker, and am considered above average in terms of my language comprehension and precision, I still have trouble with...
I should add that my knowledge of non-English languages is prejudiced, I studied French and briefly Spanish in school, and since then I've replaced whatever I knew about those with programming languages...[1]
I should add that my knowledge of non-English languages is prejudiced, I studied French and briefly Spanish in school, and since then I've replaced whatever I knew about those with programming languages...[1]
| 1. | Even there, PHP's grammar is consistent, but its verb conjugation makes English look good. I mean, str_* functions are so mindnumbingly inconsistent that very occasionally I have to look one up to figure out whether it's str_ or str, or which order it wants parameters in. Not often, mind, because I use them all pretty regularly, but just once in a blue moon... |
6368
Features / Re: New revs - Public comments
« on September 19th, 2011, 12:03 AM »
It's a tricky one because there's pros and cons both ways.
In other news, would it be worth writing a post detailing exactly what the add-on manager does and all its overall mechanics? (Most of it, an add-on author shouldn't need to worry about anyway, but just in case, do you think it'd be useful?)
In other news, would it be worth writing a post detailing exactly what the add-on manager does and all its overall mechanics? (Most of it, an add-on author shouldn't need to worry about anyway, but just in case, do you think it'd be useful?)
6369
Features / Re: New revs - Public comments
« on September 18th, 2011, 09:42 PM »
No, it's likely it will be used in the manner I describe. I did, before, get into the realm of physically registering hooks but I found cases where it could go badly wrong if something was set to disable and it actually didn't.
I take your point about categories, I just think it would be more consistent as cat= rather than an action, but that it would have an impact on index, even though it can be downplayed to check if action is unspecified and only after board and topic have been tested for.
@Aaron, I tried to do that but was not having a lot of luck with it.
I take your point about categories, I just think it would be more consistent as cat= rather than an action, but that it would have an impact on index, even though it can be downplayed to check if action is unspecified and only after board and topic have been tested for.
@Aaron, I tried to do that but was not having a lot of luck with it.
6370
Features / Re: New revs - Public comments
« on September 18th, 2011, 06:41 PM »
Re 1006, yes, I think it would be nice to limit category viewing to a single category if desired, e.g. index.php?cat=1 to show just that category, with action=boards showing all of them.
6371
Features / Re: New revs - Public comments
« on September 18th, 2011, 06:28 PM »but is it needed? Didn't Wedge already load the hook list somewhere else..?
And if an add-on is bad, you can just delete or rename its folder and it'll deactivate it safely.
6372
Features / Re: New revs - Public comments
« on September 18th, 2011, 05:58 PM »
Let's say we want to offer page= as an option in the URL, like topic and board. Ae you saying that during the behaviour hook, they should just proceed to make the test and force it to their action if found? Seems a bit ugly to me, though it's the most workable compromise.
The fallback action really should be left though, otherwise if an invalid action is specified, you are doomed to go to the board index. Assuming your default will be applied in both places, I guess that's OK, but it does mean that an add-on actually has to do some work if it actually wants to be the front page, because it has no other way of overriding the admin's choice other than fudging the modSettings value softly, as opposed to setting up a hook. (And the same issue about contention applies, only worse because there's more places that add-ons can affect that value rather than centrally)
The fallback action really should be left though, otherwise if an invalid action is specified, you are doomed to go to the board index. Assuming your default will be applied in both places, I guess that's OK, but it does mean that an add-on actually has to do some work if it actually wants to be the front page, because it has no other way of overriding the admin's choice other than fudging the modSettings value softly, as opposed to setting up a hook. (And the same issue about contention applies, only worse because there's more places that add-ons can affect that value rather than centrally)
6373
Features / Re: New revs - Public comments
« on September 18th, 2011, 05:26 PM »
It is pretty funny, actually, though we had briefly mentioned the idea before.
OK, so what's the difference between the two hooks? It's really for portals more than anything. One path is what to do if no action is specified (check for board and topic, and indeed anything else that might be specified by URL without expressly being action=something, like SP does with pages)
The second path is for actions that are requested but don't exist, so that you always get back to *something*. WedgeDesk expressly uses both hooks, though it runs the same function either way, because of its standalone mode that removes actions.
My version wasn't really designed with the goal of allowing a board to be loaded by default, it was designed so that any add-on that could override the default action can actually do so.
Pushing the board index to its own action is a good idea (though that does mean other things do have to be fixed, I have a list somewhere of URLs that expect index.php to be the board index) and I think it would be nice for admins to be able to set a default action, so ultimately from mu POV, having both would be great, provided that add-ons can if necessary override that behaviour, which is what the hooks allow for.
You mention doing it through blocks but for the specific uses I have (and I can find other more general cases), this isn't enough. WD's case is unusual but follows the pattern of all the portals where it replaces the board index entirely under some circumstances, in particular standalone mode which means to disable the forum entirely and just use WD code - having the board index is not merely inaccurate and superfluous, it's completely undesirable.
I also doubt that most admins will develop add-ons, but that one will exist that they'll use to perform that task, and I'll likely write it...
As far as conflicts go in terms of which add-on gets priority, I'm not expecting that to be a huge problem in most cases, simply because most of the time it actually won't matter. But a priority value might make sense to implement to deal with that, though that also has implications, e.g. authors blilndy setting max priority all the time. That part is still a WIP really.
OK, so what's the difference between the two hooks? It's really for portals more than anything. One path is what to do if no action is specified (check for board and topic, and indeed anything else that might be specified by URL without expressly being action=something, like SP does with pages)
The second path is for actions that are requested but don't exist, so that you always get back to *something*. WedgeDesk expressly uses both hooks, though it runs the same function either way, because of its standalone mode that removes actions.
My version wasn't really designed with the goal of allowing a board to be loaded by default, it was designed so that any add-on that could override the default action can actually do so.
Pushing the board index to its own action is a good idea (though that does mean other things do have to be fixed, I have a list somewhere of URLs that expect index.php to be the board index) and I think it would be nice for admins to be able to set a default action, so ultimately from mu POV, having both would be great, provided that add-ons can if necessary override that behaviour, which is what the hooks allow for.
You mention doing it through blocks but for the specific uses I have (and I can find other more general cases), this isn't enough. WD's case is unusual but follows the pattern of all the portals where it replaces the board index entirely under some circumstances, in particular standalone mode which means to disable the forum entirely and just use WD code - having the board index is not merely inaccurate and superfluous, it's completely undesirable.
I also doubt that most admins will develop add-ons, but that one will exist that they'll use to perform that task, and I'll likely write it...
As far as conflicts go in terms of which add-on gets priority, I'm not expecting that to be a huge problem in most cases, simply because most of the time it actually won't matter. But a priority value might make sense to implement to deal with that, though that also has implications, e.g. authors blilndy setting max priority all the time. That part is still a WIP really.
6374
Features / Re: New revs - Public comments
« on September 18th, 2011, 04:42 PM »
OK, neither of those changes were supposed to be committed. I have to use 127.0.0.1 instead of localhost to avoid a 1 second lookup on every single page to resolve the domain name in MySQL. Never understood why, just that since using WampServer, that's been the case.
As for smf/wedge, that is my boardurl, and when I was messing around trying to debug the above, I set that and forgot to revert it.
The main reason for ucfirst, as far as I can tell, is simply to indicate importance on folders that shouldn't be writable by defaults (notice that avatars and attachments are, but everything else isn't) but I have no reason to leave it as is, it's cool to change it.
This isn't finished, btw. It's a milestone that I consider practical for committing, as in the first usable version. There's plenty more to do but it is usable for activating add-ons even in its present form, and the bulk of add-ons shouldn't need much more than this anyway.
As for smf/wedge, that is my boardurl, and when I was messing around trying to debug the above, I set that and forgot to revert it.
The main reason for ucfirst, as far as I can tell, is simply to indicate importance on folders that shouldn't be writable by defaults (notice that avatars and attachments are, but everything else isn't) but I have no reason to leave it as is, it's cool to change it.
This isn't finished, btw. It's a milestone that I consider practical for committing, as in the first usable version. There's plenty more to do but it is usable for activating add-ons even in its present form, and the bulk of add-ons shouldn't need much more than this anyway.
6375
Features / Re: New revs
« on September 18th, 2011, 02:44 PM »
(Added:6 Deleted:2 Modified:33, 119KB)
Revision: 1006
Author: arantor
Date: 13:41:10, 18 September 2011
Message:
+ First usable build of the add-on manager. This has many related changes:
+ Actually add the folder. Includes a default htaccess file to block archives from being downloaded from there but potentially all other files might be. (Addons/*)
+ Add the add-on manager. (ManageAddons.*, replacing switch_on.png and switch_off.png with smaller sized images)
! create_table can now add columns and indexes (but not unique or primary indexes) if the table already exists when passed to this function. It also has rudimentary support for new datatypes, namely the floating types (float, real, double) and SET and ENUM, but this isn't properly tested and is likely buggy. (Class-DBPackages.php)
! Attempt to detect if an add-on caused an error and set the error type accordingly. (Doesn't bother to attempt to change the label to just the mod's name or similar, just attempts to locate and update for now) (Errors.php)
! Menu changes for the add-on manager. Some of this is temporary code and it leaves the old package manager available for testing with a naughty non-language-string entry. As Wedge's add-on manager matures this won't be a problem. (Admin.php, Admin.english.php, PackageGet.php, Packages.php, index language file)
! Added a setting for setting the path and URL to the Addons area. (Settings.php, install.php, ManageServer.php, Admin language file)
! Removed Modifications language file (Modifications language file, index.php, SSI.php, Load.php)
! On startup, identify the add-ons currently enabled and add their hooks into the current process' stack, as well as making sure we have the paths and URLs to these for later. (Load.php)
! Language editor can now load the language strings of add-ons and access them directly, much as SD 2.0 does. (ManageServer.php, Admin.template.php)
! New hook loader purely for language files (Subs.php)
! New hooks. (Profile-View.php, Subs-BBC.php, Subs-BoardIndex.php, Who.php (lang only), SSI.php, index.php)
! Make sure that hooked files in loaders are loaded correctly. (Profile.php, ScheduledTasks.php, Subs-Template.php, Subs.php)
! Provide facilities for add-ons to declare CSS and JS to be cached through the caching subsystem. (Subs-Cache.php)
! If icons in menu items are full URLs, don't touch them, useful for add-ons. (Subs-Menu.php)
@ This isn't even complete, there are multiple known items still to do:
- The DB changer in the add-on area cannot add columns to existing non-add-on tables (e.g. new column in members table), nor can it add indexes. Also needs more testing anyway.
- The DB changer also does not run any enable-time scripts (nor disable-time scripts, for that matter)
- There's no ability to upload new add-ons, nor any ability to remove any existing ones (including clean-up)
- Dependency management isn't accounted for either.
- The exact process for updating a given add-on is also to be figured out and implemented. I'm thinking it would actually be a process of unpacking the new one into a new folder, disabling the old one, enabling the new one if possible, then removing the old one. Proper in-place updating is a road to madness.
- File edits need to be accounted for.
- Oh, and permission handling both in terms of permissions being required to enable an add-on (e.g. 'this add-on makes file edits, proceed?') and for when file edits are used, permissions on files, preferably ones that won't screw up a lot of servers.
----
Added : /trunk/Addons
Added : /trunk/Addons/.htaccess
Added : /trunk/Addons/index.php
Modified : /trunk/SSI.php
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/Class-DBPackages.php
Modified : /trunk/Sources/Errors.php
Modified : /trunk/Sources/Load.php
Added : /trunk/Sources/ManageAddons.php
Modified : /trunk/Sources/ManageServer.php
Modified : /trunk/Sources/PackageGet.php
Modified : /trunk/Sources/Packages.php
Modified : /trunk/Sources/Profile-View.php
Modified : /trunk/Sources/Profile.php
Modified : /trunk/Sources/ScheduledTasks.php
Modified : /trunk/Sources/Subs-BBC.php
Modified : /trunk/Sources/Subs-BoardIndex.php
Modified : /trunk/Sources/Subs-Cache.php
Modified : /trunk/Sources/Subs-Menu.php
Modified : /trunk/Sources/Subs-Template.php
Modified : /trunk/Sources/Subs.php
Modified : /trunk/Sources/Who.php
Modified : /trunk/Themes/default/Admin.template.php
Added : /trunk/Themes/default/ManageAddons.template.php
Modified : /trunk/Themes/default/images/admin/switch_off.png
Modified : /trunk/Themes/default/images/admin/switch_on.png
Modified : /trunk/Themes/default/languages/Admin.english.php
Added : /trunk/Themes/default/languages/ManageAddons.english.php
Modified : /trunk/Themes/default/languages/ManageMedia.english.php
Deleted : /trunk/Themes/default/languages/Modifications.english.php
Deleted : /trunk/Themes/default/languages/Modifications.french.php
Modified : /trunk/Themes/default/languages/index.english.php
Modified : /trunk/Themes/default/languages/index.french.php
Modified : /trunk/Themes/default/skins/admin.css
Modified : /trunk/index.php
Modified : /trunk/other/Settings.php
Modified : /trunk/other/Settings_bak.php
Modified : /trunk/other/install.php
Modified : /trunk/other/install.sql
Modified : /trunk/other/tools/wedge_api.php
Modified : /trunk/other/xml/detailed-version.php
Forgot to add that there's also the loadAddon functions in Load.php now that are used for loading add-on source, template and language files as needed.
Oh, and also note that the create_table version here also fixes an SMF bug whereby the default value of a column isn't determined correctly for a pre-existing table.
Revision: 1006
Author: arantor
Date: 13:41:10, 18 September 2011
Message:
+ First usable build of the add-on manager. This has many related changes:
+ Actually add the folder. Includes a default htaccess file to block archives from being downloaded from there but potentially all other files might be. (Addons/*)
+ Add the add-on manager. (ManageAddons.*, replacing switch_on.png and switch_off.png with smaller sized images)
! create_table can now add columns and indexes (but not unique or primary indexes) if the table already exists when passed to this function. It also has rudimentary support for new datatypes, namely the floating types (float, real, double) and SET and ENUM, but this isn't properly tested and is likely buggy. (Class-DBPackages.php)
! Attempt to detect if an add-on caused an error and set the error type accordingly. (Doesn't bother to attempt to change the label to just the mod's name or similar, just attempts to locate and update for now) (Errors.php)
! Menu changes for the add-on manager. Some of this is temporary code and it leaves the old package manager available for testing with a naughty non-language-string entry. As Wedge's add-on manager matures this won't be a problem. (Admin.php, Admin.english.php, PackageGet.php, Packages.php, index language file)
! Added a setting for setting the path and URL to the Addons area. (Settings.php, install.php, ManageServer.php, Admin language file)
! Removed Modifications language file (Modifications language file, index.php, SSI.php, Load.php)
! On startup, identify the add-ons currently enabled and add their hooks into the current process' stack, as well as making sure we have the paths and URLs to these for later. (Load.php)
! Language editor can now load the language strings of add-ons and access them directly, much as SD 2.0 does. (ManageServer.php, Admin.template.php)
! New hook loader purely for language files (Subs.php)
! New hooks. (Profile-View.php, Subs-BBC.php, Subs-BoardIndex.php, Who.php (lang only), SSI.php, index.php)
! Make sure that hooked files in loaders are loaded correctly. (Profile.php, ScheduledTasks.php, Subs-Template.php, Subs.php)
! Provide facilities for add-ons to declare CSS and JS to be cached through the caching subsystem. (Subs-Cache.php)
! If icons in menu items are full URLs, don't touch them, useful for add-ons. (Subs-Menu.php)
@ This isn't even complete, there are multiple known items still to do:
- The DB changer in the add-on area cannot add columns to existing non-add-on tables (e.g. new column in members table), nor can it add indexes. Also needs more testing anyway.
- The DB changer also does not run any enable-time scripts (nor disable-time scripts, for that matter)
- There's no ability to upload new add-ons, nor any ability to remove any existing ones (including clean-up)
- Dependency management isn't accounted for either.
- The exact process for updating a given add-on is also to be figured out and implemented. I'm thinking it would actually be a process of unpacking the new one into a new folder, disabling the old one, enabling the new one if possible, then removing the old one. Proper in-place updating is a road to madness.
- File edits need to be accounted for.
- Oh, and permission handling both in terms of permissions being required to enable an add-on (e.g. 'this add-on makes file edits, proceed?') and for when file edits are used, permissions on files, preferably ones that won't screw up a lot of servers.
----
Added : /trunk/Addons
Added : /trunk/Addons/.htaccess
Added : /trunk/Addons/index.php
Modified : /trunk/SSI.php
Modified : /trunk/Sources/Admin.php
Modified : /trunk/Sources/Class-DBPackages.php
Modified : /trunk/Sources/Errors.php
Modified : /trunk/Sources/Load.php
Added : /trunk/Sources/ManageAddons.php
Modified : /trunk/Sources/ManageServer.php
Modified : /trunk/Sources/PackageGet.php
Modified : /trunk/Sources/Packages.php
Modified : /trunk/Sources/Profile-View.php
Modified : /trunk/Sources/Profile.php
Modified : /trunk/Sources/ScheduledTasks.php
Modified : /trunk/Sources/Subs-BBC.php
Modified : /trunk/Sources/Subs-BoardIndex.php
Modified : /trunk/Sources/Subs-Cache.php
Modified : /trunk/Sources/Subs-Menu.php
Modified : /trunk/Sources/Subs-Template.php
Modified : /trunk/Sources/Subs.php
Modified : /trunk/Sources/Who.php
Modified : /trunk/Themes/default/Admin.template.php
Added : /trunk/Themes/default/ManageAddons.template.php
Modified : /trunk/Themes/default/images/admin/switch_off.png
Modified : /trunk/Themes/default/images/admin/switch_on.png
Modified : /trunk/Themes/default/languages/Admin.english.php
Added : /trunk/Themes/default/languages/ManageAddons.english.php
Modified : /trunk/Themes/default/languages/ManageMedia.english.php
Deleted : /trunk/Themes/default/languages/Modifications.english.php
Deleted : /trunk/Themes/default/languages/Modifications.french.php
Modified : /trunk/Themes/default/languages/index.english.php
Modified : /trunk/Themes/default/languages/index.french.php
Modified : /trunk/Themes/default/skins/admin.css
Modified : /trunk/index.php
Modified : /trunk/other/Settings.php
Modified : /trunk/other/Settings_bak.php
Modified : /trunk/other/install.php
Modified : /trunk/other/install.sql
Modified : /trunk/other/tools/wedge_api.php
Modified : /trunk/other/xml/detailed-version.php
Posted: September 18th, 2011, 02:43 PM
Forgot to add that there's also the loadAddon functions in Load.php now that are used for loading add-on source, template and language files as needed.
Posted: September 18th, 2011, 02:43 PM
Oh, and also note that the create_table version here also fixes an SMF bug whereby the default value of a column isn't determined correctly for a pre-existing table.