Gravity Forms breaks permalinks/.htaccess #710

Closed
mikeunb opened this Issue Mar 14, 2013 · 14 comments

Projects

None yet

3 participants

@mikeunb
mikeunb commented Mar 14, 2013

I think this is this issue: #581

Which I couldn't find a solution for... the OP doesn't follow it up, but in my case I don't think it's a server issue as I'm running a dedicated setup with cPanel and about 10+ other wordpress installs all with roots and gravity forms BOTH installed and working, solid as they should be.

Luckily it's a new site so I can play around as much as I want:

Here are the steps I go through:

  1. Install latest wordpress via SSH (Wordpress 3.5.1)
  2. Install roots theme via FTP
  3. Create blank .htaccess, chmod 666.
  4. Activate roots theme.

At this point, I choose to use the nice rewrites for /assets/css, etc.

  1. Roots .htaccess with boilerplate and rewrites is copied by roots to the root directory, and it works as it should.
  2. Install Gravity Forms (1.6.7, via upload as .zip) activate, then register, then let it auto-update to latest... this appears to then confusingly downgrade to 1.6.12, but I allow it anyway because I know this worked on all my other wordpress sites on this server.

At this point the rewrite rules for /assets/ break and the front-end cant load images or css, I've experienced this a few times, but usually the fix is to just repeat steps 3 & 4.

However, nothing will make any difference from this point onward.

I've tried:

  • repeating steps 3-4 about 500 times
  • changing permalink structure to something different so wordpress restores its original rewrite rules into .htaccess first, then re-activating roots theme.
  • copying and pasting the following (standard wp rewrite rules) into a blank .htaccess file, then re-activating roots:

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
  • copying and pasting the following into blank .htaccess from another roots site that works:

    RewriteEngine On
    RewriteBase /
    RewriteRule ^index.php$ - [L]
    RewriteRule ^assets/css/(.) /wp-content/themes/roots/assets/css/$1 [QSA,L]
    RewriteRule ^assets/js/(.
    ) /wp-content/themes/roots/assets/js/$1 [QSA,L]
    RewriteRule ^assets/img/(.) /wp-content/themes/roots/assets/img/$1 [QSA,L]
    RewriteRule ^plugins/(.
    ) /wp-content/plugins/$1 [QSA,L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /index.php [L]
  • the same as above but keeping all the html5 boilerplate stuff
  • copying the entire .htaccess from another site
  • changing wordpress permalink struture to something besides /%postname%/ in admin
    ^^ this was especially weird, as it still seems to honor whatever rewrites rules it needs to for this to work (e.g. visiting /hello-world redirects to /2013/03/hello-world/ fine)
  • Deleting the entire SQL database and re-initialising the whole site from the same file structure

Finally, the one thing that works (until I install gravity forms again):

  • Delete files AND database, reinstall from scratch.

This is happening on a brand new site and I can recreate it easily on this setup, so if anyone wants to have a look I don't mind setting up a login, seems like its a rare bug to recreate. It's as if once you install gravity forms the first time, from then on, wordpress will never honor the rewrite rules from roots. Has me pretty baffled... the fact deleting the database doesn't fix it leads me to think that gravity forms must make some change to the files somewhere that effects roots/permalinks. Can't think for the life of me what it would be, but I'm still a bit of a wordpress noob in the grand scheme of things.

I'm obviously not 100% certain its a roots issue but it would be helpful even to rule out roots as the problem. Similar posts I found blamed server config issues, but weren't specific about what to check. Remember I have other sites running on the same server without this issue.

Cheers,
Mike.

@swalkinshaw
Member

Thanks for the detailed steps. I'm hoping you'll be able to try and replicate this once more to get the following for us:

  1. Your .htaccess file after you install Roots (with rewrites) and it's working.
  2. Same .htaccess file after you install Gravity Forms and it's broken.

If you could Gist those two versions of the file it would be appreciated.

@mikeunb
mikeunb commented Mar 15, 2013

Done. Actually I have three versions...

  1. first attempt to run roots activation after install resulted in this .htaccess, which has rewrite rules for /assets missing. https://gist.github.com/mikeunb/5170507
  2. re-activating twenty twelve, then re-activating roots seemed to fix the problem (this is with roots working normally)
    https://gist.github.com/mikeunb/5170507#file-htaccess-after-second-roots-activation
  3. after installing gravity forms, the page is broken as though the /assets rules are missing even though they still appear in .htaccess
    (roots will be permanently broken now)
    https://gist.github.com/mikeunb/5170507#file-htaccess-after-install-and-activate-gravity-forms-1-6-7
@swalkinshaw
Member

Thanks. Doesn't help much though since 2 and 3 are the exact same.

Few additional things to try:

https://github.com/retlehs/roots/blob/master/lib/config.php#L6-7

Disabling these two features one a time.

@mikeunb
mikeunb commented Mar 15, 2013

OK... I tried the following, between each change to config.php I uploaded a blank .htaccess to the root directory and reactivated roots.

BEFORE gravity forms:

both disabled = roots works, .htaccess has rewrite rules and boilerplate
disabling rewrites = roots will work but with absolute urls (.htaccess blank)
disabling h5bp-htaccess = no noticable change to frontend (works with rewrites, .htaccess stays blank)
disabling both = same as disabling rewrites

AFTER gravity forms:

both disabled = roots broken, .htaccess contains rewrite rules and boilerplate (as before)
disabling rewrites = roots works, with absolute urls for /assets, .htaccess stays blank
disabling h5bp-htaccess = roots broken, .htaccess contains just:

BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteRule ^assets/css/(.) /wp-content/themes/roots/assets/css/$1 [QSA,L]
RewriteRule ^assets/js/(.
) /wp-content/themes/roots/assets/js/$1 [QSA,L]
RewriteRule ^assets/img/(.) /wp-content/themes/roots/assets/img/$1 [QSA,L]
RewriteRule ^plugins/(.
) /wp-content/plugins/$1 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

END WordPress

disabling both = same as disabling just rewrites

PHP Version 5.2.17
MySQL Version 5.0.96
WordPress Version 3.5.1
Gravity Forms Version 1.6.7

@mikeunb
mikeunb commented Mar 15, 2013

Something else I just noticed is that roots breaks as soon as Gravity Forms is installed, before it's been activated at all.

@mikeunb
mikeunb commented Mar 15, 2013

Here's a working .htaccess from another wordpress site on the same server with both roots and gravity forms working perfectly fine: https://gist.github.com/mikeunb/5171250

@mikeunb
mikeunb commented Mar 15, 2013

Ok, currently I'm getting it to work by setting up wordpress on a subdomain of one of the sites that works, installing all the plugins I want, then importing the files and database over to the cpanel account for the domain that's been giving me problems.

Then I just edit the url in the database and for some reason roots and gravity forms work fine after that.

Edit: I keep getting a warning about .htaccess being not writable now, even though it has the same settings that didn't throw that warning before... and W3 Total Cache managed to add stuff to it. What's going on?

Could be server config, but I can't see the difference between the two accounts... it only seems to happen with roots/gravity forms. Anything else I should check?

@mikeunb
mikeunb commented Mar 26, 2013

I've still got no solution for this.... cpanel account looks identical to my dev one that works. It's as if after installing gravity forms to WP the first time, the cpanel account stops honoring JUST the roots rewrite rules in .htaccess (standard WP ones continue working).

Pretty bizarre, I'm hoping its something obvious I've missed.

Can still provide test environment if someone wants a closer look...

@retlehs
Member
retlehs commented Mar 26, 2013

have you contacted your webhost for support?

@mikeunb
mikeunb commented Mar 28, 2013

awaiting a response from them...

@retlehs
Member
retlehs commented Apr 20, 2013

any update?

@mikeunb
mikeunb commented Apr 23, 2013

Apologies, I got this back from our webhost admin a while ago but have been too swamped to do much testing / not sure what to try next: (we currently generate new wordpress installs by duplicating subdomain/database from an install on the cpanel account that works)

"I have had a read through all this and although I don't really understand the problem or know Wordpress I can tell you that the sub folders on your dev site probably work fine because they are inheriting the rules from the .htaccess file in the folder above.

So for example:

Root -> .htaccess
Root -> Sub Folder -> .htaccess

Any site in the sub folder will still use the same rules from the root .htaccess file as Apache will inherit the parent rules. Maybe try again and remove the .htaccess file in the root folder to see if it breaks the site.

I know this is not going to get to the bottom of the problem but it might help you understand why things are not working correctly.

Note. php.ini files do operate in the same way as .htaccess files. ie. they do not inherit from the parent folders and only apply to the script running within the same folder as the php.ini file.

Let me know how you get on.
Regards,
xxxxx"

Our webhost guy is pretty helpful but naturally he's going to say something along the lines of 'my server is fine, its your code' unless I can be more specific.

If you have suggestions of what to try I'd be keen to get to the bottom of it still.

@retlehs
Member
retlehs commented May 1, 2013

a8c5437 might help here but i can't really tell

@retlehs
Member
retlehs commented Jun 3, 2013

db13ead also might help. let me know if this needs to be reopened

@retlehs retlehs closed this Jun 3, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment