Support

 Hi Davide, Nicholas,

I would like to suggest an improvement to be able to choose to delete (or not) local site, before restoring remote backup downloaded from master site by Unite.

I mean, in <siteInfo> section, to add something like you did for databaseInfo, a kind of <existing>drop</existing>....

it could be very useful for web sites that present the content of a folder to internet user. Without this option, once the site is restored through unite, it may remain after extration some files that are no more present on master site.

This way, it could be possible to have on the replicated site the exact copy of master site, without 'ghost' files present...

i don't kow if i'm clear :
- if I have on my master site a folder name 'folder1', with 'file1.txt' and 'file2.txt' inside.
- I do a replication using Unite, so I will have the same 'folder1' with 'file1' and 'file2' inside
- then I remove 'file2' on master site
- I do a replication using Unite
- I have 'file1' and 'file2' on replicated site, instead of just having 'file1'....


Do you think it could be possible in a future release of Unite ?

Thanks for all,

Kind regards,
JM Santoni

Sorry Davide, I've just checked the tickets, and I've found it is duplicated on #25408 ticket also (sorry about that).

Following your answer in this ticket Nicholas, I agree with you I can call rm before running Unite script.

But the big difference in my opinion, should be to delete the whole directory ONLY if the backup transfer is successful, and not at the beginning of the whole replication process...

just an idea..., it is not a fundamental feature, and we could live without it...

Kind regards,
JM Santoni

The issue for this is not technical, but relative to maintaining N distributions of Unite, with homemade steps in it.

Let me explain, we have about 90 unite scripts distributed over 3 'reseller hosting' servers. We are using unite to backup a master site to 2 slaves (slaves trigger the Unite process), to be ready to serve http, in case of master failure, just doing an IP switch in Anycast DNS.

Any of the 3 server can play master or slave role, thus a web site leads to 3 Unite setups, 1 on each server. Multiply by the number of sites we host, and you reach 90.

doing extra implementation, quite easy technically, leads to maintain 90 setups each time there is a needed new Unite release to roll up, and this number is growing up.

That's why we push a bit to ask you if it is possible to implement such 'delete before restore' feature (similar from what you do deleting /installation folder under stealth . htaccess protection).

If not, we will of course do it by ourselves, but it is going to be a real pain to maintain, and one more exploitation step to think of when rolling.

I hope you understand our point of view.

We are already very happy with other CMS detection in Unite 3.0, and again many thanks for that, it is a real good job, it saves us 80% pain avoiding manual treatment to restore other CMS config files to make them work on replicated sites, it just remains this small step to be able to fully automize, using Unite, and only built-in features of Unite, without any custom code or step to add.

Thanks for help and for your great producst anyway,
Br,
JM Santoni

Hi Davide,
Thanks for your answer, we will implement a step for that on our side.

br,
JM Santoni