The content of this article or any related information is under the Creative Commons license BY, you can republish this content freely but you must mention the author of this article and indicate the URL of this page: https://www.exabyteinformatica.com/tienda/foro/stop-wordpress-from-modifying-htaccess-t1360.html
By default, depending on file permissions, WordPress automatically will modify the contents of your website’s .htaccess file. It does this on several activities, adding and/or updating the rewrite guidelines required for WP’s permalink functionality. This publish explains how this works, why it can also be dangerous, and how to stop it from occurring.
What WordPress does?
When permalinks are enabled for your web site (beneath typical > Permalinks), WordPress instantly will adjust your .htaccess file with the newest rewrite guidelines. So in case your .htaccess file has proprietor write access (very regular), WordPress will write to the file with a block of directives corresponding to here:
# begin WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.personal home page$ - [L] RewriteCond %REQUEST_FILENAME !-f RewriteCond %REQUEST_FILENAME !-d RewriteRule . /index.Hypertext Preprocessor [L] </IfModule> # conclusion WordPress
As far as I do know, this best applies to non-Multisite WP installations (i.e., WP doesn’t automatically add the rules required to permit WP Multisite, although I can be incorrect about this). After all, for commonplace WP installations, WordPress will add these suggestions every time permalinks are invoked. Here are some particulars:
• # begin WordPress and # conclusion WordPress function markers used through WordPress
• If the markers don't exist, the permalink guidelines will at delivered on the conclusion of the .htaccess file
• If the markers do exist, some thing code found between the markers might be updated automatically
• so you can stream your permalink guidelines (to someplace other than at the conclusion of the file) by means of moving the entire block of code (markers included)
• when you've got customized your permalink suggestions between the markers, the adjustments might be overridden via WordPress
• There isn't any solution to get rid of the empty line before the closing marker
So the large ethical of the story here is that you just need to add any custom .htaccess rules outside of the start and end markers. In any other case WordPress will overwrite them with the default permalink rules.
Why is it dangerous?
So given the outdated aspects, you probably have:
• custom permalink suggestions internal of the begin and conclusion markers, they will be lost
• custom permalink rules backyard of the markers (e.g., no longer the usage of any markers), then WP will add a different set of rewrite suggestions on the conclusion of the .htaccess file.
Either of these situations may also be unhealthy, above all if the customized rules are required for site performance, navigation, and so on.
As an instance, at my WordPress bookstore, i exploit customized permalink suggestions to account for variations in save gadgets, customized/brief URLs, and extra. So in my .htaccess file, the permalink suggestions are enormously personalized, and correct store functionality depends upon a very carefully crafted set of directives.
So because the block of customized rules is not wrapped with begin/end markers, WordPress was taking liberty and adding its personal default set of permalink suggestions on the conclusion of my .htaccess file. These default guidelines were redundant and could have interfered with general performance, chiefly if my custom rules had no longer been written properly (e.g., if I had omitted the L flag).
And it will have been disastrous if I had made the mistake of wrapping my custom suggestions with the begin/conclusion markers. Then WordPress would have overwritten every little thing and things basically would were broken (badly). Incidentally, the best cause I didn’t use the WP markers is because, as an .htaccess aficionado, I suppose they appear horrible, particularly with that dull clean line. Satirically it’s this superficial aesthetic option that prevented comprehensive web page breakage, however I digress.
Do you think the hundreds of thousands of different WordPress users are as cautious with the contents of their personal .htaccess info? I shudder to suppose on the frustration and wasted time brought about by this default WP functionality. Here are a few decent the explanation why instantly editing the .htaccess file isn't a good suggestion:
• Apache/.htaccess syntax is hypersensitive
• A single error in syntax/idiom can crash the server
• It’s no longer protected to anticipate any pre-current .htaccess directives
• existing .htaccess directives may additionally battle with immediately delivered rules
• Any additions to .htaccess may still be demonstrated fully earlier than going are living, principally when other suggestions could be in play earlier than looking at the way to cease WordPress from changing the .htaccess file, it's important to keep in mind that taking any steps to stay away from the default behavior may cause something to not work as meant.
Actually it’s no longer a large deal, however, as .htaccess data by using default don't seem to be writable on many servers; so lots of WordPress clients already operate in this skill devoid of problem.
Make it stop
So now that we’re all on the identical page with WP’s auto change of the .htaccess file, let’s look at how to prevent it from happening (or no longer).
System 1: Lock it down
The cleanest method, for my part, is to make the .htaccess file “read-simplest”. Through changing the file permissions to read-most effective, WordPress will not be capable of adjust it. As defined in this help thread:
“WordPress chiefly exams if each the home path and the .htaccess file in the home route are writable, using the Hypertext Preprocessor is_writable feature. If it’s not writable (aka, study-best), WordPress doesn't try to write to it. In case you’re on a Linux based hosting gadget, make the .htaccess file have 444 or 440 or four hundred permissions. Use the smallest one which still works.”
As an instance, on my server, a chmod price of 444 worked like magic. But for your server reckoning on configuration, you could need to dial it down even additional, the usage of 440 and even 400. Always most effective to verify totally, and/or ask your host if any doubt.
So the permissions alternate is a solid answer, however keep in mind that it will evade anything — WordPress, plugins, subject matters, etc. — from making changes to the .htaccess file. As a result you yourself won’t be in a position to make adjustments to the file by way of SSH/SFTP/and so on. So for example, in case you are looking to instantly block a brute-force assault, you’ll should set the permissions of your .htaccess file back to 644 (or something) with a purpose to make any changes.
Counting on how commonly you need to alter your .htaccess file, this may get tedious. So if locking down file permissions doesn’t appear to be an amazing answer, you may additionally are looking to agree with method #2.
Method 2: Add a filter
in case you wish to cease WordPress from automatically updating your permalink suggestions, however also want to make sure that the file is writable for other purposes, then you can add the following filter by the use of plugin (or theme capabilities, and so on.):
// stop WordPress from editing .htaccess permalink suggestions add_filter('flush_rewrite_rules_hard','__return_false');
This can avoid WordPress from editing the permalink suggestions for your .htaccess file (or web.config file, if using home windows server). The only drawback to this strategy is that you simply’ll need to consider of any alterations that WordPress makes to its default permalink suggestions, and update your .htaccess file hence. Happily here is rare; in my 10+ years working with WordPress, the permalink suggestions were modified only once.
Method three: customize outside of the markers
As outlined in the past, in case you don’t mind WordPress and plugins writing to your .htaccess file, you could with no trouble add and customized .htaccess guidelines outdoor of the start/end markers. That manner WordPress can maintain the permalink suggestions up thus far, and different plugins can proceed to do anything they need to your .htaccess file. Of route, imposing custom rewrite/permalink rules without definitely enhancing WP’s default rules is less difficult referred to than achieved
Formula four: Do nothing
Ultimate however not least, that you could all the time just let WordPress update your .htaccess file because it pleases. A couple of elements about this method:
• best suggested if you do not need any customized permalink guidelines
• whereas it is going to be great to let WordPress core make changes, it’s your call as to whether or not plugins et al may still enjoy the same write privileges.
So if you’re pondering, “what a nutjob, telling me to not permit WordPress to do whatever thing it wishes”, calm down. I’m saying that there are situations the place WP’s auto-writing may also be dangerous. But if you’re all the time using the default permalink rules, you they’re likely protected permitting WordPress to make alterations immediately. WordPress is a smartly-validated and usually reliable piece of utility
Within the system of setting .htaccess permissions for a few my own websites, I managed to take a few notes for future reference. Which you can ignore this section in case you don't make any permissions changes. In any other case, you may additionally find it helpful.
Default .htaccess permissions = 644 (rw- r-- r--) read-only .htaccess permissions = 444 (r-- r-- r--)
Online tool: CHMOD Calculator
Be aware: When WordPress doesn't have write access to the .htaccess file, making a transformation to the Permalink settings consequences in an admin note that says, “remember to replace your .htaccess now”. Additionally a set of .htaccess guidelines should be displayed near the backside of the web page. Otherwise, if WordPress does have write access to the file, these gadgets usually are not displayed.
No te pierdas el tema anterior: Redirigir una página web a otra con .htaccess