exbm

I have the gantry plugin and the problem goes away when disabled.

I have looked into this: correct me if I am wrong but can I add more Rest endpoints by extending the WPCOM_JSON_API_Endpoint class then extending that with a another class that defines the callback function. then constructing that class with the arguments of my new endpoint.. will this automatically update the url rewrites?

I couldn’t find in the code where you define the url_rewrites..

As far as I can tell it works like this:

XML_RPC method added json_api that initializes the JSON_API class with the url used to access the xml method. then that’s passed to the endpoints array and calls the appropriate endpoint callback method? I am assuming that you use url_rewrite to change the rest uri to the xmlrpc.php and setting the method json_api?

If you use disk:basic you can cache any wordpress url in wordpress. I have tested it using custom query_vars and a template_include filter.

use Disk:basic caching then check:

Cache URIs with query string variables

in the page cache config tab.

You can then use exclude pages you don’t want cached with regex in the never catch these pages box on the advanced section.

with the update I went from ~1 sec for initial request to under 200ms reponse time!

I got the plugin to install with no problems.

My Old Server Configuration :

php as MOD_php
Apache configured with suExec:webuser:psalcn
apache ran as apache:apache
Safe_mode ON

New Sever Configuration :

PHP as Fast_cgi
Apache configured with suExec webuser:paslcn
Apache ran as apache:apache

With the new configuration the plugin was able to install using fs_direct.. rather then having to install using the ftpsock.

I think the problem is even though suExec is in effect it doesn’t matter for PHP because PHP was ran under apache and so got apache:apache as a user. Once I changed it to FastCGI then php would execute under the user.
I am just spit balling here but it might be that if you run php under apache.. it can’t modify files. The files are owned by apache:apache some aspects of hte file system api fall under suExec and are ran as webuser:psa ??????

I use a VPS, that has Centos and Cpanel.

If you guys think this is a small issue by a small subset of users think again. You are marked as broken on your plugin page. over 61 people. You have many posts every day about this issue. Maybe your paid enterprise clients can get around it with your help but if you don’t share what you are doing to fix it. You are going to lose your install base to other caching plugins and that install base will take their enterprise clients with them.

I too believe that my problems are from server configuration. I don’t think my server is configured *wrong* but something about the way my server is configured and the way the w3tc uses the FS API is not getting along. WP has no problem installing plugins using the same API

I believe that the problems lies in a thrown exception during the SETUP class on the w3tc cache admin page. w3tc goes through a self test to make sure the files it uses in cache directory are the right permissions. To do this is creates a test_dir and a test_file.

The test_dir is created just fine on my server therefore the test_file should work in a dir created by the plugin.

I would test further but I have to go live with the site very soon and need a solution that works!

I believe the problem may lie in how cpanel configures the apahce server by default. there is the user Apache:Apache and then the user Webuser:psagroup (not exactly that) Then php is configured to SuExec as Webuser.. but when files are created they are created by apache:apache.

Btw the plugins operates normally when I manually install everything and the set the right permissions but i am still presented with errors.. I think the errors are from the testing portion. (the test fails but the plugin otherwise CAN use the files.