Closed mikeunb closed 11 years ago
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:
.htaccess
file after you install Roots (with rewrites) and it's working..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.
Done. Actually I have three versions...
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.
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
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
Something else I just noticed is that roots breaks as soon as Gravity Forms is installed, before it's been activated at all.
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
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?
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...
have you contacted your webhost for support?
awaiting a response from them...
any update?
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.
a8c543753ae4f2e9b39a9ece4f023d54f95c6588 might help here but i can't really tell
db13eaddaa7e71af16d9e9e4cf2e2c8a775719ea also might help. let me know if this needs to be reopened
I think this is this issue: https://github.com/retlehs/roots/issues/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:
At this point, I choose to use the nice rewrites for /assets/css, etc.
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:
Finally, the one thing that works (until I install gravity forms again):
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.