JavaScript, Internet Explorer, and Old Web Browsers via Yoast

I went down a bit of a rabbit hole today.

It started with trying to find a method of making Yoast add an image to a sitemap without an end user's browser downloading the actual image. The reason for doing that is saving bandwidth and reducing page load times. Various solutions like "lazy load" or Image / <IMG> Attributes like DATA-SRC would not trigger Yoast into adding an image to a sitemap index. Finally the below solution worked;

<noscript>
<img src="WhatEverURL/WhatEverImage.jpg" />
</noscript>

Placing the image inside of a NoScript Element / Tag will prevent a user's browser from downloading the image, but Yoast still adds the image to a sitemap index.

According to W3Schools, the NoScript Element / Tag is used if a a browser does NOT support JavaScript. All modern web browsers support JavaScript, so that doesn't really happen these days unless it is purposely disabled via a browser setting or a plugin. That brings up the obvious question...

What to do if a browser's JavaScript functionality is disabled?

The obvious answer is to enable JavaScript functionality. OK, fine. But, how does an end user know this needs to be done? And more importantly, the image or images will all download, thus negating the NoScript Element / Tag.

A better answer would be to require JavaScript be enabled before allowing a user to view the website. Some may consider this a bit Draconian, but if a website's presentation and display are dependent upon JavaScript the ability to view the site may not exist without it. While it is certainly possible to develop a "no JavaScript" website, that would be a LOT of effort for that small percentage of 1% of circumstances that this would occur. And it would then be a horrible experience compared to the "JavaScript enabled" site. So in the end the only realistic solution is to require JavaScript to be enabled.

Requiring JavaScript to be Enabled

For WordPress, the solution if fairly simple. Add a Plugin.

WP JS Detect (Main Tab, Js Detect) is the only plugin I could locate. It is a bit dated, but because its functionality is so simple, it will work with just about any version of WordPress. There may of course be a day when it doesn't, but the code is there. One other item to watch out for is that if it is ever Deactivated, any custom settings will be wiped out. There is another plugin (WP No JavaScript or Cookie Checker), but it is even more dated and doesn't allow message customizing to be done as easily.

Another Item to Consider

Another item to consider is Internet Explorer. On this little adventure I found that Internet Explorer 8 would actually work, but things looked really funky. Oddly, a newer version of Internet Explorer (version 11), didn't work at all (even with JavaScript enabled). So there needs to be additional detection.

A Plugin titled IE Detect didn't work at all. PHP Browser Detection is a fairly dynamic Plugin, but is a bit dated. WP Browser Update (under Settings Tab, WP BrowserUpdated) is a great candidate that does much more than just detect Internet Explorer. Unfortunately, as detailed as the documentation is, it lacks an explicit description of where to add additional configuration variables. The only choice seems to be in the /WhatEverPath/wp-content/plugins/wp-browser-update/WP-BrowserUpdate.php file. Below is the example of how to modify the settings;

ORIGINAL CODE (about 25 lines down);

var $buoop = {required:{'.$browser.'},test:'.(isset($wpbu_js[1]) ? $wpbu_js[1] : '').',newwindow:'.(isset($wpbu_js[2]) ? $wpbu_js[2] : '').',style:"'.(isset($wpbu_js[3]) ? $wpbu_js[3] : '').'",insecure:'.(isset($wpbu_js[4]) ? $wpbu_js[4] : '').',unsupported:'.(isset($wpbu_js[5]) ? $wpbu_js[5] : '').',mobile:'.(isset($wpbu_js[6]) ? $wpbu_js[6] : '').',shift_page_down:'.(isset($wpbu_js[7]) ? $wpbu_js[7] : '').',api:2020.01,};

...which can be changed to;

MODIFIED CODE;

var $buoop = {required:{'.$browser.',i:12},test:'.(isset($wpbu_js[1]) ? $wpbu_js[1] : '').',newwindow:'.(isset($wpbu_js[2]) ? $wpbu_js[2] : '').',style:"'.(isset($wpbu_js[3]) ? $wpbu_js[3] : '').'",insecure:'.(isset($wpbu_js[4]) ? $wpbu_js[4] : '').',unsupported:'.(isset($wpbu_js[5]) ? $wpbu_js[5] : '').',mobile:'.(isset($wpbu_js[6]) ? $wpbu_js[6] : '').',shift_page_down:'.(isset($wpbu_js[7]) ? $wpbu_js[7] : '').',api:2020.01,text_for_i:"This website will NOT display or function properly with Internet Explorer.  Please use a modern web browser such as Firefox, Chrome, Edge, Safari, Opera, etc.",reminder:0,remind:0,no_permanent_hide:true,no_close:true,};

...to better control usage of Internet Explorer. Full documentation can be found here: http://browser-update.org/customize.html Verified and tested that it actually works by clearing out the test browser's cache and looking at each individual file it downloaded.

Yoast Note

After looking at the raw XML output of the sitemap that Yoast generated, I noticed several pages that weren't being used or actively displayed on the website were still being cataloged by Yoast. Easy solution is to make sure that the Yoast SEO Premium, SEO Tab, Advanced, Allow search engines to show this Announcement in search results? is set to No. Alternatively, based on the same Yoast dialogue box referring to "Default for PagesOrPosts, currently: YesOrNo", might lead one to believe that one can turn off or set a default for Yoast to only create entries for individual pages or posts by setting the SEO Tab, Search Appearance, Content Type, WhatEverCategory, Show WhatEver in search results? to no. In fact this disables sitemap generation for that type of Page or Post completely, even if it is enabled on an individual item. So in a nutshell, one cannot set the default for Yoast to be "don't include anything in a sitemap index, just leave it empty until it is enabled for a specific page", as it will completely disable the sitemap index for that entity.