Wordpress Site and W3 Total Cache through Apache PHP-FPM Fas


Wordpress Site and W3 Total Cache through Apache PHP-FPM FastCGI

我已经用Wordpress安装了一个Apache服务器,在安装了几个插件后,我注意到页面加载时间长达30秒或更长,所以我遵循了几个指南,通过删除模块、启用deflate、更改工作进程等来微调和加速Apache

我做的一个更改是删除mod php并通过mod fastcgi使用php-fpm,之后我注意到了几个奇怪的错误。W3 Total Cache报告称,尽管htaccess属于同一用户和组,但它是不可写的,我甚至将其设置为全局可写(777权限),并且minimy无法工作,因为它无法对htaccess进行任何更改。

不仅如此,Minify还发出了两条奇怪的消息

Minify Auto encountered an error. The filename length value is most likely too high for your host. It is currently 150. The plugin is trying to solve the issue for you

它坐在那里试图修复,然后说

Minify Auto does not work properly. Try using Minify Manual instead or try another Minify cache method. You can also try a lower filename length value manually on settings page by checking "Disable the Minify Auto automatic filename test”

此外,兼容性检查也会产生奇怪的消息,声称有一些模块没有被检测到,这些模块已经加载。我做了一些快速研究,发现这些模块很难通过快速gi检测到,但我想知道插件是否在做什么,因为它无法检测到它们。

如有任何帮助,将不胜感激

Apache/PHP-FPM下的W3总缓存"Minify Auto"

我在使用PHP-FPM的Apache下遇到了W3 Total Cache(W3TC)及其"Minify Auto"功能的相同问题。

问题简述

当在FastCGI模式下调用PHP时,一些CGI变量(如SCRIPT_NAMEPATH_INFO)并不总是设置为脚本开发人员所期望的值。在我的例子中,SCRIPT_NAME的值是php5-fcgi可执行文件(/usr/lib/cgi-bin/php5-fcgi)的路径,而不是PHP脚本本身的路径。

W3TC插件中的迷你模块代码要求正确设置SCRIPT_NAME,但如果未正确设置,则会失败。

解决方案

php.ini指令cgi.fix_pathinfo在启用时可以解决这个"CGI变量"问题。在我的情况下,我禁用了此设置,重新启用它会生成正确的SCRIPT_NAME并解决缩小问题。

Debian/Uubuntu系统说明

要重新启用,请更改/etc/php5/fpm/php.ini:中的设置

cgi.fix_pathinfo = 1

并重新加载php-fpm服务:

sudo service php-fpm reload

洞穴

请注意,自2010年以来,在配置错误的Nginx站点中使用cgi.fix_pathinfo设置一直存在安全问题(请参阅此处了解详细信息),但我无法在Apache设置下重现这一点。

从PHP 5.3.9开始,引入了一个新的FPM配置指令security.limit_extensions。默认情况下,只将执行限制为.php文件,而且据我所知,这应该可以减轻历史安全问题。

详细的问题(对于关心的人)

损坏的CGI变量会在派生缓存目录路径的W3TC函数中导致问题。

这反过来又会导致将缩小版.htaccess文件写入磁盘,其中RewriteBase指令中的缓存路径格式不正确。

就我而言,它是:

RewriteBase inify/

而不是:

RewriteBase /wp-content/cache/minify/

这会影响后续的重写规则,最终会阻止缩小代码(依赖于这些规则)被正确调用。