TinyMCE templates: choose a static catalog or a managed template service

For current TinyMCE, the premium Templates plugin still uses the identifier advtemplate. Use advtemplate_templates for a supplied static catalog, or the documented asynchronous callbacks for an application-managed catalog. A toolbar button alone does not store reusable templates. Confirm paid-plugin access for the installed release before integrating it. Templates documentation

An original repair desk maintains approved instructions for battery returns and damaged equipment. Authors should insert the appropriate section into a reply. A supervisor also needs to control which reusable wording is available, without confusing edits to one reply with changes to the catalog.

Start with the catalog the application actually needs

This static example supplies two approved sections in one category:

const repairTemplateOptions = {
  plugins: 'advtemplate',
  toolbar: 'undo redo | inserttemplate',
  advtemplate_templates: [
    {
      title: 'Equipment returns',
      items: [
        {
          title: 'Battery return',
          content: '<h2>Battery return</h2>' +
            '<p>Contact the desk to confirm the return location.</p>'
        },
        {
          title: 'Damaged equipment',
          content: '<h2>Damaged equipment</h2>' +
            '<p>Stop using the item and contact the desk.</p>'
        }
      ]
    }
  ]
};

Merge the options into the existing initialization, keeping its selector, other plugins, toolbar controls and license setup. These are fictional instructions illustrating the catalog structure; replace them with the organization's approved handling policy.

A static catalog is suitable when application configuration owns those definitions. It does not implement a shared database where authors can create and manage templates. Only expose controls backed by the behavior the application actually supplies.

Use stable IDs when the catalog comes from a service

A managed integration uses advtemplate_list to return the available categories and templates, and advtemplate_get_template(id) to retrieve a chosen template's content. Both are asynchronous and return Promises.

The list response requires unique IDs and nonempty titles. A category has an items list, which may be empty; nested subcategories are not supported. The list can omit a template's content because the retrieval callback obtains it when needed.

For example, an illustrative list response might be:

[
  {
    "id":"category-returns",
    "title":"Equipment returns",
    "items":[
      {"id":"template-battery","title":"Battery return"},
      {"id":"template-damage","title":"Damaged equipment"}
    ]
  }
]

Retrieving template-battery must return that template's actual id, title and content. A renamed display title should not silently change its stable identity.

If authors may create, rename, move or delete catalog entries, implement the matching documented callbacks and server operations. The service must authorize those actions; a hidden control or a read-only category in the UI does not replace server permission checks. Report service failures to the author and retain the current reply rather than treating a failed catalog save as success.

Distinguish inserted text from the reusable definition

Inserting a template places its content in the current document. The author can adapt the individual reply. Saving that reply is separate from saving reusable catalog content, and neither action should silently overwrite the other.

The current documentation says the plugin does not provide direct template editing. Its described update workflow is to insert the template, edit the content, select the revised material and create a new template. Decide how supervisors retire or replace the previous definition in your catalog. A similar title alone is insufficient to identify which approved instruction authors should use.

The addtemplate control supports saving selected material as a template when the required integration is present. Verify the selected range before saving: the recipient's name and the personal introduction should not accidentally enter a shared battery-return definition.

Test a catalog change separately from a reply save

Begin a development reply with a recipient-specific introduction. Insert Battery return after it, then save and reopen the reply using the normal TinyMCE content route. Check that the introduction remains and the inserted instructions describe the correct arrangement.

Next, test the authorized catalog workflow with a revised definition. Reload the catalog and insert that definition into a different reply. Confirm the new reply receives the intended wording and the previously saved reply retains its own document content.

For recipient-specific fields within a reusable section, merge tags solve a separate problem: preserving tokens until the application supplies actual values. A catalog stores reusable sections; it does not obtain a customer's return location or send the finished reply. Finish by checking the individual reply's facts and the catalog entry's approved wording in their respective systems.

Keep reading