pjv

? hhvm –version
HipHop VM 3.4.0 (rel)

I’ll try restarting the servers as you suggest. I haven’t tried it with php-fpm yet – performance-wise, I’m a lot more wedded to HHVM than redis at the moment, but I would really like to get both working.

I made out ok by switching to this alternative redis object cache plugin: https://www.ads-software.com/plugins/redis-cache/

No idea what the problem was, but I am sure that wordpress had read permissions for wp-content/object-cache.php.

hi, did you ever resolve this?

i’m suddenly seeing the same thing. when using the “copy to new draft” link, the link is correct, but when it hits the server the server responds with a series of 302 redirects that gradually strip pieces of the query away until it gets to /wp-admin/edit.php which just shows you the list of posts.

anyone?

@archon810

fwiw, i put your quick and dirty fix into Memcached.php and it fixed an issue that i was having running woocommerce with w3TC, letting me turn on object caching for the first time. thanks!

are you running the patch for ObjectCache.php you listed above in production? If so, how is it working for you?

Same issue. What’s up with followers?

I have a script that backs up the followers into a CSV file nightly. The last time that script ran properly was 8/23/2013.

Has something changed? Is there a way to un-change it?

thanks @rahul286, i did not know that nginx let you configure multiple zones like that. it doesn’t exactly give me what i want since i still have to fully configure every host separately, but at least it would make separate cache directories possible.

i have just been trying (failing) to set up something like this (in http):

fastcgi_cache_path /home/sites/cache/$host levels=1:2 keys_zone=$host:500m inactive=60m;

but for this purpose $host is not substituted in this context (even though it is for other directives in the http block – why?), and i end up with a cache directory actually named “$host”.

now i’m wondering if there is a way to use the map directive to do something like this.

oops, yes, sorry for my sloppy language. what you said is what i actually meant.

that was actually my original suggestion from a while back on how to purge the cache. it is fast and easy. it has the security issues that other contributors to this thread have brought up, but to me it still seems like a good solution.

what i am struggling with now is a way to manage my nginx configs and my cache paths so that i can run multiple wordpress installs in parallel and be able to purge them independently.

up to now, i have been storing the cache for all the sites in one cache directory which lets me set up a single fastcgi_cache set of directives in my http block of the main nginx.conf. since the cache key includes the hostname, it works fine in practice. the problem is that with this cleaner and simpler method of purging, any “full purge” is really a FULL purge – eliminating the entire cache for all the sites and that’s not what i really want.

so i am trying to come up with a clean scheme now to have separate cache directories for each site but not have to also write a full set of separate fastcgi_cache directives into the config for each separate site since the only thing that varies between them would be one element in the cache path and the name for the keys_zone. would be nice if there was a simple way to plop in a variable, but due to scope for variables and the fastcgi_cache directives in nginx configs, i can’t figure out how to do it.

anyone have any ideas or a working example?

looks like the plugin authors changed their minds about this issue and decided to go ahead and implement a simple unlink on the cache directory.

i am seeing the same issue on my production server but not on my test server.

the production server has all kinds of caching turned on and the test server has none.

after upgrading the plugin on production, i did clear the caches, so that might not be it. but that is the primary difference between test and production.

went ahead and sent the pull request so you can decide whether you want to incorporate the change or not.

ok, i found the log and i see what the problem is. i was wrong about siteurl being correctly configured.

i was also too brief when i said that the setup was the same as in your tutorials as there is one more significant piece that i left out. i am using git to manage my wordpress install, following this guide, and that results in my siteurl needing to have /wordpress appended to it.

i can fix this issue for myself in this case by using WP_HOME instead of WP_SITEURL as the url for the homepage purge. but i am wondering if that might be the better URL to use for everyone. if so, i am happy to make the change and send you a pull request through github. otherwise i will do it for myself only and manage future updates to the plugin manually.

thanks again.

i’m running the the dev version now with
define ('JETPACK_DEV_DEBUG', true);
in my wp-config, and so-far so-great.

thanks for addressing this pressing need.

thanks, i had no idea you could set the cookie domain in wp-config.

that seems to be working for me.

never mind, i found the answer: it generates a unique additional string for media that may have been previously cached so that the new version will over-ride the cached version.

on further experimentation, i was wrong about the proxy setting having any effect on the plugin recognizing the HTTPS host as a subdomain. i hadn’t realized how much “cleaning up” i need to do to see the result of changing things clearly: clearing caches, saving settings, restarting the php-fpm process… anyway, now that i know all that, i can see that the proxy setting has no effect.

when i have the HTTP host proxied by cloudflare the plugin will not set a domain-wide cookie.

given that the HTTPS host is a simple subdomain of the HTTP host, i’m sure that there has to be a relatively simple fix for this. mike: is there anything that i can do to make it easy for you to diagnose? i can set up a user on my site and/or do any experiments that you want to suggest and log results.

i’m also willing to dig around in the plugin’s code and try things if you could point me in the direction of where to start. i’ve looked through it, and i write code, but not php and i have never done a wp plugin, so the whole structure is a little bewildering to me. i’m thinking that it has to be somewhere in the code that is validating the subdomain, but for the life of me i can’t imagine what difference it can make having the HTTP host proxied by cloudflare. it’s still the same URL, same hostname, same basename.