Changelog — JPKCom FA inline SVG shortcode
Versionsverlauf des WordPress-Plugins JPKCom FA inline SVG shortcode.
Versionsverlauf von jpkcom-fa-svg-plugin (öffnet in neuem Tab). Die Einträge stammen unverändert aus der README des Projekts. Eine ausführliche Anleitung mit Tipps findest du im Projekt-Guide.
2.0.19
- Added: updates for inactive JPKCom plugins. WordPress never runs the code of a deactivated plugin, so its own updater never ran and it was never offered an update. Every JPKCom plugin now ships updater 1.5.0; one copy answers for all installed JPKCom plugins, active or not, with the update row, the icon and "View details". The SHA-256 check applies to an inactive plugin exactly as to an active one. On multisite, at least one JPKCom plugin must be network-active or active on the main site
- Security: the stored list of plugin updates no longer contains JPKCom download URLs; they are added back only while a JPKCom updater is loaded, so a request without one cannot install an unverified package. The checksum check now also verifies a package another plugin supplied instead of accepting it, and recognises every GitHub address of a release file
- Changed: plugins installed as a Git (or other version-control) checkout or in a renamed folder are told about a new release but never updated automatically, because an update would delete the checkout or the renamed folder. Update information is fetched only for users who can update plugins, in WordPress's update cron and in WP-CLI, never for anonymous visitors
2.0.18
- Added: a plugin icon. The update manifest now points WordPress to the JPKCom logo, so the Updates screen (Dashboard → Updates) shows it next to this plugin instead of the generic pattern wordpress.org generates from the slug
2.0.17
- Security: the plugin header now carries
Update URI: https://github.com/JPKCom/jpkcom-fa-svg-plugin. Without it, WordPress also asks wordpress.org for updates under this plugin's slug, so a same-named plugin published there with a higher version would be offered as an update of this one. With the header, wordpress.org answers nothing for this plugin and updates come only from this repository - Changed: the updater keeps its manifest cache, its failure marker and its fetch lock in site transients. On multisite the network now fetches the manifest once instead of once per site; on a single site nothing changes. The old per-site entries expire on their own within a day
- Changed: the release workflow downloads phpDocumentor from a fixed GitHub release and verifies its SHA-256 before running it, instead of executing whatever phpdoc.org serves that day. No effect on the shipped plugin
- CI:
shivammathur/setup-phppinned to 2.40.0
2.0.16
- Fixed: the shortcode callback was the only function in the plugin without a vendor prefix and without a
function_exists()guard — a globaljsvg_code(). Any theme or plugin declaring that name caused a fatal redeclare error on load. Renamed tojpkcom_fasvg_shortcode()and guarded like every other function here;jsvg_code()remains as a deprecated shim so code calling it directly keeps working - Fixed: the upload path and URL were resolved once while the plugin file was being included. The plugin is
Network: true, and on multisite each site has its own upload directory, so the captured value kept pointing at whichever site was active at load time — wrong for anything rendered afterswitch_to_blog(). The shortcode and the stylesheet registration now go throughjpkcom_fasvg_path()/jpkcom_fasvg_url(), which resolve per call.JPKCOM_FASVG_PATHandJPKCOM_FASVG_URLstay for backwards compatibility - Changed: those helpers use
wp_get_upload_dir()instead ofwp_upload_dir(), i.e. the variant that does not try to create the directory — reading icons never needed that side effect, which the load-time call performed on every request - Fixed: the
<title>id now comes fromwp_unique_id()instead ofwp_rand( 10, 500000 ). With a few dozen titled icons on one page a collision was unlikely but possible, and a duplicate id silently breaksaria-labelledbyand is invalid HTML - Changed: the
<title>text is escaped withesc_html()rather thanesc_attr(). Both produce identical output in WordPress, so this changes nothing visible — it uses the helper that matches the context - Changed: all five
JPKCOM_FASVG_*constants are nowdefined()-guarded; four of them were not, so a stray second copy of the file raised "constant already defined" warnings - Added:
tests/test-hooks.php— 26 cases, 5 red against 2.0.15, including five path-traversal attempts asserting no file outside the icon folder can be read. CI runs it on every pull request and push tomain - Note: path traversal was already closed before this release and remains so.
basename()plussanitize_file_name()reducenameto a flat string,.svgis always appended, andtypeis whitelisted — verified against inputs such as../../../../etc/passwd,solid/../../wp-config,..and an embedded null byte
2.0.15
- Changed: the update manifest generator now defaults a missing
Network:header to false instead of true, matching WordPress' own default. No change for this plugin, which declaresNetwork: trueexplicitly - CI: the lint and guard workflow now also runs on pushes to
main. It only covered pull requests, so a direct push with bypass rights skipped every check - Changed: comments, workflow step names and CI output across the repository are now English throughout, and the developer notes in
CLAUDE.mdwere translated and trimmed. No effect on the shipped plugin
2.0.14
- Changed:
Tested up toraised to WordPress 7.1 - Changed: the bundled updater's runtime floor now matches the plugin's own minimum. It bailed out below WordPress 6.8 while the plugin header has required 6.9 for several releases, so the check could never fire on a supported installation
- Fixed: the Font Awesome stylesheet now reaches the block editor canvas. It was hooked to
enqueue_block_editor_assets, which only loads into the surrounding admin document. From WordPress 7.1 the post editor always renders its canvas in an iframe, so inline SVGs shown in a block preview would have lost the Font Awesome sizing rules (height: 1em,display: inline-block,overflow: visible) and rendered at their intrinsic size. The hook is nowenqueue_block_assets, which WordPress runs both when it assembles the iframe assets and on block editor admin screens — the non-iframed editor of WordPress 7.0 and earlier behaves exactly as before - Changed: one shared style handle
jpkcom-fasvg-stylefor front end and editor; the separate editor handlejpkcom-fasvg-gutenberg-styleis gone. Registration is idempotent, so the inline.svg-inline--farule is emitted once per document - The front end is untouched: it keeps its own
wp_enqueue_scriptsregistration and deliberately does not rely onenqueue_block_assets, which optimisation plugins unhook to strip the core block library - CI: the release manifest's fallback values for
requiresandtestednow say 6.9 and 7.1. They only apply when the README metadata cannot be read, but a stale fallback would have published a minimum the plugin no longer supports
2.0.13
- Added: plugin banners (
assets/banner-1544x500.avif,assets/banner-772x250.avif) — a plain#3c4955surface with no lettering. The update manifest already advertised these two URLs, but nothing was published under them, so the plugin card in wp-admin had a broken banner
2.0.12
- CI: the release step no longer copies the staging directory into itself, so the ZIP has no empty
jpkcom-fa-svg-plugin/jpkcom-fa-svg-plugin/folder - CI: bumped the pinned GitHub Actions (checkout v7.0.1, setup-python v7.0.0, action-gh-release v3.0.2, fetch-metadata v3.1.0), still pinned to full commit SHAs
- CI: the release ZIP now excludes the development-only
tests/andtools/directories - CI: security and regression tests now run on every pull request, where a plugin has them
2.0.11
- Security: update packages are now verified before installation — the verified file is handed to WordPress instead of being downloaded a second time, so the bytes that were checked are the bytes that get installed
- Security: a missing or unfetchable SHA-256 checksum now aborts the update instead of installing unverified code (previously it silently skipped verification)
- Security: pinned every GitHub Action to a full commit SHA and added Dependabot with a 7-day cooldown, so a moved tag can no longer change the release build
- Security: tightened which download the updater claims, so sibling plugins cannot match each other's package
- Fixed:
sprintf()calls in the updater bound named arguments to a variadic parameter, which raisesArgumentCountErroron PHP 8.3 - Fixed: the "View Details" modal could fail with a
TypeErrorwhen the manifest omittedrequires_plugins - Performance: a failed manifest fetch is now cached for an hour instead of being retried on every admin request
- Added: CI workflow on every pull request (PHP lint, named-argument check, YAML validation, action-pinning guard)
2.0.10
- Docs: corrected the FAQ section heading so it is included in the release manifest, and linked the published PHPDoc API documentation
2.0.9
- Added secure self-hosted plugin updates via GitHub with SHA256 checksum verification
- Added an automated release workflow (builds the ZIP, generates the manifest and deploys to gh-pages on tag push)
- Raised the minimum WordPress version to 6.9 and "Tested up to" to WordPress 7.0
- Switched license metadata to the SPDX identifier
GPL-2.0-or-laterwith the HTTPS license URI - Added PHPDoc-generated API documentation, built and deployed to gh-pages on release
- Security: prevented path traversal in the
[jsvg]nameattribute (now sanitized withsanitize_file_name()/basename()) - Hardening: enabled
declare(strict_types=1), tightened parameter/return types, guarded the SVG file read and removed dead code
2.0.8
- PHP warnings fixed "Undefined variable ..."
2.0.7
- Tested up to WP v6.8
2.0.6
- Making use of wp_rand()
- Fix Stable tag
2.0.5
- README.md version update
2.0.4
- README.md meta data update
2.0.3
- Plugin meta data update
2.0.2
- README.md update
2.0.1
- Network support
2.0.0
- PHP 8.3+
- WP v6.7+
- wp-content/uploads folder support
1.0.0
- Initial Release