Htaccess rewrite rules on migration

Expected behavior

Previously added WP mod_rewrite rules should be overwritten by CP rules.

Current behavior

I have migrated a test install from WordPress to ClassicPress.
I then reset the permalinks but noticed the WP rules were still present in htaccess.
See attached.

ht

Steps to reproduce

  1. Install WordPress
  2. Migrate to Classicpress
  3. Reset permalinks

Context

Although the migration is working perfectly fine, my spidey sense/ OCD dictates the WP rules should have disappeared.

2 Likes

Thanks for the report. I will test this when I can, in the meantime, can anyone else confirm or deny that this is an issue for them?

I’ve seen it. Didn’t break anything. Looking at the code I think it looks for the #Begin and #End tags to do a hard flush and rewrite or not. So if it finds #Begin WordPress it leaves that there and writes the #Begin ClassicPress rule set. Have to do more tests to see if it happens on migration and/or just when updating permalinks.

<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript text/javascript
</ifmodule>





# 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

# Wordfence WAF
<Files ".user.ini">
<IfModule mod_authz_core.c>
	Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
	Order deny,allow
	Deny from all
</IfModule>
</Files>

# END Wordfence WAF


# BEGIN ClassicPress
<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 ClassicPress

So when I change the permalinks to plain it removes the ClassicPress but leaves the WordPress rules. The site doesn’t use the WordPress rules however so again doesn’t break anything.

<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript text/javascript
</ifmodule>

# 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

# Wordfence WAF
<Files ".user.ini">
<IfModule mod_authz_core.c>
	Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
	Order deny,allow
	Deny from all
</IfModule>
</Files>

# END Wordfence WAF


# BEGIN ClassicPress

# END ClassicPress

Hi,

It’s more interesting to me.
For me, the hosting has added additional rows to the WordPress part. But not for the part about ClassicPress. I guess the reason is the AutoSSL in C Panel.
I’m getting involved in the discussion to say that the WordPress section may have been modified by some hosting companies.

Thank you for your efforts to have an alternative to WordPress.

2 Likes

@KokoFresha that is interesting, which hosting provider is this?

I think putting these rules inside the ### WordPress section is not a great idea on their part, it would be better placed in a separate section. Otherwise, I am not sure why they wouldn’t just be overwritten when WordPress refreshes its rules.

Anyway the fact that sometimes this section doesn’t look as expected is a good thing to keep in mind here when testing, so thanks for bringing it up.

1 Like

The provider is Superhosting. The best provider in Bulgaria.
I just asked for some information from the support.
Their answer is, “These are system rules for AutoSSL to work properly.”
I suppose they update .htaccess before each renewal of the certificate, which is automatically 3 months. Since I was migrating to ClassicPress after the last renewal, the part for Classicpress was not affected.
These rules are added to all my Rewrite rules - bad bot, https redirects, access denied…
I was also surprised at this editing, but it is good to know that some suppliers may use such an approach.
It seems to me to be useful for future updates of ClassicPress.
:slight_smile:

Same in my multisite install. Since it works fine I didn’t consider that as an issue however. I noticed my hosting modified the wp part.
I have avoided touching it because I wasn’t sure it was OK deleting wp part.

Not seeing both WordPress and ClassicPress rules after migration; just ClassicPress.
Also, rules that existed outside the # BEGIN / # END lines were undisturbed (where my webhost added rules related to AutoSSL).
So, seems to work as expected. (I did not visit and resave the rewrite rules, BTW)

This is odd. I’m checking the sites I have migrated and they all have the Wordpress rules but no ClassicPress rules at all.

Edit. Oh, I see. If I go in and resave the permalink settings page, it does add the CP code into .htaccess, but the WP code is still there too.

1 Like

I have just tried this on one of my own sites and can confirm this behavior. Migrating from WP to CP has no effect on the .htaccess file. But saving permalinks adds the CP code to the end of that file while leaving the WP code intact.

1 Like

Do you actually have to save the settings? I thought just visiting the permalinks settings page flushed the rules.

Yep, you need to hit the save button.

1 Like

Ah, ok. Perhaps what I mentioned only applies after permalinks have been saved once. I only need to visit the page to refresh the rules at that point; no save required.

1 Like

But visiting the page to refresh the rules is not exactly an intuitive thing. It never occurred to me to do it on the sites I migrated. I think it should be automatic and overwrite the WP rules.

2 Likes

Just thought I would check mine. I haven’t touched any thing since my recent migration, I haven’t even visited permalinks, nor resaved.

I have the exact same thing as the initial poster, I assume it was the migration that tagged the identical classicpress rules after the WP rules.

I deleted the WP rules before I read all the posts, it all still works fine, (which I guess seems obvious?)

Thanks for testing this everyone. ClassicPress is looking for a # BEGIN ClassicPress section in the .htaccess file, and if it doesn’t find that, it makes a new one.

Trying to flush and update the rewrite rules during migration doesn’t seem like a good idea, it is just one more thing that isn’t strictly necessary but could go wrong.

We can get rid of the duplication though. If ClassicPress saves its rewrite rules, and there is already a # BEGIN WordPress section, we can replace it instead of adding a new one.

I’m happy to get this change made in ClassicPress v1 if we can get it implemented and tested. I don’t think we should hold up the release for this change but I think it’s something we should fix eventually.

1 Like

Is this on migration, James, or when you save the permalinks page? It’s just that none of the sites I checked have any mention of ClassicPress in .htaccess after migration.

Does it matter if they are labelled as WordPress rules? What would be wrong with simply replacing the word “WordPress” with “ClassicPress” in .htaccess and keeping all the current rules intact. From the OP’s example it looks like the rules are the same.

When you save the permalinks page from ClassicPress.

Not really, it doesn’t break anything :slight_smile: This is probably still what will happen when you’ve migrated a site, but you haven’t re-saved the permalinks yet.

What would be wrong with simply replacing the word “WordPress” with “ClassicPress” in .htaccess and keeping all the current rules intact.

This is basically what I’m thinking we can do, but it will happen the first time ClassicPress re-saves the permalink structure / rewrite rules.

OK - thanks James. That all sounds good.

The only thing I didn’t really understand was this talk about “resaving the permalinks page”. Why would anyone even do that? I am migrating existing WP sites that are already set up the way I want. It never occurred to me to go back in and save the same settings again.