Home Forums Weaver Xtreme Theme Uncaught ReferenceError: wvrxEndOpts is not defined

This topic contains 14 replies, has 2 voices, and was last updated by  Ahrale 11 months, 1 week ago.

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
  • #53018



    got this error on my console:

    Uncaught ReferenceError: wvrxEndOpts is not defined
    at weaverxBrowserResizeEnd (weaverxjslib-end.min.js:1)
    at weaverx_js_update (weaverxjslib-end.min.js:1)
    at HTMLDocument.<anonymous> (weaverxjslib-end.min.js:1)
    at i (jquery.js:2)
    at Object.fireWith [as resolveWith] (jquery.js:2)
    at Function.ready (jquery.js:2)
    at HTMLDocument.K (jquery.js:2)

    Please advise how to fix it. Thanks,




    You must not have the latest versions of Weaver Xtreme and the Weaver Xtreme Theme support plugin.

    If you think you have the correct versions please copy the system info found at the end of the Weaver Admin Help tab and paste here.



    Given your other post I just saw, I wonder if you have tried to disable so. Weaver Xtreme functionally.




    Of course I use only latest version…. here is my copy paste:

    ### Weaver System Info ###

    — WordPress Configuration —

    Site URL: https://web4u.win/eldad
    Home URL: https://web4u.win/eldad
    Multisite: No
    Version: 4.9.2
    Language: he_IL
    WP_DEBUG: Disabled
    WP Memory Limit: 40M
    Permalink: /%year%/%monthnum%/%day%/%postname%/
    Show On Front: page
    Page On Front: אלדד (ID# 9)
    Page For Posts: (ID# 0)
    Current Theme: Weaver Xtreme (3.1.10)
    Post Types: post, page, attachment, revision, nav_menu_item, custom_css, customize_changeset, oembed_cache, ngg_pricelist, ngg_pricelist_item, ngg_order, td_nm_notification, ngg_album, ngg_gallery, ngg_pictures, lightbox_library, photocrati-comments, ngg_coupon, nextgen_proof, tcb_content_template, tcb_lightbox, displayed_gallery, display_type, gal_display_source

    — Weaver Xtreme Configuration —

    Weaver Xtreme Version: 3.1.10
    Theme Support Version: 3.1.9

    — Server Configuration —

    Operating System: Linux
    PHP Version: 7.1.13
    MySQL Version: 5.6.38
    jQuery Version: 1.12.4
    Server Software: Apache

    — PHP Configuration —

    Local Memory Limit: 2048M
    Server Memory Limit: 2048M
    Post Max Size: 128M
    Upload Max Filesize: 128M
    Time Limit: 0
    Max Input Vars: 9000
    Display Errors: N/A

    — WordPress Active Plugins —

    BackupGuard Pro: 1.1.57
    Duplicate Page and Post: 2.2
    Mega Main Menu: 2.1.5
    NextGEN Gallery: 2.2.33
    NextGEN Pro: 2.5.7
    Thrive Architect: 2.0.20
    Weaver Xtreme Theme Support: 3.1.9

    — WordPress Inactive Plugins —

    Akismet Anti-Spam: 4.0.2
    <h3>End System Info ###</h3>




    Some plugin or change is removing the runtime generated javascript that makes that definition.

    I would suspect: ngg_resource_manager





    The code to define wvrxEndOpts is generated by the theme footer.php function.

    I also see you have figured out some way to stop loading the standard theme css file. So I wonder if you’ve also done something to override the theme footer.php code. If that code is executed as required, then the variable will always be defined. The definition is missing from your page.

    And if you are modifying theme files, I wonder how you are doing that? I don’t see any sign of a child theme. If you are modifying theme code, then the only safe way to do that is with a child theme.



    Thanks Weaver,

    So actually, it happens by the Thrive Architect plugin.

    This visual builder enable to use page templates instead of the Theme.

    I will open a ticket about it to their support.

    Thanks again,




    The actual issue then would be that Weaver Xtreme queues a couple of JavaScript files, one to be loaded at the top of the file, and one to be loaded at the end. WP core controls when the loading of the scripts. Both of the scripts are being loaded, and invoked at runtime. The issue is that Weaver Xtreme generates some inline script at the end of the generated output from the file footer.php which is a standard file used by most themes to generate the footer content. That script defines the “missing” variable. The value of that JS variable can’t be defined until the main part of the content has been generated as there are dynamic options from individual pages or posts (per page/post settings).

    I guess the issue is that footer.php by WP theme implementation standards is there to emit stuff at the bottom of the page – footer, copyright, theme credit, footer widget area – whatever a theme puts at the bottom, and the plugin is somehow bypassing that standard file.



    I applied to Thrive themes about this endpoints error.

    The reply I received was:

    “The fix needs to be from the theme developers.

    Using wvrxEndOpts variable, this needs to be checked if exists or not in the code, and if it exists, then the call should be stopped.”    (Thread on forum here)

    So, I’m not sure what to do about it now. I feel a little bit in the middle between the 2 of you..



    The fix they suggest would likely solve the problem, but their approach requires altering the theme, which in the WordPress world is really the master. Plugins are supposed to work with any theme. If they are subverting the invocation of the standard footer.php code by any theme (which is apparently true), then Weaver won’t be the only theme they break.

    Defining JavaScript variables at runtime for use in loaded scripts is standard practice in WordPress. There is a standard, widely used function in core WordPress called ‘wp_localize_script’ that is designed and used exactly for this purpose. Whatever that plugin is doing is breaking this standard system call. They really are not allowed to do that by WordPress coding standards.

    The proper fix, I think, would be for that plugin to allow you to specify some PHP that should be executed if that plugin is “in control”. This code could be a call to stop some scripts from even being loaded. But this is Thrive’s problem, NOT the theme.

    I’d might suggest this review: https://www.wpcrafter.com/versus/elementor-vs-thrive-architect/

    We recommend Elementor which has no known issues with Weaver.



    Thanks Weaver for your detailed & well explained reply. I passed it forward to Thrive & waiting for their reply.

    However the review you suggested is not a professional one & only reflects part of the truth as well as hiding some. The author of that review is using few Thrive plugins (for marketing) mixed with Elementor & Beaver Builder on top of Astra theme which is the only theme I consider to climb up towards Weaver. It still has long way to go, but have even some advantages.

    My guess is that his review is based on the fact he is an affiliate of Elementor that give him 50%  While Thrive has no affiliates program.




    Hi Weaver,

    I only got now the reply from Thrive Dev & here it is:

    What they say is true with some exceptions.

    If they are subverting the invocation of the standard footer.php code by any theme (which is apparently true), then Weaver won’t be the only theme they break.
    The script is included in footer.php that also works with TAR but not for landing pages.

    Ex of a non-landing page: https://web4u.win/eldad/?p=115&tve=true

    For landing pages, we remove the header and footer that comes from the theme.

    To support page builders other themes enqueue scripts at “wp_enqueue_scripts” hook.

    Please ask the theme developers to do the same in order to avoid these conflicts





    We do use wp_enqueue_scripts, but we also MUST emit the wvrxEndOpts at the end as they are dynamically determined at the page is generated.

    But please see https://weavertheme.com/beta-versions/ and try the latest cutting edge versions of Weaver Xtreme. I went ahead and put in the code to avoid issues if the dynamic wvrxEndOpts is never generated. This should avoid the issues with the page builder.



    Thanks Weaver,

    I will download & check it out.


Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic.