Add the two screenshots from the assets/ folder to both README.md (GitHub) and readme.txt (WordPress.org), and commit the assets/ directory so the relative image references resolve.
The FilterPanel was being mounted as a free-floating sibling of the block via an `editor.BlockEdit` HOC. In WordPress, a `PanelBody` only renders in the sidebar when wrapped in `<InspectorControls>`; without that wrapper, the panel renders wherever it lands in the React tree, which here was the editor canvas.
Move the InspectorControls mount into the Edit component itself (the idiomatic place for an own block to expose sidebar controls), and drop the `editor.BlockEdit` filter from `src/index.js`. Add an Edit test that pins the contract: the filter panel must mount inside InspectorControls and never float outside it. Add a manual jest mock for @wordpress/block-editor so the Edit test can render in an environment without WordPress globals.
Two related bug fixes:
- Transforms: `type: 'block'` callbacks must return a block instance created by createBlock; the previous code returned raw attribute objects which WordPress silently ignored, so the toolbar block-switcher transforms never fired. Update tests to assert on `result.name` and `result.attributes`. Add a manual jest mock for @wordpress/blocks since the package is provided at runtime via dependency-extraction-webpack-plugin.
- Filter CSS: the SCSS used a descendant combinator (`.wp-block-ksolo-image-filter .has-filter-warm img`) but the JSX puts both classes on the same element, so the filter rule never matched and picking a filter had no visual effect on the editor or the front end. Target the inner <img> by its stable class pair (`.ksolo-image-filter-img.has-filter-<slug>`) instead. Add a regression test that reads the compiled CSS and asserts the selectors are present for every preset.
Keith Solomon
Keith Solomon