Forum Replies Created

Viewing 12 replies - 16 through 27 (of 27 total)
  • Thread Starter Rodrigo Gomes

    (@rodrigogomes-1)

    Hello @bcworkz,
    Thank you! ?? You’re right. Is not the ideal solution.

    Due to the cache plugins (WP Super Cache, W3 Total Cache, etc.), some plugins (the most important ones at least) understand that they should use DONOTCACHEPAGE for more compatibility. This gave me this idea to improve the compatibility of my Varnish with some plugins.

    But, it’s just an add-on, in my VCL I have already configured that Varnish should skip some pages. For example:

    	if (req.url ~ "(?i)/wp-admin|/admin/|/adm/|/login/|/wp-(login|signup|activate|mail|cron)\.php|preview\=true|/xmlrpc\.php|/bb-admin|control\.php|bb-login\.php|bb-reset-password\.php|register\.php") {
    		if (req.url !~ "(?i)^[^?]*\.(bmp|css|gif|ico|jpeg|jpg|js|png|svg|svgz)(\?.*)?$") {
    			set req.http.X-BypassVarnish = "allready";
    			set req.http.X-BackendUncacheable = "admin-page";
    			return(pass);
    		}
    	}
    	if (req.url ~ "(?i)/(cart/|my-account/|checkout/|addons/|logout/|lost-password/)|(\?add-to-cart=|\?wc-api=)") { 
    		set req.http.X-BypassVarnish = "allready";
    		set req.http.X-BackendUncacheable = "admin-page";
    		return (pass); 
    	}
    	if (req.http.Cookie) {
    		if (req.http.Cookie ~ "(?i)wordpress_logged_in_|comment_|wp-postpass_") {
    			set req.http.X-BackendUncacheable = "cookie-session";
    			set req.http.X-BypassVarnish = "allready";
    			return(pass);
    		}
    	}

    This is only for some cases where some people rename the standard WooCommerce page or the WordPress administrative page.

    It’s conceivable a plugin simply outputs a no-cache meta tag and does not decide to do so until it’s too late to send headers — that Catch-22.

    And you’re right again, If the Header is not sent before, it will not have another chance, but the person can clear the cache manually when this happens or ask me to bypass the cache in VLC, it is not a very serious problem.

    Or they may output Cache-Control or Pragma headers only. You can check for these in the “wp_headers” filter, but if they are set by .htaccess rules, all PHP can do is read the file, searching for the appropriate Header set rules. Or does Varnish check for these headers anyway?

    By default, Varnish Cache work that way, analyzing the Cache-Control headers.
    But to get a higher cache hit rate on Varnish, I’d rather customize my cache completely.
    So I get a great saving of resources, minimally compromising the functionality of WordPress.

    The final code looks like this:

    	function donotcache() {
    		if(defined('DONOTCACHEPAGE') || defined('DOING_CRON') || is_admin() || $GLOBALS['pagenow'] === 'wp-login.php') {
    			// Do not set header if header has already been sent
    			if (!headers_sent() && $_SERVER['HTTP_X_SERVER'] == "blizhost-varnish") {
    				header("BypassVarnishCache: TRUE");if(!$_SERVER['HTTP_X_BYPASSVARNISH']){exit;}
    			}
    		}
    	}
    	function donotcache_filter($template) {
    		donotcache();
    		return $template;
    	}
    	add_filter( 'init', donotcache );
    	add_filter( 'template_include', donotcache_filter );

    I really appreciate your help and opinion! ??

    Thread Starter Rodrigo Gomes

    (@rodrigogomes-1)

    Hello @bcworkz,

    Thank you for your time in such a detailed response.

    template_include actually work!

    function my_function($template) {
            if(defined('DONOTCACHEPAGE')) {
                    header("MyCustomHeader: 12345");
            }
            return $template;
        }
    add_filter( 'template_include', 'my_function' );

    I’m going to do a few more tests, but it works perfectly so far.

    What I’m going to do is much more complex.
    I will use this Header to communicate with the Varnish Cache (proxy server) and set when it should not cache some content.

    As Varnish Cache will only know that content can only be cached after actually accessing it, the connection will repeat itself.
    To save resources from the server, I set to stop processing the page once it realizes that it is the access that will be repeated and after sending the header.

    if(defined('DONOTCACHEPAGE') || defined('DOING_CRON') || is_admin()) {
    	if (!headers_sent() && $_SERVER['HTTP_X_SERVER'] == "blizhost-varnish") {
    		header("BypassVarnishCache: TRUE");
    		if(!$_SERVER['HTTP_X_BYPASSVARNISH']){ exit; }
    	}
    }

    Because of Varnish’s limitations as a proxy, this was the best way I found to do this.
    If it gets confusing, I can try to explain it another way.

    Note: The connection needs to be repeated because the cookies sent on the first access will be sent to the second. Limitation of Varnish Cache with cookies.

    @petjordan I’m not sure, but I believe this plugin does not make requests on admin-ajax.php.
    I’m using this plugin with a high traffic load too and the CPU is very light.

    Thread Starter Rodrigo Gomes

    (@rodrigogomes-1)

    The problem keeps happening, many requests on the “admin-ajax.php”.

    Thread Starter Rodrigo Gomes

    (@rodrigogomes-1)

    Hello,

    The problem has come back with the latest update.

    Thread Starter Rodrigo Gomes

    (@rodrigogomes-1)

    Hello,

    I updated the plugin and it seems that has been resolved.
    In the last 24 hours we had no overhead on the server.

    Thank you!

    Thread Starter Rodrigo Gomes

    (@rodrigogomes-1)

    Sure! I can attach here as image.

    apache logs

    And in Network tab on Google Chrome, I see this: action: call_an_adblock_counter
    Page: admin-ajax.php

    Thread Starter Rodrigo Gomes

    (@rodrigogomes-1)

    For three reasons:
    1 – The Network tab on Google Chrome Inspect Element Tool
    2 – Apache server status logs
    3 – The problem stops when the plugin is disabled

    The problem does not occur in version 1.9 of the your plugin.

    Plugin Author Rodrigo Gomes

    (@rodrigogomes-1)

    Obrigado pelo feedback Anderson!
    Ficamos felizes em ler seu comentário. ??

    Plugin Author Rodrigo Gomes

    (@rodrigogomes-1)

    Disponha!

    Estou marcando o tópico como resolvido. E obrigado pelo feedback! ??

    Plugin Author Rodrigo Gomes

    (@rodrigogomes-1)

    Olá Anderson,
    Que bom! fico feliz que conseguiu resolver o problema do seu carrinho.

    Quando um cliente solicita Varnish Cache em seu site nós estudamos o sistema do site e configuramos o cache para ignorar certas páginas e sess?es, ent?o as páginas /carrinho, /conta, /checkout, etc. e usuários logados s?o completamente ignorados pelo Varnish cache.

    Além disso, assim como um blog quando cria/edita novas postagens tem o cache apagado automaticamente, o mesmo acontece quando você cria/edita novos produtos.

    Posso te ajudar em mais alguma coisa? Se tiver duvidas n?o hesite em perguntar!

    Plugin Author Rodrigo Gomes

    (@rodrigogomes-1)

    Olá Anderson,
    Nosso plugin é 100% compatível com WooCommerce!
    O seu problema é muito comum e acontece com muitos sites que utilizam sistemas de cache, o carrinho do seu site está carregando os produtos diretamente no código da página e o varnish está salvando essa página na memória, por este motivo ele exibe para você e/ou outras pessoas produtos no carrinho que n?o est?o ali.
    Para resolver esse problema, basta você usar temas e carrinhos que utilizam a tecnologia ajax, requisi??es ajax n?o s?o armazenadas em cache. Além disso, você pode abrir um ticket para que possamos analisar e tornar as páginas do seu site e-commerce compatível com o Varnish Cache.

Viewing 12 replies - 16 through 27 (of 27 total)