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 6 months ago.

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

    Ahrale
    Participant

    Hi,

    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,

    Ahrale

    #53025

    Weaver
    Keymaster

    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.

    #53031

    Weaver
    Keymaster

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

    #53043

    Ahrale
    Participant

    Hi,

    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>
    Thanks,

    Ahrale

    #53057

    Weaver
    Keymaster

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

    I would suspect: ngg_resource_manager

     

    #53060

    Ahrale
    Participant
    #53062

    Weaver
    Keymaster

    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.

    #53064

    Ahrale
    Participant

    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,

    Ahrale

    #53067

    Weaver
    Keymaster

    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.

    #53098

    Ahrale
    Participant
    Hi,

    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..

    #53110

    Weaver
    Keymaster

    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.

    #53114

    Ahrale
    Participant

    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.

     

    #53330

    Ahrale
    Participant

    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.
    https://www.screencast.com/t/FVwghxgjw

    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

    Thanks,

    Ahrale

    #53349

    Weaver
    Keymaster

    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.

    #53369

    Ahrale
    Participant

    Thanks Weaver,

    I will download & check it out.

    Ahrale

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

You must be logged in to reply to this topic.