Preserve formatting of code for display by preventing its modification by WordPress and other plugins while also retaining whitespace.
This plugin preserves formatting of code for display by preventing its modification by WordPress and other plugins while also retaining whitespace.
NOTE: Use of the visual text editor will pose problems as it can mangle your intent in terms of code
tags. I strongly suggest you not use the visual editor in conjunction with this plugin as I have taken no effort to make the two compatible.
Notes:
Basically, you can just paste code into code
, pre
, and/or other tags you additionally specify and this plugin will:
Keep these things in mind:
br
tags).Example:
A post containing this within code
tags:
$wpdb->query(" INSERT INTO $tablepostmeta (post_id,meta_key,meta_value) VALUES ('$post_id','link','$extended') ");
Would, with this plugin enabled, look in a browser pretty much how it does above, instead of like:
$wpdb->query(— INSERT INTO $tablepostmeta (post_id,meta_key,meta_value) VALUES ('$post_id','link','$extended') ―);
Links: Plugin Homepage | Plugin Directory Page | GitHub | Author Homepage
preserve-code-formatting.zip
inside the plugins directory for your site (typically wp-content/plugins/
)Settings
-> Code Formatting
admin settings page (which you can also get to via the Settings link next to the plugin on the Manage Plugins page) and customize the settings.code
tags. If you are using the block editor (aka Gutenberg), then this plugin is only useful for maintaining code formatting for posts written before WP 5.0 (or whenever you started creating posts with the block editor). You should be using the built-in code block when including code into the block editor. Otherwise, if you are actively using the classic editor, be sure to use the HTML (aka “Text”) editor and not the “Visual” editor or you’ll encounter formatting issues.Are you using the visual editor? The visual editor has a tendency to screw up some of your intent, especially when you are attempting to include raw code. This plugin does not make any claims about working when you create posts with the visual editor enabled.
How to tell if you’re using the visual editor: you’re using what is now referred to as the Classic Editor (the editing experience in WordPress that pre-dates the block editor since WordPress 5.0). Above the post content field and to the right, there is a tab labeled “Visual” and another labeled “Text”. If you’re writing code, you want to use “Text” for such posts and not switch back to “Visual”.
Yes, shortcodes within code tags (or any tag processed by this plugin) will be output as pure text and not be processed as shortcodes by WordPress.
Yes, in the sense that it doesn’t do anything at all. The code block in the block editor should preserve code formatting without this plugin’s intervention.
(If you have older content that predates the block editor and has not been converted to blocks, you’ll still want to keep this plugin active to preserve code formatting in those older posts. But having this plugin active won’t interfere with the behavior of code blocks.)
Yes.
Highlights:
Details:
{!{
and }!}
instead of [[
and ]]
to prevent interpretation as shortcodes, fixing conflict with SyntaxHighlighter. Props azito122.c2c_{PluginName}_Plugin_051
to c2c_Plugin_060
get_c2c_string()
as a getter for translated stringsget_c2c_string()
whitelist_options()
to allowed_options()
add_allowed_options()
instead of deprecated add_option_whitelist()
for WP 5.5+allowed_options
filter instead of deprecated whitelist_options
for WP 5.5+is_wp_version_cmp()
and get_c2c_string()
)is_wp_version_cmp()
as a utility to compare current WP version against a given WP versioncontextual_help()
to be easier to read, and correct function docblocksnumber_format_i18n()
to format integer value within input fieldreadme_url()
to refer to plugin’s readme.txt on plugins.svn.wordpress.orgHighlights:
Details:
printf()
rather than using string concatenationoptions_page_description()
Full changelog is available in CHANGELOG.md.