WordPress.org

Support

Support » Plugins and Hacks » Nginx Helper » [Resolved] Feature Suggestion for Additional Purge Options

[Resolved] Feature Suggestion for Additional Purge Options

  • It would be great if the plugin could incorporate these options in a future release:

    Nginx Settings

    • Plugin Options
    • Purging Options
      • Purge Homepage:
      • Purge Post/Page/Custom Post Type:
      • Purge Archives:
      • Purge Everything:
        • when a new theme is activated.
        • when the current theme is modified (e.g., customize header image, background, colors, etc.).
        • when a menu is modified or added.
        • when a widget is modified or added.

    An alternative might be to simply add a manual Purge Cache button to the settings page.

    Also, I want to say thank you for creating this plugin and making it publically available. 🙂

    http://wordpress.org/extend/plugins/nginx-helper/

Viewing 15 replies - 1 through 15 (of 25 total)
  • Plugin Contributor Saurabh Shukla

    @saurabhshukla

    Hi Darren,

    The ‘purge everything’ functionality is the pot of gold we also want to reach. (all our sites, clients’ sites run on nginx and we built nginx-helper primarily as our own dog food) Unfortunately, there’s nothing (yet) in nginx that can purge the whole cache at one go. So, the only way this would be done is, loop through all the urls whether they are cached or not and purge them.

    A possible optimisation is storing a list of urls that have been cached into the database. However, the sheer inelegance of these solutions have kept us back from adding a ‘purge all’ option or functionality. We’ve been looking for a more elegant solution, probably, from the nginx community. Or probably a brainwave that’ll give us a nicer way to do it.

    If you can think of a good approach, please help us out with it. We’ll be always obliged. Thanks for the encouragement, though.

    Regards.

    Correct me if I’m wrong, but it looks to me like the plugin is already using that approach (looping through all the URLs whether they are cached or not), it just limits itself to certain classes of URLs (e.g., home, archives, posts, pages, etc.), depending on the WP action that initiated the purge.

    For the Purge Everything button, I was envisioning a simple function that calls each of the purge functions (or methods, rather) in succession. In fact, when I was looking at purger.php, I noticed there’s a method that seems to do exactly what I was hoping for:

    private function _purge_them_all() {
        $this->log( __( "LET'S PURGE ALL THE BLOG.", "rt_wp_nginx_helper" ) );
        $this->_purge_homepage();
        $this->_purge_personal_urls();
        $this->_purge_all_posts();
        $this->_purge_all_taxonomies();
        $this->_purge_all_date_archives();
        return true;
    }

    But I couldn’t find _purge_them_all mentioned anywhere else in the code. So…I guess my question is: besides the inelegance aspect, is there another reason why this wasn’t made available to users? For example, does it cause significant performance issues at a certain point?

    I’ve only recently started using the fastcgi_cache directives, but as far as I know, there’s no way to define separate cache paths for each server block. Right now, I can easily empty the cache because I only have one domain using it, so I just delete everything in the folder (via command line). But as I start to configure more domains to use the cache, it won’t be that simple (unless I just delete the cache for all domains every time one of them changes). The way I see it, using something like _purge_them_all might be the only solution available to me.

    Regarding ideas for a better approach, nothing really comes to mind. The only alternative I can think of would be to loop through the cache directories/files themselves, read the content, parse out the KEY: httpGETwww.example.com/example-uri strings, and build a list of cached URLs, which you could then send to /purge.

    One problem with reading the cache directly is that the files are owned by the server, so I’m not even sure if PHP can read them on the average nginx setup, without users changing the permissions first. Even if they could, I don’t see how this would be any better/faster than blindly sending all WP URLs to /purge.

    Yeah, nevermind that idea. I just talked myself out of it. LOL.

    Anyway, please let me know what’s up with _purge_them_all, because I’m really tempted to hook it into something.

    Thanks.

    Plugin Contributor Saurabh Shukla

    @saurabhshukla

    I agree. what we are doing currently is also inelegant, as it stands, but the number of urls to purge when each such class is purged is incomparable to the number that get purged if all of them are called at the same time.

    Because there is no other way, the _purge_them_all function was written. We tested it too and then decided against it. We eat our own dog food, and this part of it was very tasteless!

    In any case, if you can try your hand at it, why not fork the project on [github](https://github.com/rtCamp/nginx-helper/tree/1.6.5), make the changes you’d like to and send a pull request. Kindly use this tag instead of the master. It already has a merged request that needs work upon. Do let me know if you need any help with that,

    In fact, currently, we are rather busy with our [BuddyPress Media plugin](http://wordpress.org/extend/plugins/buddypress-media/) and hence the next release of this plugin could be a little late, unless you are willing to contribute to it :). We are only doing bug fixes for a while.

    In case you buy into my request, just add the option to disable the ‘purge everything’ functionality.

    Regards.

    Okay, I’ll take a stab at it. I’ll probably just go with the manual button approach, to reduce the likelihood of users automatically triggering it without understanding the impact.

    I do have one question though…

    In your recommended site configuration, you disable the caching of /feed/ URLs:

    # Don't cache uris containing the following segments
    if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
        set $no_cache 1;
    }

    But then I noticed in my nginx-helper/nginx.log file that the /feed/ variation of all URLs is also sent to /purge/. Seems to me if no one is caching /feed/ files to begin with, then I’d be able to remove them from the purge process, and thus reduce the number of uncached URLs sent to /purge/ by as much as 50%.

    So the question is: should I disable the purging of /feed/ URLs or leave it alone?

    Plugin Contributor Saurabh Shukla

    @saurabhshukla

    Hi,

    Now, that’s an oversight. Feel free to make any such modifications. In fact, while doing that, if you find more, do what you feel is fine. If you could send in a pull request at each such change, we can discuss it over at github before merging, if there is any doubt.

    Only, leave the plugin headers and readme.txt as it is. We like writing changelogs and such metacode!

    Regards.

    Okay, I just sent a pull request for the “Purge Everything” functionality. I didn’t make any changes to the /feed/ links (yet). The only other minor change I made was to add a space between the top checkboxes and their labels (on the settings page). The nonconformity was killing me. 😉

    Plugin Contributor Saurabh Shukla

    @saurabhshukla

    Hi,

    I made a mistake by accepting a pull request on the master branch the last time and hence the repo went bad. That’s why I had asked you to use the 1.6.5 tag to fork and send pull requests to. Your pull request, hence, contains code from the other pull request that we can’t use right now.

    Now, I’ve turned things around a little and got the latest code onto the master. I can manually add your code (it isn’t much, thankfully) but then your contribution will become invisible on github, which is not good.

    So, with apologies, I have to ask you to re-fork and resend the pull request, please!

    Thanks.

    That’s weird. I went to the URL you provided for tag 1.6.5 and forked it. If it didn’t work, then…I guess I don’t know how to fork a repo according to a specific tag.

    But if I understand you correctly, you made adjustments so that I don’t need to use the tag. In other words, I’ll just repeat the same process I used last time…but this time it should work.

    Plugin Contributor Saurabh Shukla

    @saurabhshukla

    Yes, just repeat that and it’ll work.

    Regards

    Plugin Contributor Saurabh Shukla

    @saurabhshukla

    Hi,’

    I have added the code with some cosmetic modifications and released a new version. However, the contributors’ list doesn’t link to your profile.

    Could you give me your wordpress.org username that you use for logging in. It doesn’t seem to be darren-slatten. Would it be Darren-Slatten? Because wordpress is case sensitive, as well!

    Thanks for the contribution.

    Regards.

    The username I enter to log in is Darren Slatten, but in the wordpress.org URL it appears as /darren-slatten/. I’m assuming you figured it out though, because I updated to the latest version and the changelog link to my profile is working. Thanks for the recognition.

    Plugin Contributor Saurabh Shukla

    @saurabhshukla

    The changelog was fine, but i couldn’t link your profile to the contributor’s list. Done, now.

    Congratulations on your first plugin 😉

    Plugin Contributor pjv

    @pjv

    probably this is lack of php script knowledge, but is there no way to execute something like rm -r * at the os level in the cache directory?

    i don’t know php at all, but in a python script you would be able to do something like that pretty easily.

    Plugin Contributor Daan Kortenbach

    @daankortenbach

    Being able to do rm -r * from a button on a website is probably not a very smart move, but we could get in contact with the nginx developers and to discuss our needs.

    Plugin Contributor pjv

    @pjv

    yeah, i understand the issue, but if there were some way to confirm that the command was only running on the cache directory… guess that could be difficult to do.

    maybe force the user to enter the full path to the cache and also get the path to the nginx config from the user and then parse it to confirm that it has the same path entered for fastcgi_cache_path and then don’t show the button unless the user checks a box that says they understand the danger and know what they are doing.

    probably still pretty dangerous and not worth people yelling at you.

Viewing 15 replies - 1 through 15 (of 25 total)
  • The topic ‘[Resolved] Feature Suggestion for Additional Purge Options’ is closed to new replies.
Skip to toolbar