gidomanders

@malferov Those errors have nothing to do with PHP 7.2 incompatibility. You forgot to install the json PHP extension:

https://stackoverflow.com/questions/18239405/php-fatal-error-call-to-undefined-function-json-decode

@malferov could you share those errors please? We fixed the issue that’s causing PHP warnings in the logs (upcoming release, v0.9.7.1), but we’re not aware of any PHP errors. Sharing those errors can help us fix incompatibilities in the upcoming release too.

The messages you see are warnings, so you could change the PHP configuration to not display warnings (or any messages at all). The second and third warning are caused by the first warning, as there is something sent to the output buffer before a session could be started or headers could be set.

You could try to change WP_DEBUG to false define( 'WP_DEBUG', false ); in your wp-config.php. If that doesn’t work, add error_reporting( E_ERROR ^ E_WARNING ); directly below the WP_DEBUG definition. You could also disable all reporting by adding error_reporting(0); instead.

If none of the above works, please ask your host to help you by changing the core PHP settings. They’ll know what I mean.

If you’re still having issues after this was fixed, please don’t hesitate to ask. I’m happy to help!

I think deleting and reinstalling is not going to help. I also can’t help that much figuring out what causes the 500 error, without checking the logs. It could be another plugin that’s not compatible or your theme… You should check out the logs for any details about the errors and share them if you don’t know what to do.

If you select an option, you’ll see what it costs. The plugin configuration is 200 dollars.

I suggest you go to Performance => Support and request plugin configuration. Then we can ask for login details and help you set up the plugin for your environment.

If you see something similar to this: https://ps.w.org/static-html-output-plugin/assets/screenshot-1.jpg?rev=1905857
Then Performance should be located in the left sidebar in the bottom where Freemius Debug is located in the screenshot.

It is a menu item added by the plugin that is supposed to be somewhere underneath settings, but not in the settings submenu. You should be able to see an item called Performance in the admin bar too. If you don’t see that, you didn’t install our plugin, or you didn’t activate it.

In your WP Admin, there should be an item in the menu called Performance. When you hover over it, a submenu should appear next to it. When you clicked it, the submenu opens underneath that item.

One of the submenu items is General Settings, click that one. On that page, you have a lot of blocks, first one is “General”, second one is “Page Cache”. On the Page Cache block there is an option Page Cache: which should be enabled, if not then enable it. There also is an option Page Cache Method: where you should select Disk: Enhanced.

After changing the settings, click Save Settings & Purge Caches. If you have any trouble, I advice you to click the submenu item Support and choose “Plugin Configuration”. Fill in the rest of the form and we’ll help you set up your plugin as soon as possible.

That’s the default behaviour. You don’t have to do anything but check the settings if Page Cache mode is set to Disk: Enhanced.

WordPress is actually not built to hide itself.

Install our plugin and set Page Cache mode to Disk: Enhanced in Performance => General Settings. That mode actually works like serve static pages directly to the main url folder, but instead of having the files in the main url folder, the pages are saved in the wp-content/cache/ directory of your WordPress installation. Our plugin will configure your Apache/NginX to serve the files directly instead of running the installation to build the page.

The best way to do that is to install WordPress in a directory that is not available to the public. You can then rewrite all requests to the private directory using htaccess or a custom NginX config. Use a CDN for static files, otherwise scripts and styles won’t work because your installation is in a private directory.

@ritaantal Fragment cache is a premium feature, but page fragment cache is not. I’ve actually been working on an FAQ item about page fragment cache. here’s the part of it that explains the difference with Fragment Cache:

“Page fragment cache” dynamically loads content (real-time) on your cached pages by parsing them for specific tags you manually embed. Despite the naming, this feature should not be misunderstood with “Fragment Cache”, the premium feature. “Fragment Cache” extends the transient API in WordPress to provide caching and purge policy management for fragments you manually create. It also enables fragment groups, defined by a plugin or theme, which include common operations to be cached using transients.

@ritaantal I think I know what the problem is. They modify the page before the page is cached. This means that they change the page according to the cookie preferences of the user that is requesting the page, and then the page is cached. For visitors requesting the same page after it was cached, the cached page will be sent directly from Apache/NginX to the browser, so the server doesn’t have to start up a PHP process. This means they will not get the page according to their preferences if their preferences are different.

What I explained above is how Page Cache Disk: Enhanced works. If you use Disk: Basic, a PHP process will be started and the cached page will be crawled to check for (page) fragment cache before sending it to the browser. A short explanation:

Fragment Cache and “page fragment cache” dynamically loads content (real-time) on your cached pages by parsing them for specific tags you manually embed. That way the server doesn’t have to build the entire page from scratch.

Using Disk: Basic should also fire the WordPress shutdown hook, so I expect their plugin to be compatible with ours as long as you do not use Disk: Enhanced.

@ritaantal To answer their questions:

We register our own shutdown hook to capture pages for minify and caching. We do this using register_shutdown_hook(). Hooks are fired in the same order as they are registered, and we register ours after the WordPress core shutdown hook is registered, so the WordPress shutdown hook should run normally before ours.

To clear the cache, they can call one of our functions: w3tc_flush_all(), w3tc_flush_post($post_id), w3tc_flush_posts() or w3tc_flush_url($url).

But I’d like to know what issues you encounter. Maybe we can help you set up the plugin correctly to work smoothly with their plugin without disabling Page Cache entirely.