Hi Brad,

1. The Addon key is used in several places to isolate an addon from the core. In the data model there are already provisions to regulate the availability of addons per portal. The key ties everything together into one logical whole. In the end it became logical to treat the core DMX as an entity as well in this respect, hence the name 'Core'. Best practice is to define your own key if you start adding your own ascx files and processing that need to integrate with DMX.

2. The addons I make have an SqlDataProvider script with them that add extensions to the db. You will also need to add your own trigger to make sure it is added to other portals when they are created. Note that this is not the most 'pretty' solution, but the only one available. You can see this in the PDFViewer addon. I hope the core team will implement the interface I requested so that a module can 'react' to core events (like 'new portal created').

3. Naming: Call your extension 'Custom.Collection.Something' and it will appear in the dropdown. Further tuning can be achieved by using the AccessRights field. This is a semicolon separated list of role id's. Note there is a difficulty with the trigger: when a new portal is created the admin and reg user roles are not yet defined. '-1' will always work as it is a default role id.

Check the sql for the PDF viewer. It does more or less the same. The script does (1) add a trigger, and (2) add to existing portals. Note that if your trigger is faulty, it will prevent a portal from being created (SQL will not return a result for AddPortal and DNN will exit with an error)

Peter

Peter