Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Option to disable caching for Home Page / Posts Page #191

Closed
raamdev opened this issue Jun 2, 2014 · 17 comments
Closed

Feature Request: Option to disable caching for Home Page / Posts Page #191

raamdev opened this issue Jun 2, 2014 · 17 comments

Comments

@raamdev
Copy link
Contributor

@raamdev raamdev commented Jun 2, 2014

It would be nice if there was a simple option to disable caching for the Home Page and/or the Posts page, if a site owner wanted to that.

Excluding the Home Page from the cache is not currently possible without manually adding PHP code to the theme template to define DONOTCACHEPAGE. Using the URI Exclusions Feature wouldn't work because the exclusion pattern of / would exclude everything on the site.

@raamdev
Copy link
Contributor Author

@raamdev raamdev commented Jun 5, 2014

@jaswrks
Copy link

@jaswrks jaswrks commented Jun 17, 2014

Another way you could do this is from the wp-config.php file.

if(preg_match('/^\/(index\.php\/?)?(\?|$)/', $_SERVER['REQUEST_URI']))
    define('ZENCACHE_ALLOWED', FALSE); // Don't cache home page.

This could also be done via .htaccess using mod_rewrite too.


I think it would be good for us to support a raw regex pattern in the list of URI/Referer/User-Agent exclusions where we currently support only the * wildcard character. I'm thinking of an alternate, more advanced syntax for those who need it; where a line can optionally start with regex: to indicate that it's a raw regular expression that should not be escaped like others are by default.

The default pattern matching is more of an fnmatch() style approach to keep it easy to work with for novice site owners; but adding some additional support here for regex would be great IMO. The underlying exclusion checks already use regex, so we just need to add a syntax variation I think.

@jaswrks
Copy link

@jaswrks jaswrks commented Jun 17, 2014

Actually, I just remembered that this constant could also be configured manually if you prefer. So this is also possible using the /wp-config.php file if you prefer; even in the current release.

Put the following into your /wp-config.php file...

define('ZENCACHE_EXCLUDE_URIS', '/^\/(index\.php\/?)?(\?|$)/');
@jaswrks
Copy link

@jaswrks jaswrks commented Jun 17, 2014

A more simplified variation, this doesn't cover as many edge cases.

define('ZENCACHE_EXCLUDE_URIS', '/^\/(\?|$)/');
@raamdev raamdev modified the milestone: Future Release Nov 29, 2014
@raamdev
Copy link
Contributor Author

@raamdev raamdev commented Nov 29, 2014

Noting that I had two requests for this feature today via ZenCache Pro support.

@jaswrks
Copy link

@jaswrks jaswrks commented Nov 29, 2014

Using the URI Exclusions Feature wouldn't work because the exclusion pattern of / would exclude everything on the site.

I agree. I saw a ticket about this earlier in ZenDesk and left a private comment there, not remembering that we had an open issue about it also. I think a possible solution here is to allow for the ^ and $ chars to be used in the URI exclusion patterns; i.e. making it possible to set an exclusion that will match at the beginning or end of the URI, or as an ^/exact-match/$

I really hate to enable regex in that field though, as it is likely to cause more confusion. The current implementation uses more of an fnmatch() style pattern-matching syntax, where we support wildcards *. For power users, enabling regex would be easier, but for novice site owners it will make it next to impossible for them to use this feature at all.

What's the right solution? Not sure. If we add support for ^ and $, in addition to *, will that be enough? Yet still simple enough for everyone to benefit from? Or, is the addition of ^ and $ just going to lead us down a path of everyone wanting exclusion patterns to support true regex?

One example that comes to mind, is for the home page. If we make it possible to do this, in order to exclude the home page: ^/$, that would not be compatible with a site that chooses to cache query strings too. In a case where query string vars might be present, a more sophisticated regex pattern would be necessary here: ^\/(?:[?&]|$) (but obviously much harder to work with also).

@raamdev
Copy link
Contributor Author

@raamdev raamdev commented Nov 29, 2014

I really hate to enable regex in that field though, as it is likely to cause more confusion.

I see two possible routes here:

  1. A toggle option that enables regex on that field; disabled by default but can be enabled by advanced users
  2. A second field specifically for regex patterns; this would help clarify things and we could hide the second field in a collapsable box that is hidden by default and opens with "Advanced Regular Expression Patterns" link.

I'm in favor of the latter, but I wonder how much extra work that would be in the code.

@jaswrks
Copy link

@jaswrks jaswrks commented Nov 29, 2014

A second field specifically for regex patterns; this would help clarify things and we could hide the second field in a collapsable box that is hidden by default and opens with "Advanced Regular Expression Patterns" link.

I like that idea too. Great! I see both of these as being the same amount of work, but the latter being a little easier, since it will not require any changes to the existing pattern-matching routine. The current implementation converts the simplified patterns into regex anyway, so we'd just need to add the additional option keys, the UI components, and then merge the new patterns into the array before running the conditionals; i.e. preg_match().

@raamdev
Copy link
Contributor Author

@raamdev raamdev commented Nov 29, 2014

we'd just need to add the additional option keys, the UI components, and then merge the new patterns into the array before running the conditionals;

Great! I'll keep this feature request in mind during the triage phase of a future development cycle. :)

@raamdev
Copy link
Contributor Author

@raamdev raamdev commented Dec 6, 2014

@jaswrks
Copy link

@jaswrks jaswrks commented Oct 7, 2015

Next Actions (Step 1 of 2)

Referencing: https://gist.github.com/jaswsinc/8dedeb364a010ccdd8d0 and https://github.com/websharks/team/issues/29

  • New feature branch: feature/191-step-1 in the websharks/zencache-pro repo.

  • In this directory, create a new file named: PatternUtils.php

    <?php
    namespace WebSharks\ZenCache\Pro;
    /*
    * Convert line-delimited patterns to a regex.
    *
    * @since 15xxxx Enhancing exclusion pattern support.
    *
    * @param string $patterns Line-delimited list of patterns. 
    *
    * @return string A `/(?:list|of|regex)/i` patterns.
    */
    $self->lineDelimitedPatternsToRegex = function ($patterns) use ($self) {
        $regex    = ''; // Initialize.
        $patterns = (string)$patterns;
    
        if (($patterns = preg_split('/['."\r\n".']+/', $patterns, null, PREG_SPLIT_NO_EMPTY))) {
            $regex = '/(?:'.implode(
                '|',
                array_map(
                    function ($string) {
                        return preg_replace(
                            array(
                                '/\\\\\^/',
                                '/\\\\\*\\\\\*/',
                                '/\\\\\*/',
                                '/\\\\\$/',
                            ),
                            array(
                                '^', // Beginning of line.
                                '.*?', // Zero or more chars.
                                '[^\/]*?', // Zero or more chars != /.
                                '$', // End of line.
                            ),
                            preg_quote($string, '/')
                        );
                    },
                    $patterns
                )
            ).')/i';
        }
        return $regex;
    };
  • Replace these lines of code with the following:

    $_value = "'".$self->escSq($self->lineDelimitedPatternsToRegex($_value))."'";
  • After this line add the following:

    /**
    * Before we changed the way exclusion patterns work.
    *
    * @since 15xxxx Enhancing exclusion patterns.
    */
    protected function fromLte151006()
    {
        if (version_compare($this->prev_version, '150807', '<=')) {
            if (is_array($existing_options = get_site_option(GLOBAL_NS.'_options'))) {
                if (!empty($existing_options['exclude_uris'])) {
                    $this->plugin->options['exclude_uris'] = str_replace('*', '**', $existing_options['exclude_uris']);
                }
                if (!empty($existing_options['exclude_refs'])) {
                    $this->plugin->options['exclude_refs'] = str_replace('*', '**', $existing_options['exclude_refs']);
                }
                if (!empty($existing_options['exclude_agents'])) {
                    $this->plugin->options['exclude_agents'] = str_replace('*', '**', $existing_options['exclude_agents']);
                }
                if (!empty($existing_options['htmlc_css_exclusions'])) {
                    $this->plugin->options['htmlc_css_exclusions'] = str_replace('*', '**', $existing_options['htmlc_css_exclusions']);
                }
                if (!empty($existing_options['htmlc_js_exclusions'])) {
                    $this->plugin->options['htmlc_js_exclusions'] = str_replace('*', '**', $existing_options['htmlc_js_exclusions']);
                }
                if ($this->plugin->options !== $existing_options) {
                    $this->plugin->updateOptions($this->plugin->options); // Save/update options.
                }
            }
        }
    }
  • After this line add the following:

    $this->fromLte151006();
  • Submit PR.

@jaswrks
Copy link

@jaswrks jaswrks commented Oct 7, 2015

Next Actions (Step 2 of 2)

  • New feature branch feature/191-step-2 in the websharks/zencache-pro repo.

  • In this file go through all of the relevant config. options; i.e., those that accept patterns, and update the inline documentation with details about this new syntax.

    New Syntax
    ^    = Beginning of line.
    *    = Zero or more chars that are NOT a / slash.
    **   = Zero or more chars of any kind, including a / slash.
    $    = End of the line.
    

    2015-10-06_23-20-07


    2015-10-06_23-19-17


    2015-10-06_23-20-42

  • Submit PR.

@jaswrks
Copy link

@jaswrks jaswrks commented Oct 7, 2015

@kristineds While working on this issue you can take note of what Regex is and why it is a crucial piece of the puzzle whenever you are working to enhance your skills as a developer. Regular Expressions are a language of their own, but they are vital in almost every programming language that deals with string manipulation; i.e., almost all of them.

We deal almost exclusively with PCRE (Perl-Compatible Regular Expressions). So whenever you seek information to help you write regex patterns and/or understand what you're looking at, you can put your focus on articles that discuss PHP's preg_*() (PCRE) functions and sites that discuss PCRE in general.

Once you understand PCRE and how to work with regex in PHP, you'll have no trouble adapting that knowledge whenever you work in JavaScript, Ruby, Python, etc..

Referencing: http://php.net/manual/en/ref.pcre.php The most important PCRE functions in PHP are:

@raamdev
Copy link
Contributor Author

@raamdev raamdev commented Oct 18, 2015

@kristineds Ping. ↑ Just wondering when you'll be able to get around to submitting a PR for step 2 above so that I can close this issue before the next release RC deadline of October 22nd.

@kristineds
Copy link

@kristineds kristineds commented Oct 19, 2015

@raamdev I just submitted the PR for step 2. Please refer to the latest commit for the updated version. Would love to hear your feedback on this and how to proceed. Thanks! cc @jaswsinc

@raamdev
Copy link
Contributor Author

@raamdev raamdev commented Oct 24, 2015

Next Pro Release Changelog:

  • New Feature! A new watered-down Regular Expression syntax is now supported in several existing ZenCache features, including the new list of Custom URLs to Auto-Clear, URI Exclusion Patterns, HTTP Referrer Exclusion Patterns, User-Agent Exclusion Patterns, and the HTML Compressor CSS Exclusion Patterns and JavaScript Exclusion Patterns. This new syntax greatly increases the power and flexibility of each of these features and makes things possible like the much-requested ability to Auto-Clear the Home Page or Posts Page of a site whenever a post cache is cleared. For more information on this new watered-down Regular Expression syntax, this KB Article. Props @kristineds @jaswsinc. See Issue #191.
@raamdev raamdev closed this Oct 24, 2015
@raamdev
Copy link
Contributor Author

@raamdev raamdev commented Nov 14, 2015

ZenCache v151114 has been released and includes changes from this GitHub Issue. See the v151114 announcement for further details.


This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#191).

@wpsharks wpsharks locked and limited conversation to collaborators Nov 14, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants