Enqueued Scripts not present in cached markup

[stklcode]

As I discovered now this was not an issue with a single page I had to exclude from caching some time ago, but now messes up with a complete theme of mine.

We initialize the cache in the template_redirect phase and pass our callback to the output buffer.

Now imagine some scripts added in the footer using code like this:

add_action( 'wp_enqueue_scripts', 'my_script_function' );

function my_script_function() {
  wp_enqueue_script( 'my-script', '/path/to/my-script.js', array(), 1.2.3, true );
}

(btw. this is the way default themes like TwentySeventeen and many plugins popular do the job)

The enqueued script is not present in the markup when the OB callback is triggered, so it is not cached.

Issue present in 2.2.4, 2.3-beta.1 and GH master. Tested with WP 4.9.8 and current 5.0 snapshot.

[stklcode]

I just modified the init method (plugins_loaded phase) from

add_action( 'template_redirect', array( __CLASS__, 'manage_cache', ), 0 );

to just calling

self::manage_cache();

And because this phase is damn early and a lot can happen inbetween, I added a _skip_cache() call directly before storing in the set_cache( $data ) function:

public static function set_cache( $data ) {
  // [...]
  if ( ! self::_skip_cache() ) {  // <-- here
    call_user_func(
      array( self::$method, 'store_item', ),
      ...
    );
}

This solves the problem for all of my test sites.

Question:
Did I miss anything here why this could not be safe?

[Georg-Git]

I also stepped into this trap - the link to my js file becomes not part of the cached html file.
So it is really a bug of the current cachify version.

Sorry - due to lack of experience I can not assess Your proposal.

But nevertheless I would like to ask when You expect a update of cachify.

A plugin listed in WordPress Plugin Directory with attributes like:
"updated 2 years ago and tested upto wp 4.6.12"
makes me a little bit nervous 😲

[chesio]

The enqueued script is not present in the markup when the OB callback is triggered, so it is not cached.

Normally, the output buffer passed to Cachify::set_cache should contain everything that has been output by the PHP script (including footer scripts), because the output buffer should be flushed at the end of request. From documentation to ob_start (emphasis mine):

An optional output_callback function may be specified. [...] The function will be called when the output buffer is flushed (sent) or cleaned (with ob_flush(), ob_clean() or similar function) or when the output buffer is flushed to the browser at the end of the request.

If this is not the case on your website, then perhaps something is forcing the output buffer to flush earlier? Since your problem seems to be gone when you activate output buffering (= call ob_start()) early, my guess is that you have another plugin installed that captures parts of or entire HTML output (Autoptimize or similar) and perhaps it conflicts with Cachify in some way..?

Did I miss anything here why this could not be safe?

I would say it is safe, but it comes with a penalty of output buffering being always on, even if the output buffer is later discarded because of positive "skip cache" check.