David Aguilera
Forum Replies Created
-
I guess you’re right and it’d be better if we moved our
nabfolder insidewp-content/uploads(thus relying on WordPress’wp_upload_dirhelper function). Please let me look into this and I’ll get back to you ASAP. Also, send me an email at support at nelio software dot com. This way, I can send you a beta version to validate that it all works fine.Hi! That endpoint is unrelated to the page loading process. The issue must lie somewhere else. Could you please send me an email at support at nelio software dot com? I’d like to take a closer look at your setup to identify what’s going on, probably in a staging environment if possible.
Fixed in version 8.4.0
Thanks for the report! Please give me some time to address it.
I’m afraid that’s precisely the issue. Custom Post Type tests only work if the post type itself behaves like a regular WordPress page, meaning it has its own URL and what not. If the post type creates a block that’s then embedded elsewhere (like, for example, a page), this type of test will not work.
Here’s what I would do instead. If you want to test an alternative block in your homepage, create a page test and run it on the home page. Then edit your variant B and add the AI block in it. Does this sound feasible?
Glad I could help!
I guess the problem is you’re defining a function (
archive_header) that already exists in the global scope, which triggers an error. Rename your alternative function to something else:remove_action( 'woocommerce_before_shop_loop', 'archive_header' );
function archive_header_b_variant() {
…
}
add_action( 'woocommerce_before_shop_loop', 'archive_header_b_variant' );- This reply was modified 3 weeks, 6 days ago by David Aguilera.
I looked at your website and, as far as I can tell, you’re running a custom post type test. What’s the URL of the custom post? Or is it a post type that behaves like a partial or something similar? Because, if it’s the latter, that type of test will not work as expected.
If you could please let me know what it is that you’re trying to achieve, I might be able to help you.
I’m not sure whether it would even be possible to create a test that changes the content of the custom field. I tried the custom post type test, but the custom fields are not available in the drop down.
Yeah, no, I don’t think that’d be possible with the current set of tests. You’ll have to create a PHP test whether you like it or not.
I think the only solution would be to create a PHP test that somehow looks something similar to this:
// Unhook original hero section:
remove_action('woocommerce_before_shop_loop', 'archive_header', 10);
// Create new hero section:
function archive_header_b() {
if ( ! is_product_category() ) {
return;
}
$cat = get_queried_object();
// Load different field:
$custom_field = get_field( 'product_category_header_b', $cat );
echo '<div class="fullwidth-banner cat-banner">' . $custom_field . '</div>';
do_action( 'woo_cat_rating', $cat );
if (in_array($cat->slug, array('schimmelentferner', 'spruehgeraete'))) {
echo '<p style="text-align: center;"><a class="button scroll-element" id="video" href="#produktvideo">Anwendungsvideo</a></p>';
}
}
add_action('woocommerce_before_shop_loop', 'archive_header', 10);and that’ll probably do the trick.
You’d still need a PHP test to change the value of the field, right?
Thanks for the detailed report, @hannah3405.
I was unable to reproduce the issue locally but, thanks to your detailed explanation, I think I was able to address and fix it correctly. If you could please upgrade to version 8.3.1, validate it, and let me know how it goes, I’d really appreciate it.
We’re really sorry you encountered this fatal error. We were unable to identify this issue before the release (in fact, I’m still unable to reproduce it), but thanks to a couple more tickets we’ve received in the past few hours, I think we finally fixed it.
To fix the critical error on your website, the first thing you gotta do is deactivate the plugin. If you have access to your dashboard, just do that. If you can’t, you’ll have to connect via FTP to your server and simply remove our plugin’s folder (i.e.
wp-content/plugins/nelio-ab-testing/). Your hosting provider can help you with that.Once the faulty version of Nelio A/B Testing has been removed, you can install version 8.3.1, which I think addresses and fixes all the unexpected issues.
Do you mean you’re not seeing variant B ever? Please contact us via email (support at nelio software dot com) and we’ll take a closer look at your setup.
Thanks for reaching out! I looked at your tested page and noticed that our plugin inline and regular scripts are being optimized by (I think) Perfmatters. So let’s try the following: can you temporarily deactivate that plugin and try again? If the plugin starts tracking data afterwards, we’ll know for sure the issue is there and all we’ll have to do is find the correct settings in Perfmatters (usually, excluding our scripts from being optimized by it) so that both plugins can coexist.
Thanks, mate! That was really helpful. I was able to identify and understand what was causing the issue. I’ll work on the fix and publish it in our next release (8.2.3).