v1.19.0

Naming and wording, ahead of the WordPress.org submission. No functional changes.

The code-highlighting module is now called Code Highlighter

It was named after the standalone Enlighter plugin — in the modules list, its settings page, the block inserter and the Elementor widget. Naming a feature after another plugin is what the directory's trademark guideline exists to prevent, and it was inaccurate anyway: this is our own dependency-free highlighter, not a fork.

Nothing that is stored moved. The module id, its settings option, the block name digitizer/enlighter, the [dpt_code] and opt-in [enlighter] shortcodes and the Elementor widget name are all unchanged. Existing pages render identically and saved settings are untouched — the module keeps its on/off state and its configuration through the update. The only thing that changes on a live site is the name you see.

The one address that did change is the settings page URL (admin.php?page=dpt-code-highlighter), which matters only to a bookmark.

Compatibility with Enlighter's saved markup is unchanged, and now described accurately. Code carrying data-enlighter-language attributes or EnlighterJSRAW classes still highlights without editing the post. Enlighter's own shortcode tags are still claimed only when a filter opts in, and still stand down while that plugin is active and handling them. The two are meant to run side by side.

Module descriptions no longer name other plugins. Each module now describes its own scope, and which saved markup it can read, instead of what it replaces.

Translations: the four renamed strings were swapped in the Hebrew catalog rather than appended, so nothing is orphaned. 561 strings, zero missing.

Verified with 84 assertions across two stub harnesses, including one dedicated to proving every stored key survived the rename, plus php -l, node --check and the four Plugin Check sniffs at zero.