WP AutoMedic

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.

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.

You can set the reloading for each type of supported resource to run on the Front End, Back End (Admin Area) of your site - or both - or neither... Minimum recommended setting is Front End loading for both images and stylesheets.

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.

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, so read that section for more details.

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 CMS and website platforms - or basically for any HTML page in the future so the basic functions work just by adding an automedic.js script to the page (currently image and stylesheet reloading.) The more advanced features will more than likely require a little more setup with the standalone version to get working as it may require buffering the entire page output. (WP AutoMedic can do this already for example using the WordpPress hooks.) To begin with however, the Wordpress plugin version will be used for development and testing of a standalone version. (The WP version will probably always have more features as it is able to hook into the existing Wordpress settings, action hooks and page content much more easily and provide a settings interface.)

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 attempt to use cross-browser compatible checks for it's own purposes as it needs to, but these should not be relied upon outside the scope of the plugin for browser compatibility testing.

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 way 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 before outputting if you prefer.) Another alternative is to just 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.)

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
• loops document.styleSheets (with fallback to document.sheet)
• matches link element href to stylesheet href to get stylesheet if either of these, considers stylesheet unloaded:
• !stylesheet.cssRules and !stylesheet.rules
• stylesheet.cssRules.length === 0 and stylesheet.rules.length === 0
• caveat: does not (cannot) check 'external' stylesheets with this method

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.

To manually test, you can put a broken resource on a page (a HTML tag to an image src, or link stylesheet href) 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.