[Resolved] Why is CRED referring to admin-ajax-php

[Author]

Posts

[Loco-z68]

Hi,

I did realize that on my frontend website in the footer multiple <script> tags are included, which do refer to admin-ajax.php.

They were e.g.

<!-- this one goes away when deactivating CRED -->
<script type='text/javascript'>
/* <![CDATA[ */
var MyAjax = {"ajaxurl":"http:\/\/www.mydomain.com\/wp-admin\/admin-ajax.php"};
/* ]]> */
</script>

<script type='text/javascript'>
/* <![CDATA[ */
var _wpUtilSettings = {"ajax":{"url":"\/wp-admin\/admin-ajax.php"}};
var _wpUtilSettings = {"ajax":{"url":"\/wp-admin\/admin-ajax.php"}};
/* ]]> */
</script>

<!-- This might come from Views -->
<script type='text/javascript'>
/* <![CDATA[ */
var wpv_pagination_local = {"front_ajaxurl":"http:\/\/www.mydomain.com\/wp-admin\/admin-ajax.php", ............
/* ]]> */
</script>

I was quite surprised and found out when I e.g. deactivate CRED, at least the first goes away.

Why are the Toolset components referring to admin scripts, even when not logged in?

[Beda]

Because we need them for several actions.

Views for as example pagination and AJAX updates, CRED for Date Fields, AJAX submission and more.

This is intended.

Is there an issue with it?

[Loco-z68]

Hi Beda,

yes, the issue is that Toolset includes the reference to admin-ajax.php by default - and by the way also to quite a lot JS files (e.g. mediaelement-and-player.min.js, wp-mediaelement.min.js, wp-util.min.js, backbone.min.js, wp-playlist.min.js, wpv-pagination-embedded.min.js).

This means just by activating the plugin and having no single Toolset view I get all these (at that point unneeded) includes on all my pages.

The issue is basically performance/page load time and SEO (in particular for the JS files). Beside that you can read quite a lot on the web on how page load times suffer from Heartbeat usage (admin-ajax.php).

For this reason other plugins often offer an option in the settings that includes are only done on sites, where the plugin is used.

Is there something similar? I.e. that Toolset would only includes the admin-ajax.php reference and the JS scripts, when the current page or content includes the Toolset functionality?

[Beda]

This is because we do not know at that moment if the Page is including any Views/CRED instance.

Now if we would load that only if those are present, it's too late for several things.

There is no setting to disable this, but we recently improved on the issue, especially for CSS files.

But some things we need to load "by default", otherwise it's too late for the plugin's features to work properly.

[Loco-z68]

Ok, I understand. But at least for all the JS files it would be quite easy. You can enqueue them even very lately with wp_enqueue_script() https://developer.wordpress.org/reference/functions/wp_enqueue_script/

Are there any plans to improve further?

[Juan Supporter Timezone: Europe/Madrid (GMT+02:00)]

Hi Martin

This is Juan, lead Views developer and Toolset team leader. Thanks for your feedback. I was asked to step in and provide some feedback on my own.

In a general sense, you are right: assets should only be loaded when you are positive they will be needed. But in reality, things are not as easy as they seem. Let's separate between two kind of assets: stylesheets and scripts.

As you might know, stylesheets can only be loaded in the header of an HTML page. There is no valid way of adding a stylesheet after that, regardles the fact that it does work. But the WordPress native methods (namely, wp_enqueue_style) can only be run in the header. Of course, by the time the header is output, we can not now whether the current page will contain a View, or a CRED form. It is literally impossible to know, even less given the nested structures that you can create with Layouts, with any page builder or just with good ol' native template hierarchy. So whenever we need a stylesheet in the frontend, our only safe bet is to enqueue it always. You migt have noticed that other plugins do exactly the same, for the exact same reasons.

Now, there is a nice technique to avoid that, which consists in loading the CSS stylesheets from a javascript file. Instead of enqueuing the stylesheets with the native function wp_enqueue_style, you detect whether the current page will need it, on load or during any execution of a given action, and load the stylesheet just once in the header. The good side of this is that you no longer load the stylesheet when not needed. the bad side is that you first need a script, and second you can no dequeue it using the WordPress functions. There is no win-win option.

Regarding scripts, kind of the same principle applies. But with scripts you can enqueue them on whatever place of the page, and they get printed in the footer... so why would you force them? Well, again, reality is not always so clean, and sometims you do not detect when rendering the page that you will need a script.

Imagine that you have a View, and it has AJAX pagination enabled. Imagine that the second page of the View contains a WordPress audio shortcode. This shortcode, when added to a page, raises a flag so its assets (basically, the script), gets added in the footer. But remember that in the View first load, page one, there is no audio shortcode: it is on page two. So when you paginate to page two, unless the WordPress assets to manage audio shortcodes are already available, the audio shortcode will not work.

In other words: you can try to detect which scripts you will need to correctly display the current page, but there are non trivial chances that you will miss some scripts unless you force them from the start.

I understand your concerns about performance, of course. With browser cache and CDNs available everywhere this should not be a major issue by now, anyway.

Now, back to some of your concerns.

None of the Toolset plugins is referencing improperly to the admin-ajax.php file. None. We always act accordingly to the documentation on how to use AJAX in the fontend:
https://codex.wordpress.org/AJAX_in_Plugins#Ajax_on_the_Viewer-Facing_Side
This means:

• Adding some actions that reference users with proper rights, using the prefix "wp_ajax_noprov_".
• Include a reference to the URL of the admin-ajax.php file by localizing a script and passing this value as an "ajaxurl" property of a custom object. Sometime swe do not use this "ajaxurl" variable name, but the spirit is the same.

The reference to admin-ajax.php is mandatory and totally needed in order to have any kind of frontend AJAX functionality. I is not an obscure reference, nor points to a hidden gen that should never be linked. It is quite the opposite: the natural, safer way to use AJAX in the frontend without having to reference a plugin file instead that would manage such requests.

This is not related in any way to Heartbeat, which is a particular usage of the WordPress AJAX functionality when editing a post. Having AJAX functionality in the frontend, besides not having the minimal relation to backend Heartbeat, depends on the developer implementation and the events that fire those AJAX calls. In Toolset, we are quite clear about which events fire them: Views AJAX pagination or AJAX frontend custom search, CRED forms posted without reloading the page... In addition, we take security quite seriously and we check that each action executed in an AJAX call is secured and safe for te current user performing it.

To close up, we try to load our assets only when needed, for sure, and we are extending the technique to dynamically load the stylesheets just when needed, although it has its own risks. We try to narrow as much as possible the scripts that we force, and we will probably evaluate the same tchnique for dynamically loading script dependencies only when needed. However, this is not a set-and-run thing and sometimes the less weird solution is to force some assets by design.

Hope it helps.

Regards.

[Loco-z68]

Hi Juan,

Thanks a lot for your awesome reply. This gives me a great overview and I understand now much better. Thanks for that.

Regards