NAME
MT::App::CMS
SYNOPSIS
The application-level callbacks of the MT::App::CMS application are documented here.
CUSTOM REBUILD OPTIONS
The pop-up rebuild dialog that you see in Movable Type has a drop-down list of rebuild options. This list can be populated with custom options provided through a plugin. For example, a plugin might want to provide the user with an option to rebuild a template identified for creating author archives.
$app->add_rebuild_option(\%param)
- label
- The label to display in the list of rebuild options.
- code
- The code to execute when running the custom rebuild option.
- key
- An identifier unique to this option (optional, will derive from the label if unavailable).
In addition to this application method,
there is also a RebuildOptions callback that can be used to further customize the list of extra rebuild options.
This callback is useful when needing to add items to the list that are unique to the active user or weblog.
CALLBACKS
- RebuildOptions
- The RebuildOptions callback provides control over an array of additional custom rebuild options that are displayed in MT's rebuild window. The array is populated with hashrefs, each containing:
- code
- The code to execute when running the custom rebuild option.
- label
- The label to display in the list of rebuild options.
- key
- An identifier unique to this option (optional, will derive from the label if unavailable).
- CMSPostSave.entry
- Called when an entry has been saved, after all of its constituent parts (for example, category placements) have been saved. An CMSPostEntrySave callback would have the following signature:
callback($eh, $app, \@options)
sub cms_post_entry_save($eh, $app, $entry, $original)
{
...
}
For backward compatibility, CMSPostEntrySave and AppPostEntrySave are aliases to CMSPostSave.entry.
Parametric Calllbacks
Every object "type" has a suite of callbacks defined for that type, as below. Each item in the list below forms a callback name by appending the object "type" after an underscore, e.g. CMSViewPermissionFilter_blog, CMSPostSave_template, etc. The "type" values come from the same space as passed to the CMS app's _type query parameter. If you're not sure what _type corresponds to a certain MT::Object subclass, consult the following list:
- author => MT::Author
- comment => MT::Comment
- entry => MT::Entry
- template => MT::Template
- blog => MT::Blog
- notification => MT::Notification
- templatemap => MT::TemplateMap
- category => MT::Category
- banlist => MT::IPBanList
- ping => MT::TBPing
- ping_cat => MT::TBPing
Callbacks that apply to these object types are as follows:
- CMSViewPermissionFilter
- Calling convention is:
- Where
$idis the ID of an object, if it already exists, orundefif the user will be creating a new object of this type. $obj_promiseis a promise for the object itself. You can use$obj_promise-force> to get ahold of the object, if you need it, but typically you won't need it. (See MT::Promise)- Return a false value to abort the operation and display a message to the user that s/he doesn't have permission to view the object.
- CMSDeletePermissionFilter
- CMSSavePermissionFilter
- Calling convention is:
- Where
$idis the ID of the object, if it already exists, orundefif it is a new object with this request. - Note that at this point, the object may not yet exist. The request can be understood through the query parameters of the app, accessible through
$app->param(). ACMSSavePermissionFiltercallback should be "safe"--it should not modify the database. - Return a false value to abort the operation and display a message to the user that s/he doesn't have permission to modify the object. The method is not called if the acting user is a superuser.
- CMSSaveFilter
- This callback gives you the chance to "decline" for reasons other than lack of permissions.
- The routine is called as follows:
- Returning a false value will decline the request. It is advisibable to return an error via the
$ehobject in order to signal to the user what went wrong. - Note that the new object has not been constructed yet. The operation can be understood by examining the
$appobject's query parameters via$app->param() - A
CMSSaveFiltercallback should be "safe"--it should not modify the database. - CMSPreSave
$objand$originalhold the object which is about to be saved, and the object as it was when this request began, respectively. This allows the callback to determine what kind of changes are being attempted in the user's request. If the request is to create a new object, $original will be a valid object reference, but the object will be "blank": it will be just what is returned by thenewmethod on that class.- CMSPostSave
$objand$originalhold the object which is about to be saved, and the object as it was when this request began, respectively. When the callback routine is called, the new object as$objhas already been committed to the database. This is a convenient time to trigger follow-up actions, such as notification and static-page rebuilds.- CMSPostDelete
$objholds the object that has just been removed from the database. This callback is useful when removing data that is associated with the object being removed.- CMSUploadFile
- This callback is invoked for each file the user uploads to the weblog. It is called for each file, regardless of type. If the user uploads an image, both the
CMSUploadFileandCMSUploadImagecallbacks are invoked.
callback($eh, $app, $id, $obj_promise)
callback($eh, $app, $obj)
callback($eh, $app, $id)
callback($eh, $app)
callback($eh, $app, $obj, $original)
callback($eh, $app, $obj, $original)
callback($eh, $app, $obj)
callback($eh, %params)
Parameters
- File
- Url
- Size
- Type
- Blog
The full file path of the file that has been saved into the weblog.
The URL of the file that has been saved into the weblog.
The length of the file in bytes.
Either 'image', 'file' or 'thumbnail'.
The MT::Blog object the uploaded file is associated with.
- CMSUploadImage
- This callback is invoked for each uploaded image. In the case the user creates a thumbnail for their uploaded image, this callback will be invoked twice-- once for the uploaded original image and a second time for the thumbnail that was generated for it.
- File
- Url
- Size
- Type
- Height
- Width
- ImageType
- Blog
callback($eh, %params)
The full path and filename for the uploaded file.
The full URL for the uploaded file.
The length of the uploaded image in bytes.
Either "image" or "thumbnail" (for generated thumbnails).
The height of the image in pixels (available if Image::Size module is present).
The width of the image in pixels (available if Image::Size module is present).
The image identifier as reported by the Image::Size module. Typically, 'GIF', 'JPG' or 'PNG'.
The MT::Blog object of the weblog the image is associated with.
POD ERRORS
Hey! The above document had some coding errors, which are explained below:
- Around line 9986:
- You forgot a '=back' before '=head3'
- Around line 10012:
- '=item' outside of any '=over'
