[WordPress] 外掛分享： iG:Syntax Hiliter

becomes a real element and the is dropped entirely. Because the whole post is one block, editing an unrelated paragraph is enough to re-save every snippet in the post in that damaged form. The conversion moves your code into block attributes, where TinyMCE cannot reach it, before that can happen. It is surgical — only the snippets are replaced and every other byte of the post is left exactly as it was.
Snippets that have been converted to blocks are not visible if the plugin is deactivated
This is the trade-off for the block editor support and on this one point blocks are worse than shortcodes. A shortcode left behind by a deactivated plugin at least stays on screen as [php]…[/php] text, which you can see and act on. A block whose plugin is gone is not registered at all, renders as nothing and the snippet silently disappears from the post.
The Gist block goes the same way for the same reason, and so does the Gist it names.
To fix this issue, the settings page of the plugin has a Before you deactivate section containing a tool that converts this plugin’s blocks back into shortcodes across the whole site — published, draft, pending, scheduled and private posts of public post types. Run it before you deactivate or delete the plugin. A code block becomes a [sourcecode language="…"] shortcode, so a snippet that started life as [php]…[/php] comes back as [sourcecode language="php"]…[/sourcecode]. That is the same thing semantically, but it is not a byte-for-byte round trip to what you originally typed. A Gist block becomes [github gist="https://gist.github.com/…"], which is the address the block was already embedding.
A snippet whose code quotes this plugin’s own tags converts like any other, and it is worth knowing how. A shortcode ends at the first closing tag in its code, so the tool doubles the brackets of every one of this plugin’s tags it finds there — [[sourcecode language="php"]] and [[/sourcecode]] — which is how a snippet says that a tag is text rather than a tag. A reader sees the tags you typed. With the plugin deactivated you see the doubled brackets in the code sample instead, which is the price of the snippet being on the page at all.
Only the tags the plugin actually shipped are recognised
Those are:
actionscript actionscript3 apache applescript asp bash c c_mac code cpp csharp css diff groovy html4strict html5 ini java java5 javascript jquery mysql oracle11 pcre perl perl6 php postgresql python rails ruby sql text vb vbnet xml yaml

plus the aliases as, html and js, plus [sourcecode] and [github].
A tag this plugin never shipped is left completely alone — not registered, not rendered, not converted. If your post contains [email], it stays [email] and goes to whichever plugin owns it. That is deliberate: claiming a wider set of tags would mean taking shortcodes away from other plugins, which is a worse problem than the one it would solve.
This also means that if you added custom language files for GeSHi and were using them with drop-in tags (eg., you added email language file and were using [email] tag), those are no longer recognized by the plugin and are left behind. You can go back and update those posts if you want and switch those tags to [sourcecode] variant or into this plugin’s block for the block editor – and they will then be picked by the plugin and have the syntax highlighted on frontend. This is a breaking change in v6.0.0 as it is almost impossible to determine if a BB tag (for a language not originally shipped with this plugin) is for use with this plugin via drop-in language support or use with some other plugin. But this affects only [] type of tags. So [email] will be left behind but [sourcecode language="email"] would still be supported and get converted to this plugin’s block if you use the block editor and open that post in it for editing.
Some old tags now highlight as a different language
Prism does not have a component for everything GeSHi had, so a handful of tags are mapped onto the nearest thing Prism does have. In a shortcode the mapping happens when the page is rendered — what is stored in your post is the tag you typed — so it can be improved later without touching your posts. A snippet converted to a block is the exception and stores the mapped name, because that is the name the block’s language dropdown offers. A name Prism does not know is stored exactly as you typed it either way — it is your word and a name overwritten could never be recovered — and such a snippet renders as an unhighlighted code box.
Most of it is uncontroversial: html, html4strict, html5 and xml all become markup; mysql and postgresql become sql; oracle11 becomes plsql; jquery becomes javascript; rails becomes ruby; pcre becomes regex; actionscript3 and as become actionscript; java5 becomes java; js becomes javascript; apache becomes apacheconf; vb and vbnet both become visual-basic; and code and text become none, which is a styled but deliberately unhighlighted box.
Three of them change the language, not just its name, so your code will be coloured by different rules than it was in v5:

asp is highlighted as ASP.NET. GeSHi’s asp was classic ASP, which Prism has no component for.
perl6 is highlighted as Perl. Perl 6 is a different language — it has been called Raku since 2019 — and Prism has no component for it.
c_mac is highlighted as plain C.

Your code itself is untouched in every case; only the colouring differs.
Languages added by dropping in GeSHi files are no longer supported
Since v3.0 you could add a language by putting a GeSHi language file in the plugin’s own geshi/ directory and since v4.1 in a geshi/ directory in your theme instead, in both cases using its filename as a tag. GeSHi is gone in 6.0.0 and both mechanisms are gone with it. The plugin no longer ships a geshi/ directory and no longer looks for one anywhere, in the plugin or in a theme. There is no automatic replacement. A snippet using such a tag is no longer recognised, so it will appear as ordinary post text with the [tag] markers visible, formatted by WordPress like any other text.
Approx 300 languages ship with the plugin, so there is a good chance one of them is the language you were adding — use it with [sourcecode language="…"].
The changelog entries below for v3.0 and v4.1 still describe those drop-in directories and are left as they are — they are the record of what those versions shipped, not of what 6.0.0 does. Neither mechanism works in 6.0.0.
Highlighting is done by the browser now
Prism colours the code client side. Its files load only on pages that contain a snippet and only the languages that page uses. Visitors with JavaScript turned off get a plain but properly styled code box with the code intact. A language the plugin cannot resolve produces an unhighlighted but styled box rather than an error — nothing breaks and nothing 404s.
strip_shortcodes() now strips this plugin’s tags too
Worth knowing if you write themes or plugins. This plugin hooks strip_shortcodes_tagnames, so any call to strip_shortcodes() anywhere on the site — yours, your theme’s, another plugin’s — now removes [php], [code], [html], [js], [c], [sourcecode] and the rest of this plugin’s tags along with the shortcodes WordPress knows about.
That is deliberate. The plugin does not register its tags globally any more, so core has no idea they are shortcodes and an automatic excerpt would otherwise print a whole snippet as prose. Naming the tags to core fixes that everywhere at once — but it is wider than the excerpt path. If you were relying on strip_shortcodes() leaving [php]…[/php] standing in some other bit of content, it no longer will.
The classic editor’s Visual tab is still not a place to write code
It never was. Snippets are supported in the block editor and in the classic editor’s Code view. Switching a post to Visual mode can corrupt code inside shortcodes. That is documented behaviour since beginning when TinyMCE WYSIWYG editor was added; it is not a bug.Documentation on plugin usage and configuration

延伸相關外掛