iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
The error means Apache found a legacy Order directive in your WordPress .htaccess file, but the document root does not allow that directive class. In the Apache <Directory> block that covers the site, add the Limit override class—for example, AllowOverride FileInfo Limit—then run apachectl configtest (or apachectl -t) before reloading Apache. On Apache 2.4, converting the rule to Require syntax is the preferred long-term fix.
What “Order not allowed here” means
Apache controls which settings a per-directory .htaccess file may change. The server administrator declares those permissions with AllowOverride in an applicable <Directory> section. If the file contains a directive outside the permitted override classes, Apache rejects it and may return a configuration error or a WordPress 500 response.
Recommended Free Tools
Order, along with its companion directives Allow and Deny, belongs to Apache’s legacy Limit override class. Therefore, AllowOverride FileInfo by itself permits rewrite and file-information directives but does not permit Order. The error is a server-policy mismatch, not proof that the Akismet files are corrupted.
The exact Akismet template can vary by plugin and version, and the available material does not identify a particular Apache release for the affected site. The Apache rule is still decisive: if the generated or edited .htaccess includes Order, the containing directory must allow Limit, or the rule must be rewritten using the modern authorization system.
#1 Best Overall
Repair the existing rule safely
Use this path when you need the current legacy rule to work and you can edit the virtual-host or main Apache configuration.
1. Back up both configurations
Copy the site’s .htaccess file and the Apache virtual-host configuration before changing anything. Keep the copies outside the web root and record which file serves the affected hostname. A backup lets you restore the previous state if a syntax test or reload exposes an unrelated problem.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →2. Identify the correct <Directory> block
Find the Apache <Directory> section whose path contains the WordPress document root—for example, /var/www/example.com/public_html. The setting must be made in a <Directory> context. AllowOverride is not valid in <Location> or <Files> sections, so changing a similarly named block there will not authorize the .htaccess directive.
Check the complete virtual-host configuration rather than editing the first directory block you find. A more specific block can override a broader one, and the site may use a different filesystem path than the hostname suggests.
3. Add the narrow override class required by Order
If the file intentionally uses legacy access control, change the applicable block to include Limit:
<Directory "/var/www/example.com/public_html">
AllowOverride FileInfo Limit
</Directory>Keep any other classes the site genuinely needs. For example, if the existing configuration already says AllowOverride FileInfo, append Limit rather than replacing FileInfo. This narrowly enables the class that contains Order, Allow, and Deny.
Do not use AllowOverride All merely to suppress this one message, and do not enable broad overrides in the filesystem root. A site-specific class list limits what an uploaded or modified .htaccess can change.
4. Test the Apache configuration before a reload
Run the syntax check using the Apache service account’s normal command:
apachectl configtest
# or
apachectl -tApache documents these commands as configuration checks that do not start the server: Apache HTTP Server configuration documentation. Continue only when the command reports that the syntax is valid. If it names a different file or line, fix that reported problem first; a successful edit to AllowOverride does not make unrelated syntax errors disappear.
5. Reload Apache and make a real request
Use the service procedure provided by the operating system or hosting platform to reload Apache. A reload applies the new configuration without unnecessarily terminating existing workers; use a full restart only when the platform requires it. Then request the affected WordPress URL, open the operation that previously triggered the error, and inspect the Apache error log at the same time. The original “order not allowed here” entry should no longer appear.
If the page still returns 500, capture the newest log line and the exact URL. Do not repeatedly reload an untested configuration: return to the backup, run the syntax check again, and isolate the next error before trying another change.
Why FileInfo alone fails
Apache groups directives into override classes. FileInfo covers a different set of per-directory settings, while the old access-control directives are classified under Limit. Thus this block is insufficient for a file containing Order:
<Directory "/var/www/example.com/public_html">
AllowOverride FileInfo
</Directory>Adding Limit addresses the authorization error at the point where Apache enforces it:
<Directory "/var/www/example.com/public_html">
AllowOverride FileInfo Limit
</Directory>The value is not added inside .htaccess. AllowOverride is an administrator-level setting; placing it in the file that needs permission cannot grant that permission.
Free tools Windows power users keep installed
One-click scans. No signup required.
Apache 2.4: replace legacy access rules when practical
Order, Allow, and Deny are supplied by mod_access_compat and are deprecated in Apache 2.4. Apache’s preferred authorization system uses Require. If you control the rule and can verify its intended behavior, migrate the access logic instead of extending the lifetime of the compatibility syntax.
Allow every client
A legacy rule that permits all clients is commonly expressed as:
Order allow,deny
Allow from allIts Apache 2.4 authorization equivalent is:
Require all grantedUse this only when the old rule really was an unconditional allow. A conversion is not a license to remove an existing restriction.
Restrict by IP address
Rules that formerly used an address-based Allow from or Deny from condition can generally be represented with Require ip, followed by the approved address or network. Preserve the original network boundaries exactly and test from both an allowed and a denied address.
Require ip 192.0.2.0/24Restrict by host name
Host-based conditions can use Require host when reverse-DNS behavior is appropriate for the site’s security model.
Require host example.orgNames and addresses in these examples are illustrative syntax, not a recommendation to authorize those specific networks or domains.
Do not mix authorization systems casually
Apache provides the compatibility module so older configurations can continue to run, but it discourages mixing Order/Allow/Deny with Require in the same access-control logic. Their merging behavior can produce a result that is different from reading either rule set in isolation. Migrate one coherent rule set, validate it, and test the intended allow and deny cases.
Choose the fix that matches your environment
| Situation | Appropriate action | Security and maintenance trade-off |
|---|---|---|
Apache configuration is under your control and the existing file intentionally uses Order |
Add Limit to the specific WordPress document-root block, such as AllowOverride FileInfo Limit. |
Smallest change that preserves the current rule; the legacy directives remain deprecated. |
| Apache 2.4 and the access rule can be understood and rewritten safely | Replace the old access logic with the corresponding Require directives. |
Uses the supported authorization model, but an incorrect conversion can change who is allowed. |
Shared or managed hosting with no access to the <Directory> block |
Ask the provider to enable Limit for the document root or convert the rule to Require. |
Provider approval is required; you cannot safely grant the class from .htaccess itself. |
| Only a temporary diagnostic is needed | Back up the file, identify the legacy lines, and coordinate a provider-side change rather than enabling global overrides. | Avoids an unnecessarily broad AllowOverride All setting. |
The correct choice depends on four facts: the Apache version, whether you can edit the relevant <Directory> block, whether the file uses legacy or modern authorization syntax, and how narrowly the change can be scoped.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
If you cannot change Apache configuration
Many shared and managed plans do not expose virtual-host files or the main Apache configuration. In that case, do not attempt to place AllowOverride in the WordPress .htaccess; Apache will reject it because the directive is not valid there.
Send the host the document-root path, the exact error-log line, and the relevant legacy rule. Ask for one of two specific actions:
- Permit the
Limitoverride class for that document root while retaining the existing restrictions. - Rewrite the rule with Apache 2.4
Requiresyntax and remove the obsolete compatibility directives.
Request that the provider run its configuration test before reloading. If the host cannot make either change, ask whether it has a supported way to disable the plugin-generated rule or to manage the access policy at the virtual-host level. Avoid replacing a controlled server policy with a broad override setting simply to make one request succeed.
Troubleshooting after the change
The same “order not allowed here” message remains
- Confirm that the edited
<Directory>path is the actual filesystem path for the WordPress document root. - Check for a second, more-specific
<Directory>block that still has onlyFileInfoor hasAllowOverride None. - Verify that Apache reloaded the configuration file you changed; a syntax test against one installation does not change a different running instance.
- Search all applicable configuration files and
.htaccessfiles for anotherOrderdirective. The reported line may come from a nested directory rather than the site root.
The syntax test fails after adding Limit
Read the first reported error, including its file and line number. Check that the directive is spelled AllowOverride, that it is inside <Directory> and </Directory>, and that the path is quoted and closed correctly. Restore the backup if the failure is unrelated, then reapply one edit at a time so the next test identifies a single cause.
The site returns 500 after the reload
Inspect the Apache error log for the timestamp of the request. A 500 generated by a malformed or unauthorized directive will normally identify the file and line. Correct that line, run apachectl configtest or apachectl -t, and reload only after the test passes. If the log instead reports an application-level failure, keep the server change separate and investigate the application error rather than repeatedly changing AllowOverride.
The old error is gone but access behavior changed
This usually indicates that the rule was converted with different semantics, or that a broader directory block is now applying. Compare the old and new conditions, then test each intended case from an allowed and a denied client. On Apache 2.4, do not combine the old and new authorization directives as a shortcut; make one complete, understandable policy.
Quick Recap
Prevent the problem from returning
- Keep a dated copy of the working
.htaccessand the corresponding virtual-host block. - After plugin updates or site migrations, inspect the generated file for legacy
Order,Allow, orDenylines before the next reload. - Record the exact document-root path and the Apache service command used by the host so a future incident can be reproduced quickly.
- Run the Apache syntax check as part of every configuration change, before making a production request.
- Prefer a narrowly scoped override list or a deliberate
Requiremigration over globalAllowOverride All.
Quick checklist
- Back up
.htaccessand the Apache virtual-host configuration. - Locate the
<Directory>block covering the WordPress document root. - If retaining the legacy rule, set
AllowOverride FileInfo Limit(plus only other classes the site actually needs). - Run
apachectl configtestorapachectl -t. - Reload Apache through the host’s normal procedure.
- Request the affected WordPress URL and inspect the error log.
- For Apache 2.4, plan a tested migration from
Order/Allow/DenytoRequire. - If you lack server access, give the host the exact path and error and request a scoped
Limitpermission or a safeRequireconversion.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
