Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimizing doesn’t work on my nginx with APC #135

Open
MatzeKitt opened this issue Jul 12, 2017 · 9 comments
Open

Minimizing doesn’t work on my nginx with APC #135

MatzeKitt opened this issue Jul 12, 2017 · 9 comments
Labels
Milestone

Comments

@MatzeKitt
Copy link
Member

I use a fresh Debian Stretch system with the official builds of nginx and PHP 7. My caching method is APC and it does cache some files (if I may trust the stats on the dashboard so far).

The problem is that neither the HTML nor the JavaScript minimizing is working on my system. A live demo with the current active setting “HTML + Inline JavaScript” results in a source code as usual, uncompressed:
https://kittpress.com

I left every other setting untouched.

The nginx configuration is, of course, identical to the one in the wiki.

If you need any further information, please let me know.

@stklcode
Copy link
Contributor

stklcode commented Jul 12, 2017

Is your live demo up to date with Cachify still active? Looks like caching does not work at all.

If it worked, the HTML code should contain the Cachify signature in the end. Should look lilke this:

<!-- 
Cachify | http://cachify.de
APC Cache @ 01.01.1970 12:34:56
-->

Did you add the corresponding lines to your php.ini (or PHP config within nginx), as described on the "Setup" tab of the Cachify settings?

@MatzeKitt
Copy link
Member Author

Yes, it is.

And yes, I added the PHP configuration inside of nginx:

        ##
        # Cachify
        ##

        location ~ .php {
                include /etc/nginx/fastcgi.conf;
                fastcgi_pass 127.0.0.1:9001;
                fastcgi_param PHP_VALUE auto_prepend_file=/var/www/kittpress/wp-content/plugins/cachify/apc/proxy.php;

                location ~ /wp-admin/ {
                        include /etc/nginx/fastcgi.conf;
                        fastcgi_pass 127.0.0.1:9001;
                        fastcgi_param PHP_VALUE auto_prepend_file=;
                }
        }

You can ignore the different filename for fastcgi_params as I use this file for a custom implementation for another software.

However, I can’t find any setting I should change in the php.ini file. Did I miss something here?

I noticed this:
https://wordpress.org/support/topic/plugin-has-no-valid-headerapc-caching/#post-8698598

So if this is still the current state of the plugin it can’t be used within PHP 7 because there is no more APC but OPcache and APCu.

@stklcode
Copy link
Contributor

However, I can’t find any setting I should change in the php.ini file. Did I miss something here?

No, the description is just little confusing. You might as well place the auto_prepend_file value inside the php.ini (global or pool), if not passed by nginx. Should give the same result

So if this is still the current state of the plugin it can’t be used within PHP 7 because there is no more APC but OPcache and APCu.

Yes and no. The APC proxy explicitly checks for extension_loaded( 'apc' ), which should fail (you might try on your system or check the phpinfo()). If you really want to use APC(u) (I would suggest having a look at memcached), you can install apcu_bc (APC backwards compatibility) via PECL to re-enable apc_fetch() (and probably remove the extension check).

@MatzeKitt
Copy link
Member Author

apcu_bc has been installed automatically (there’s an official package in Debian Stretch 🙂 ) and thus extension_loaded( 'apc' ) returns a true, so this couldn’t be the problem.

@stklcode
Copy link
Contributor

stklcode commented Jul 12, 2017

I think I might just have found the bug... Your page is shipped via HTTPS and we changed the hash-function some releases ago (#2), but forgot the APC proxy.

Could you replace this line in your cachify/apc/proxy.php:
&& ( $cache = apc_fetch( md5( $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] ) . '.cachify' ) )
with this:
&& ( $cache = apc_fetch( md5( 'https-' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] ) . '.cachify' ) )

@krafit
Copy link
Member

krafit commented Jul 12, 2017

No, the description is just little confusing.
Well, it's not supposed to be confusing, isn't it? We should take care of, see #136

@krafit krafit added this to the 2.3.0 milestone Jul 12, 2017
stklcode added a commit that referenced this issue Jul 12, 2017
The added prefix for HTTPS pages, introduced in #2, has not been added for the APC proxy which breaks APC functionallity for HTTPS pages (reported in #135).
stklcode added a commit that referenced this issue Jul 12, 2017
The added prefix for HTTPS pages, introduced in #2, has not been added for the APC proxy which breaks APC functionallity for HTTPS pages (reported in #135).
@MatzeKitt
Copy link
Member Author

Even then, it won’t work. On the one hand function_exists('apc_cache_info') in general returns true but $cache=@apc_cache_info($cache_mode) doesn’t, which results in a different behavior of APCu according to APC.

So even with apcu_bc I can’t get APC running in a way as needed by Cachify. 😞

@stklcode
Copy link
Contributor

I know the APC backend has several flaws and this issue is yet a year old, but I'd like move this out of the currently blocked release and into the 2.4 milestone with an overhauled fully APCu compatible backend.

Any other opinions on that?

@krafit
Copy link
Member

krafit commented Mar 25, 2019

moves issue to 2.4

@krafit krafit modified the milestones: 2.3.0, 2.4.0 Mar 25, 2019
@krafit krafit removed the help wanted label Jan 4, 2022
@krafit krafit modified the milestones: 2.4.0, 3.0.0 Feb 14, 2022
@mindsolve mindsolve mentioned this issue Jul 28, 2022
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants