Hi gdeschep,
I’ll add this item to the todo list…
Thanks for the feedback!
Great ! I’m looking forward to it.
Hi gdeschep,
I took a deeper look into this and these are my findings:
.htaccess file
Since so many other plugins write to the .htaccess file it really only makes sense to refresh the file and then ask the users to resave the plugins that write to the .htaccess. Otherwise the majority of most plug-ins that write settings to the .htaccess file write the settings specifically for the server that is currently on.
Because the majority of most duplications incur a new server transfer, the settings are no longer valid for the majority of many of the settings. In the very early versions of the duplicator I never overwrote .htaccess file and this caused way more trouble and questions about things being broken on many systems than it actually did good. Because the .htaccess file was configured completely different for a different system it caused all kinds of issues on the new server. This doesn’t make things any easier when users don’t even know what a .htaccess file is to begin with…
Until I can find a really clean solution resetting the .htaccess file makes the most sense at this point. I’ll continue to look into the problem in future versions. One solution would be to add a check box that says don’t touch the .htaccess and then users can configure it themselves.
Also for now don’t forget that the orginal is backed up to htaccess.orig so you can easily copy the values from there…
wpconfig vars
As far as the wp-config variables are concerned, those should now show up in the general report. The report is designed to help users finalize any settings. I can’t replace those particular variables because I’ll have no idea what the end-user will want them to be, some systems will actually use variables in the variable string making it impossible to know what the desired outcome should be…
Hope that helps!
First of all thanks for taking a deeper look at those issues.
1) .htaccess file:
I understand what you mean, but isn’t it so that duplicator knows both the url of the old installation and the url of the new installation when doing the clone ?
If so, then I would expect it to be possible to simply search for the old url in this file and replace it with the new url, no ?
Because that’s the only thing that I would like to see implemented – if possible of course.
So to put it simple, it should do something like this:
scan the original .htaccess file, search for <old-url> (e.g. “myoldblog.com”) and replace each match with <new-url> (e.g. “mynewblog.com”).
Example:
*** content original .htaccess:
RewriteCond %{HTTP_REFERER} !^(.*)myoldblog.com/wp-admin
RewriteCond %{HTTP_REFERER} !^(.*)myoldblog.com/wp-login\.php
*** content of new .htaccess (i.e. after search & replace)
RewriteCond %{HTTP_REFERER} !^(.*)mynewblog.com/wp-admin
RewriteCond %{HTTP_REFERER} !^(.*)mynewblog.com/wp-login\.php
Note: if you say that you expect a lot of troubles when not resetting the .htaccess file, I understand and I can live with the fact that you make a copy of the original one and (optionally ?) do the replace in that copy.
This way I can simply copy over this modified file if I want to.
2) wp-config:
No problem, I understand what you mean and I think the issue I described only happens when my blog is in a subfolder (e.g. /myblogs/blog1)
Hey gdeschep,
Yeah you would think that is all you have to override, but with a .htaccess file there are so many different permutations. And trying to code around it gets complex pretty quick. I actually use Better Security myself and have the same complaint as you do. The problem isn’t even so much with that plugin because the .htaccess content it generates is very clean.
Its the other ones that do all kinds of SEO opts that really get things pretty messy. The problem is that once a user is done with the install and they can’t see their site right away because some Apache rule is erroring out, redirecting or messing with the URI, then I receive a help ticket asking me why the plugin sucks and they can’t see anything…
And a good part of the time after digging around in the .htaccess file its something a plugin set in the file. So for right now it is more a protection from extra emails, but you are right it would be nice to have a cleaner solution. I’m still working on it but just trying to figure out the best approach, whatever that might be 🙂
Thanks for helping to provide good feedback!
To be honest I wasn’t aware it could become that complecated 🙂
But now I do and I appreaciate the fact that you want to take your time to find a good solution.
No Problem! Yeah I didn’t realize it was going to be this complicated a when I started… The core move of the files and DB aren’t so bad its trying to work with so many different plugins that really takes the time to get things right. It will keep getting better over time…
Cheers!
