This information builds on the blog post, "Integrating an Application without a Front-End Controller into Mura CMS." The next step is to take that integrated app and turn it into a Mura plugin.

• Creating a plugin makes the app available to all sites within a Mura instance rather than having it only available to just the one site where the app resides (i.e. one set of code being used across multiple sites vs one set of code being used for one site).
• Creating a plugin allows admin users to easily insert the app as a content object rather than using dspInclude.
• There's no memory hit making a plugin as opposed to using dspInclude.

Note: Rule of thumb for deciding whether an application should be made into a plugin is to ask, "Does it need to be re-usable for other sites?" If you find yourself integrating the same app over and over again on different sites, it may make a good candidate for a Mura plugin.

Creating the Plugin

Make a Copy of the App

Copy the [siteID]/includes/display_objects/myapp directory (created in this blog post) and save it to your desktop or other desired location.

Setup the Plugin Directory

Download the Hello World example plugin from getmura.com (download link is at the bottom of that page) We will be using some of the files as "Starter Code."

Copy the "plugin" directory from the Hello World example plugin and paste it into the myapp folder. The "plugin" folder is the plugin config folder. It contains files Mura uses to install the plugin.

Edit the config.xml file

Open the config.xml file in your favorite editor. This file contains settings for the plugin in xml format. Carefully edit these settings to reflect the new "myapp" plugin:

• <name> - the human readable name of the plugin. Change this to "MyApp" (or whatever name you happen to prefer).
• <package> - A new directory is created for each plugin when it is installed. The package name becomes the first element of the new plugin directory name. More importantly, the package name becomes a mapping by which the plugin can then be referenced.
• <version> - is the version number of the plugin - - set it to 1.0 for now.
• <loadPriority> - The load priority makes it possible to dictate which plugins get loaded before other plugins. This can come in handy if you create suites of plugins that depend on each other. The setting is new as of Mura 5.2 so you may need to add it to the config.xml
• <provider> - Whoever is providing the plugin.
• <providerURL> - The URL of the provider website.
• <category> - The type of plugin (arbitrary for now).
• <settings> - Settings define customizable inputs or requirements for the plugin. Since, in this case, there will be no need for any settings, replace all the settings elements with "<settings/>"
• <eventHandlers> - Event Handlers are a way to map components to events. (For more information on Mapping Events in Mura see: http://www.getmura.com/index.cfm/blog/mapping-events-in-mura/ ) Since this plugin example will not be using event handlers, replace all the eventHandlers elements with "<eventHandlers/>"

The <displayobjects> Element

The displayobjects element tells Mura what display objects the plugin is making available. It has one setting (location=global or location=local). This setting only executes when it pertains to a plugin display object.

Note: When a plugin is installed in a Mura instance, it can be assigned to multiple sites within that one instance. If these sites each have dramatically different interfaces, you can set the plugin displayobjects location to "local" (<displayobjects location="local"> ) and the plugin is installed, Mura will copy the plugin files to the local plugin folder of each site it is assigned to and run just the display objects from there. The benefit of this is that you can custom skin each display object on a per site basis after the plugin has been deployed. If interface customization is not needed, leave the plugin displayobjects location set to "global" (<displayobjects location="global"> )

<displayobject>

The <displayobject> element (inside the displayobjects collection element) gives each plugin display object a name and tells Mura where, based off the root of the plugin, to find the file for that particular display object. (You can have multiple display objects.) This file can be a regular .cfm file or a .cfc.

Example:

<displayobjects location="global">
<displayobject name="MyApp (cfc) " displaymethod="theMethod" component="app" persist="false"/>
<displayobject name="MyApp (cfm)" displayobjectfile="app.cfm"/>
</displayobjects>

In the previously integrated application, the index.cfm file handled all the display via a simple cfswitch. Since plugins use the index.cfm as an internal landing page in the Mura Admin Plugin Manager, rename the myapp index.cfm to app.cfm and set the displayobject element as follows:

<displayobjects location="global">
<displayobject name="Main Application" displayobjectfile="app.cfm"/>
</displayobjects>

Add a Plugin index.cfm

As mentioned above, plugins use an index.cfm as an internal landing page in the Mura Admin Plugin Manager. After you have renamed the original myapp index.cfm to app.cfm, copy the index.cfm from the "Hello World" plugin and paste it into the new "myapp" folder. Open the file in your favorite editor.

Notice that the index.cfm includes the config.cfm located in the plugin folder:

<cfinclude template="plugin/config.cfm" />

Including the config.cfm makes sure a config exists and will also redirect anyone away from the Mura Admin if they try to access the plugin landing page without being logged in as an Administrator.

Next add a description of the plugin, or some simple instructions to the cfsavecontent cfoutput area.

Note: You could also use the plugin index.cfm to add a full blown application if necessary.

The renderAdminTemplate() variable

The renderAdminTemplate() variable renders the plugin landing page content inside the Mura admin template providing a consistent admin look and feel for the user. Besides the "body" and "pageTitle" arguments, there is a third argument for specifying a js library. If not set, this currently defaults to the prototype library.

Note: If you're going to require jquery or prototype, go ahead and include the argument because Mura will eventually be switching the default js library to jquery.

Edit the plugin.cfc

The plugin/plugin.cfc file contains different methods that allow you to run code as needed whenever the plugin is installed, updated or deleted. For example, on install you could run a script that creates some needed database tables while, on delete it would run a script that would delete all the database tables that had been previously created for that plugin. On update might run a script that rolls out any database changes that need to happen when a new version of the plugin is installed.

In case of this example, these methods are not needed. Change the cfcomponent tag so that it reads:

<cfcomponent output="false" extends="mura.plugin.plugincfc">

Delete all the methods since they will not be needed, but leave the component tag so the component can still be found by Mura.

Edit the App Files

Now, rename the myapp Application.cfm to settings.cfm, then open the app.cfm file and change the first include to reflect the new file name:

<cfinclude template="settings.cfm">

Note: This is necessary because the plugins folder is a top level (above siteID level) directory, and any application.cfm there will be run, creating a new application space and causing the plugin to throw application errors.

Zip & Deploy

You are now ready to zip up all the files located WITHIN the new "myapp" directory. (do NOT include the "myapp" directory itself) then install the new plugin. Once it has been installed, click on the plugin name in the Plugins Manager to view the plugin landing page (the new index.cfm). Insert the plugin display object into a content page to view and test.