pkhamre / wp-varnish Goto Github PK

I think line

plugins/wp-varnish/wp-varnish.php:371: add_options_page(__('WP-Varnish Configuration','wp-varnish'), 'WP-Varnish', 1, 'WPVarnish', array($this, 'WPVarnishAdmin'));

has to be corrected in like http://tumbledesign.com/fix-notice-has_cap-was-called-with-an-argument-that-is-%20deprecated-since-version-2-0-in-wordpress%20/

See http://codex.wordpress.org/Roles_and_Capabilities#User_Level_to_Role_Conversion

I found this repository looking for the the most recent wp-varnish code. I really like some of the updates and in fact started using the code on our site.

I use the following config in wp-config.php

global $varnish_servers, $varnish_version;
$varnish_servers = array('127.0.0.1:80');
$varnish_version = "3";
define('VARNISH_HIDE_ADMINMENU',1);

I don't want any of the options to be viewable by users on the network. I guess this is a feature request, and would like to see these settings in network admin pages, rather than on the site admin pages. Another plugin I use for domain mapping does this very well and could be an example. Either way I like having the options above.

It is possible that varnish has been configured to deny access to requests with empty or non existent user-agent header.

Some sites needs a bit of tweaking to appropriately cache: for example, my site also has a custom feed (url: ?feed=premoderate) which is not purged by wp-varnish.
With a filter, I'll add this to "commonobjects".

I intend to work on this to propose a patch; but I'm asking for opinions here.

when status changes, post, homepage and feed has to be purged.

I have a patch for this :) I'll publish it asap

When saving a navigation menu with the latest version (0.4) or previous version of wp-varnish (0.3) enabled it can triple or quadruple the time it takes to actually save the menu. I've taken a screenshot in NewRelic of the process trace: http://c.ed.gs/MebR.

Also since updating to 0.4 we seem to be experiencing random bouts of mass PURGE requests taking over PHP, in effect killing or slowing down our server massively.

Cheers,
Ed

vcl that is included caches 404'ed images, javascript, etc.

When the url is generated to purge the cache it is taken from the blog info. The result is on mapped domains the cache never gets purged.

If I use classdroid to upload an image to wordpress the cache isn't cleared, it would be nice to have support for this.

obj.ttl changed to beresp.ttl

so not:
obj.ttl = 60s;

now:
beresp.ttl = 60s;

From: http://wordpress.org/support/topic/purge-css-files

How do I purge css files without using a shell account and sending a request?

You should build into this plugin a spot to put a file (http address) to purge and let us hit the Purge button!

Hello,

The wordpress plugin repo installs this plugin as wordpress-varnish.
This plugin thinks it's called wp-varnish.

So, when it goes looking for the javascript file, in order to allow you to add rows, it can't find it, because it's looking for:
~/public_html/wp-content/plugins/wp-varnish/wp-varnish.js
instead of what it should be looking for:
~/public_html/wp-content/plugins/wordpress-varnish/wp-varnish.js

Can you either fix the names, or make it detect it's location automagically please? :)

Since posts are listed on category pages, those pages should be purged as well.

function WPVarnishPurgeCommonObjects() {
...
$this->WPVarnishPurgeObject('/category/(.*)');
...
}

wp-cron.php need not to be cached, if we want to execute via cronjob (wget / curl)

What do you think ?

On another installation, noticed that localhost was hardcoded which breaks purging:

Warning: fsockopen() [function.fsockopen]: unable to connect to localhost:80 (Connection refused) in /var/www/dxxxxxx/wp-content/plugins/wp-varnish/wp-varnish.php on line 75
Connection refused (111)

Warning: Cannot modify header information - headers already sent by (output started at /var/www/xxxxxx/wp-content/plugins/wp-varnish/wp-varnish.php:75) in /var/www/xxxxxx/wp-includes/pluggable.php on line 868

line 75 and 93 have:

$varnish_sock = fsockopen("localhost", 80, $errno, $errstr, 30);

You'll want to use

$varnish_sock = fsockopen(get_settings('wpvarnish_address'), get_settings('wpvarnish_port'), $errno, $errstr, 30);

After putting in the logic to save host/port. Also, you default to port 6082, the administration port, but, your code logic and included vcl works through the HTTP/listen port.

Certain WordPress UI functions were slowing down my app (igrealty.com). It seems whenever I upload images, save and delete posts or delete assets from the media library the app spikes in slowness. New Relic produces alerts and things go very slowly. Here's a grab: http://imgur.com/NzyG6

Disabling all my plugins and reactivating one by one I found that WordPress Varnish is the culprit. With WordPress Varnish disabled my app is much faster with more normal page load times. Apdex > .7.

Anyone else having this problem?

the line

add_action('plugins_loaded',array($this, 'WPVarnishPurgeAll'), 99); 

in wp-varnish.php file triggers unnecessary "ban" request sends to varnish server when visitors hitting different URLs on the website.

For example, a vistor first request a url http://example.com/wordpress, varnish caches the request. But when he hit second url http://example.com/wordresss/?p=1, a BAN request is send to varnish, and banning all the cached objects. Please see the following varnish ban list captured after the second request.

0x7faddb3fd700 1360642410.172042     0 req.url ~ /wordpress/category/(.*) && req.http.host == example.com
0x7faddb3fd6c0 1360642410.171567     0 req.url ~ /wordpress/feed/atom/ && req.http.host == example.com
0x7faddb3fd680 1360642410.170976     0 req.url ~ /wordpress/feed/ && req.http.host == example.com
0x7faddb3fd640 1360642410.170378     0 req.url ~ /wordpress/ && req.http.host == example.com
0x7faddb3fd600 1360642410.169820     0 req.url ~ /wordpress/?p=1 && req.http.host == example.com

After I disabled this line, the plugin works as expected.

• Load/Unload VCL on the fly.

um, nevermind :)

We've used the Wordpress.vcl, but for some reason logouts are not working, it is not clearing the cookies.

Login works just fine.

WP 3.7.1

http://wordpress.org/support/topic/create-blogsite-warning-fsockopen

In 3.5.1 Multisite I'm seeing an fsockopen() error when creating a blog/site. The blog creates without any issue, I just thought I'd report this.

Warning: fsockopen() [function.fsockopen]: unable to connect to :0 (Failed to parse address "") in /public_html/wp-content/plugins/wordpress-varnish/wp-varnish.php on line 371

$temp_ip = explode(',', isset($_SERVER['HTTP_X_FORWARDED_FOR'])
? $_SERVER['HTTP_X_FORWARDED_FOR'] :
(isset($_SERVER['HTTP_CLIENT_IP']) ?
$_SERVER['HTTP_CLIENT_IP'] : $_SERVER['REMOTE_ADDR']));
$remote_addr = trim($temp_ip[0]);
$_SERVER['REMOTE_ADDR'] = preg_replace('/[^0-9.:]/', '', $remote_addr );

The line here:

https://github.com/pkhamre/wp-varnish/blob/master/wp-varnish.php#L111

// When xmlRPC call is made
add_action('xmlrpc_call',array($this, 'WPVarnishPurgeAll'), 99);

Causes the entire site to be flushed with fairly high frequency on Wordpress installs where users use mobile apps to submit stories. Is it really necessary? There are already highly targetted hooks that purge specific pages when an article is added, deleted, etc.

Method to test to make sure purge is working from within the admin

May not purge enough

• Category added, all pages that mention the category need to be purged (I believe purge req.http.host ~ www.domain.com in the Varnish CLI)
• New Tag, again, all pages
• comment_post/edit_comment/delete_comment
• trackback_post
• wp_set_comment_status
• blogroll modifications

With Varnish, in order to use ESI, you must remove the gzip/deflate vary headers as Varnish will not uncompress content to check for ESI. While that can be fixed in VCL, assembled pages with ESI are not compressed when delivered to the end-user.

I've not had the time to write a simple zip compression for vcl_hash yet.

Horrible horrible bug with latest version 0.5
Infinite loop somewhere.
Setup a seperate server etc to isolate the issue. Took 8 hours of my working day to find out it was the plugin. Worked fine before update but i updated it in bulk with other plugins ....
Anyway haven't had time to isolate the exact line of code in question.
If there is anything to add to the vcl file since 0.4 plz make that explicit in the changelog.
Removing in the mean time.
Thanks

Hi There

Awesome plugin thanks! Much better than any of the others I tried.

My favourite feature, is the 'clear this page' option, when you are logged in and browsing your site. Might just be me, but I think it would be much better if it flushed and then reloaded the page, rather than sending you to the wp-varnish page.

Do you think this is worth pursuing?

Cheers
Sam

Hello,
Thank you for your work on this project.

I have a Multi-Site 3.01 install with buddypress, multi-domain, and a affiliate plugin installed.
When I login to my account typically on the site url the admin bar would change. It seems to change once I am under wp-admin but visit the just the page it is if I am still logged out.

I am not sure if this is just caveat of caching or if I could work around this type of stuff.

http://mysiteinc.net

Again thank you for your work.
Joe

Just a heads up. When you install the plugin through the wordpress plugin installer, it downloads it to plugins/wordpress-varnish, which breaks most functionality since you hard coded the paths to be wp-varnish, the same as in this repository. I cloned the git repository instead since it contains the correct directory name, but even then the javascript file isn't included correctly, so I when I click on the + button, nothing happens. I had to load the javascript in myself using chrome dev tools and make the call explicitly.

During purge,

$varnish_sock = fsockopen($wpv_purgeaddr[$i], $wpv_purgeport[$i], $errno, $errstr, $wpv_timeout);

$wpv_purgeport[$i] is somehow a string.

Warning: fsockopen() expects parameter 2 to be long, string given in /home/xxxx/public_html/wp-content/plugins/wordpress-varnish/wp-varnish.php on line 364

Need to verify the data entry, it appears that a string can be sent through in the port number somehow.

I noticed in the varnishlog my blog (located at /blog) would appear as /blog/blog in the urls

I added this to the WPVarnishPurgeObject function to fix the issue above
add after "$wpv_url = $wpv_blogaddr . $wpv_url;"

if (0 === strpos($wpv_url, $wpv_blogaddr . $wpv_blogaddr)) {
    $wpv_url = str_replace($wpv_blogaddr . $wpv_blogaddr, $wpv_blogaddr, $wpv_url);
}

Also single posts wouldn't purge so I added

$this->WPVarnishPurgeObject($wpv_url);

before "// Add support for multipage content for posts and pages"

hope this helps someone (I'm running WP 4.1)

At the moment, I use the following setup using this plugin...

1. Use admin port instead of PURGE method. (this option is checked)
2. Varnish version - 3

Basically, I use only ban in Varnish.

The only situation when I need to use ban multiple objects is when I have to ban all objects of the entire site. That is what happens, when I click the button "Purge All Blog Cache". In most other cases, I do not have to ban multiple objects. There are exceptions, of course, such as banning all objects of a particular category or tag.

The current code at https://github.com/pkhamre/wp-varnish/blob/master/wp-varnish.php#L406 bans all the URLs starting with the requested URL. For example, if I request to ban only the home page, it actually bans all the objects of a site.

Fresh install, looks in wp-varnish for wp-varnish.js rather than wordpress-varnish/wp-varnish.js

PHP Version 5.4.1
WordPress 3.3.2

[06-May-2012 13:46:02 UTC] PHP Warning: Missing argument 2 for WPVarnish::WPVarnishPurgePostStatus() in /wp-content/plugins/pkhamre-wp-varnish-9c8acca/wp-varnish.php on line 140
[06-May-2012 13:46:02 UTC] PHP Warning: Missing argument 3 for WPVarnish::WPVarnishPurgePostStatus() in /wp-content/plugins/pkhamre-wp-varnish-9c8acca/wp-varnish.php on line 140

[06-May-2012 13:46:02 UTC] PHP Warning: Missing argument 2 for WPVarnish::WPVarnishPurgeCommonObjectsStatus() in /wp-content/plugins/pkhamre-wp-varnish-9c8acca/wp-varnish.php on line 113
[06-May-2012 13:46:02 UTC] PHP Warning: Missing argument 3 for WPVarnish::WPVarnishPurgeCommonObjectsStatus() in /wp-content/plugins/pkhamre-wp-varnish-9c8acca/wp-varnish.php on line 113