Go to main content

Menu

Core callbacks reference

This comprehensive reference provides detailed information about all callbacks used in Textpattern, including their events and steps.

Contents

Public-side callbacks

These all trigger at various points during the rendering of publicly viewable content served by Textpattern. Use them to inject content - JavaScript, CSS or HTML - into the page or to alter various facets of visitor interaction with the site. They have events, but no steps.

publish.php

The callbacks in this section all deal with the web page content itself.

pretext

  • When it occurs: At the very top of the pretext() function, just after the prefs have been extracted.
  • What it allows: Injection/alteration of variables in the prefs array or to set up anything that affects the whole page.

pretext_end

  • When it occurs: Just after pretext() has run but before its variables have been extracted into the global scope.
  • What it allows: Altering anything set in pretext() or adding variables to it.

file_download

  • When it occurs: As soon as a file_download is detected.
  • What it does: Intercepts the regular file downloading process.

textpattern

  • When it occurs: Just before the page is rendered.

textpattern_end

  • When it occurs: Once the page has been fully rendered.
  • What it allows: Replacement of content in the output buffer via search/replace.

publish/atom.php

If you wish to alter atom feeds, these callbacks will help.

atom_head

  • When it occurs: After the feed’s header has been set.
  • What it allows: Adding items to the Atom feed’s header.

atom_entry

  • When it occurs: As soon as the article’s data has been populated.
  • What it allows: Injection of extra markup after the standard Atom feed items have been generated.

feed_filter

  • When it occurs: Before the articles list is generated.
  • What it allows: Injection of extra filtering criteria (e.g. status="sticky") when generating the feed’s entries.

publish/rss.php

If you wish to alter rss feeds, these callbacks will help.

rss_head

  • When it occurs: After the feed’s header has been set.
  • What it allows: Adding items to the RSS feed’s header.

rss_entry

  • When it occurs: As soon as the article’s data has been populated.
  • What it allows: Injection of extra markup after the standard RSS feed items have been generated.

feed_filter

  • When it occurs: Before the articles list is generated.
  • What it allows: Injection of extra filtering criteria (e.g. status="sticky") when generating the feed’s entries.

publish/comment.php

Any time a comment form is rendered or a comment is posted on an article, the following callbacks fire, so use them to intercept or alter comment layout/payloads.

comment.form

  • When it occurs: At the end of the commentForm() function.
  • What it allows: Injection of markup after the textarea generated by the <txp:comment_message_input /> tag.

comment.save

  • When it occurs: Just before a comment is posted.
  • What it allows: Additional decisions to be made, based on the comment content (e.g. for anti-spam plugins).

comment.saved

  • When it occurs: Just after a comment is posted to the database.
  • What it allows: Additional processing that might affect other related tables. Argument #3 is an array of name-value pairs containing the message text, name, email, web, parentid, commentid, ip, and visible status of the posted comment.

publish/log.php

As long as Logging is switched on from the Preferences panel, whenever a visitor requests a web page from Textpattern, a hit is registered. Use the callback here to intercept it.

log_hit

  • When it occurs: Just before a log message is recorded in the ‘txp_log’ table.
  • What it allows: Alteration of the log message.

Administration-side callbacks

Administration-side callbacks are split into three flavours. The first are easy to recognize from the address bar of your browser. If you select any administration-side panel link, you’ll see the URL contains ?event=panelname, and if you select any link in that panel that performs an action, you’ll see ?event=panelname&step=action. Those values correspond to the $event and $step parameters you can use during plugin or theme development. In fact, they will call any user-defined function that is registered for said $event and $step, allowing you to add your own events and steps as you need them.

If you wish to utilise such core hooks, consult the administration-side events and steps document, which lists them all.

The second type of callback relate to actions that occur in response to various page-level signals. These could be when certain parts of the administration interface are rendered or when actions (such as deletion) complete, and are listed below.

The final type of callback is pluggable_ui(). These deal with specific chunks of content that appear on the page and allow direct manipulation of individual elements or blocks. They are listed in the pluggable_ui document.

Major block-level callbacks

These callbacks relate to the <head> and <footer> sections, and navigation area of each admin panel. Raising callbacks on these event > step combinations will call your plugin on every panel. Check the global $event if you only wish to target a specific panel.

admin_side > head_end

  • When it occurs: Just before the closing </head> tag on every administration-side panel.
  • What it allows: Injecting JavaScript or style rules into the page’s header.

admin_side > pagetop

  • When it occurs: Immediately before control is handed to the theme.
  • What it does: Renders the navigation bar.

admin_side > pagetop_end

  • When it occurs: Immediately after the theme has been loaded and its header rendered. Just before the closing </header> tag.
  • What it allows: Injection of admin-wide markup below the panel navigation area.

admin_side > main_content

  • When it occurs: Immediately after the ‘announce’ area (where feedback messages appear) and before the panel’s main content begins. Just inside the <main> tag.
  • What it allows: Addition of information at the top of any panel, below the navigation area.

admin_side > main_content_end

  • When it occurs: Immediately before the closing </main> tag at the bottom of the panel.
  • What it allows: Addition of information at the bottom of any panel, above the footer area.

admin_side > body_end

  • When it occurs: After the theme’s footer has been rendered, before the closing </body> tag.
  • What it allows: Injection of non-blocking JavaScript <script> tags.

UI element callbacks

These callbacks are raised when input elements or constructs are rendered. They allow you to target input controls such as multi-edit options, pagination widgets, etc.

{event}_ui > multi_edit_options

  • When it occurs: Whenever a list of multi-edit options is rendered. The {event} is the panel on which the multi-edit control appears.
  • What it allows: Alteration or augmentation of the multi-edit select list. Argument #3 contains the options array, passed by reference so it may be altered directly.

{event}_ui > pageby_values

  • When it occurs: Whenever a set of pagination options are rendered. The {event} is the panel on which the pagination options appear.
  • What it allows: Alteration or augmentation of the steps in which pagination may occur, i.e. how many ‘rows’ of data are shown per page.
  • Argument #3: The array of sizes, passed by reference so it may be altered directly.

Panel-level callbacks

Write panel

article_posted

  • When it occurs: Immediately after article creation.
  • What it allows: Interception of the article create process to append or prepend content to the record, or to perform some additional processing.
  • Additional parameter: The posted contents as an array.

article_saved

  • When it occurs: Immediately after article update/save.
  • What it allows: Interception of the article save process to append or prepend content to the record, or to perform some additional processing.
  • Additional parameter: The posted contents as an array.

ping

  • When it occurs: Just before a ping notification is sent upon publication of an article.
  • What it allows: Interception of the ping so you can provide your own.

article_ui > partials_meta

  • When it occurs: Just before the partials are refreshed on an Ajax save.
  • What it allows: Alter or augment the interface, usually based on the data sent to/from the Ajax save process.
  • Argument #3: The record set of the article being edited.
  • Argument #4: The partials array comprised of:
    • key: Unique name of the item available to alter, then an array as follows:
      • mode: The mechanism by which the partial may be updated
      • selector: The wholly encapsulated DOM selector to which the partial applies
      • callback The callback function to utilize to update the nominated part of the interface
      • html An optional return value of the callback function

Articles panel

articles > multi_edit.{action} (where action is delete, changeauthor, changecategory1, changecategory2, changecomments, changesection, changestatus, or a plugin’s action)

  • When it occurs: Either before (pre=1) or after (pre=0) one or more articles have been altered via the multi-edit tool.
  • What it allows: To perform any additional functionality when one or more articles are changed, or about to be changed via the multi-edit tool.
  • Additional parameter: An array of affected article IDs, the database field affected, and the new value assigned.

articles_deleted

  • When it occurs: After one or more articles have been deleted and any associated comments have had their visibility removed.
  • What it allows: To do any additional cleanup after one or more articles are removed from Textpattern.
  • Additional parameter: An array of deleted article IDs.
  • Note: Will be phased out in favour of the above articles > multi_edit.{action} (pre=0) callback in future.

multi_edited.articles > {action} (where action is delete, changeauthor, changecategory1, changecategory2, changecomments, changesection, changestatus, or a plugin’s action)

  • When it occurs: After one or more articles have been altered via the multi-edit tool.
  • What it allows: To perform any additional functionality after one or more articles are changed via the multi-edit tool.
  • Additional parameter: An array of affected article IDs, the database field affected, and the new value assigned.
  • Note: Will be phased out in favour of the above articles > multi_edit.{action} (pre=0) callback in future.

Categories panel

categories_deleted

  • When it occurs: After one or more categories have been deleted and the tree has been rebuilt.
  • What it allows: To do any additional cleanup after one or more categories are removed from Textpattern.
  • Additional parameter: An array of deleted category IDs.

Images panel

image_deleted

  • When it occurs: Before an image and its thumbnail are deleted.
  • What it allows: To do any additional cleanup after one or more images are removed from Textpattern.
  • Additional parameter: The ID of the deleted image.

thumbnail_deleted

  • When it occurs: Before a thumbnail is deleted.
  • What it allows: To do any additional cleanup after a thumbnail is removed from Textpattern.
  • Additional parameter: The ID of the deleted thumbnail.

image_uploaded

  • When it occurs: After an image has been uploaded or replaced by another image.
  • What it allows: To do any additional processing after an image is added or replaced from Textpattern.
  • Additional parameter: The ID of the image.

Files panel

file_deleted

  • When it occurs: Before each file is deleted.
  • What it allows: To do any additional cleanup after one or more files are removed from Textpattern.
  • First additional parameter: The file ID of the deleted file.
  • Second additional parameter: The full path to the deleted file.

links_deleted

  • When it occurs: After one or more links have been deleted.
  • What it allows: To do any additional cleanup after one or more links are removed from Textpattern.
  • Additional parameter: An array of deleted link IDs.

Comments panel

discuss_deleted

  • When it occurs: After one or more comments have been deleted, but before the comment counts have been updated in the affected articles.
  • What it allows: To do any additional cleanup after one or more comments are removed from Textpattern.
  • Additional parameter: An array of deleted comment IDs.

Themes panel

See Administration-side theme callbacks.

Sections panel

sections_deleted

  • When it occurs: After one or more sections have been deleted.
  • What it allows: To do any additional cleanup after one or more sections are removed from Textpattern.
  • Additional parameter: An array of deleted section names.

Pages panel

page_created / page_duplicated

  • When it occurs: After a new page has been created/duplicated.
  • What it allows: To do any additional cleanup after a page is instantiated or cloned in the database.
  • Additional parameter: The name of the page and its new name (which will be the same during creation, and may differ on duplication).

page_updated

  • When it occurs: After a new page has been updated.
  • What it allows: To do any additional cleanup after a page is altered in the database.
  • Additional parameter: The name of the page and its new name (in case it was renamed).

page_saved

  • When it occurs: After a new page has been stored.
  • What it allows: To do any additional cleanup after a page is altered in the database.
  • Additional parameter: The name of the page and its new name (in case it was renamed).

page_deleted

  • When it occurs: After a page template has been deleted.
  • What it allows: To do any additional cleanup after a page template is removed from Textpattern.
  • Additional parameter: The name of the deleted page and the theme in which it resided.

Forms panel

form_created / form_duplicated

  • When it occurs: After a new form has been created/duplicated.
  • What it allows: To do any additional cleanup after a form is instantiated or cloned in the database.
  • Additional parameter: The name of the form and its new name (which will be the same during creation, and may differ on duplication).

form.create > done

  • When it occurs: After a form has been created from the UI.
  • What it allows: To do any additional processing when a form is created in Textpattern.
  • Additional parameter: An array comprising the new Form name, its type and its Form contents.

form_updated

  • When it occurs: After a new form has been updated.
  • What it allows: To do any additional cleanup after a form is altered in the database.
  • Additional parameter: The name of the form and its new name (in case it was renamed).

form_saved

  • When it occurs: After a new form has been stored.
  • What it allows: To do any additional cleanup after a form is altered in the database.
  • Additional parameter: The name of the form and its new name (in case it was renamed).

forms_deleted

  • When it occurs: After one or more forms have been deleted.
  • What it allows: To do any additional cleanup after one or more forms are removed from Textpattern.
  • Additional parameter: An array of deleted form names and the theme in which they resided.

Styles panel

css_created / css_duplicated

  • When it occurs: After a new stylesheet has been created/duplicated.
  • What it allows: To do any additional cleanup after a stylesheet is instantiated or cloned in the database.
  • Additional parameter: The name of the stylesheet and its new name (which will be the same during creation, and may differ on duplication).

css_updated

  • When it occurs: After a new stylesheet has been updated.
  • What it allows: To do any additional cleanup after a stylesheet is altered in the database.
  • Additional parameter: The name of the stylesheet and its new name (in case it was renamed).

css_saved

  • When it occurs: After a new stylesheet has been stored.
  • What it allows: To do any additional cleanup after a stylesheet is altered in the database.
  • Additional parameter: The name of the stylesheet and its new name (in case it was renamed).

css_deleted

  • When it occurs: After a stylesheet has been deleted.
  • What it allows: To do any additional cleanup after a stylesheet is removed from Textpattern.
  • Additional parameter: The name of the deleted stylesheet and the theme in which it resided.

Diagnostics panel

diag_results > low or > high

  • When it occurs: At the end of the doDiagnostics() function that renders the content of the Diagnostics panel.
  • What it allows: To add any extra information to the diagnostic output depending on the level of output the user has chosen (high or low).

Languages panel

lang_installed

  • When it occurs: When a language is added to the database.
  • What it allows: To perform any additional functionality when a language is installed into Textpattern.
  • Additional parameter: The language short code (e.g. ‘en’).

lang_deleted

  • When it occurs: When a language is deleted from the database.
  • What it allows: To perform any additional functionality when a language is removed from Textpattern.
  • Additional parameter: The language short code (e.g. ‘en’).

Users panel

authors_deleted

  • When it occurs: After user(s) have been deleted and all assets have been reassigned.
  • What it allows: To do any additional cleanup after a user is removed from Textpattern.
  • Additional parameter: An array of deleted user names.

user.assign_assets > done

  • When it occurs: After user(s) have been deleted and all assets have been reassigned. Only runs if the existing user and new owner accounts both exist.
  • What it allows: To do any additional cleanup after a user is removed from Textpattern.
  • Additional parameter: An array containing the existing owner, the new_owner and a list of columns that have been affected by the reassignment.

See also user.assign_assets > columns.

user.create > done

  • When it occurs: After a user has been successfully created.
  • What it allows: To do any additional processing after a user has been created.
  • Additional parameter: An array containing the entire set of columns and their data about the new user.

user.update > done

  • When it occurs: After an existing user account has been successfully altered.
  • What it allows: To do any additional processing after user metadata has been modified.
  • Additional parameter: An array containing the name, email, realname and any additional metadata.

user.password_change > done

  • When it occurs: After an existing user has successfully changed their password.
  • What it allows: To do any additional processing after user metadata has been modified.
  • Additional parameter: An array containing the user name, password, and hash.

user.remove > done

  • When it occurs: After an existing user account has been successfully deleted.
  • What it allows: To do any additional processing after user removal.
  • Additional parameter: An array containing the list of deleted user names, and the new_owner of the deleted authors’ assets.

See also authors_deleted.

user.rename > done

  • When it occurs: After an existing user login name has been changed.
  • What it allows: To do any additional processing after user metadata has been modified.
  • Additional parameter: An array containing the original user name, and the newname.

user.change_group > done

  • When it occurs: After privileges of an existing user account has been successfully altered.
  • What it allows: To do any additional processing after user metadata has been modified.
  • Additional parameter: An array containing a list of the user names affected and new privilege level they have been assigned.

Plugins panel

txp.plugin > data.fetch

  • When it occurs: As a plugin’s internal data is fetched from the database.
  • What it allows: To fetch the data from somewhere other than the database column.
  • Additional parameter: The name of the plugin.

txp.plugin > textpack.fetch

  • When it occurs: As a plugin’s internal Textpack is fetched from the database.
  • What it allows: To fetch the Textpack from somewhere other than the database column.
  • Additional parameter: The name of the plugin.

Administration-side criteria callbacks

These callbacks allow you to alter the criteria used in the various panels. You can append SQL to the criteria to apply additional filtering.

Note the criteria is appended, so existing search parameters are honoured. Therefore your returned statement should begin with " AND …". If you wish to ignore any previous filtering, begin " AND 1 AND …".

The third argument to your callback function contains the current criteria used, so you may make decisions based on its contents (e.g. you may not want to filter the results if a search has been performed).

These callbacks all have the same $event called admin_criteria.

Panel $step
Articles list_list
Comments discuss_list
Files file_list
Forms form_list
Images image_list
Links link_list
Pages page_list
Sections section_list
Styles css_list
Themes skin_list
Users author_list
Visitor logs log_list

Administration-side validation callbacks

These callbacks allow you to alter or append to the constraints imposed by the core when saving data. Textpattern will check that the passed values for things like categories, sections, and so forth actually exist in the database to avoid new ones being introduced at unexpected places.

If you’re developing plugins, you may wish to open up or restrict data in certain types of actions, or create entirely new constraints and take advantage of the built-in validator. If so, these callbacks are the ones to use.

These additional arguments are all passed by reference to your application, so you can alter them directly:

  • Argument #3 is the incoming array of values posted from the save operation, unsanitized.
  • Argument #4 is the array of constraints.
Panel $event $step
Articles article_ui validate_save
Articles article_ui validate_publish
Comments discuss_ui validate_save
Files file_ui validate_save
Images image_ui validate_save
Links link_ui validate_save

Administration-side theme callbacks

When performing theme operations such as import and export, you can intercept or alter the content. These allow you to do additional processing or file system operations, such as importing prefs and additional content when a theme is updated or installed.

$event $step $pre Argument #4 What it allows / does
txp.skin create 1 Theme metadata and theme name Prepare or check content prior to theme creation
txp.skin create 0 Theme metadata, theme name, and result of creation (false, or the name of the theme that was successfully created) Perform additional content, database or file manipulation on completion of the create process
txp.skin update 1 Theme metadata and theme name Prepare or check content prior to theme update/resynchronisation with the file system
txp.skin update 0 Theme metadata, theme name, and result of update (false, or the name of the theme that was successfully updated) Perform additional content, database or file manipulation on completion of the update/resynchronisation process
txp.skin duplicate 1 List of theme names to be processed Prepare or check content prior to theme duplication
txp.skin duplicate 0 List of theme names scheduled for duplication, and the name of each successfully duplicated theme Perform additional content, database or file manipulation on completion of the duplication process
txp.skin import 1 List of theme names to be processed Prepare or check content prior to theme import from the file system
txp.skin import 0 List of theme names scheduled for importing, and the name of each successfully imported theme Perform additional content, database or file manipulation on completion of the import process from the file system
txp.skin export 1 List of theme names to be processed Prepare or check content prior to theme export to the file system
txp.skin export 0 List of theme names scheduled for exporting, and the name of each successfully exported theme Perform additional content, database or file manipulation on completion of the export process to the file system
txp.skin delete 1 List of theme names to be deleted Prepare or check content prior to theme deletion
txp.skin delete 0 List of theme names scheduled for deletion, and the name of each successfully deleted theme Perform additional content, database or file manipulation on completion of the deletion process
txp.css, txp.form, txp.page import 1 Theme name and a list of its assets to be processed Prepare or check content prior to asset import from the file system
txp.css, txp.form, txp.page import 0 Theme name, the list of its assets to be processed, and the name of each successfully imported asset Perform additional content, database or file manipulation on completion of the import process from the file system
txp.css, txp.form, txp.page export 1 Theme name and a list of its assets to be processed Prepare or check content prior to asset export to the file system
txp.css, txp.form, txp.page export 0 Theme name, the list of its assets to be processed, and the name of each successfully imported asset Perform additional content, database or file manipulation on completion of the export process to the file system

Modification callbacks

Like pluggable_ui() callbacks, this type of callback is performed ‘pass by reference’ and allows you to directly alter the passed content by importing it by reference and manipulating it directly in your function. Use an ampersand in front of the data attribute to do so, like this which adds a new status level after the existing core set:

register_callback('abc_my_function', 'status.types', 'types');

function abc_my_function($evt, $stp, &$data)
{
    $data[6] = 'supersticky';
    return $data;
}

form.types > types

  • When it occurs: When the list of Form types are first retrieved on a panel.
  • What it allows: To alter or extend the available list of Form types.
  • Additional parameter: An array containing a list of the current form types, which you can directly alter if you wish and return.

form.essential > forms

  • When it occurs: When the list of ‘essential’ (fixed) Forms are first retrieved on a panel.
  • What it allows: To alter or extend the available list of essential Forms.
  • Additional parameter: An array containing a list of the current essential forms. The array key is the form name, and the array value is its group.

user.assign_assets > columns

  • When it occurs: The first time user assets are reassigned on a panel call.
  • What it allows: To alter or extend the available list of asset types that are affected when a user is deleted.
  • Additional parameter: An array containing a list of the currently affected columns. The aray key is the table name, and value is the name of the author column in that table.

status.types > types

  • When it occurs: When the list of Article publication status values are first retrieved on a panel.
  • What it allows: To alter or extend the available list of Status values.
  • Additional parameter: An array containing a list of the current statuses. The key is its numeric value (usually a constant) and the value (language key) is its name. Note the value is not its label as that is fetched from the txp_lang table for the current languauge.

API callbacks

form.fetch

  • When it occurs: The first time any Form is read from the database. Anything returned from your custom handler is used as Form contents for the named form.
  • What it allows: To alter where the Form contents is read.
  • Additional parameter: An array containing the name of the Form being fetched and the theme (skin) to which it is assigned. Note the skin may be the working theme if the site is being previewed.

page.fetch

  • When it occurs: The first time any Page is read from the database. Anything returned from your custom handler is used as Page contents for the named page.
  • What it allows: To alter where the Page contents is read.
  • Additional parameter: An array containing the name of the Page being fetched and the theme (skin) to which it is assigned. Note the skin may be the working theme if the site is being previewed.

site.update > {event}

  • When it occurs: Every time the site’s hidden lastmod value is updated in the preferences.
  • What it allows: To perform additional processing (e.g. caching) after one or more events have triggered the site modification datastamp to change.
  • Additional parameter: An array containing some details (like id etc) of the affected rows, plus an array containing the whenStamp (time now) and whenDate (database-friendly timestamp of time now).

preference.create > done

  • When it occurs: After a preference value has been successfully created.
  • What it allows: To do any additional processing after a preference value has been created.
  • Additional parameter: An array containing the entire set of columns and their data about the new preference.

preference.update > done

  • When it occurs: After a preference value has been successfully altered.
  • What it allows: To do any additional processing after a preference value has been changed.
  • Additional parameter: An array containing the entire set of columns and the new data that defines the preference.

preference.rename > done

  • When it occurs: After a preference value has been successfully renamed.
  • What it allows: To do any additional processing after a preference name has been changed.
  • Additional parameter: An array containing the preference’s original name, its newname and user_name to whom it is assigned. The user_name will be null if it’s a core preference value.

txp.article > neighbour.criteria

  • When it occurs: Before the next/prev article button is rendered in the Write panel.
  • What it allows: To append a clause to the SQL that determines which article comes before or after the current one.
  • Additional parameter: An array containing the current article’s ID, whichway (the direction in which the button is being rendered: ‘next’ or ‘prev’) and the timestamp of the current article sPosted.

Plugin callbacks

In order to process these callbacks, your plugin must raise the PLUGIN_LIFECYCLE_NOTIFY flag to register its intent. In addition, if you wish to offer a link to your plugin’s preferences from the Plugins panel, you must raise the PLUGIN_HAS_PREFS flag.

$event $step When it occurs
plugin_lifecycle.abc_your_plugin enabled When somebody switches abc_your_plugin to “Enabled” (Yes) from the Plugins panel.
plugin_lifecycle.abc_your_plugin disabled When somebody switches abc_your_plugin to “Disabled” (No) on the Plugins panel.
plugin_lifecycle.abc_your_plugin installed When abc_your_plugin has been installed by the act of the user pasting its code in the Plugins panel and selecting Install button on the next screen.
plugin_lifecycle.abc_your_plugin deleted When abc_your_plugin has been removed by the act of a user selecting it and deleting it from the Plugins panel (note that the plugin_lifecycle.abc_your_plugin / disabled callback fires first).

Function- and tag-based callbacks

In lib/txplib_misc.php there are some callbacks that allow you to modify the default behaviour of some of the core functions. These are listed below:

$event $step When/where it occurs What it allows/does
sanitize_for_url - At start of the sanitizeForUrl() function. Apply your own URL sanitization rules; passes the text to be sanitized as the callback’s 4th argument.
sanitize_for_file - At start of the sanitizeForUrl() function. Apply your own filename sanitization rules; passes the text to be sanitized as the callback’s 4th argument.
sanitize_for_page - At start of the sanitizeForPage() function Apply your own page name sanitization rules; passes the text to be sanitized as the callback’s 4th argument.
txp_die http_status_code Once the page’s HTTP status has been determined. Passes the numerical HTTP status code as the callback’s step (e.g. 410, 301, etc) allowing you to target particular status codes and take action.
textfilter register When a Textfilter (e.g. Markdown) is added to Textpattern. To intercept filter creation and perform some additional actions.
textfilter filter Before (pre=0) and after (pre=1) a Textfilter is used. To operate upon the pre-filtered or post-filtered content, which is passed as the 3rd parameter. The context in which the filter is used is sent as the 4th parameter.

If you notice any kind of problem with this page's construction or content (outdated information, typos, broken links, or whatever), open an issue to have it sorted. Or have a go at it yourself. :)