- 1.07: Exclude runtime detritus from the repository and bump 1.06 -> 1.07. The 1.06 push published an error_log file that was sitting in the plugin directory on the live server. Its contents were harmless – a single Composer deprecation notice from 10 August 2026, no credentials, no paths beyond /usr/local/bin/composer – but it had no business in a source repository, and the mechanism that put it there will keep doing so. PHP writes error_log into whatever directory the executing script lives in, so the file reappears on its own after any deletion; lh-github-publisher then runs git add -A over the directory as it stands. Deleting it fixes nothing past the next PHP notice, which makes .gitignore the only durable answer.
The entry is generalised past the one file that caused it: error_log, *.log and .DS_Store. The principle is that the plugin directory on a live server accumulates files that are not source, and the publisher has no way to tell them apart. Anything of that kind belongs here rather than being caught by review each time, because review is exactly what failed at 1.06 – the pre-push security scan checked the code for secrets and never questioned which files were in the directory at all. list-plugin-files filters by extension and does not show an extensionless error_log, so the file was invisible to the obvious check.
Worth recording for the next push of any plugin: enumerate what will actually be committed, not what the file-listing ability chooses to show. A force push replaces the branch outright, so re-pushing at 1.07 removes the file from history rather than merely deleting it in a later commit.
No PHP behaviour changes. The two code files carry the version number and nothing else.
- 1.06: Add a .gitignore excluding vendor/, correct readme.md's description, and bump 1.05 -> 1.06. lh-github-publisher pushes a plugin by running git init, git add -A and a force push over the plugin directory exactly as it sits on disk, then deleting .git afterwards. There is no .distignore, no exclusion filter and no build step anywhere in that path, so whatever is in the directory is what lands in the repository. For this plugin that would mean the entire automattic/blocks-engine-php-transformer tree, several hundred files of third-party code, committed as though it were ours and re-committed wholesale on every future push. A .gitignore file is the only lever available, since it lives on disk and therefore survives between pushes while .git does not.
vendor/ is the only entry. composer.json and composer.lock stay tracked, which is what makes the exclusion safe rather than merely tidy: a clone has everything needed to reconstruct the exact dependency tree with composer install. The trade-off is accepted deliberately – a fresh clone is inert until that command is run, and three of the four abilities return their missing-vendor WP_Error until then. This is the GitHub-only position; distributing through wordpress.org, where a user cannot run composer at all, needs a deploy workflow that installs dependencies before the SVN sync, and that does not exist yet.
readme.md's description was written when the plugin only converted one way and understated what it now does: it converts in both directions and has a save path that takes post IDs. The installation section gains a sentence stating plainly that vendor/ is absent from the repository by design, so someone cloning it does not read the composer step as optional housekeeping. readme.txt moves its Stable tag and trimmed changelog forward per standing rule 8.
No PHP behaviour changes. The two code files carry the version number and nothing else: the plugin header and plugin_version(), which must agree or the changelog automation tags entries against a stale version.
- 1.05: Reclassify this plugin as editorial rather than developer tooling, and move the capability gate accordingly. permission_check() drops from install_plugins to edit_posts, per the LH convention that editor-facing content-operation abilities are gated to edit_posts. Because convert-post-to-blocks writes to real posts and previously relied on install_plugins as its only authorisation, it now also checks current_user_can('edit_post', $id) per individual post ID inside the loop, refusing that ID rather than the whole call – edit_posts alone says nothing about whether the caller may edit any particular post. The per-post check is added ahead of the gate change so there is no state in which the gate is open without it. Bump 1.04 -> 1.05.
- 1.04: Per Peter's decision: moves the combined convert+save ability from lh-portfolio (where it started as a temporary, portfolio-specific fix for task #147196) into lh-mcp-block-transformer as a permanent, generalized ability — lh-mcp-block-transformer/convert-post-to-blocks. Works on any post type now, not just lh-portfolio entries. The confirm-gate simplifies from lh-portfolio's 'published root entry' concept (which doesn't generalize — most post types have no root/child hierarchy) to the more universal 'already-published post', mirroring the same confirmed:true semantics. Same underlying FormatBridge call and same core safety guarantee as before: only a post ID ever crosses the MCP boundary, never the block markup itself, since that transcription is what corrupted a live entry earlier in task #147196. Version bump to 1.04.