add option to copy .htaccess or other files verbatim

[leonstafford]

Use case:

User is transferring to a web server supporting htaccess and needs to keep the htaccess there for 301 redirects or such (this may pave the way for including our own .htaccess/entries for the wp-content to contents, etc rewriting

Other uses may include favicons (should be a default kind of thing, though).

[themorgan]

Other use cases include:

• Users change a headline of a WP post, and update the URL correspondingly, but want to keep the original URL functional with a redirect. (Note: this is probably the most common use case.)

• User removes a page, but doesn't want it the former page going to an error page but instead to redirect it to another page such as the front page of the site

• Certain pages are password protected via the .htaccess (note: the .htpasswd file also needs to be moved in those cases)

• .htaccess removes the "www." from URLs to have all URLs redirect to the non-www form. Or vice-versa.

• .htaccess redirects all users from the 'http://' URL to the 'https://' URL.

• .htaccess to ban any access to a directory, like a directory of just the the backup plugin-created .zip backup files

• .htaccess to ban users from downloading certain file-types, like to prevent any access to .zip or .tar.gz or .docx files

Other Notes / Suggestions:

• The fantastic plugin "Redirection" ( https://wordpress.org/plugins/redirection/ ) has over 1+ million installs, and it includes lots of great functionality, and it modifies the .htaccess with the rules that the plugin either automatically creates [when a post name changes etc] or you create manually via the plugin. So this is basically ensuring compatibility with this plugin.

• The .htaccess and .htpasswd files aren't only in the root directory, it's common to put them in sub-directories also, so ensure that this copies the files in all/any directories

• The main complexity seems to be that the .htaccess file will contain a bunch of code that's no longer needed -- most notably, code from a caching plugin, for example. One possible solution is to search for and remove the code from all the major caching plugins. (Don't forget my beloved WP-Rocket, hehe.)

• Special feature request: to me, it makes the most sense to use the .htaccess file to make my privateinvisibleWP.domain.com site [the subdomain for the WP install that creates the text files to be moved over] to make the entire site private via the htaccess file. It would be amazing to have the ability to modify the htaccess to do that but not carry over that one line to the live version.

• I so use the .htaccess file soooo much that.... I once created a plugin to help manage it by doing some particular functionality easily via the WP interface: https://wordpress.org/plugins/htaccess-site-access-control/ [I also made a paid version once that like 6 people bought, but that I never marketed it but it never caught on organically] so I'm happy to give you free access to the paid version if you want to use/test it btw! My gift to you ;)

• I personally use all the above use cases extensively so I'm happy to test it as needed, or to provide to you sample .htaccess files from one of my sites to test or to let you know which plugins I use that modify the .htaccess files, etc.

[themorgan]

I realized in the shower this morning that: while I suggested removing the .htaccess code for the caching plugins -- on reflection, it may be more complex than that. Lots of caching plugins add .htaccess lines that do something valuable, like the gzipping, and more broadly, with the flat files, some parts of the caching are made irrelevant but some parts aren't. This requires more thought. Possible solutions include: [a] options to turn it on/off that the user has, [b] maybe support a very limited number of caching plugins [including wp-rocket of course haha] and have a deeper integration with them, [c] give users an interface to adjust the .htaccess rules via your plugin on the static site.

Yeah I know I'm obsessed with your plugin ;)

[leonstafford]

Thanks @themorgan for further fleshing this out.

Perhaps the easiest way for the first cut of this, is to present the user with a copy of the original WP site's .htaccess, with some rules added for 301's of the wp-content to contents, etc as the plugin has set or they have overridden.

Any more advanced usage beyond that and the user is probably proficient enough to setup some more scripts. I should have SSH/SCP deploys working soon, where the user will have the ability to add some pre/post commands to the deploy, such as to unzip an archive on the remote or such.

[themorgan]

Love it! Agreed that anyone who is editing it at the level I articulate above will know what they're doing, or at least think they know what they're doing. And this is much simpler than the complex solution I was imagining above. Some further thoughts on that:

1 - the .htpasswd should always go hand-in-hand with that 2 - not just for the root directory (I often edit the .ht-files in /wp-admin for example)

Thank you!

[leonstafford]

@themorgan - I'll migrate this over to an Idea topic on forum.wp2static.com soon and close the issue.

Hopefully, you've had a chance to play around with the new WP-CLI integration, else will with the release. This should give the behaviour of what I was mentioning re the SCP/SSH deploys, which I don't think I will do via the UI anymore, or at least not for sometime, as the WP-CLI runner now affords the flexibility DIY those workflows.

[leonstafford]

closing this, now that we have Additional URLs and hook support to modify the crawl list https://github.com/leonstafford/wp2static#modify-the-initial-list-of-urls-to-crawl