Hello,
We understand the frustration, and Unyson becoming unusable was a major issue for us as well. At the time, it was a very promising framework, and its discontinuation was outside of our control.
Rather than abandoning the theme or releasing a new one, we invested significant time and resources to adapt it for the future. This included creating a new theme options panel, adding full WPBakery support, porting most Unyson elements, recreating the demo content using WPBakery and more.
There is no need to worry about updates, as the theme will continue to receive updates even after the support period ends, since updates and support are handled separately.
Unyson is no longer maintained and cannot be made compatible with PHP 8.2 in a stable way. Rebuilding content outside of Unyson is the only reliable path forward. If questions arise during the process, we can assist with guidance.
Best regards,
Shufflehound team
Hello,
Thanks for the questions and details!
Hopefully, this helps. 🙂
Best regards,
Shufflehound team
Hello,
Unfortunately, there’s no stable workaround to keep using Unyson under PHP 8.2. The only reliable approach is to gradually rebuild your pages in WPBakery Page Builder and then fully disable Unyson once all content is moved. The issue comes from Unyson’s outdated codebase, which can’t be patched directly from the theme side.
If your site was originally based on one of our demos, you can reimport it using WPBakery demo content and rebuild the layout section by section. If needed, we can also assist with the rebuild as a paid service.
Best regards,
Shufflehound team
Hello,
Thanks again for confirming and sharing all the details – we will keep this in mind for future testing. 🙂
Best regards,
Shufflehound team
Hello,
Thanks for the extra details.
We tried to reproduce this on our end and we can see something similar happening during the Complianz wizard, but we still cannot find the exact cause. We did some checks and basic debugging, but didn’t find what could cause this.
For now, we recommend continuing with the workaround you received from the Complianz team. The manual policy pages with the Complianz shortcodes, plus the link override if needed, looks like the most reliable way to avoid the corrupted auto generated content.
Best regards,
Shufflehound team
Hello,
The issue was not related to Jevelin itself, but to the deprecated Unyson framework. The Unyson Page Builder extension was missing and could no longer be downloaded because the Unyson servers are offline, so we added the extension manually. Your pages are now loading correctly.
We also noticed the site is running a very old Jevelin version, so we recommend updating to the latest release for improved compatibility and security.
Additionally, since Unyson (previous main theme plugin/builder) is no longer supported, we now recommend using WPBakery Page Builder for a more stable and user friendly editing experience. Unfortunately, old Unyson content cannot be migrated automatically and would need to be rebuilt manually, as Unyson was never designed to convert layouts to a different page builder. If the theme was originally based on one of our demos, we recommend using the corresponding WPBakery demo content as a starting point. If needed, we can also help with custom work outside the regular support scope to assist with rebuilding or adjusting older content.
Best regards,
Shufflehound team
Hello,
Thank you for the detailed follow up. We’ve reviewed the recent theme updates and can confirm that there haven’t been any changes to the WooCommerce templates or 404 handling that could affect the “order received” page. We also ran additional tests using Jevelin 5.14 with WooCommerce and WPBakery 8.7.2, but couldn’t reproduce the issue, and haven’t received any other similar reports from other theme users regarding the order received page.
We understand your point that switching to a different theme makes it work, though when we switched between Jevelin versions during testing, the page also started working again, even without any code changes. That makes it difficult to confirm whether the issue originates directly from the theme or from something else in the environment reacting to the theme switch.
Have you tried adjusting any WPBakery settings or temporarily disabling any caching or performance plugins? It might help, as something there could be contributing to the issue.
Best regards,
Shufflehound team
Hello,
Thank you for sharing the detailed information. We haven’t encountered this issue before, and we don’t use Complianz in our testing setups, so we haven’t been able to reproduce it on our side yet. Since the incorrect content appears during Complianz’s automatic page generation, before Jevelin or WPBakery modifies anything, it seems to come from how the plugin processes content rather than from the theme or builder.
If you can provide the exact steps you followed in the Complianz setup wizard to trigger the issue, we can try to replicate it in a clean test environment. This will help us see if there’s anything on the theme side contributing to the conflict.
Best regards,
Shufflehound team
Hello,
Thanks for the clarification. We were referring to tests done on our own test installation, where Jevelin 5.14 together with WPBakery 8.7.2 and WooCommerce is working normally. At the moment we still cannot reproduce the 404 issue on our side.
Based on your latest notes and what we observed while testing directly on your development site, it appears that something in the environment is causing the first load of the “order received” page to be treated as a 404. Since refreshing the exact same URL loads correctly, this points to caching, redirects, or another process marking the request as 404 before WooCommerce finishes loading the endpoint.
When we switched between 5.14 and 5.13 on your site, the 404 disappeared once and continued working after updating back to 5.14, which also suggests that the issue is not tied to the theme update itself but to how the environment handles that first request.
At this stage, because we haven’t been able to reproduce the problem consistently on your site or our clean setup, we don’t yet have a specific source we can point to. The behavior aligns more with a local configuration or caching rule rather than an issue introduced in the theme update. If you notice any pattern or can narrow down when the 404 triggers (specific payment method, browser, plugin combination, etc.), please let us know and we will check that scenario specifically.
Best regards,
Shufflehound team
Sure, no worries! 🙂
Hello,
We’ve just replied to your email, so you should now have our full response there.
Please also note that we’re available only on business days, which is why replies may take a bit longer during weekends.
Best regards,
Shufflehound team
Hello,
Regarding custom CSS or custom theme code work, thank you for your interest. We’ve replied to you privately with more information about this. 🙂
We also tested the mobile cart again on our side using the same steps shown in your video, and it’s still working normally for us (see in the attachment below).
One thing we noticed is that the LiteSpeed Cache plugin is still active. This plugin can sometimes cause issues with WooCommerce features such as the mini cart, AJAX requests, and redirects. We recommend temporarily disabling LiteSpeed Cache (or excluding all WooCommerce pages and mini cart urls) to check if the problem disappears.
Please try that and let us know the results, and we’ll continue from there.
Best regards,
Shufflehound team
Hello,
Thanks for the update. To look into this properly, could you please tell us which versions of WordPress, the Jevelin theme, and WPBakery you’re currently using?
We tested the checkout process on our test site with the latest theme and WPBakery versions, but we weren’t able to recreate the 404 issue. We also haven’t seen similar reports from other users, so the versions might help us better understand and test what’s happening.
Best regards,
Shufflehound team
Hello,
Thanks for sharing the new details and screenshots. Below are answers for the issues you mentioned:
Best regards,
Shufflehound team
Hello,
That’s great to hear! We’re glad it is working fine now.
Thanks for letting us know. 🙂
Best regards,
Shufflehound team
Hello,
Thanks for the kind words and for testing everything! Yes, all the mentioned backup plugins (including All-in-One WP Migration, UpdraftPlus, and Duplicator) can back up your full site: theme, settings, custom CSS, and database content. If the import fails, it’s usually due to upload limits on your hosting. Increasing the PHP upload_max_filesize and post_max_size values usually fixes that.
As for editing, you can use either WPBakery Page Builder or Elementor, as both have been tested with the theme. WPBakery generally offers slightly better compatibility, while Elementor might be easier to use but is sometimes more prone to issues after major updates. You can try both and see which one fits your workflow best.
Best regards,
Shufflehound team
Hello,
Thanks for checking that. It does seem related to WPBakery rather than the theme. You can also try reinstalling WPBakery from Appearance > Install Plugins, it might help.
Best regards,
Shufflehound team
Hello,
Thanks for the update and for sharing the details. Here’s what we did and what you can try next:
Each of these plugins lets you export a full copy of your site (theme, settings, and database) that you can later restore or move to another server.
Best regards,
Shufflehound team
Hello,
We can see that you’ve installed version 5.13, and the “Thank You” page works fine there. We also tested it again using version 5.14, and the order confirmation message appeared correctly without any 404 errors.
So we’re not sure what caused the issue earlier, or if you may have already fixed it on your side, as we haven’t made any changes yet.
Best regards,
Shufflehound Team
Hello,
Thanks for the details!
Could you please share a link to the page where the video player is used? That will help us inspect it directly and see what’s causing the freeze on mobile devices.
Best regards,
Shufflehound Team