0 comments on “Debugging: Add locations w/ Power “Uncaught SyntaxError: redeclaration of const wp_data””

Debugging: Add locations w/ Power “Uncaught SyntaxError: redeclaration of const wp_data”

SLP 5.13.5 prerelease + Power 5.11 has a problem found during testing… the admin add locations breaks (probably a lot of other things as well).

The browser console:

This is related to moving to wp_add_inline_script() vs. the wp_localize_script() based on findings that indicate wp_localize_script() may a not work with block themes and it is really intended for i18n/l10n.

Further investigation finds…

store-locator-le/include/module/admin_tabs/SLP_BaseClass_Admin.php
enqueue_admin_javascript()

This is called for each add-on that needs it…


Power needs it.
handle: slppower_manage_locations
data stack:
{"ajax_nonce":"50164ddb77"}

SLP (base plugin) needs it.
handle: slp_manage_locations
data stack:
{"ajax_nonce":"50164ddb77"}

However, a code search shows that ONLY the base plugin admin JavaScript is using/referencing wp_data…

Why is Power setting up an enqueue of this file?

Code Analysis of enqueue_admin_javascript()…

This is always true:

if ( ! empty( $tab_js_settings ) ) {

Because this is always set further up in the code…

// All our JS will now have an AJAX_NONCE setting.
$tab_js_settings = array( 'ajax_nonce' => wp_create_nonce('slp_ajax'), );

They key player here “ajax_nonce” set above is ONLY ever used here… SLP base plugin admin.js… which is only called when doing a change_option. That is fired from both the base plugin and Power add on, HOWEVER… they both reference the SLP_ADMIN.change_option() method in JavaScript.

ajax_nonce usage in JavaScript is only in SLP base plugin admin.js (SLP_ADMIN) change_option() method attached to the options property (SLP_ADMIN.options.change_option).
All calls to the SLP_ADMIN.options.change_option() call

Resolution

Do not set the baseline tab_js_settings in SLP_BaseClass_Admin.php

This will stop the default (only) ajax_nonce PHP array entry from being set, effectively short-circuiting the enqueue of the script from the Power add-on.

While this fixes the issue short-term and stops overloading the tab_js_settings, if Power (or any other add on) finds it necessary to add some custom entries to the tab_js_settings array, it will break again. This is a fragile patch.

The change…

Add the handle to the JavaScript variable definition

The current setup is to hard-code the JS environment variable to “wp_data” for ALL add-ons. This will make them “fight” per the message above.

Instead of blindly referencing a generic hard-coded “wp_data” variable, let’s change that to be based on the add-on name.

For our use cases above that would do this.

For SLP base plugin wp_data => slp_data

For Power add on wp_data => slppower_data

The change…

0 comments on “WordPress & JavaScript “Admin Edition””

WordPress & JavaScript “Admin Edition”

WordPress does some odd things when it comes to managing the DOM elements, especially when it comes to JavaScript and CSS. WordPress has crafted their own creative PHP methodology for getting data from PHP into JavaScript when loading the scripts. This allows for JavaScript variables to be “pre-initialized” when the scripts are first rendered.

Useful for getting a known starting state in JavaScript based on PHP state and logic that has run up to the point that the scripts are loaded.

Not standard AT ALL given today’s single page app and other advanced methodologies just as REST queries, etc. that could do the same job.