Not a developer? Go to


Page Actions

Page Actions

Page actions are links that can be registered by plugins to appear in the sidebar of virtually any page in Movable Type. Page actions provide an easy way for plugins to augment the HTML of the page to surface the ability for users to perform some action in relation to the content on the screen.

Let’s take a look at the following example and then walk through it line-by-line so that we can see what is going on.

 1 name: Example Plugin for Movable Type
 2 id: Example
 3 description: This plugin is an example plugin for Movable Type.
 4 version: 1.0
 5 page_actions:
 6    comment:
 7        promote_indiv:
 8            label: Promote to Entry
 9            order: 101
10            code:  $Example::Example::Plugin::comment_page_action
11            permission: edit_all_posts

On line 6 you see the phrase “comment” which refers to the page you wish to target. A list of pages you can target page actions for has been provided below.

On line 7 you see the unique ID or key the developer has assigned to the page action. It is not used directly by Movable Type.

Lines 8-11 contain all of the registry properties for the individual page action with an id of promote_indiv. For a complete list of allowable registry properties, see the list below.

Registry Properties

  • label - a string representing the name of the link that will be displayed on the targeted page.
  • order - a number that controls the sort order, or in which position your link will appear relative to other page actions.
  • condition - a reference to a subroutine that will return 1 if the corresponding page action should appear, and 0 otherwise.
  • permission - a comma delimited list of permissions that the current user must possess in order to see and click on the link (see “Binding Permissions to Modes or Dialogs” for a list of the permissions you can refer to).

In addition to the above properties, you will need specify how Movable Type will handle a user clicking on a page action. There are three possibilities: 1) link directly to a page, 2) spawn a dialog or 3) perform a form post. Each of these corresponds to the following registry properties, of which you can only specify one:

  • mode - a string representing the mode (the value of the __mode querystring parameter) Movable Type will construct a link to.
  • dialog - like the “mode” property, the value of this property is also the name of a mode, but instead of linking directly to the screen referred to by “mode,” Movable Type will spawn a modal dialog containing the contents of “mode”.
  • code - a reference to a handler in your file that will process a form post containing information about the page action being clicked on (see example below).

Page Action Handler

If you register a subroutine to process your results by using the code registry property, then you will need to implement a handler to process the request that is triggered when the user clicks on the link. The following is an example page action handler.

sub comment_page_action {
    my ($app) = @_;
    $app->validate_magic or return;
    require MT::Comment;
    my $comm_id = $app->param('id');
    my $comm = MT::Comment->load($comm_id) or next;
    # Do something
                mode => 'view',
                args   => {
                    '_type' => 'entry',
                    blog_id => $app->blog->id,
                    id      => $comment->entry->id,

A couple notes about the code sample above:

  • When Movable Type creates the page action link for you, it will automatically include additional information in the URL to signal to your handler what the request may be in regards to. For example, when adding a page action to the “Edit Comment” screen, the page action link will include the ID of the comment currently being edited.

  • The $app->validate_magic should be called by any page action handler and is there for security purposes. Removing it will not impact the functionality of your handler, but it is recommended nonetheless.

Pages You Can Target

The following is a list of the pages that can be targeted with page actions. Each of the following pages refers to the editing screen for the object with the corresponding name (e.g. asset refers to the edit asset screen):

  • asset
  • author
  • blog
  • category
  • comment
  • commenter
  • entry
  • folder
  • ping
  • template

As you might expect by glancing at the list below, each of the following refers to the listing screens for the object type with the corresponding name (e.g. list_author is for the author listing screen/table):

  • list_asset
  • list_author
  • list_blog
  • list_category
  • list_comment
  • list_entry
  • list_member
  • list_notification
  • list_ping
  • list_tag
  • list_template

And then the rest:

  • view_log - the activity log screen for a blog and for the system

1 Comment

indigirl on August 21, 2009, 9:33 a.m. Reply

Not sure if this has been updated in more recent releases, but for 4.21, the proper listing screen to target in a plugin’s config.yaml is actually:


(Note the plural)