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

Clear target server cache option #19

Open
hughbris opened this issue May 31, 2022 · 3 comments
Open

Clear target server cache option #19

hughbris opened this issue May 31, 2022 · 3 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@hughbris
Copy link
Owner

I had a crazy idea when I should have been sleeping that it would be handy to be able to perform a clear cache operation on the target publishing server when pushing, e.g. large image updates.

That came out of a fear that when a client of mine makes a large set of edits to be pushed at once, users of the site might see some screwy pages until the cache refreshes. I have witnessed this myself updating media via git on command line. I normally have high levels of caching set for production servers.

You could do this by triggering another webhook on the editing instance. It could be a global checkbox on the file selection list UI.

This idea is not very incompatible with another half-baked plan of mine to split this plugin into "pushy-publisher" and "pushy-target".

@hughbris hughbris added the enhancement New feature or request label May 31, 2022
@pamtbaau
Copy link
Collaborator

pamtbaau commented Jun 1, 2022

Do you think the person who is supposed to publish the changes is apt to decide whether a clear cache is needed?

  • Does the user know the size of the push?
  • Does the user know when the issue might occur?
  • Does the user know the performance hiccup of clear cache on a large site?

@hughbris
Copy link
Owner Author

hughbris commented Jun 2, 2022

Do you think the person who is supposed to publish the changes is apt to decide whether a clear cache is needed?
* Does the user know the size of the push?
* Does the user know when the issue might occur?
* Does the user know the performance hiccup of clear cache on a large site?

You're right, those are serious concerns. This came about because I am expecting a client to push some big changes including media onto the production server. Probably not gonna happen often, I might try to coordinate a cache refresh from me.

@hughbris hughbris added the question Further information is requested label Jun 2, 2022
@pamtbaau
Copy link
Collaborator

pamtbaau commented Jun 2, 2022

Some thoughts:

  • When a copy/paste of a /user folder (maybe excluding plugins/themes) on the same server is faster then a remote fetch (the git changes), it might be an idea to apply the git changes onto a staging folder (no need to be a website) and copy/paste that folder into the production Grav folder.
  • Or only apply scheduled pulls on remote server during hours that user traffic is low.
  • Or maybe even both above options

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants