Pretty permalinks going to 404

June 10, 2017 157 views
Apache WordPress Ubuntu 16.04

I've been having this issue all day and I can't figure it out. My site keeps going to a 404 page when it's accessing the pretty url for a blog post

My htaccess file looks fine to me and so does the vhost conf file but maybe I'm missing something? I've restarted apache and also enabled a2enmod rewrite...

http conf

<VirtualHost *:80>
  ServerAdmin webmaster@domain.com
  ServerName domain.com
  ServerAlias www.domain.com

  DocumentRoot /var/www/domain.com
  <Directory />
       Options FollowSymLinks
       AllowOverride None
  </Directory>
  <Directory /var/www/domain.com>
       Options Indexes FollowSymLinks MultiViews
  AllowOverride None
       Order allow,deny
       allow from all
  </Directory>
  ErrorLog ${APACHE_LOG_DIR}/domain.com-error.log
  CustomLog ${APACHE_LOG_DIR}/domain.com-access.log combined

RewriteEngine on
RewriteCond %{SERVER_NAME} =domain.com [OR]
RewriteCond %{SERVER_NAME} =www.domain.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

https conf

<IfModule mod_ssl.c>
<VirtualHost *:443>
  ServerAdmin webmaster@domain.com
  ServerName domain.com
  ServerAlias www.domain.com

  DocumentRoot /var/www/domain.com
  <Directory />
       Options FollowSymLinks
       AllowOverride None
  </Directory>
  <Directory /var/www/domain.com>
       Options Indexes FollowSymLinks MultiViews
  AllowOverride None
       Order allow,deny
       allow from all
  </Directory>
  ErrorLog ${APACHE_LOG_DIR}/domain.com-error.log
  CustomLog ${APACHE_LOG_DIR}/domain.com-access.log combined

SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

.htaccess

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
2 Answers

Hi @tannerchung

Can you delete the .htaccess file. Then go to domain.com/wp-admin/options-permalink.php and select Plain, click save, then click Post name and click save.

Also edit you http conf and change it to this instead:

<VirtualHost *:80>
  ServerName domain.com
  ServerAlias www.domain.com
  Redirect / https://domain.com/
</VirtualHost>

And https conf to this:

<IfModule mod_ssl.c>
<VirtualHost *:443>
  ServerAdmin webmaster@domain.com
  ServerName domain.com
  ServerAlias www.domain.com

  SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem
  Include /etc/letsencrypt/options-ssl-apache.conf

  DocumentRoot /var/www/domain.com

  ErrorLog ${APACHE_LOG_DIR}/domain.com-error.log
  CustomLog ${APACHE_LOG_DIR}/domain.com-access.log combined
</VirtualHost>
</IfModule>

@hansen

I've changed the two conf files as you wrote and removed the .htaccess file. After, I went ahead and saved Plain and Post name in the permalinks settings. It doesn't seem have created a new .htaccess file. It's still doing a 404 on the pretty link blog post : \

  • @tannerchung

    Seems like your Apache/PHP and WordPress doesn't have the same user rights, so WordPress cannot create/update files.
    I'm getting closer to recommending starting over with a clean LEMP stack.

    You can try to run this command to set all files to be owned by www-data, which is the default Apache/PHP user:

    sudo chown -R www-data:www-data /var/www/domain.com
    

    Then try to set the permalink in WordPress again.

    Otherwise you need to manually add the /var/www/domain.com/.htaccess:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
    </IfModule>
    # END WordPress
    
  • @hansen thanks for bearing with me on this... it's not that the tutorial for multiple WordPress on here is wrong but I think it is more complicated - probably better practices? I used this instead for http.. haven't tried https yet

    <VirtualHost *:80>
        ServerName domain.com
        ServerAdmin webmaster@domain.com
        DocumentRoot /var/www/domain.com
        <Directory /var/www/domain.com>
                AllowOverride all
        </Directory>
    </VirtualHost>
    
    • @tannerchung

      If you have followed the tutorials for Ubuntu 16.04, then they're pretty updated and follow most best practices.

      I'm not a huge fan of Apache - the configuration quickly turns messy and the .htaccess is the root to more problems than it solves.

      Since you want to serve your site as https, then you should only change the https-conf - leave the http-conf just as a redirect.

      But you're probably right, you need the allow override for .htaccess to work:

      <IfModule mod_ssl.c>
      <VirtualHost *:443>
        ServerAdmin webmaster@domain.com
        ServerName domain.com
        ServerAlias www.domain.com
      
        SSLCertificateFile /etc/letsencrypt/live/domain.com/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/domain.com/privkey.pem
        Include /etc/letsencrypt/options-ssl-apache.conf
      
        DocumentRoot /var/www/domain.com
      
        <Directory />
          AllowOverride all
        </Directory>
      
        ErrorLog ${APACHE_LOG_DIR}/domain.com-error.log
        CustomLog ${APACHE_LOG_DIR}/domain.com-access.log combined
      </VirtualHost>
      </IfModule>
      
      • @hansen
        There were a few issues going on simultaneously that was causing this problem

        1. The site would randomly try to redirect to https. Even when I took the site down on purpose, a2dissite, typing in the domain would bring it to https://www.domain.com which is really really strange. I thought it was the browser cache or something but I tried on different browsers and incognito
        2. The conf file had "issues". I would not say for certain at all because a few days ago I had it working find until I started that whole postfix debacle
        3. The htaccess file did not have the right permission? I only witnessed it not being able to write but I saw the the permission ls -la was correct so I can't tell what was causing that
        4. After doing a rebuild #3 disappeared but #1 kept happening and I caught it once because the browser lagged even though this was not showing up in the logs and this is when #2 allowed the site to briefly work - I have no idea how
        5. After I decided to just use a work around and install certs again so the redirect would take it to the right page anyways the htaccess needed to be reset so because I had a new rebuild I was able to use WordPress to rewrite the htaccess file and permalinks started to work

        The confusing part of this is why it is redirecting to https even with the site down, and even if it was shouldn't it be just showing that the site is insecure?

        I'm going to try the "correct" conf later.

        • @tannerchung Hurray, it's working!!! I can see the pretty permalinks now without 404.

          1. Browser cache is actually a real pain. And Chrome is really bad here. A good way to test would be to use the curl command, because it never caches anything and tells you about redirects and headers.
          2. That's strange - Apache and Postfix shouldn't touch each other.
          3. I'm not sure what happened with the rights, but it seems to work now.
          4. Number 1 can cause so much confusion, that you start doing other changes, which actually just makes everything worse.
          5. Great.
          • Yeah Postfix and Apache shouldn't have been causing problems but right when I installed Postfix to handle my mail (I took the advice to use Sparkpost finally) I enabled SPF, DKIM, and DMARC and the VM started running out of memory.

            I kept an htop around to watch the processes and didn't see anything abnormal but this is also me enabling all the services that w3 total cache was asking for so it's possible that could have caused all the memory to be consumed - only because I'm a noob and when I set it up I probably did it wrong. It would be ironic that a caching plugin and it's ecosystem of utilities that is meant to reduce latency would be hoggin up the memory like that.

  • @hansen I take all of that back. the entire site went down and then the came back up. then permalink stopped working again. I'm at a loss lol

    • Take it as a learning experience. Since I can see that your site is empty, then I would actually recommend that you rebuild the droplet with a clean Ubuntu 16.04 and follow LAMP tutorial again.
      As you know, practice makes champions. This is how I learned in the beginning, simply by making mistakes and starting over, and then doing it better.

Have another answer? Share your knowledge.