mark8887
Forum Replies Created
-
Forum: Fixing WordPress
In reply to: I don’t understand the behaviour on Apache server redirectionThat worked, thanks so much. I have also gone back into my http.conf file and tightened up the access to <Directory /> <Directory /var/www> and <Directory /var/www/html> by removing AllowOverride All in those sections and your answer continues to have the configuration working by just the setting in the VirtualHost section.
All the above had the AllowOverride All directive but must not have inherited down to the VirtualHost section.
Also I have done two test’s but so far it looks like in my VirtualHost section if I configure two ways
1.<Directory> AllowOverride All </Directory>
2.
<Directory "/var/www/html/site-name"> AllowOverride All </Directory>
The second configuration is proving 0.5 seconds faster.
The exact configuration in my Virtual host section is as follows with the <Directory …> configuration sitting above my redirect rules.
<VirtualHost *:80> ServerAdmin [email protected] DocumentRoot /var/www/html/site-name.com ServerName site-name.com ServerAlias www.site-name.com <Directory "/var/www/html/site-name.com"> AllowOverride All </Directory> RewriteEngine On <IF "req('Host') != 'www.site-name.com'"> RewriteCond %{HTTP:X-Forwarded-Proto} =http RewriteRule .* https://www.%{HTTP:Host}%{REQUEST_URI} [L,R=301] </IF> <ELSE> RewriteCond %{HTTP:X-Forwarded-Proto} =http RewriteRule .* https://www.%{HTTP:Host}%{REQUEST_URI} [L,R=301] </ELSE> ErrorLog logs/site-name.com-error_log CustomLog logs/site-name.com-access_log common </VirtualHost>
Thanks again for your help, very much appreciated.
- This reply was modified 6 years, 5 months ago by mark8887. Reason: removed bold tags nested in code tags as they did not work as intended
Forum: Fixing WordPress
In reply to: WordPress permalink issuesThe problem is now solved.
I must re-iterate again how much of a lifesaver your comment was in terms of getting me on a different line of thought.
I started reviewing my mod_rewrite setup. I realized that I had tested from within the httpd.conf file but not tested redirection at the .htaccess level following some tips from the following article,
It ended up that the .htaccess file was being bypassed.
The ultimate culprit were the explicit re-directs to https in the httpd.conf file
RewriteEngine On <IF "req('Host') != 'www.beta-test-three.com.au'"> RewriteCond %{HTTP:X-Forwarded-Proto} =http RewriteRule .* https://www.%{HTTP:Host}%{REQUEST_URI} [L,R=301] </IF> <ELSE> RewriteCond %{HTTP:X-Forwarded-Proto} =http RewriteRule .* https://%{HTTP:Host}%{REQUEST_URI} [L,R=301] </ELSE>
I removed these lines and tested again… The standard WordPress permalinks are all resolving. I had initially added those lines because when I had been typing domain-name.com (without the https prefix) I was getting browser messages that the site is not secure.
However by updating the wp-config file as follows (see below) I don’t need the https redirection in the httpd.conf file and this has allowed the .htaccess rewrite rules to work.
define('WP_HOME','https://www.domain-name.com'); define('WP_SITEURL','https://www.domain-name.com'); if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) $_SERVER['HTTPS']='on';
Forum: Fixing WordPress
In reply to: WordPress permalink issuesThank you so much for your reply. I have installed the rewrite rules inspector plugin. As you suggested it does appear to be an issue with the rewrite rules.
Apart from choosing the simple option from WordPress -> Permalinks every other permalink option gives me the default of prefixing index.php on the rewrite.
I am investigating this and will likely write my custom function. Strange that it works for so many other people out of the box.
E.g. below is how the rewrite rule for the page entry and how this interpreted when I set to /%postname%/ the rewrite still has index.php.
(.?.+?)/page/?([0-9]{1,})/?$ index.php?pagename=$matches[1]&paged=$matches[2] page
After installing the plugin I did flush the rewrite rules and saved the Permalinks twice in a row. I can confirm that there are no posts and pages with the same name.
Thanks again.