The Developer Center for each application and plugin is designed to be a tool that facilitates creating and updating applications and plugins for the Invision Community software. It can help you automatically track things such as settings, database changes, tasks, and more. While most of the functionality available through the developer center can be bypassed by adjusting your files directly on disk, we strongly encourage you to make use of the developer center whenever possible to minimize development time as well as potential for bugs in your third party code.
Because the needs for an application versus a plugin are different, the Developer Center for each is different.
The Developer Center for each application allows you to manage several aspects of the application and facilitates creating upgrade routines and managing versions easily. We will run through each tab in the Developer Center to outline what can be done.
Modules - Front
The front modules tab allows you to create new front modules, which correspond to folders underneath applications/(your-application)/modules/front/ . Once you have created a front module, you can then create one or more controllers underneath it, and you can define which module is the default front module (i.e. if you visit index.php?app=(your-application) which module should be loaded), as well as which controller is the default within each module. You can also edit and delete modules and controllers here.
Modules - Admin
Just like with the front modules, you can manage your admin modules from the Developer Center. The behavior of this tab is very similar to the front modules tab, with one key (and important) difference: when you create controllers, you can simultaneously create menu entries, ACP restrictions, and you can use one of three templates for the controller itself (a normal controller, a table helper controller, or a node controller). If the controller will be a node controller (i.e. a page to allow you to manage categories which you intend to use the Node functionality for), then you should use the node controller template. Similarly, if you intend to output a table of data (like the member list, or the system logs) then you should use the table helper controller template.
Very simply, the settings tab allows you to add new settings and to define their default values. These settings will then be tracked in a settings.json file within your application's data/ folder, and when administrators install your application the setting records will be installed as well. You will still need to create one or more controllers to present the settings to the administrator so that the administrator can adjust the values, as appropriate.
You can use the tasks tab to add any tasks that are required by your application. You will define a 'key' which will be used as the filename, and how often the task should run, and then a skeleton file will be created in your applications/(your-application)/tasks/ folder for you automatically, ready for you to complete. Your tasks will also be tracked in a tasks.json file (within your application's data/ folder) and automatically inserted into the software when your application is installed.
With a brand new application you will see two records automatically on the versions tab: install, which represents installation of your application, and working, which represents the current unreleased version (you do not define a version number until you are ready to release your application, even for subsequent update releases). Typically, you will not need to define any database changes here. When you make changes under the Database Schema tab (see below), the SQL changes are automatically tracked for both installations and for the latest release. However, if you are updating your application from 3.x for 4.x you may need to manually define queries to run during an upgrade, or if you are adjusting database tables outside of your application you will need to manually define those changes here.
You can also add and remove upgrade routines and manual queries for older versions from this page if needed.
If you are creating an upgrade release which requires executing more code than a simple database query, you can click the </> code icon for the "working" version which will create an upgrade.php file in your application's setup/upg_working/ directory. You can then open this file and follow the instructions in the file to create upgrade steps that perform more work than simply executing database queries.
You can read more about versioning for applications in the Versions/Upgrading article.
If your application defines any sidebar widgets, you can define them from the Developer Center of your application. When you add a widget for your application, you will define a widget key and specify which widget class your widget extends (which provides certain automatic functionality, such as caching the widget based on permissions if necessary). You can specify if your widget is available in the sidebar and/or within the Pages application for use on pages, you can specify whether your widget should display within your application by default out of the box, choose which style of configuration form to use (menu or popup modal), and determine if the widget can be used more than once on the same page. Upon saving the form, a skeleton template will be written to applications/(your-application)/widgets/ which you will need to adjust as appropriate and the widget will be tracked in /data/widgets.json for installations and upgrades of your application.
Applications, like plugins, can define hooks which are essentially a way to override how default code within the Suite behaves. You can read more about code hooks and theme hooks in the respective articles.
Extensions allow you to perform actions at certain points during normal code execution without having to "hook" into the code execution directly. There are many different types of extensions within the Suite. To create a new extension for your application, under the Extensions tab you expand the application that holds the extension you want to create (typically core or nexus), and then click on the + icon next to that extension type. A skeleton file will be written to your application's extensions/(app)/(extension)/ directory for you.
If your application wishes to define its own extensions that other applications can generate, underneath your application's data/ folder you will need to create a folder defaults/ and underneath this folder create a folder named extensions. Within this folder, you create your extension templates which end with a .txt extension, instead of a .php extension. You can see examples within the developer tools for the core application. It is then your responsibility to call the extension during code execution as needed. It is relatively uncommon that a third party application would need to leverage this capability.
Whenever you need to add new database tables or adjust existing database tables for your application you should always do this under the Database Schema tab within your application's Developer Center. Not only will your changes be ran on your database automatically for you immediately, they will be tracked and automatically executed during both installations and upgrades of your application. You can add, edit and delete database tables, columns, indexes and default inserts for these tables from this area of the Developer Center through a simple to use GUI.
Admin CP Restrictions
This tab of the Developer Center allows you to define Admin CP Restrictions, which you can then check in your code to determine if the currently logged in administrator has permission to perform the action they are attempting to perform. There is no technical requirement to use Admin CP Restrictions, however it is strongly encouraged that you do so when your application provides various different functionality. For example, if your application can allow administrators to add content, and to view reporting statistics, a website may wish to allow one group of administrators permission to do everything and another group of administrators only permission to view the statistics. You can accomplish this easily by defining these restrictions in the Developer Center, and then checking the restrictions in your code.
Restrictions are tied to a module, so you will first need to create an admin module (and you can automatically create a basic restriction during this process). If your module handles viewing, adding, editing and deleting within one module (as an example), however, you may wish to create additional restrictions from the Admin CP Restrictions tab and then adjusting your controllers to check the appropriate restriction when the administrator attempts to perform that specific action.
Note, also, that you will want to create language strings for each restriction group and each restriction that is listed on this page, as the language strings will be used in the Admin CP Restrictions area of the AdminCP. If you created a restriction "myappview", then the language key you will want to set will be "r__myappview" for the group, and "r__myappview_manage" (by default, unless you delete this restriction) for the restriction itself.
Admin CP Menu
The Admin CP Menu tab allows you to manage your links in the AdminCP Menu and relates to the data/acpmenu.json file for your application. You will create new AdminCP Menu entries automatically when adding admin modules (if you choose to do so), however you can also edit this file manually to customize the menu further if needed.
If you wish to locate a menu entry (or multiple entries) underneath the statistics tab, you will need to use the top level tab "stats".
The only Developer Center tab for plugins that does not exist for applications is the 'Information' tab, which allows you to adjust the information about your plugin (the author, the plugin name, and so on). The remainder of the tabs are identical to those for applications, and serve the same purpose. You can learn more about plugins and how to use them in our Plugins developer documentation.