Extreme Text Replacer
Features
The plugin adds an admin page under Tools where you enter an exact search string and an optional replacement string. Replacements run across all published posts or only those in a chosen category. It uses exact string matching (PHP str_replace) so you can target block comments such as <!-- wp:block {"ref":66} /-->, HTML fragments, or any other literal text. A dry-run mode lets you preview how many occurrences would be changed and in which posts, with a table of post ID, title, and occurrence count, before applying changes. When the search text matches patterns that could affect layout (e.g. block delimiters, common HTML tags), the interface shows a warning and asks for confirmation. Replacements are executed via AJAX with a nonce and capability check so only users with manage_options can run them.
Tech Stack
The plugin is built with a single main PHP class that registers a Tools submenu page, enqueues admin CSS and JavaScript only on that page, and exposes an AJAX action for the replacement. The backend uses WP_Query to fetch posts (optionally filtered by category), then iterates over post content and applies str_replace; in dry-run mode it collects preview data instead of calling wp_update_post. The admin UI is plain HTML forms with jQuery for validation, dangerous-pattern checks, AJAX submission, and dynamic preview tables. Scripts are localized with wp_localize_script to pass the AJAX URL, nonce, and the list of dangerous patterns. Styling is done with a small admin CSS file. The plugin requires WordPress 5.0+ and PHP 7.0+.
Translation Glossary
Features
The plugin introduces two custom post types: Glossaries and Glossary Terms. A glossary is assigned to one or more categories via a meta box; only posts in those categories use that glossary’s terms. Each term has a title, a definition (post content), optional variations (e.g. plurals, conjugations) stored in post meta, and an assignment to a single glossary. In the admin, a custom top-level menu groups the management of glossaries and terms; metaboxes handle category assignment for glossaries and glossary assignment plus variations for terms. On the front end, when viewing a single post, the plugin loads glossaries linked to the post’s categories, gathers all terms from those glossaries, and runs a case-insensitive regex over the content to wrap the first occurrence of each term (and its variations) in a span with a data attribute holding the explanation. Public CSS and JavaScript (jQuery) style these spans and show the explanation on hover. Single glossary posts display the glossary title plus a generated list of all terms and their definitions below the content. The plugin avoids replacing text inside HTML tags and prevents overlapping highlights. For themes that assume every post has a category, it assigns a fallback category to glossary posts and filters get_the_category so glossary CPTs do not cause errors.
Tech Stack
The codebase is organized around a singleton main class that defines constants, includes the component classes, and hooks activation and deactivation (including rewrite flush). Separate classes handle custom post types (tg_glossary, tg_term with category support for glossaries), admin UI and menu, front-end content filters and enqueue, and metaboxes with nonce-protected save. Post meta is used for category ID, glossary ID, and term variations. The front end uses the_content and the_title filters, WP_Query and get_posts with meta_query to resolve category–glossary–term relationships, and regex with word boundaries for matching. Assets are enqueued with versioned URLs; the plugin loads its text domain from a languages directory and ships a .pot file. It requires WordPress 5.0+ and PHP 7.0+ and is licensed under GPL v2 or later.
Placeholder Translations
Features
The plugin provides a settings page under Settings where you add placeholders by specifying a slug (lowercase, numbers, underscores) and default text. The slug is stored as the key in an option array; the value is the default (or source) string. Existing placeholders are shown in a table with slug, usage hint {{slug}}, and default text, and can be deleted with a nonce-protected link. In block content (Site Editor, posts, pages), any {{slug}} is detected at render time via the render_block filter and replaced by the corresponding text. If Polylang is available, the replacement uses pll__() so the output is translated for the current language. Placeholder strings are registered with Polylang in the admin via pll_register_string under the group “placeholder-translations” so they appear in Languages → String translations. The plugin does not alter stored content; replacement happens only when blocks are rendered, so the same template or reusable block can show different text per language. Add, delete, and registration logic are guarded by nonces and manage_options.
Tech Stack
The bootstrap file defines version and path constants and an option name constant, then conditionally loads an admin class and always loads the render and Polylang integration classes. Initialization runs on init: the render class hooks render_block and replaces each known {{slug}} by looking up the option and calling a small helper that returns pll__( $default_text ) when Polylang exists, otherwise the default. The Polylang class hooks init at priority 20 and, only in the admin, reads the option and registers each slug–text pair with pll_register_string. The admin class adds an options submenu page, handles POST save and GET delete with nonces and capability checks, sanitizes slug with sanitize_key and text with wp_kses_post, and renders the form and table with escaped output. No custom post types or database tables are used; all data lives in a single WordPress option. The plugin requires WordPress 5.9+, PHP 7.4+, and is designed to work with Polylang for multilingual sites.