You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if this is a Kirby or a kirbyup issue:
Developing a plugin that already contains built assets (index.css specifically) running npx kirbyup@next dev src/index.js as noted in the migration guidelines will load the existing CSS file AND the dynamically rendered styles.
So you end up with merged old and new styles.
Expected behavior
Kirby should only load the up-to-date live styles.
My guess is, Kirby needs to ignore an existing index.css file if index.dev.js is present.
To reproduce
Take an existing panel plugin with generated assets and run npx kirbyup@next dev src/index.js.
Create contradicting styles for an element defined in the static assets (setting a different background colour so instance).
Both style definitions – old and new – will be present in the panel.
Your setup
Kirby Version
Kirby 6 Beta 1
Console output
Your system (please complete the following information)
Thanks @nilshoerrmann, confirmed, Kirby loads index.css regardless of index.dev.js.
The simple fix on our side would be to skip index.css whenever index.dev.js exists. That works for kirbyup dev, where Vite injects the CSS via JS. But kirbyup build --watch also writes index.dev.js and puts its CSS into index.css, so watch mode would lose all styles.
@johannschopplich could watch builds inline their CSS into index.dev.js (e.g. prepended as a <style> tag)? Then index.dev.js always carries its own styles and Kirby can simply ignore index.css next to it. As a bonus, watch mode would no longer overwrite the production index.css. Or do you see a better way?
I'd pair the files instead: when index.dev.js exists, Kirby loads index.dev.css (if non-empty) in place of index.css. kirbyup build --watch writes its CSS there, kirbyup dev writes none.
I see a problem with your idea: An injected <style> lands after the panel.css link, so in watch mode plugin styles would override panel.css – in production it's the other way around. Watch mode should behave like the production build, and its own stylesheet ensures that.
You'd only have to implement pairing in Plugins::css() and dev.css in the media route pattern. The kirbyup side is ready in johannschopplich/kirbyup#52. Both have to ship together, otherwise watch mode loses its styles on the new Kirby, or keeps the stale index.css on beta.1. 👍
Activity
[-]Plugin assets loading[/-][+]|v6] Plugin assets loading[/+]distantnative commentedon Oct 16, 2026
Thanks @nilshoerrmann, confirmed, Kirby loads
index.cssregardless ofindex.dev.js.The simple fix on our side would be to skip
index.csswheneverindex.dev.jsexists. That works forkirbyup dev, where Vite injects the CSS via JS. Butkirbyup build --watchalso writesindex.dev.jsand puts its CSS intoindex.css, so watch mode would lose all styles.@johannschopplich could watch builds inline their CSS into
index.dev.js(e.g. prepended as a<style>tag)? Thenindex.dev.jsalways carries its own styles and Kirby can simply ignoreindex.cssnext to it. As a bonus, watch mode would no longer overwrite the productionindex.css. Or do you see a better way?johannschopplich commentedon Oct 16, 2026
I'd pair the files instead: when
index.dev.jsexists, Kirby loadsindex.dev.css(if non-empty) in place ofindex.css.kirbyup build --watchwrites its CSS there,kirbyup devwrites none.I see a problem with your idea: An injected
<style>lands after thepanel.csslink, so in watch mode plugin styles would overridepanel.css– in production it's the other way around. Watch mode should behave like the production build, and its own stylesheet ensures that.You'd only have to implement pairing in
Plugins::css()anddev.cssin the media route pattern. The kirbyup side is ready in johannschopplich/kirbyup#52. Both have to ship together, otherwise watch mode loses its styles on the new Kirby, or keeps the staleindex.csson beta.1. 👍distantnative commentedon Oct 16, 2026
Sounds good. Will make the change for beta.2 - we will probably release it sometime mid next week. Will update you on any concrete date.