Dixlase Core v0.1.14

Plugin API — Added

• Ten elements that plugins and themes already used are now listed in PLUGIN-API.md, so a reference to any of them is covered by the Plugin and Theme Exception (#603, fixes #594): App\Helpers\AdminHelper, App\Services\RevisionService, App\Presenters\Admin\RevisionDiffPresenter, App\Presenters\Admin\ContentEditorPresenter, load_plugin_assets(), @cspNonce, the front.ip middleware, custom.custom_files_dir, the plugin.capabilities / linkable.providers / localized-url.providers tags, and the themes::layouts.app / themes::layouts.preview layouts. ContentEditorPresenter, load_plugin_assets() and render_x_cloak_style() gain their @api tags. Core's own translation keys and the multilingual_content block of plugin.json are recorded as deliberately not promised.

Fixed

• The media selector pages through the whole library (#601, fixes #600). It showed only the 20 newest items, so "Insert image" in the content editor and every x-media.picker could not reach older media. It now has previous / next buttons and the page position, and the selection is kept while moving between pages. Plugins and themes keep using openMediaSelector() and the media-selected event unchanged.

Upgrading

Nothing to do by hand. This release adds no migration, so dls:core:update applies VERSION and dixlase.json together as usual. The bundled theme stays at v0.4.1.

---

Plugin API — 追加

• プラグインとテーマがすでに使っていた 10 件を PLUGIN-API.md に載せました。これらへの参照は、プラグインとテーマの例外の対象になります(#603、#594 を修正)。App\Helpers\AdminHelper、App\Services\RevisionService、App\Presenters\Admin\RevisionDiffPresenter、App\Presenters\Admin\ContentEditorPresenter、load_plugin_assets()、@cspNonce、ミドルウェアの front.ip、custom.custom_files_dir、タグの plugin.capabilities / linkable.providers / localized-url.providers、レイアウトの themes::layouts.app / themes::layouts.preview です。ContentEditorPresenter、load_plugin_assets()、render_x_cloak_style() に @api タグを付けました。core の翻訳キーと、plugin.json の multilingual_content は、あえて約束しないものとして記録しました。

修正

• メディア選択で、ライブラリのすべてのメディアをページを送って選べるようにしました(#601、#600 を修正)。これまでは新しい 20 件しか出ず、コンテンツエディタの「画像を挿入」からも、どの x-media.picker からも、古いメディアを選べませんでした。前へ・次へのボタンと今のページ位置を出し、ページを移っても選択は残ります。プラグインとテーマは、openMediaSelector() と media-selected イベントをそのまま使えます。

更新について

手で行う作業はありません。このリリースにはマイグレーションがないので、dls:core:update はいつもどおり VERSION と dixlase.json をまとめて更新します。同梱テーマは v0.4.1 のままです。

Dixlase Core v0.1.13

Added

• The content editor has an "Insert image" button (#570). It opens the media library and puts the chosen item at the cursor: ![alt](path) in Markdown, an <img> with its width, height and loading="lazy" in HTML and Blade, and a link for a file that is not an image. Paths are root-relative, so content survives a change of domain. The alt text is the item's own, falling back to its name. insertImage="false" turns the button off.

Changed

• <x-form-content-editor> is the one content editor (#569). It can now carry a split-pane live preview, the CSS / JS tabs of the HTML editor, a fixed list of editor types, starter templates per language and file storage under one directory — each optional — and its Alpine data is the registered contentEditor component, which is ready for the CSP build. The Markdown, HTML and Blade editors share one field. The front page create and edit screens use it, and their own splitPaneEditor and frontPageCreate components are gone. <x-content-editor.storage-info> talks to the editor through window events, so it works from a sidebar. Every existing prop keeps working, so a plugin that embeds the component needs no change; inlineMarkdownPreview turns off the side-by-side Markdown view for a screen that has a preview of its own.

• A single line break in Markdown now renders as a line break (#584). It shows as <br> on the page, in the server preview and in the editor's browser preview. Japanese is written a clause per line, and CommonMark joined such lines into one run of text, so a page that looked right in the editor came out as a wall of text. This changes how existing Markdown content renders — pages, front pages and plugin content alike — so a page that relied on CommonMark joining its lines will look different after the update. Read "Upgrading" below.

Fixed

• Supported locale codes (ja, en) are reserved route slugs. They are the first segment of a localized URL, but a plugin's URL prefix or the admin URL could be set to one, which took the site's own language routing away from it. A plugin that refused them on its own no longer needs to (#551).

• Database cleanup reads a plugin's entries from config/admin/database-cleanup.php, the place the documentation, DeclaresVerifier and dls:plugin:permissions all use. It read config/database-cleanup.php, so no plugin that followed the documented rule had its old rows cleaned up, and nothing reported the mismatch. The old path is still read as a fallback, so a plugin that used it keeps working (#550).

• Changing a role's access to an admin screen is recorded in the audit log. The role / permission matrix and the per-menu reset button wrote their overrides straight from the controller, so one of the few settings that changes what another account can do left no audit_logs row at all. Both paths now go through an action and record the effective values before and after, keyed by menu key, under role_changed. A save that changes nothing writes no row. The matrix is also validated before anything is written, so a form rejected for giving edit permission below view permission no longer leaves the values it rejected saved (#474).

• Creating, revoking and regenerating an API key is recorded in the audit log. The three operations wrote only to the admin_activity file log, which reads as "recorded" while the tamper-evident trail had nothing — and an API key is a credential that can act on the site without a login. They now go through actions and write api_key_created, api_key_revoked and api_key_regenerated, naming the key by id and name and, for a regeneration, both the old and the new id. No key material (the plain key, its hash or its prefix) is ever put in the row. The file log stays as the request trace it always was (#476).

• A confirmation modal that submits a form no longer stays in its saving state when the browser refuses the submit, as it does for an empty required field (#580). The modal closes and the browser points at the field; when the field sits in the collapsed right sidebar, the sidebar is opened first so the message can be shown. Before this, both buttons stayed disabled and the only way out was to reload the page — on every admin screen that saves through a confirmation modal, in core and in plugins.

• The editor type cards of the content editor stay on one row when the right sidebar narrows the editor (#582). They wrapped onto a second row and pushed the editor's body down.

• A front page can see the member signed in to the admin panel (#585). The guard-aware session driver keeps the admin login in members_sessions and a front request's session in sessions under one cookie, so auth('member') was false on the front: the admin bar never appeared on a theme page, the maintenance banner never appeared, and the lockdown did not recognise the member either. The new App\Services\Auth\SignedInMemberResolver reads the member behind the shared session id. It is read-only, so the two session rows stay separate and the CSRF token still belongs to the row the page was rendered against. The service is on the Plugin API surface (PLUGIN-API.md section 9.2), so a plugin or theme can ask the same question.

Internal

• A core deploy that moves the bundled theme's locked version no longer leaves the theme without its built assets. Composer installs the theme from an archive that carries neither .git nor the build output, and the deploy's re-adoption step restores only the .git half: resources/assets/ is gitignored, so neither the archive nor the git checkout holds it. The re-adoption therefore reported success while every site served pages with no theme stylesheet and no theme script tag at all — at HTTP 200, and within a few hundred bytes of the normal page size, so neither a status check nor a size check noticed. The deploy now restores the directory from the copy the theme's own deploy already keeps under _shared/themes/, the same way it restores core's own build, and when there is no copy to restore from it says so and the run goes red rather than reporting a clean deploy (#539).

• The bundled theme moves to v0.4.1. That release adds a CSP self-audit test and a manual trigger for the theme's deploy workflow, and changes no runtime code. composer.lock has to name the theme's newest release or the release build refuses to produce the ZIP, which is why the bump rides along here.

Upgrading

Nothing to do by hand. This release adds no migration, so dls:core:update applies VERSION and dixlase.json together as usual, and a core update never changes an installed theme.

Read #584 before updating a site with hand-written Markdown. A single line break now renders as a line break, which is the behaviour the editor's preview always suggested — but content written against the old behaviour, where CommonMark joined consecutive lines into one paragraph, will render with the breaks it was written with. Nothing is lost and nothing needs editing; the text simply wraps where its lines do. A page whose source was hard-wrapped at a fixed column is the case worth looking at.

The bundled theme's lock moves from v0.4.0 to v0.4.1. A site that installed the theme already keeps the copy it has — a core update never touches an installed theme.

The two audit entries start recording from the moment the release is installed; they do not backfill rows for changes made before it.

---

追加

• コンテンツエディタに「画像を挿入」ボタンが付きました（#570）。メディアライブラリを開き、選んだものをカーソルの位置に入れます。Markdown は ![代替テキスト](パス)、HTML と Blade は幅・高さと loading="lazy" つきの <img>、画像でないファイルはリンクになります。パスはドメインを含まないので、ドメインが変わっても切れません。代替テキストはその項目のものを使い、無ければ名前を使います。insertImage="false" でボタンを消せます。

変更

• <x-form-content-editor> が、ただ 1 つのコンテンツエディタになりました（#569）。左右分割のライブプレビュー、HTML エディタの CSS／JS タブ、エディタタイプの固定の一覧、言語ごとのひな形、1 つのディレクトリへのファイル保存を持てます（どれも任意）。Alpine のデータは登録済みの contentEditor コンポーネントで、CSP ビルドに対応した形です。Markdown・HTML・Blade のエディタは 1 つの入力欄を共有します。フロントページの作成と編集の画面はこれを使い、独自の splitPaneEditor と frontPageCreate はなくなりました。<x-content-editor.storage-info> は window のイベントでエディタとやり取りするので、サイドバーに置けます。これまでの属性はすべてそのまま使えますので、このコンポーネントを埋め込んでいるプラグインに変更は要りません。inlineMarkdownPreview は、自前のプレビューを持つ画面で Markdown の左右表示を切ります。

• Markdown の 1 回の改行が、改行として表示されるようになりました（#584）。ページ、サーバーのプレビュー、エディタのブラウザのプレビューのどれでも <br> になります。日本語の文章は 1 節ごとに改行して書くことが多いのですが、CommonMark はその行をつなげていたため、エディタでは整って見えるページが、表示では 1 つの塊になっていました。これは既存のコンテンツの見え方を変えます。ページ、フロントページ、プラグインのコンテンツのどれも対象で、CommonMark が行をつなげることを前提に書いたページは、更新後に見た目が変わります。下の「更新について」をお読みください。

修正

• 対応している言語コード（ja、en）を、URL の予約語にしました。言語つき URL の先頭の区切りなのに、プラグインの URL のプレフィックスや管理画面の URL に設定でき、サイト自身の言語のルーティングを奪えてしまう状態でした。自前でこれを拒んでいたプラグインは、その確認がいらなくなります（#551）。

• DB のクリーンアップが、プラグインの項目を config/admin/database-cleanup.php から読むようになりました。ドキュメント、DeclaresVerifier、dls:plugin:permissions はどれもこの場所を使います。これまでは config/database-cleanup.php を読んでいたため、ドキュメントどおりに置いたプラグインの古い行は消されず、その食い違いを知らせるものもありませんでした。古い場所も予備として読むので、そちらを使っていたプラグインはそのまま動きます（#550）。

• ロールが管理画面に到達できるかどうかの変更を、監査ログに記録するようになりました。ロール / 権限のマトリクスとメニュー単位のリセットボタンは、コントローラから直接オーバーライドを書いていたため、他のアカウントにできることを変える数少ない設定が audit_logs にまったく残っていませんでした。どちらの経路も Action を通し、メニューキーごとの変更前後の実効値を role_changed として記録します。何も変わらない保存では行を書きません。あわせて、書き込みの前にマトリクス全体を検証するようにしたので、編集権限が表示権限より低いとして却下されたフォームが、却下した値を保存したままにすることも無くなりました（#474）。

• API キーの作成・失効・再生成を、監査ログに記録するようになりました。この 3 つの操作は admin_activity のファイルログにしか書いておらず、改ざん検知の対象である監査ログには何も無いのに「記録されている」ように読めていました。API キーは、ログインを経ずにサイトに対して動ける資格情報です。これらを Action 経由にし、api_key_created / api_key_revoked / api_key_regenerated を書くようにしました。キーは id と名前で識別し、再生成では旧 id と新 id の両方を残します。鍵そのもの（平文・ハッシュ・前置き）は行に入れません。ファイルログは従来どおりリクエストの痕跡として残ります（#476）。

• フォームを送る確認のモーダルが、必須の欄が空のときのようにブラウザが送信を止めても、「保存中」のまま残らなくなりました（#580）。モーダルを閉じて、ブラウザがその欄を示します。閉じた右サイドバーの中の欄であれば、メッセージを表示できるように先にサイドバーを開きます。これまでは両方のボタンが無効のままになり、ページを再読み込みするしかありませんでした。確認のモーダルで保存するすべての管理画面が対象で、コアもプラグインも同じです。

• コンテンツエディタのエディタタイプのカードが、右サイドバーでエディタが狭くなっても 1 行に並ぶようになりました（#...

Dixlase Core v0.1.12

Fixed

• .env.example ends with a newline, so a setting appended to a copy of it with >> lands on its own line. Without it the setting continued the last line (HSTS_PRELOAD=falseAPP_KEY=base64:…), and CheckInstallationReady reads the key with /^APP_KEY=(.+)$/m — the file's own APP_KEY= line is empty and does not match either — so it found none, generated a key and redirected the request to its own URL. Any script that appends a setting to a fresh .env was affected, not only for APP_KEY. A unit test now pins the newline (#538).

Internal

• A deploy that moves the bundled theme's locked version no longer fails on a site whose theme directory is not group-writable, and a Composer failure no longer skips the rest of that site's deploy. The group write bit is set on themes/ after the ownership fix, on every deploy rather than once, because the theme's own deploy rsyncs its built assets back to mode 755 each time it runs. When Composer fails anyway, the deploy records the failure and carries on through the theme re-adoption, the asset copy, the permission fixes and the cache clears, instead of aborting mid-replacement and leaving the site serving a half-deleted theme as an HTTP 200 with a tiny body (#537).

• The bundled-theme check blocks before a release is published instead of failing after it. It used to run only inside the release build, which release: published triggers, so the earliest it could refuse was once the release was already public — and archives are attached only at that moment, so a refusal left a release that could never be given any. A new Bundled Theme Lock check now fails any pull request that changes VERSION while composer.lock names a theme release that is not the newest, and the release build warns and builds instead of refusing (#557).

• A pull request that changes only Markdown or only docs/ can be merged again. Two workflows produced required status checks from behind a pull_request path filter, and GitHub matches required checks by name against what was reported for the head commit — a workflow a filter skips reports nothing at all, so the requirement was never satisfied and the pull request stayed pending for ever (#561).

Upgrading

Nothing to do by hand. dls:core:update applies VERSION and dixlase.json together as usual, and a core update never changes an installed theme. The bundled theme is unchanged from 0.1.11 (v0.4.0).

Operators who install with the Docker installer: this release is what main carried, so a ./setup.sh run now lands on a released tree. The installer is separately moving its default from main to the newest release tag.

---

修正

• .env.example が改行で終わるようになり、そのコピーに >> で書き足した設定が独立した行に載るようになりました。これまでは書き足した設定が最後の行の続きになっていました(HSTS_PRELOAD=falseAPP_KEY=base64:…)。CheckInstallationReady は鍵を /^APP_KEY=(.+)$/m で読みますが、このファイル自身の APP_KEY= の行は空でそちらにも当たらないため、鍵を見つけられず、新しい鍵を生成してリクエストを同じ URL へリダイレクトしていました。新しい .env に設定を書き足すスクリプトはすべて、APP_KEY に限らず影響を受けていました。改行はユニットテストで固定しました(#538)。

内部

• 同梱テーマの lock が動くデプロイが、テーマのディレクトリにグループの書き込み権が無いサイトで失敗しないようになり、Composer が失敗してもそのサイトの残りの工程が飛ばされなくなりました。所有権の修正のあとに themes/ へグループの書き込みビットを立てます。一度ではなく毎回のデプロイで行います。テーマ側のデプロイが、実行されるたびにビルド済みのアセットをモード 755 で rsync し直すためです。それでも Composer が失敗した場合は、失敗を記録したうえで、テーマの再採用・アセットのコピー・権限の修正・キャッシュの破棄まで進みます。差し替えの途中で中断して、半分消えたテーマを HTTP 200 の小さな本文として配り続けることがなくなります(#537)。

• 同梱テーマの確認が、リリースの公開後に失敗するのではなく、公開前に止めるようになりました。これまではリリースのビルドの中だけで走っており、そのビルドの引き金は release: published なので、拒否できる最も早い時点がすでにリリースが公開されたあとでした。そして資材が添付されるのはその瞬間だけなので、拒否すると、二度と資材を付けられないリリースが残りました。新しい Bundled Theme Lock のチェックが、composer.lock が最新でないテーマのリリースを指している状態で VERSION を変えるプルリクエストを落とし、リリースのビルドは拒否せず警告してビルドするようになりました(#557)。

• Markdown だけ、あるいは docs/ だけを変えるプルリクエストが、ふたたびマージできるようになりました。2 本のワークフローが pull_request のパスのフィルタの後ろで必須ステータスチェックを出しており、GitHub は必須チェックを head コミットに対して報告されたものの名前で照合します。フィルタで飛ばされたワークフローは何も報告しないため、要件が満たされることがなく、プルリクエストが永久に pending のままになっていました(#561)。

更新について

手で行うことはありません。dls:core:update が VERSION と dixlase.json を今までどおり一緒に適用し、コアの更新はインストール済みのテーマを変えません。同梱テーマは 0.1.11 から変わっていません(v0.4.0)。

Docker インストーラで導入している運用者の方へ。このリリースは main が持っていた内容そのものなので、今 ./setup.sh を実行すればリリース済みのツリーに着地します。インストーラ側では別途、既定を main から最新のリリースタグへ移す作業を進めています。

Dixlase Core v0.1.11

Fixed

• The release carries its distribution archives again, and a new installation gets the theme's current release. The theme published v0.4.0 53 seconds before 0.1.10 was released, so composer.lock still named the theme's v0.3.0 and the release build refused to ship a theme that is not the newest (#517). 0.1.10 was therefore published with no assets at all: the versioned ZIP, the dixlase-core.zip alias that the static releases/latest/download/ link resolves to, and checksums.sha256 all answered 404, and the one-line installer fell back to its Composer path, which fails outright on a host without Composer. composer.lock now names the theme's v0.4.0.

Upgrading

If you were about to install 0.1.10, install this release instead. 0.1.10 has no downloadable archive and cannot be given one — archives are attached only at the moment a release is published — so its tag exists but nothing can be downloaded from it. 0.1.11 contains the same core code as 0.1.10 plus the moved theme lock.

Nothing to do by hand for an existing installation. dls:core:update applies VERSION and dixlase.json together as usual, and a core update never changes an installed theme — the bundled theme matters for new installations only. An operator who wants the theme's v0.4.0 on an existing site moves it with dls:theme:update.

Operators who deploy from git: a release that moves the theme lock makes the next deploy replace themes/DixlaseOnePage/ from the locked archive. On a site where that directory is not group-writable, Composer cannot complete the replacement and the deploy stops part-way (#537). Check the directory modes before deploying this release.

---

修正

• リリースが配布用のアーカイブをふたたび持つようになり、新規インストールがテーマの現在のリリースを得るようになりました。0.1.10 を公開する 53 秒前にテーマが v0.4.0 を公開したため、composer.lock はテーマの v0.3.0 を指したままで、リリースのビルドは最新でないテーマを出荷することを拒否しました(#517)。そのため 0.1.10 は資材が 1 つも付かない状態で公開されました。バージョン付きの ZIP、固定リンク releases/latest/download/ が解決する dixlase-core.zip、checksums.sha256 のいずれも 404 を返し、ワンライナーのインストーラは Composer 経路に切り替わりますが、これは Composer が無いホストでは失敗します。composer.lock はテーマの v0.4.0 を指すようになりました。

更新について

0.1.10 を入れようとしていた方は、このリリースを入れてください。 0.1.10 にはダウンロードできるアーカイブが無く、後から付けることもできません。アーカイブが添付されるのはリリースが公開される瞬間だけだからです。タグは存在しますが、そこから何もダウンロードできません。0.1.11 のコアのコードは 0.1.10 と同じで、テーマの lock が動いた分だけが違います。

すでにインストールされている環境で手で行うことはありません。dls:core:update が VERSION と dixlase.json を今までどおり一緒に適用し、コアの更新はインストール済みのテーマを変えません。同梱テーマが関係するのは新規インストールだけです。既存のサイトでテーマの v0.4.0 にしたい場合は、dls:theme:update で移してください。

git からデプロイしている運用者向けに 1 点。テーマの lock が動くリリースでは、次のデプロイが themes/DixlaseOnePage/ を lock のアーカイブから差し替えます。そのディレクトリがグループ書き込み可でないサイトでは、Composer が差し替えを完了できず、デプロイが途中で止まります(#537)。このリリースをデプロイする前に、ディレクトリの権限を確認してください。

Dixlase Core v0.1.10

This release has no downloadable archive. Install v0.1.11 instead.

The theme published v0.4.0 53 seconds before this release was published, so composer.lock still named the theme's v0.3.0 and the release build refused to ship a theme that is not the newest (#517). Archives are attached only at the moment a release is published, so this one cannot be given any after the fact. The tag and this page stay in place because the tag already deployed; 0.1.11 carries the same core code plus the moved theme lock. Where that check runs is #557.

このリリースにはダウンロードできるアーカイブがありません。v0.1.11 を入れてください。

このリリースを公開する 53 秒前にテーマが v0.4.0 を公開したため、composer.lock はテーマの v0.3.0 を指したままで、リリースのビルドが最新でないテーマの出荷を拒否しました(#517)。アーカイブが添付されるのはリリースが公開される瞬間だけなので、後から付けることはできません。タグはすでにデプロイされているため、タグとこのページはそのまま残します。0.1.11 のコアのコードはこれと同じで、テーマの lock が動いた分だけが違います。この確認が走る位置は #557 です。

---

Fixed

• dls:theme:list lists the installed themes again. It read theme_settings, the key/value store that holds the active theme id, instead of themes, so it stopped with Undefined property: stdClass::$name on any site with an active theme, and reported "no themes" on a site without one. It now shows each theme's directory, version and whether it is the active one (#508).

• Ten dls: commands describe themselves again in php artisan list and --help. Five showed a translation key that exists in no language file (command.theme_install.description and the like, also in their argument help), two showed the make:command placeholder Command description, and three showed nothing, because they set the description after Symfony had already read it. A feature test now fails on any dls: command whose description is empty, a placeholder or a key (#509).

• A theme can be linked to an extension source again after the one it came from was removed. Removing a source leaves its extensions unlinked, and dls:theme:update then told the operator to run dls:theme:download, which does not exist; a registered theme had no way back to a source. dls:theme:install <directory> --force --source=<id> now re-links it, and the update message names that command (#510).

Internal

• Every admin GET route core registers is opened in a feature test and asserted not to return 5xx, as both an ADMIN and an EDITOR. A page can pass its route and permission tests and still crash on open, because those do not run the request lifecycle — middleware, controller, view resolution, Blade compile — that a release regression surfaces in (#524).

Note for plugin and theme authors

The 0.1.8 section of the changelog now carries the two Plugin API entries that belonged to it: CspPolicyRegistry dropping sources that would weaken the site's policy (#494), and the deprecation of App\Traits\AuditableTrait, which will be removed in v0.2.0 (#477). Both changes shipped in 0.1.8, but their records had been left in [Unreleased]. Nothing about the code changed in this release — only where the changelog records it.

Upgrading

Nothing to do by hand. dls:core:update applies VERSION and dixlase.json together as usual, and a core update never changes an installed theme. composer.lock has not moved since 0.1.9, so a new installation gets the same theme release (v0.3.0) that 0.1.9 bundled.

---

修正

• dls:theme:list が、インストール済みのテーマをふたたび一覧するようになりました。themes ではなく、有効なテーマの id を持つキーと値の表 theme_settings を読んでいたため、テーマが有効になっているサイトでは Undefined property: stdClass::$name で止まり、無いサイトでは「テーマなし」と表示していました。各テーマのディレクトリ、バージョン、有効かどうかを表示します(#508)。

• 10 個の dls: コマンドが、php artisan list と --help でふたたび説明を表示するようになりました。5 つはどの言語ファイルにも無い翻訳キー（command.theme_install.description など。引数の説明も同様）を、2 つは make:command の仮の文言 Command description を表示し、3 つは Symfony が説明を読み終えたあとに設定していたため何も表示していませんでした。説明が空・仮の文言・キーの dls: コマンドがあれば落ちる Feature テストを追加しました(#509)。

• 入手元の拡張機能ソースを削除したあとでも、テーマをソースに紐付け直せるようになりました。ソースを削除するとその拡張機能は紐付けが外れ、dls:theme:update は存在しない dls:theme:download を実行するよう案内していました。登録済みのテーマをソースに戻す方法もありませんでした。dls:theme:install <directory> --force --source=<id> で紐付け直せるようにし、更新時のメッセージもこのコマンドを案内します(#510)。

内部

• コアが登録する管理画面のすべての GET ルートを Feature テストで開き、ADMIN と EDITOR のどちらでも 5xx を返さないことを確かめるようにしました。ルートや権限のテストは、リリース時の退行が現れる経路（ミドルウェア → コントローラ → ビューの解決 → Blade のコンパイル）を通さないため、そこを通っているページでも開いた瞬間に落ちることがあります(#524)。

プラグイン・テーマの作者向けの注記

CHANGELOG の 0.1.8 の節に、本来そこに属していた Plugin API の 2 項目を収めました。サイトのポリシーを弱める値を CspPolicyRegistry が捨てるようになったこと(#494)と、App\Traits\AuditableTrait を非推奨にし v0.2.0 で削除すること(#477)です。どちらも 0.1.8 で出荷された変更ですが、その記録が [Unreleased] に残ったままになっていました。このリリースでコードが変わったわけではなく、CHANGELOG のどこに記録されるかが変わっただけです。

更新について

手で行うことはありません。dls:core:update が VERSION と dixlase.json を今までどおり一緒に適用し、コアの更新はインストール済みのテーマを変えません。composer.lock は 0.1.9 から動いていないので、新規インストールは 0.1.9 が同梱していたものと同じテーマのリリース(v0.3.0)を得ます。

Dixlase Core v0.1.9

Security

• Extension verification compares the manifest's files hashes before it resolves the signer's public key. The two halves of verification answer different questions and only the signature needs a key, so a result reached without one now still reflects the files on disk, and pending narrows to its proper meaning: the files are intact but the signer could not be confirmed.

Fixed

• A new installation gets the theme's current release. Every delivery path — the one-line installer, the ZIP download, composer create-project — installs the version composer.lock records, and that lock had never moved since the theme's first release, so 0.1.7 and 0.1.8 shipped a theme from 2026-09-26. The lock now points at the theme's latest release, and a release build stops rather than ship an outdated one (#517).

Internal

• scripts/check-bundled-theme.php compares the locked theme version against the theme's newest stable tag; release.yml runs it, with an opt-out for deliberately rebuilding an older tag. docs/development/releasing.md and its Japanese mirror describe the pre-release step (#517).

Upgrading

Nothing to do by hand. dls:core:update applies VERSION and dixlase.json together as usual, and a core update never changes an installed theme — the bundled theme matters for new installations only.

Operators who deploy from git: since 0.1.8, a push to main no longer deploys. Production moves when a release is published, or when the deploy workflow is dispatched at a tag.

---

セキュリティ

• 拡張機能の検証が、署名者の公開鍵を解決する前にマニフェストの files のハッシュを照合するようにした。検証の 2 つの半分は別々の問いに答えるもので、鍵が必要なのは署名の側だけである。そのため鍵なしで到達した結果もディスク上のファイルを反映するようになり、pending は本来の意味に狭まる。ファイルは無傷だが署名者を確認できなかった、である。

修正

• 新規インストールがテーマの現在のリリースを得るようにした。ワンライナーのインストーラ、ZIP のダウンロード、composer create-project のどの経路も composer.lock が記録している版を入れるが、その lock はテーマの最初のリリース以降一度も動いていなかった。そのため 0.1.7 と 0.1.8 は 2026-09-26 のテーマを出荷していた。lock をテーマの最新のリリースに向け、古いものを出荷しようとするリリースのビルドは止まるようにした(#517)。

内部

• scripts/check-bundled-theme.php が、lock のテーマの版をテーマの最新の安定版タグと比べる。release.yml がそれを実行し、古いタグを意図して作り直すときは省ける。docs/development/releasing.md とその日本語版に、リリース前の手順を書いた(#517)。

更新について

手で行うことは無い。dls:core:update が VERSION と dixlase.json を今までどおり一緒に適用する。コアの更新はインストール済みのテーマを変えないので、同梱テーマが関係するのは新規インストールだけである。

git からデプロイしている運用者向けに 1 点。0.1.8 以降、main への push はもうデプロイしない。 本番が動くのは、リリースが公開されたとき、またはデプロイのワークフローをタグ指定で手動起動したときである。

Dixlase Core v0.1.8

The first release that reaches a production site through the release itself. Until now a merge to main deployed; the deploy workflow is now triggered by a published release and moves each site to that release's tag (#529).

Added

• The extension rescan and the audit-log integrity check run on a schedule. A status that gets worse — a health score dropping, a signature that stopped verifying, an audit chain that no longer validates — raises a banner in the admin that clears once it is resolved (#500)
• dls:extensions:reconcile-versions brings the version recorded for each installed plugin and theme back in line with its manifest on disk and reports which ones moved. --dry-run reports the drift and exits non-zero, so it can be used as a check (#522)

Changed

• A production site is deployed from a published release, not from main. The deploy workflow triggers on release: published; it also accepts a manual run with a tag, which is how a specific version is placed deliberately. A merge to main no longer deploys anything (#529)
• Core carries one release workflow again. The second one triggered on every v* tag, failed on every tag it ran for, and would have created the GitHub release itself with GITHUB_TOKEN — which raises no release: published for anything else (#528)
• An extension installs into the directory its manifest names, instead of a name rebuilt from the slug (#503)
• AuditableTrait is deprecated. Audit entries are produced in the action layer only (#484)

Fixed

• The version an extension records in the database is reconciled with its manifest. A deploy places files but installs nothing, so the recorded version stayed at whatever the install wrote — and that value decides whether the admin panel offers an update. A stale row therefore offered an update to a version that was already installed, and accepting it deletes the extension directory along with the nested .git a deploy owns. The reconciliation happens during a rescan, so the admin Rescan button, the daily schedule and a deploy all repair it (#521, #522, #525)
• The deploy visits every production site and fails instead of skipping one it cannot resolve. Each site's layout — Docker installer or shared stack — is resolved per site (#516)
• A CSP source declared by an extension is validated before it reaches the policy, and a plugin's web routes are registered only on the sites where that plugin is enabled (#501)
• The health and signature gate that guards the admin screens applies to the CLI as well (#498)
• A plugin's autoload.files entries are loaded only while the plugin is enabled (#499)
• Every dangerous API call counts toward the health score, not only the first one found in a file (#497)
• The CLI's stale-download warning is translated instead of being emitted in English (#489)

Documentation

• The plugin security documentation describes the checks the code actually performs (#496)

Upgrading

Nothing to do by hand. dls:core:update applies VERSION and dixlase.json together as usual.

Operators who deploy from git should know that a push to main no longer deploys. Production moves when a release is published, or when the deploy workflow is dispatched at a tag.

---

リリースそのものを通して本番サイトに届く最初のリリースである。これまでは main へのマージがデプロイしていた。デプロイのワークフローは公開されたリリースで発火し、各サイトをそのリリースのタグへ移すようになった(#529)。

追加

• 拡張機能の再スキャンと監査ログの整合性の照合を定期実行するようにした。状態が悪くなったとき — 健全性のスコアが下がった、署名が検証できなくなった、監査の連鎖が検証できなくなった — 管理画面にバナーを出し、解消したら消える(#500)
• dls:extensions:reconcile-versions を追加した。インストール済みの各プラグインとテーマについて、記録された版をディスクのマニフェストと揃え、どれが動いたかを報告する。--dry-run はずれを報告して非ゼロで終了するので、確かめるために使える(#522)

変更

• 本番サイトは main ではなく、公開されたリリースからデプロイされる。 デプロイのワークフローは release: published で発火する。タグを指定した手動実行も受け付け、特定の版を意図して置くときはこれを使う。main へのマージはもう何もデプロイしない(#529)
• コアのリリースのワークフローを 1 本に戻した。2 本目は v* のタグごとに発火し、走ったすべてのタグで失敗し、しかも GITHUB_TOKEN で GitHub のリリースを自分で作るものだった。その方法で作られたリリースは他に対して release: published を発火させない(#528)
• 拡張機能は、slug から組み立てた名前ではなく、マニフェストが名指しているディレクトリにインストールされる(#503)
• AuditableTrait を非推奨にした。監査の記録は Action 層だけで作られる(#484)

修正

• 拡張機能がデータベースに記録している版を、マニフェストと揃えるようにした。デプロイはファイルを置くだけでインストールは何もしないので、記録された版はインストール時の値のままだった。しかもその値が、管理画面が更新を提示するかどうかを決めている。つまり古い行はすでに入っている版への更新を提示し、それを受け入れると拡張機能のディレクトリと、デプロイが所有する入れ子の .git が消える。揃える処理は再スキャンの中で行うので、管理画面の 再スキャン ボタン・日次の定期実行・デプロイのすべてが直す(#521・#522・#525)
• デプロイが本番サイトを全て回り、解決できないサイトを飛ばす代わりに失敗するようにした。各サイトの構成 — Docker のインストーラ構成か共有の構成か — をサイトごとに解決する(#516)
• 拡張機能が宣言した CSP の値を、ポリシーに入る前に確かめるようにし、プラグインの web ルートを、そのプラグインが有効なサイトだけで登録するようにした(#501)
• 管理画面を守っている健全性と署名の関門を CLI にもかけた(#498)
• プラグインの autoload.files のエントリを、そのプラグインが有効な間だけ読み込むようにした(#499)
• 危険な API の呼び出しを、ファイル内で最初に見つかった 1 件だけでなく、すべて健全性のスコアに数えるようにした(#497)
• CLI の「ダウンロードが古い」警告を、英語のまま出すのではなく翻訳するようにした(#489)

ドキュメント

• プラグインのセキュリティの文書を、コードが実際に行っている確認どおりに書き直した(#496)

更新について

手で行うことは無い。dls:core:update が VERSION と dixlase.json を今までどおり一緒に適用する。

git からデプロイしている運用者向けに 1 点。main への push はもうデプロイしない。 本番が動くのは、リリースが公開されたとき、またはデプロイのワークフローをタグ指定で手動起動したときである。

Dixlase v0.1.7

Dixlase v0.1.7 is a patch release for the v0.1 beta. It fixes resizing of the text fields in the front-page editor.

Update

From the admin panel: Settings → System → Updates → Check now, then update the core. A backup before updating is recommended. Sites installed with the Docker installer can also run ./update.sh.

Fixed

• In the front-page editor, a text field resized by hand keeps its size, and the CSS and JS fields show the resize handle. Until a field is resized by hand, it still grows to fit its content (#463).

Full details: CHANGELOG.md.

---

Dixlase v0.1.7 は v0.1 ベータのパッチリリースです。 フロントページのエディタで、入力欄のリサイズを直しました。

更新のしかた

管理画面の 全体設定 → システム → アップデート管理 → いますぐ確認 から、コアを更新してください。更新の前にバックアップを取ることをおすすめします。Docker インストーラで入れたサイトは ./update.sh でも更新できます。

修正

• フロントページのエディタで、手でリサイズした入力欄がその大きさを保つようにし、CSS と JS の欄にもリサイズのつまみを出すようにしました。手でリサイズするまでは、今までどおり内容に合わせて自動で伸びます(#463)。

詳しくは CHANGELOG.ja.md をご覧ください。

Dixlase v0.1.6

Dixlase v0.1.6 is a patch release for the v0.1 beta. It fixes theme admin screens that bounced to the dashboard, and offers the documentation and AI assistant instruction files under additional, more permissive licenses.

Update

From the admin panel: Settings → System → Updates → Check now, then update the core. A backup before updating is recommended. Sites installed with the Docker installer can also run ./update.sh. If your site caches routes (route:cache), rebuild the cache after updating.

Fixed

• A theme's own admin screens are reachable again. Their routes were registered outside Laravel's web group, so a signed-in operator was treated as a guest and sent back to the dashboard (#465).

License

• The user documentation is also available under CC BY 4.0 (code examples in it also under CC0 1.0), and the AI assistant instruction files (CLAUDE.md and similar) under CC0 1.0, as alternatives to the AGPL. The covered files are listed in the new Part 2 of LICENSE-EXCEPTIONS (version 1.2). Legal and policy documents, source code and configuration stay under their current terms (#460).

Changed

• The release ZIP no longer contains CLAUDE.md / CLAUDE.ja.md or internal working notes (#460).

Full details: CHANGELOG.md.

---

Dixlase v0.1.6 は v0.1 ベータのパッチリリースです。 テーマの管理画面がダッシュボードに戻されてしまう問題を直し、文書と AI アシスタント向けの指示ファイルを、よりゆるいライセンスでも提供するようにしました。

更新のしかた

管理画面の 全体設定 → システム → アップデート管理 → いますぐ確認 から、コアを更新してください。更新の前にバックアップを取ることをおすすめします。Docker インストーラで入れたサイトは ./update.sh でも更新できます。ルートをキャッシュしているサイト(route:cache)は、更新のあとにキャッシュを作り直してください。

修正

• テーマ独自の管理画面に、再び入れるようになりました。ルートが Laravel の web グループの外で登録されていたため、ログインしている運営者がゲストとして扱われ、ダッシュボードに戻されていました(#465)。

ライセンス

• 利用者向けの文書を CC BY 4.0(文書の中のコードの例は CC0 1.0)でも、AI アシスタント向けの指示ファイル(CLAUDE.md など)を CC0 1.0 でも、AGPL に代わる選択肢として提供します。対象のファイルは LICENSE-EXCEPTIONS(版 1.2)に新しく足した第 2 部に記載しています。法律・方針の文書、ソースコード、設定は今までどおりです(#460)。

変更

• リリースの ZIP に CLAUDE.md / CLAUDE.ja.md と内部の作業メモを入れないようにしました(#460)。

詳しくは CHANGELOG.ja.md をご覧ください。

Dixlase v0.1.5

Dixlase v0.1.5 is a maintenance release for the v0.1 beta. It makes plugin and theme updates and rollbacks leave a complete record, makes a rollback undo everything the update added, and warns before an outdated download is installed.

Update

From the admin panel: Settings → System → Updates → Check now, then update the core. A backup before updating is recommended (the updates screen links to it). Sites installed with the Docker installer can also run ./update.sh.

Fixed

• Update records: every plugin and theme update and rollback now writes a version-history entry and an audit entry, whether it ran from System → Updates, the rollback button on the Plugins and Themes screens, or the CLI. Failed updates and rollbacks are audited too, and runs started from the admin screens record who started them.
• After a rollback: the version you rolled back from is offered as an update again right away, for extensions and for the core. Before, it disappeared until the next update check.
• Rollback and migrations: rolling back an extension undoes every migration its update added. An update that added several migrations used to be only partly undone.
• Update log: storage/logs/extension-update.log keeps earlier runs instead of being overwritten.

Added

• Outdated downloads: a plugin or theme that was downloaded but not installed, and is older than the latest release on its source, is marked in the list and in the install confirmation, and dls:plugin:install / dls:theme:install print a warning. To install the latest, delete the download and add the extension again.

Notes

• Everything in this release takes effect as soon as the core is on v0.1.5, including the record of the first extension update or rollback you run afterwards.
• For extension authors: docs/development/plugins/updates-and-rollback.md describes what an update and a rollback do, and why update seeders are not undone.

Full details: CHANGELOG.md.

---

Dixlase v0.1.5 は v0.1 ベータのメンテナンスリリースです。 プラグインとテーマの更新・ロールバックを漏れなく記録し、ロールバックで更新の内容をすべて戻し、古いダウンロードをインストールする前に知らせるようにしました。

更新のしかた

管理画面の 全体設定 → システム → アップデート管理 → いますぐ確認 から、コアを更新してください。更新の前にバックアップを取ることをおすすめします(アップデート管理の画面に案内があります)。Docker インストーラで入れたサイトは ./update.sh でも更新できます。

修正

• 更新の記録: プラグインとテーマの更新・ロールバックは、システム → アップデート管理、プラグイン・テーマの画面のロールバックのボタン、CLI のどこから実行しても、版の履歴と監査ログを残すようになりました。失敗した更新とロールバックも監査ログに残し、管理画面から始めたものは実行した人も記録します。
• ロールバックの後: 拡張機能でもコアでも、戻す前の版をすぐにまた更新として案内します。以前は次の更新の確認まで消えていました。
• ロールバックとマイグレーション: 拡張機能のロールバックで、更新で入ったマイグレーションをすべて戻します。マイグレーションを複数足した更新は、以前は一部しか戻りませんでした。
• 更新のログ: storage/logs/extension-update.log を上書きせず、以前の実行分を残します。

追加

• 古いダウンロード: ダウンロードしただけでインストールしていないプラグインやテーマが、取得元の最新リリースより古いとき、一覧とインストールの確認画面に表示し、dls:plugin:install / dls:theme:install も警告を出します。最新を入れるには、ダウンロード済みのものを削除してから追加し直してください。

補足

• このリリースの変更は、コアが v0.1.5 になった時点から効きます。その後に行う最初の拡張機能の更新やロールバックも記録されます。
• 拡張機能の開発者向け: docs/ja/development/plugins/updates-and-rollback.md に、更新とロールバックが何をするか、更新用のシーダーがなぜ戻らないかを書きました。

詳しくは CHANGELOG.ja.md をご覧ください。