Rashed Hossain
Forum Replies Created
-
Hello @kalaganov5
I’m sorry to inform you that this forum is dedicated to free products only. If you are using the free version and need assistance or have any issues, feel free to ask here.
Hello @balavander
Thank you so much for your response. We will check and fix the issue as soon as possible.
Have a good day.
Hello @balavander
What I meant is that the latest version of Kirki might be conflicting with another plugin on your site. Could you share the list of active plugins so we can take a closer look?
Hello @balavander
We tested Kirki with the Goya theme across multiple environments and didn’t run into any issues. This looks like a conflict with another plugin.
Hello @delideli
Based on your information, I tested the Goya theme across several environments and didn’t encounter this issue. I also updated Kirki from version 5.x to 6.0.1, 6.0.2, and 6.0.3 without any problems.
It looks like this might be specific to your website—possibly a conflict with another plugin or customization.
Hi @delideli
Thanks for the detailed report — that behavior isn’t expected.
Just to clarify, Additional CSS is handled by the WordPress Customizer and is stored separately for each theme. So if it disappears, it usually points to a theme-related issue or a conflict during the Customizer save process.
That said, it could still be a compatibility issue with Kirki in certain setups. We’ll check this on our end as well, and if we’re able to reproduce it, we’ll make sure it gets fixed as soon as possible.
Hi @bulgeo
We’ve released a new version of Kirki—please update and check if the issue is resolved. If you’re still seeing the same problem, let me know.
To fix this, please update your setup as follows:
1. Use a boolean default value
‘default’ => false,instead of:
‘default’ => ‘off’,
2. Update the active_callback to use boolean
‘active_callback’ => [
[
‘setting’ => ‘breadcrumb_elementor_switch’,
‘operator’ => ‘==’,
‘value’ => true,
],
],
3. Change transport to refresh
‘transport’ => ‘refresh’,Using postMessage can prevent the Customizer from updating control visibility properly in some cases.
Thanks for sharing the details and your code.
The issue here is related to how the Checkbox_Switch value is handled in the latest Kirki version. While you’re using ‘on’ / ‘off’ in choices, Kirki internally works more reliably with boolean values for conditions in the Customizer.
To fix this, please update your setup as follows:
1. Use a boolean default value
‘default’ => false,instead of:
‘default’ => ‘off’,
2. Update the active_callback to use boolean
‘active_callback’ => [
[
‘setting’ => ‘breadcrumb_elementor_switch’,
‘operator’ => ‘==’,
‘value’ => true,
],
],
3. Change transport to refresh
‘transport’ => ‘refresh’,Using postMessage can prevent the Customizer from updating control visibility properly in some cases.
- This reply was modified 1 month, 1 week ago by Rashed Hossain.
Hello @luffy99
Thanks for pointing that out.
You’re right—
active_callbackrelies on PHP conditions, so it won’t reflect changes instantly in the Customizer preview. Real-time updates are only supported when using Kirki’sactive_callbackwith supported formats (JS-based conditions).We’ll review the documentation to make this behavior clearer and avoid confusion.
Hello @red_sun
Thanks for the detailed information. We’re working on it now and will fix the issue as soon as possible, then release a new version.
Hello @bulgeo
I was trying to find the Kakina Pro theme and noticed it’s been discontinued. That means it’s no longer updated for the latest versions of WordPress and PHP. On the other hand, Kirki 6 is actively maintained and supports the latest WordPress and PHP versions.
Hi Ivailo,
Thanks for reaching out and for the detailed explanation.
To help us investigate this properly, could you please confirm which theme (and version) you’re currently using? You mentioned Kakina Pro—just want to double-check the exact version.
From similar reports, these kinds of issues are often related to how the theme integrates with Kirki rather than the core plugin itself, especially if the theme hasn’t been updated to align with newer Kirki changes.
Once we have the theme details, we can take a closer look and guide you more precisely.
Hi @rzepak
I hear your frustration — especially given your long history with Kirki. Changes like this can be disruptive, particularly when you’ve relied on something being stable for years.
That said, as the current maintainers, we do have to make decisions about the direction of the plugin, including larger architectural changes. We understand that not everyone will agree with those choices.
Regarding the issues you mentioned: many of the reported errors are happening on sites where themes or bundled integrations haven’t been updated in a long time, and are not yet compatible with the newer Kirki structure. That said, we’re not dismissing the impact — we’re actively reviewing all reported bugs and working through fixes where they’re needed.
We genuinely appreciate the feedback, even when it’s critical. It helps us identify where things are breaking in real-world use and improve stability moving forward.
In the meantime, if stability is critical for your current projects, sticking to a known working version (such as 5.2.3) is a safe temporary approach until compatibility updates are rolled out.
Hi @madc7c
Thanks for sharing the detailed error log — that helps a lot.
From what you’ve described, the issue isn’t with Kirki itself, but with how it’s integrated into the XStore theme. Kirki 6.x introduced structural changes, and the error (
Kirki\Module\CSS::get_instancenot found) indicates that the theme’s bundled Kirki integration hasn’t been updated to match those changes.Since XStore includes its own Kirki implementation via the core plugin, this needs to be addressed by the theme authors. Rolling back to Kirki 5.2.3 works because that version is still compatible with their current integration.
At this point, the best path forward is to contact the XStore theme support team and ask for an update that ensures compatibility with Kirki 6.x.
In the meantime, keeping Kirki at 5.2.3 is the correct temporary workaround to avoid the 500 error.