Fabian

I can confirm this. It seems to be quiet on front-end page requests. Any ajax, rest or dashboard page request triggers this error.

@wfyann Yes, it was blocking one of my sites for a couple of 100ms. Good to hear that you plan to optimize it!
I understand the cache issue, its a shame that you actually can’t reliably use the cache anymore.

Thanks for your reply.

I didn’t mean the bundling process (aka. merging, vulcanizing) of JS/CSS files. Its about the JS/CSS inside the HTML markup.

True with slow connections, but with gzip the actual saving is not that big, considering that usually (with good plugins) there is few JS inlined in the page HTML.

I think in W3 Total Cache there is a confusion between “Minification” (the actual code compression) and “Bundling” (merging multiple JS/CSS) files into a single one.

(As a side note: Bundling looses importance with HTTP/2, see https://stackoverflow.com/questions/30861591/why-bundle-optimizations-are-no-longer-a-concern-in-http-2 )

My sentece about CPU/Network is the actual reason for the issue I’m talking about.

It would be interesting to see how much you could win, if you pass a callback to ob_start() that receives the chunks, minifies them, and outputs as soon as they are ready, for example after a ‘</script>’ in HTML

• This reply was modified 7 years, 1 month ago by Fabian.

Thank you!

Get 3.4.4 from https://github.com/f4bsch/WP-Filebase

Did you set a File Browser Page in WP-Filebase settings? If not, try to set the ID there to 999999.

Again, update from here: https://github.com/f4bsch/WP-Filebase/archive/master.zip

Please update from https://github.com/f4bsch/WP-Filebase

3.4.1 is fine, thats the same as on GitHub (btw there is Download Zip button)

This has been fixed, update at https://github.com/f4bsch/WP-Filebase

I just commited the fix, get latest update from https://github.com/f4bsch/WP-Filebase .

Try the update from GitHub: https://github.com/f4bsch/WP-Filebase

@jetskun: Easiest fix is to edit the Mysql table structure with PhpMyAdmin (allowing NULL values for file_hash)

@wp-newbee: check your browsers’ console to see what the server responded.

Just a side note: this is tested to be working with W3 Total Cache and WP Super Cache.

I think the 1. issue is related to thee post_status. New tickets from the front-end get a status queued, but this status is not queried in the back-end.

An easy fix is to add this filter on the ticket page:
add_filter('pre_get_posts', function($q) { unset($q->query_vars['post_status']); });

This is a very “dirty” fix though, does not consider ticket status anymore.
It seems that the plugin is somehow “messing” with post status. It uses the post_status value and another meta value _wpas_status to specify ticket status. This needs a cleanup I think