Fixes the Internet! Self-healing nanobots for your website! Or at least, automatically reloads broken images and other page resources.

You spend ages to get everything working on your site, BUT then, it can still break for visitors with a slow connection or temporary connectivity problems. A single failed stylesheet load can make your site look like it is ugly or broken - or just from 1994. The only answer (until now) was the user refreshing the whole page and starting again... often only to have something else break and losing your visitor to frustration.

WP AutoMedic attempts to solve this problem by checking each resource on the page, whether it is an image or stylesheet or script, and reloading ONLY those resources that failed to load. While it won't fix typos pointing to resources which don't exist, it will at least try again (and as many times as you set it to) so that the webpage display can "heal itself" automatically (or rather, automedically!) in the majority of cases - mostly for slow or temporarily bad connections - without having to hit the refresh button and start all over again!

So what? What's in it for me?

Well, first off, it simply means your site visitors will have a better overall experience when broken images and stylesheets etc. magically heal themselves before their eyes. They may not even notice, but they WILL notice if they DO break, and many people can too easily assume your "site is broken" or "badly designed" even if it is actually their slow or interupted network connection that is at fault! It happens far more than you think, and especially if you have a fast connection yourself, you may not have even stopped to consider if your users do. Now is the time to fix that!

Browsers have decided to ignore this common problem, but you don't have to. Instead, having WP AutoMedic in place for your visitors increases the stickiness, friendliness and usability of your site, which basically means they stay on your site longer - which is probably what you want! - and will probably lead to an increase in real page views and thus subscriptions and/or sales etc. etc. If that doesn't "sell" you on the benefits of installing and using WP Automedic, that's okay, I'm not trying - it's free. ๐Ÿ™‚

What does it actually do?

  1. Loads after the webpage says it is loaded.
  2. Checks all chosen elements for broken resources.
  3. Sets a timed cycle for each broken resource.
  4. Attempts to reload the resource on each cycle.
  5. Magically medicates and heals your webpage.

What resources does it work for?

Checking a resource is loaded and reloading it is no simple feat, and different for different page elements, and different browsers - which have different javascript functions or support - making is rather complex and time-consuming to code and test. So, I have starting with the most common page elements and am going from there. ๐Ÿ™‚

Currently WP AutoMedic works for: * Broken Images (<img> elements) - comparitively pretty easy! * Broken Stylesheets (<link rel='stylesheet'> elements) - pretty tricky! (and yes it can check and reload stylesheets in Firefox!)

Almost works (in progress) for: * Broken Scripts (<script src='somescript.js'> elements) - difficult! * Broken Iframes (<iframe src='somepage.html'> elements) - near impossible! ...and 'unowned' iframe load checking cannot be checked in any case. * fallback to local image/stylesheet cache for external images/stylesheets

Does not currently work for: * initial check of external stylesheets (workarounds possible) * stylesheets @imported inside inline <style> elements (very possible) * broken image and background URLs inside stylesheets (maybe possible)

Of course other alternatives and workarounds are being explored, and suggestions and contributions are very welcome! It would be nice to improve WP AutoMedic to cover more situations and be tested and improved for different browsers.

How does it work?

  1. Loads itself after the webpage says it is finished.
  2. Checks all chosen element types for broken resources.
  3. Timed cycles through broken resources and reloads them.
  4. When a resource is checked as loaded it's cycle stops.
  5. or, when number of attempts set is reached it's cycle stops.

How do I know it is working?

Ideally, you wouldn't need this as your page loads fine every time... but of course, that is not always the case, hence the need for this plugin in the first place. So most of the time you probably won't notice WP AutoMedic is actually doing anything, but like a medic should be, it is on standby in case of emergencies, and firing your medic (deactivating the plugin) just because you are not injured ("but my pages are loading fine!") may not be the best idea when you don't have to (this plugin is free.)

However, you may want to make sure the medic is well trained (that this plugin actually works and does what it says) and so do a training exercise. The testing of this plugin script particularly tricky, simply because most of the time your page DOES load fine! So to truly know and test this plugin is working correctly (rather than just the page is loading correctly - ie. no injury) we need to set up a fake page with some broken resources (simulate an injury) and then look at that with AutoMedic loaded and see exactly what happens...

To that end, you can test WP AutoMedic by putting the [automedic-test] shortcode on a new post or page - optionally save as a draft for later - and then click on Preview Post. The output of the shortcode simulates a number of broken resources in the content area so that you can see the results. You can also check the browser console log to see all the AutoMedic events that are logged there along ith all those lovely lines of red broken resources. Keep in mind that the output and result can be different in different browsers and test those if you like. You can adjust the plugin settings (elements to reload and reload times etc on the settings page) and reload the page again to check it, and further adjust to suit your liking.

Are there any limitations?

Yes, definitely. First, this is never going to be perfect. Depending on which browser is used and what it's particular limitations are, the AutoMedic script may fail in part or entirely, if the browser does not have the needed browser support to do what it needs. (But, this could be said for just about any script and supporting older browsers has always been a web developer's nightmare.)

On the other hand, AutoMedic was written with this kept in mind specifically from the start, so the needed functions have been kept to a bare minimum of very commonly supported Javascript-only usage (not jQuery, even though the whole thing would have been much easier to write in jQuery!) and checks are in place for even thosee remotely unsupported functions used, so as to make sure it works most of the time and can fallback (or rather, failback) to doing nothing if the support really isn't there. As it improves and adds more checks like this, it will work better across more browsers. For a more specific list of limitations and issues, see Other Notes section.

Can I use this with a Content Delivery Network (CDN)?

Yes. Depending on the CDN it may or may not limit what AutoMedic can check and reload, as some resources may be considered 'cross-domain' due to this. Specifically that is, for stylesheets, that depending on the domain they are loaded from they may be treated as external stylesheets if the resource URL is for a CDN on another domain. There are workarounds in place for external stylesheets however, you read that section for more details. As for iframes, they are unlikely to be affected because their URL would be on your domain not the CDN (and those are the only ones that can be checked anyway.)

Can I use this on non-Wordpress sites?

The short answer is no. The longer answer is 'not yet'. WP AutoMedic is written in pure Javascript rather than jQuery to increase it's chance of success and also so it can be released as a standalone minimal script for other platforms, or basically for any HTML page (and without needing jQuery) in the near future so the basic functions work just by adding the script (meaning the basic image and stylesheet reloading.) The more advanced features will require a little more setup. To begin with however, the Wordpress plugin version will be used for development and testing, and probably always have more features (and a setting interface) as it is able to hook into the existing Wordpress settings, action hooks and page content much more easily.

Can WP AutoMedic help me check for specific-browser functionality?

No, that is not it's purpose. It is an after-production helper for improving site user experience rather than a development tool for fixing cross-browser functionality. If that is what you are looking for you can check out the modernizr.js library for the latest reliable checks on browser Javascript supports and CSS stylesheet rule support etc. Also check out NWMatcher and NWEvents if you are looking for cross-browser event testing and support. WP AutoMedic does some very basic checking itself for it's own purposes as it needs to, but these should not be relied upon outside it's scope as the plugin could be deactivated and break your code.

What's the deal with external stylesheets?

It is difficult to check the load success or failure of external stylesheets, (those on a different domain to your main site domain) some may say impossible... browsers prevent any access to determining whether those style rules have ever been added for "security" reasons (despite the common protest "c'mon it's just a stylesheet.")

Using 'local' stylesheets (in this context meaning with the same main domain name as your site) is preferable wherever possible. But sometimes it is not, so in this case, one effective solution is to rewrite the style tags to change the way they are loaded before they 'hit' the page output, so they are loading in a ay they can be checked the first time. Fortunately, AutoMedic can hook into the enqueued Wordpress style tags and rebuild them to use this reload method. OR it can buffer the page output and replace all the style tags on the page if you prefer.

Another alternative is to allow them to load as they normally would and to let the reload cycler reload them the first time using the alternative method so that their load state can be checked the second time. This can mean the stylesheet is loaded twice anyway, but fortunately will not affect the page further as the style rules already exist and are cascaded in any case (the C in Css.)

= What about script dependencies? */

Some scripts rely on another script (dependency) to load, and where the dependency failed to load, they try to run and fail because the library they need is not there. (A simple example is jquery-ui needs jquery to load.) Even if the dependency is successfully reloaded later, the script that failed to run the first time will NOT be retriggered by WP AutoMedic, as there is no way of knowing what that would do!

If you really need to make sure a script has run on a page there are a few options:

  1. If it's a library of needed functions, test it's functions exist by checking existance of a function within the script. eg. if (!window.jQuery)
  2. If it's a run once script for an effect, you can set a variable inside the script that says it has successfully run once and set up your own check cycle to attempt to call it's main script load function. So if either it fails or it's dependency fails, but is reloaded later, the function can be retriggered by the cycler and may launch the needed script for the desired effect.
  3. Note that by default Wordpress handles script dependencies simply by setting their enqueued load order rather than by any actual internal dependency function checking. Better handling of script dependencies can be achieved using the script, and so integrating this into WP AutoMedic is being looked into.
  4. If you have inter-related script dependencies for a development project, or want to set them up, you should probably be using requirejs! It is made for that, whereas this is for trying to fix post-production load problems rather than for development.

What actual checks are used to determine if a resource is loaded?

This varies depending on the type of resource, you may need to check the specifics of the latest version as the checks improves. But basically the following combination of checks are used to give the best cross-browser results (so far, having tested numerous methods, but there are certainly some others to be tried.)

Images: - loops image elements <img> to check them if any of these, considers the image unloaded: - imageelement.naturalWidth == 0 (mostly this does the trick) - typeof imageelement.naturalWidth == 'undefined' - !imageelement.complete (Internet Explorer) - imageelement.readystate == 'uninitialized'

Stylesheets - loops link elements <link> (with rel='stylesheet') to check - loopsdocument.styleSheets(with fallback todocument.sheet) - matches link element href to stylesheet href to get stylesheet *if either of these, considers stylesheet unloaded:* -!stylesheet.cssRulesand!stylesheet.rules-stylesheet.cssRules.length === 0andstylesheet.rules.length === 0` - caveat: does not (cannot) check 'external' stylesheets with this method

Scripts checking of static script load directly is not possible, no such check exists! scriptelement.length === 0 etc. does absolutely nothing it seems. (by this I mean any script with a src tag, there is no need to check inline scripts.) but, checking of script load IS entirely possible by using event callbacks: scriptelement.onerror, scriptelement.onload, (and .onreadystatechange for old IE)

But, unlike stylesheets you don't want to risk loading any script twice, so you cannot simply append the script with the callbacks somewhere later, as it may have already loaded. As soon as the static script tag is on the page - it is already too late to add a load event to it - it must be done at the same time (or before if adding dynamically.)

Fortunately, it is possible with Wordpress to hook into the enqueued scripts and add the needed callbacks directly to the style tags before they are outputted, and thus fire the script load/error callback events. Then the cycler can periodically check the statuses these events set and re-create (destroy the old and create the new) script elements - only for unloaded scripts. ie. where onerror event has fired or onload event has not (onreadystatechange is used for IE7/IE8 onload support.)

A valid alternative (much more complex, but I actually coded it first) is this: (please do not worry if this makes no sense to you, as if so you probably won't use it) Buffer the entire page output, convert static tags of <script src=""> to dynamic self-loading scripts - to add the needed load callbacks - then output the converted page HTML. The script check cycler can then do it's thang. While this method does work, it may not always be desirable to buffer the entire page, but it's up to you because it does allow you to apply AutoMedic to all stylesheets not just those enqueued by Wordpress. (note: this method failsback to normal static loading to writing the script tag directly to the page if support for the common setAttribute found in the browser, or if the browser is IE6 or IE7 (to bypass the dreaded operation aborted bug, and it uses conditional comments to achieve this.)

Iframes Similar to scripts, load events can be added to iframes, but with the (fatal) exception that you cannot check whether the contents of an iframe have actually loaded using the events. A failed load will callback as loaded in the exact same way as a successful one. And as much as you'd wish otherwise, the onerror event never fires on iframes. ๐Ÿ™

The contents of iframe documents - on the same domain only - can be checked using: iframeelement.contentDocument || iframeelement.contentWindow.document to give access to the iframe document tree (again, cross-domain is blocked for this, and will throw a security warning if it is tried. document.domain may even need to be matched for subdomains of the same domain to avoid this warning.) However, this leaves us with the currently unsolved dilemma of what to check them for anyway to determine if they have loaded properly, because again, the content could be anything and a browser warning is a valid document just as much as a normal webpage.

So where does that leave iframes? Rather than give up entirely, there is a way to check loading, but only for iframes where you are the owner and can edit the contents of them... this is because child iframes can however send information BACK to the parent window using javascript. This can be done by pasting a snippet of javascript in the footer of the Iframe contents... the actual snippet for doing is currently being tested and optimized with some forethought so it hopefully doesn't have to be changed later.

What do I do if it's not working?

If it's really "not working", I would like to know about it so it can be fixed, since the whole point of this plugin is fixing things! However, you need to be totally sure that the resource you are having problems is working fine in itself on a normal page (one without WP AutoMedic) before even considering the problem has anything to do with WP AutoMedic. Seriously, please double-check this before reporting a bug, there is just no way to fix things otherwise because there would simply be no time left to check real issues if it is all taken up by misreported ones. That said, here's what you can do:

  1. Take a moment to think about (and test?) whether the problem is one that could be caused by AutoMedic OR is one not being fixed by AutoMedic so you have that clear.
  2. This is because possible problems being caused by AutoMedic must take priority.
  3. Retest the issue a few times yourself to reproduce it. Bugfixing relies on testing and if the issue cannot be reproduced effectively, it simply cannot be fixed.
  4. Check the known issues/limitations of AutoMedic to make sure it is something new.
  5. Take note of the browser and exact version used when you had the problem.
  6. Take note of your operating system and the exact version used also.
  7. Install another browser, check the page and see if the result changes.
  8. Note the other browser and version number and whether the issue reoccurred or not.
  9. Optionally repeat with as many browsers as you think confirms/denies the issue.
  10. Clearly write all this information and describe exactly how to reproduce the issue.
  11. If you are a developer yourself, help out by trying to find both the bug and the solution yourself and possibly contributing that directly instead of a bug report.

How do I do a manual test?

To manually test, you can put a broken resource on a page (a HTML tag to an image src, or link stylesheet href, or script src, or iframe src that doesn't exist at that URL) and load the page. (If you already have a broken resource on a page, did you triple check it is not just a typo?) Then manually (eg. by FTP) rename an existing resource to where the resource URL is already pointing to. Depending on your delay and cycle settings the resource will then be found and loaded. eg:

  1. Add <img src="/images/nothinghere.gif"> to a page and Save.
  2. Load or preview the post/page in your browser.
  3. Rename /images/somethinghere.gif to /images/nothinghere.gif
  4. Wait for the image reload cycle to kick in and reload the image.
  5. To retest, rename the image back again before loading page.


  • Public Release Version *
  • Fix to Cache Busting Function
  • Fix to Debug console logging options


  • Release Candidate *
  • Script Reloading Beta
  • Script Events Beta
  • Iframe Cycler Working
  • Page Buffering Working
  • Fallback Resource Cache Alpha
  • Dynamic Loading Method Working
  • Fallback Dynamic ImageLoad Method Working
  • Stylesheet Reloading Optimized
  • All js functions 'am' prefixed


  • Beta Version
  • Stylesheet Reloading Working
  • Image Reloading Optimized


  • Alpha Version
  • Image Reload Working


  • Development Version
  • Reload Cycling Working (sheesh!)
  • Image and Stylesheet Testing

  1. Upload via the Plugins upload page.
  2. Activate the plugin through the 'Plugins' menu in WordPress
  3. Visit the Settings -> WP AutoMedic menu to choose your options.
  4. Select which resources to reload and where to reload them.
  5. Set the delay/cycle/attempts for each selected resource and Save.


Please Login (or Register) to Download this Plugin.
Log In

Leave a Reply

Your email address will not be published. Required fields are marked *