afraid the hash is an inherent part of how AO keeps tabs on files changing & caches honorconsulting. even more; if you have CSS with different media-attribute values the hash is the only way to differentiate between e.g. the CSS for media="print" and the one for media="screen" or media="all" or between the autoptimized JS for page A (with a slider and thus the slider JS) and page B (with a contact form and thus specific JS for that).
why not keep the hashes, ugly as they may seem, and prior to generating the static site purge the AO cache to make sure no old cache files remain?
Yes, I’m realizing that it would not be feasible to separate these two. Instead, I am going to exclude anything but foundational CSS (theme and child), so that it will be minified, but not aggregated, and intercept plugin styles through functions to load a “plugin child stylesheet”, so that small changes to plugin specific classes etc. won’t end up changing autoptimize hashes across the entire site when it really only affects a few individual pages. Static is Cloudfront running on HTTP/2 so this should keep things dynamic, but with little impact on performance. The only reason I’m fussing with this is to reduce the amount of time it takes to deploy. Less changes to HTML means I can take advantage of the iterative features of WP2Static and deploy faster for small changes.
Instead, I am going to exclude anything but foundational CSS (theme and child)
in that case it might interest you to know that AO has filters (autoptimize_filter_js_whitelist and autoptimize_filter_css_whitelist) to set a whitelist to set what can be optimized (aggregated & minified).
