I develop my Grav site locally and use github and push to sync local changes to the live site. Recently, I added Let’s Encrypt to my live site, with changes to .htaccess. Those changes mean I cannot work locally without reverting the need for SSL. That’s OK, but it is tiresome to have to remember to rename .htaccess each time I want to do something locally and then back again afterwards.
I tried to ignore .htaccess in gitignore, but that then deletes it on the live site.
Is there any way to have one .htaccess on the dev site and a different one on the live site and make sure that syncing does not change either of them?
To be honest, I really think the best way is to sync only the user/ folder. This does mean you have to keep your Grav installation up date date remote and local independently, but does allow you to have different .htaccess and means much less files actually stored in GitHub and synced, so faster.
Alternatively, for simplicity, yes, you would need to just add .htaccess to .gitignore. Then you just create it manually on the remote and local site (if it’s removed by git).
Thanks for that. Syncing only /user might be simplest in the end, because any time I do anything locally, I will see whether there are any updates and so on there, so I can go to the live site and update if necessary.
I’ve gone as far as I can with syncing only /userand have run into a problem. Putting the webhook.php folder into /user seems to run afoul of this bit of .htaccess:
# Block access to specific file types for these user folders
RewriteRule ^(user)/(.*)\.(txt|md|yaml|php|pl|py|cgi|twig|sh|bat)$ error [F]
At least, I think that’s the problem. Github shows an error on trying to deliver the payload.
I have not yet tried moving the webhook to /grav-blog in case there is some better way of doing things.
I actually encountered this situation yesterday. Independently arrived at the same solution as you: place the automatic webhook script into the root folder. Now items updated or added in user are automatically uploaded to production server after a GitHub Sync. Thanks for validating my conclusion.