Can't connect to DreamHost via SSH using this.

[joshuaiz]

First, this is super awesome - I can't believe there isn't more interest in it. I have it set up in my local WP install, configured the variables and now just going down the commands to test. Was able to create a local db backup in about .2 seconds. How cool.

I have a VPS with DreamHost. Running ssh [email protected] works as expected - my RSA keys are verified and I can connect without entering a password. Using those settings:

r_user=myusername r_host=mydomain.com

I can't connect using SyncDB: Error: could not connect to host.

What am I doing wrong? What else should I try? Thanks!

[joshuaiz]

Just an update...was able to successfully run the following commands:

upload_script do_remote_backup

So it seems it can connect just something is not quite right with the test_ssh script so at that stage push fails.

[jplew]

Hi Joshua: thanks for your interest and feedback. :) I think there's a problem with the test conditions. I've had problems similar to yours on other hosts, so I'm grateful to you for confirming. I'll experiment a bit and get back to you with a fix.

[joshuaiz]

One more update. Was able to use rsync to push my /uploads folder. But that got me thinking...I had my repo in my theme directory but instead I changed it to the /wp-content directory which then syncs the uploads folder and any customizations I make to plugins, etc. What is the advantage of using rsync for the uploads folder? To keep git/github code only?

[markchitty]

Hi, just started using this and I think there's a bug in the test_ssh() function. The exit code test assumes an exit code of 1 = success. Shouldn't this be an exit code of 0?

if [ $? == 1 ] # check if the SSH connection is working  <== BUG??
    then
echo
echo "${green}${msgSuccess}$reset SSH connection is working."
        echo
else
echo "$red$msgError$reset could not connect to host. Confirm that the SSH connection, $yellow$r_user$reset@$yellow$r_host$reset, is working."
        exit 1
fi

[jplew]

hi @joshuaiz, firstly my apologies for not helping sooner. @markchitty hit the nail on the head, I made a bizarre oversight with the SSH test. Whenever you get the chance, can you please test the updated script and see if it's working?

As for your question about organization: yes, the advantage of separating the uploads folder is to get it out of git. This will boost performance, as Git is not really intended to version control binaries—trust me it will avoid headaches down the line. :) Except for the ones required for the theme, I generally keep all images out of my theme folder. Hth.

[joshuaiz]

Great news. I will redownload the script, try again and report back.

Thanks!

J

On Mar 16, 2014, at 12:29 AM, jplew [email protected] wrote:

hi @joshuaiz, firstly my apologies for not helping sooner. @markchitty hit the nail on the head, I made a bizarre oversight with the SSH test. Whenever you get the chance, can you please test the updated script and see if it's working?

As for your question about organization: yes, the advantage of separating the uploads folder is to get it out of git. This will boost performance, as Git is not really intended to version control binaries—trust me it will avoid headaches down the line. :) Except for the ones required for the theme, I generally keep all images out of my theme folder. Hth.

— Reply to this email directly or view it on GitHub.

[joshuaiz]

Just did a quick test and everything seems to be working. Thank you!

Using a command prompt in Xiki (https://github.com/lunixbochs/SublimeXiki) so I never have to leave ST3 - sweetness!!!

Wow once I get this set up for all my active sites this is a total game changer.

Like I mentioned in my first message I'm surprised there isn't more interest in this but I have a post on my personal site about workflow which I will update and add a link.

Best,

Joshua

On Mar 16, 2014, at 12:29 AM, jplew [email protected] wrote:

hi @joshuaiz, firstly my apologies for not helping sooner. @markchitty hit the nail on the head, I made a bizarre oversight with the SSH test. Whenever you get the chance, can you please test the updated script and see if it's working?

As for your question about organization: yes, the advantage of separating the uploads folder is to get it out of git. This will boost performance, as Git is not really intended to version control binaries—trust me it will avoid headaches down the line. :) Except for the ones required for the theme, I generally keep all images out of my theme folder. Hth.

— Reply to this email directly or view it on GitHub.

[jplew]

thanks Joshua for your feedback and for the link. Do let me know of any more bugs you come across! Cheers, -JP

[joshuaiz]

Hey JP,

Been using SyncDB a lot for dev sites and it is working great except for one thing:

with rsync it is transferring the /wp-content/uploads/ folder into an /uploads folder outside of the year folder.

Here is my folder structure:

/wp-content/uploads/2014/ --/04/ --/05/ --/uploads/ <-- rsync is putting the uploads here (in year and month folders)

What adjustment(s) should I make to have rsync upload into the correct remote folders?

Thanks!

J

On Mar 19, 2014, at 8:29 PM, JP Lew [email protected] wrote:

thanks Joshua for your feedback and for the link. Do let me know of any more bugs you come across! Cheers, -JP

— Reply to this email directly or view it on GitHub.

[jplew]

Hi Joshua: good to hear from you again. This is related to this bug: https://github.com/jplew/SyncDB/issues/6

The problem is the omission of the trailing slash at the end of the uploads folder. It should be /wp-content/uploads/ instead of /wp-content/uploads

Can you please check if that's the case? Thanks!

[joshuaiz]

Hi JP,

I did not have the trailing slash. Should it be included on both local and remote? Obviously the script is grabbing the correct local folder...

Let me know and I can test right away.

J

On May 6, 2014, at 5:45 PM, JP Lew [email protected] wrote:

Hi Joshua: good to hear from you again. This is related to this bug: #6

The problem is the omission of the trailing slash at the end of the uploads folder. It should be /wp-content/uploads/ instead of /wp-content/uploads

Can you please check if that's the case? Thanks!

— Reply to this email directly or view it on GitHub.

[jplew]

You can test for me to confirm, but I believe the trailing slash should also be there for the local one.

On Wed, May 7, 2014 at 4:17 AM, Joshua Michaels [email protected]:

Hi JP,

I did not have the trailing slash. Should it be included on both local and remote? Obviously the script is grabbing the correct local folder...

Let me know and I can test right away.

J

On May 6, 2014, at 5:45 PM, JP Lew [email protected] wrote:

Hi Joshua: good to hear from you again. This is related to this bug: #6

The problem is the omission of the trailing slash at the end of the uploads folder. It should be /wp-content/uploads/ instead of /wp-content/uploads

Can you please check if that's the case? Thanks!

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jplew/SyncDB/issues/1#issuecomment-42369551 .

[joshuaiz]

Seems like it's working - thanks!!!

J

On May 6, 2014, at 6:08 PM, JP Lew [email protected] wrote:

You can test for me to confirm, but I believe the trailing slash should also be there for the local one.

On Wed, May 7, 2014 at 4:17 AM, Joshua Michaels [email protected]:

Hi JP,

I did not have the trailing slash. Should it be included on both local and remote? Obviously the script is grabbing the correct local folder...

Let me know and I can test right away.

J

On May 6, 2014, at 5:45 PM, JP Lew [email protected] wrote:

Hi Joshua: good to hear from you again. This is related to this bug: #6

The problem is the omission of the trailing slash at the end of the uploads folder. It should be /wp-content/uploads/ instead of /wp-content/uploads

Can you please check if that's the case? Thanks!

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jplew/SyncDB/issues/1#issuecomment-42369551 .

— Reply to this email directly or view it on GitHub.

[jplew]

awesome!

On Wed, May 7, 2014 at 4:40 AM, Joshua Michaels [email protected]:

Seems like it's working - thanks!!!

J

On May 6, 2014, at 6:08 PM, JP Lew [email protected] wrote:

You can test for me to confirm, but I believe the trailing slash should also be there for the local one.

On Wed, May 7, 2014 at 4:17 AM, Joshua Michaels < [email protected]>wrote:

Hi JP,

I did not have the trailing slash. Should it be included on both local and remote? Obviously the script is grabbing the correct local folder...

Let me know and I can test right away.

J

On May 6, 2014, at 5:45 PM, JP Lew [email protected] wrote:

Hi Joshua: good to hear from you again. This is related to this bug: #6

The problem is the omission of the trailing slash at the end of the uploads folder. It should be /wp-content/uploads/ instead of /wp-content/uploads

Can you please check if that's the case? Thanks!

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/jplew/SyncDB/issues/1#issuecomment-42369551> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jplew/SyncDB/issues/1#issuecomment-42371249 .

[joshuaiz]

Hey JP,

Trying to use syncdb for a client on a new host: aiso.net. I've never used them before.

I've updated all the variables but I can't connect via ssh. When I connect through Terminal outside of syncdb I am asked for my password every time - it's not saved in my RSA known hosts.

How can we adjust the script to enter the ssh password on prompt and then go to the next step?

Thanks!

J

On May 6, 2014, at 6:22 PM, JP Lew [email protected] wrote:

awesome!

On Wed, May 7, 2014 at 4:40 AM, Joshua Michaels [email protected]:

Seems like it's working - thanks!!!

J

On May 6, 2014, at 6:08 PM, JP Lew [email protected] wrote:

You can test for me to confirm, but I believe the trailing slash should also be there for the local one.

On Wed, May 7, 2014 at 4:17 AM, Joshua Michaels < [email protected]>wrote:

Hi JP,

I did not have the trailing slash. Should it be included on both local and remote? Obviously the script is grabbing the correct local folder...

Let me know and I can test right away.

J

On May 6, 2014, at 5:45 PM, JP Lew [email protected] wrote:

Hi Joshua: good to hear from you again. This is related to this bug: #6

The problem is the omission of the trailing slash at the end of the uploads folder. It should be /wp-content/uploads/ instead of /wp-content/uploads

Can you please check if that's the case? Thanks!

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/jplew/SyncDB/issues/1#issuecomment-42369551> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jplew/SyncDB/issues/1#issuecomment-42371249 .

— Reply to this email directly or view it on GitHub.

[jplew]

oh this is a really good point. Presently I think SyncDB only works with password-less login. I will test out some solutions and get back to you.

The only alternative at present is for you to pass all the functions individually, or continue to use the push function but manually comment out the test_ssh command, like so:

push () {
    #test_ssh [This is line 1122 in the new script I just posted.]
    backup_local_db
    ...

You can do the same thing for the pull routine too. By commenting this out it will skip the SSH test step altogether, and should continue with the rest of the script, prompting you for the remote password wherever necessary.

I'll try to figure out a more permanent solution. Thanks for bringing this to my attention.

[joshuaiz]

Hey JP,

Will try this when I get a chance.

Regarding the duplicate uploads folder...looks like the script is doing that again, even after adding the trailing slash. Here is what I have:

l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads/

Should I add a slash at the beginning?

Thanks!

J

On May 8, 2014, at 1:52 PM, JP Lew [email protected] wrote:

oh this is a really good point. Presently I think SyncDB only works with password-less login. I will test out some solutions and get back to you. Thanks for brining that to my attention.

The only alternative at present is for you to pass all the functions individually, or continue to use the push function but manually comment out the test_ssh command, like so:

push () { #test_ssh [This is line 1122 in the new script I just posted.] backup_local_db ... You can do the same thing for the pull routine too. By commenting this out it will skip the SSH test step altogether, and should continue with the rest of the script, prompting you for the remote password wherever necessary.

I'll try to figure out a more permanent solution. Thanks for bringing this to my attention.

— Reply to this email directly or view it on GitHub.

[jplew]

Are you pulling/pushing, or both?

The problem might be that for pushing, it should be like this: l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads

And for pulling it should be like this: l_upload_dir=wp-content/uploads r_upload_dir=wp-content/uploads/

I haven't had the chance to test this yet, I'm just basing it on the following from man rsync:

` A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name", but in both cases the attributes of the con- taining directory are transferred to the containing directory on the destina- tion. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

          rsync -av /src/foo /dest
          rsync -av /src/foo/ /dest/foo

`

If that's the case I can implement that. If you have time to check that'd be great.

[joshuaiz]

Chalk it up to user error: I forgot so save the changes, That said, the client is entering content on the live site so I don't want to overwrite anything.

Once they are done, I can do a pull and then retest.

As for the other host, I tried commenting out the test ssh portion of the script and still wasn't able to connect:

[error log removed]

Before all this I was having trouble connecting to begin with - both with ssh and FTP. They said they installed some DDOS protection for the server so that may be wound a bit too tight.

Maybe I'll shoot them a message and see if they can configure RSA authentication so that I don't need a password...

Thanks!

J

On May 9, 2014, at 12:39 AM, JP Lew [email protected] wrote:

Are you pulling/pushing, or both?

The problem might be that for pushing, it should be like this: l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads

And for pulling it should be like this: l_upload_dir=wp-content/uploads r_upload_dir=wp-content/uploads/

I haven't had the chance to test this yet, I'm just basing it on the following from man rsync:

` A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name", but in both cases the attributes of the con- taining directory are transferred to the containing directory on the destina- tion. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

      rsync -av /src/foo /dest
      rsync -av /src/foo/ /dest/foo

`

If that's the case I can implement that. If you have time to check that'd be great.

— Reply to this email directly or view it on GitHub.

[joshuaiz]

Yep, it's working now...thanks!

Seriously, when there are sites/hosting setups that I can't use this script on, I feel like I am going back to the stone ages.

J

On May 9, 2014, at 12:39 AM, JP Lew [email protected] wrote:

Are you pulling/pushing, or both?

The problem might be that for pushing, it should be like this: l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads

And for pulling it should be like this: l_upload_dir=wp-content/uploads r_upload_dir=wp-content/uploads/

I haven't had the chance to test this yet, I'm just basing it on the following from man rsync:

` A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name", but in both cases the attributes of the con- taining directory are transferred to the containing directory on the destina- tion. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

      rsync -av /src/foo /dest
      rsync -av /src/foo/ /dest/foo

`

If that's the case I can implement that. If you have time to check that'd be great.

— Reply to this email directly or view it on GitHub.

[joshuaiz]

Sorry, forgot to add I was using this:

l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads/

That is working on DreamHost.

I get why rsync works that way - it copies all the sub-directories without having to explicitly list them which makes sense.

J

On May 9, 2014, at 12:39 AM, JP Lew [email protected] wrote:

Are you pulling/pushing, or both?

The problem might be that for pushing, it should be like this: l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads

And for pulling it should be like this: l_upload_dir=wp-content/uploads r_upload_dir=wp-content/uploads/

I haven't had the chance to test this yet, I'm just basing it on the following from man rsync:

` A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name", but in both cases the attributes of the con- taining directory are transferred to the containing directory on the destina- tion. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

      rsync -av /src/foo /dest
      rsync -av /src/foo/ /dest/foo

`

If that's the case I can implement that. If you have time to check that'd be great.

— Reply to this email directly or view it on GitHub.

[joshuaiz]

Just tried to do a pull from DreamHost and got this:

Replacing contents of local database...

Success: Local database replaced with contents from remote database.



Downloading srdb.class.php and srdb.cli.php...

curl -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0

Error: Search and Replace Tool download failed.

Any ideas on how to fix?

J

On May 9, 2014, at 12:39 AM, JP Lew [email protected] wrote:

Are you pulling/pushing, or both?

The problem might be that for pushing, it should be like this: l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads

And for pulling it should be like this: l_upload_dir=wp-content/uploads r_upload_dir=wp-content/uploads/

I haven't had the chance to test this yet, I'm just basing it on the following from man rsync:

` A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name", but in both cases the attributes of the con- taining directory are transferred to the containing directory on the destina- tion. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

      rsync -av /src/foo /dest
      rsync -av /src/foo/ /dest/foo

`

If that's the case I can implement that. If you have time to check that'd be great.

— Reply to this email directly or view it on GitHub.

[jplew]

can you executing this command in the shell (locally)?

curl -O

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

It seems like curl isn't working, it's not downloading the scripts.

On Sat, May 10, 2014 at 10:38 PM, Joshua Michaels [email protected]:

Just tried to do a pull from DreamHost and got this:

Replacing contents of local database...

Success: Local database replaced with contents from remote database.

Downloading srdb.class.php and srdb.cli.php...

curl -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php-O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0

Error: Search and Replace Tool download failed.

Any ideas on how to fix?

J

On May 9, 2014, at 12:39 AM, JP Lew [email protected] wrote:

Are you pulling/pushing, or both?

The problem might be that for pushing, it should be like this: l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads

And for pulling it should be like this: l_upload_dir=wp-content/uploads r_upload_dir=wp-content/uploads/

I haven't had the chance to test this yet, I'm just basing it on the following from man rsync:

` A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name", but in both cases the attributes of the con- taining directory are transferred to the containing directory on the destina- tion. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

rsync -av /src/foo /dest rsync -av /src/foo/ /dest/foo `

If that's the case I can implement that. If you have time to check that'd be great.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jplew/SyncDB/issues/1#issuecomment-42747842 .

[joshuaiz]

It seemed like these worked - got no errors in the shell.

Where would it have downloaded these files or how can I test?

J

On May 10, 2014, at 12:57 PM, JP Lew [email protected] wrote:

can you executing this command in the shell (locally)?

curl -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

It seems like curl isn't working, it's not downloading the scripts.

On Sat, May 10, 2014 at 10:38 PM, Joshua Michaels [email protected]:

Just tried to do a pull from DreamHost and got this:

Replacing contents of local database...

Success: Local database replaced with contents from remote database.

Downloading srdb.class.php and srdb.cli.php...

curl -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php-O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0

Error: Search and Replace Tool download failed.

Any ideas on how to fix?

J

On May 9, 2014, at 12:39 AM, JP Lew [email protected] wrote:

Are you pulling/pushing, or both?

The problem might be that for pushing, it should be like this: l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads

And for pulling it should be like this: l_upload_dir=wp-content/uploads r_upload_dir=wp-content/uploads/

I haven't had the chance to test this yet, I'm just basing it on the following from man rsync:

` A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name", but in both cases the attributes of the con- taining directory are transferred to the containing directory on the destina- tion. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

rsync -av /src/foo /dest rsync -av /src/foo/ /dest/foo `

If that's the case I can implement that. If you have time to check that'd be great.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jplew/SyncDB/issues/1#issuecomment-42747842 .

— Reply to this email directly or view it on GitHub.

[jplew]

it would have downloaded them to your .bak directory

On Sat, May 10, 2014 at 11:30 PM, Joshua Michaels [email protected]:

It seemed like these worked - got no errors in the shell.

Where would it have downloaded these files or how can I test?

J

On May 10, 2014, at 12:57 PM, JP Lew [email protected] wrote:

can you executing this command in the shell (locally)?

curl -O

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php -O

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

It seems like curl isn't working, it's not downloading the scripts.

On Sat, May 10, 2014 at 10:38 PM, Joshua Michaels [email protected]:

Just tried to do a pull from DreamHost and got this:

Replacing contents of local database...

Success: Local database replaced with contents from remote database.

Downloading srdb.class.php and srdb.cli.php...

curl -O

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php-O

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0

Error: Search and Replace Tool download failed.

Any ideas on how to fix?

J

On May 9, 2014, at 12:39 AM, JP Lew [email protected] wrote:

Are you pulling/pushing, or both?

The problem might be that for pushing, it should be like this: l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads

And for pulling it should be like this: l_upload_dir=wp-content/uploads r_upload_dir=wp-content/uploads/

I haven't had the chance to test this yet, I'm just basing it on the following from man rsync:

` A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name", but in both cases the attributes of the con- taining directory are transferred to the containing directory on the destina- tion. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

rsync -av /src/foo /dest rsync -av /src/foo/ /dest/foo `

If that's the case I can implement that. If you have time to check that'd be great.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/jplew/SyncDB/issues/1#issuecomment-42747842> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jplew/SyncDB/issues/1#issuecomment-42749347 .

[joshuaiz]

Looks like curl isn't working for me:

$ curl -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0

I was able to download the srdb files manually, but them in the .bak directory for my working project and then run ./syncdb pull

J

On May 10, 2014, at 1:32 PM, JP Lew [email protected] wrote:

it would have downloaded them to your .bak directory

On Sat, May 10, 2014 at 11:30 PM, Joshua Michaels [email protected]:

It seemed like these worked - got no errors in the shell.

Where would it have downloaded these files or how can I test?

J

On May 10, 2014, at 12:57 PM, JP Lew [email protected] wrote:

can you executing this command in the shell (locally)?

curl -O

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php -O

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

It seems like curl isn't working, it's not downloading the scripts.

On Sat, May 10, 2014 at 10:38 PM, Joshua Michaels [email protected]:

Just tried to do a pull from DreamHost and got this:

Replacing contents of local database...

Success: Local database replaced with contents from remote database.

Downloading srdb.class.php and srdb.cli.php...

curl -O

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php-O

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0

Error: Search and Replace Tool download failed.

Any ideas on how to fix?

J

On May 9, 2014, at 12:39 AM, JP Lew [email protected] wrote:

Are you pulling/pushing, or both?

The problem might be that for pushing, it should be like this: l_upload_dir=wp-content/uploads/ r_upload_dir=wp-content/uploads

And for pulling it should be like this: l_upload_dir=wp-content/uploads r_upload_dir=wp-content/uploads/

I haven't had the chance to test this yet, I'm just basing it on the following from man rsync:

` A trailing slash on the source changes this behavior to avoid creating an additional directory level at the destination. You can think of a trailing / on a source as meaning "copy the contents of this directory" as opposed to "copy the directory by name", but in both cases the attributes of the con- taining directory are transferred to the containing directory on the destina- tion. In other words, each of the following commands copies the files in the same way, including their setting of the attributes of /dest/foo:

rsync -av /src/foo /dest rsync -av /src/foo/ /dest/foo `

If that's the case I can implement that. If you have time to check that'd be great.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/jplew/SyncDB/issues/1#issuecomment-42747842> .

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jplew/SyncDB/issues/1#issuecomment-42749347 .

— Reply to this email directly or view it on GitHub.

[jplew]

Hi Josh:

I discovered the source of the problem. It looks like github has abandoned its https://raw.github.com server, and is redirecting all traffic there to https://raw.githubusercontent.com. It redirects http traffic just fine, but it can't point curl or wget in the right direction.

I updated the script locations to the following, so hopefully it should work now:

_Before_ https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

_After_ https://raw.githubusercontent.com/interconnectit/Search-Replace-DB/master/srdb.class.php https://raw.githubusercontent.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

Thanks for finding that bug, it's great to have someone like you who uses this on a regular basis!

Apart from that, there's still the problem with trying to SSH login using a password, correct?

Thanks. -JP

On Sun, May 11, 2014 at 2:57 AM, Joshua Michaels [email protected]:

curl -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

[joshuaiz]

Hey JP,

No worries - I'm happy to beta test.

Yes still having that problem on another remote/local pair. Haven't had a chance to ask that host if they can set up ssh keys yet.

I'll let you know if I can work that out.

Thanks will download the updated script.

J

On May 10, 2014, at 10:57 PM, JP Lew [email protected] wrote:

Hi Josh:

I discovered the source of the problem. It looks like github has abandoned its https://raw.github.com server, and is redirecting all traffic there to https://raw.githubusercontent.com. It redirects http traffic just fine, but it can't point curl or wget in the right direction.

I updated the script locations to the following, so hopefully it should work now:

_Before_ https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

_After_ https://raw.githubusercontent.com/interconnectit/Search-Replace-DB/master/srdb.class.php https://raw.githubusercontent.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

Thanks for finding that bug, it's great to have someone like you who uses this on a regular basis!

Apart from that, there's still the problem with trying to SSH login using a password, correct?

Thanks. -JP

On Sun, May 11, 2014 at 2:57 AM, Joshua Michaels [email protected]:

curl -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

— Reply to this email directly or view it on GitHub.

[joshuaiz]

Hey JP,

One other thing this has brought up. Let's say I have 15 sites using syncdb so I have a different version of the script in each of my respective sites' folders. With that many scripts, it makes sense to split out the script settings from the script itself so when syncdb is updated I don't have to update all those files.

So you would have a settings file with the configuration details (login, server paths, etc) and then the script itself. One of the settings that would be ideal would be to update the script file itself automatically on run. You could turn that on or off in case you made any customizations (as with non-keyed ssh hosts).

Just off the top of my head and in plain english when you run the script:

grab settings file if auto-update is set to yes, check to see if there is an updated version of the script on github and if so, download new script and run with settings if auto-update is set to no, run script with settings

Does that make sense?

J

On May 10, 2014, at 10:57 PM, JP Lew [email protected] wrote:

Hi Josh:

I discovered the source of the problem. It looks like github has abandoned its https://raw.github.com server, and is redirecting all traffic there to https://raw.githubusercontent.com. It redirects http traffic just fine, but it can't point curl or wget in the right direction.

I updated the script locations to the following, so hopefully it should work now:

_Before_ https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

_After_ https://raw.githubusercontent.com/interconnectit/Search-Replace-DB/master/srdb.class.php https://raw.githubusercontent.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

Thanks for finding that bug, it's great to have someone like you who uses this on a regular basis!

Apart from that, there's still the problem with trying to SSH login using a password, correct?

Thanks. -JP

On Sun, May 11, 2014 at 2:57 AM, Joshua Michaels [email protected]:

curl -O https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

— Reply to this email directly or view it on GitHub.

[jplew]

Hey Joshua: great idea, I've been considering that feature lately, but you've convinced me to implement it. I've had the same problem in the past. What I usually do to update different instances of the script is to vimdiff it, but your suggestion is way better.

The auto-update I hadn't thought of, but I like it. Just give me a week or two, and it shall be done. :)

Take care, -JP

On Sun, May 11, 2014 at 10:01 AM, Joshua Michaels [email protected]:

Hey JP,

One other thing this has brought up. Let's say I have 15 sites using syncdb so I have a different version of the script in each of my respective sites' folders. With that many scripts, it makes sense to split out the script settings from the script itself so when syncdb is updated I don't have to update all those files.

So you would have a settings file with the configuration details (login, server paths, etc) and then the script itself. One of the settings that would be ideal would be to update the script file itself automatically on run. You could turn that on or off in case you made any customizations (as with non-keyed ssh hosts).

Just off the top of my head and in plain english when you run the script:

grab settings file if auto-update is set to yes, check to see if there is an updated version of the script on github and if so, download new script and run with settings if auto-update is set to no, run script with settings

Does that make sense?

J

On May 10, 2014, at 10:57 PM, JP Lew [email protected] wrote:

Hi Josh:

I discovered the source of the problem. It looks like github has abandoned its https://raw.github.com server, and is redirecting all traffic there to https://raw.githubusercontent.com. It redirects http traffic just fine, but it can't point curl or wget in the right direction.

I updated the script locations to the following, so hopefully it should work now:

_Before_

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.class.php

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

_After_

https://raw.githubusercontent.com/interconnectit/Search-Replace-DB/master/srdb.class.php

https://raw.githubusercontent.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

Thanks for finding that bug, it's great to have someone like you who uses this on a regular basis!

Apart from that, there's still the problem with trying to SSH login using a password, correct?

Thanks. -JP

On Sun, May 11, 2014 at 2:57 AM, Joshua Michaels [email protected]:

curl -O

https://raw.github.com/interconnectit/Search-Replace-DB/master/srdb.cli.php

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/jplew/SyncDB/issues/1#issuecomment-42761873 .

[jplew]

Hey Josh: when you get the chance, please test the latest release, I incorporated your idea for the config file. The auto-update feature is coming next, stay tuned. Thanks, -JP

[joshuaiz]

Cool JP,

Heading out for the weekend but can test this when I get back.

J

On May 22, 2014, at 12:01 PM, JP Lew [email protected] wrote:

Hey Josh: when you get the chance, please test the latest release, I incorporated your idea for the config file. The auto-update feature is coming next, stay tuned. Thanks, -JP

— Reply to this email directly or view it on GitHub.

[jplew]

Hi Joshua: I finally got around to implementing the auto-update feature you requested. Would love to get your feedback on it, so please take it for a spin.

[joshuaiz]

Hey JP,

Downloaded 0.3.1, copied my settings over in about 2 seconds to syncdb-config and ran it...worked beautifully.

Seemed to work a bit faster then before although i didn't have any rsync files to update.

Will let you know if I run into any issues but this is a great step forward.

J

On May 27, 2014, at 5:29 AM, JP Lew [email protected] wrote:

Hi Joshua: I finally got around to implementing the auto-update feature you requested. Would love to get your feedback on it, so please take it for a spin.

— Reply to this email directly or view it on GitHub.

[jplew]

Great, thanks so much for testing! Have some more features planned so will update you, On 30 May 2014 06:45, "Joshua Michaels" [email protected] wrote:

Hey JP,

Downloaded 0.3.1, copied my settings over in about 2 seconds to syncdb-config and ran it...worked beautifully.

Seemed to work a bit faster then before although i didn't have any rsync files to update.

Will let you know if I run into any issues but this is a great step forward.

J

On May 27, 2014, at 5:29 AM, JP Lew [email protected] wrote:

Hi Joshua: I finally got around to implementing the auto-update feature you requested. Would love to get your feedback on it, so please take it for a spin.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/jplew/SyncDB/issues/1#issuecomment-44604950.

[joshuaiz]

Hey JP,

Having an issue with syncdb pull. When I pull from remote, the script is not updating either the site_url or home_url fields in the wp_options table. When you push, these get updated on remote fine.

Any reason why this may occur?

J

On May 29, 2014, at 9:37 PM, JP Lew [email protected] wrote:

Great, thanks so much for testing! Have some more features planned so will update you, On 30 May 2014 06:45, "Joshua Michaels" [email protected] wrote:

Hey JP,

Downloaded 0.3.1, copied my settings over in about 2 seconds to syncdb-config and ran it...worked beautifully.

Seemed to work a bit faster then before although i didn't have any rsync files to update.

Will let you know if I run into any issues but this is a great step forward.

J

On May 27, 2014, at 5:29 AM, JP Lew [email protected] wrote:

Hi Joshua: I finally got around to implementing the auto-update feature you requested. Would love to get your feedback on it, so please take it for a spin.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/jplew/SyncDB/issues/1#issuecomment-44604950.

— Reply to this email directly or view it on GitHub.

[jplew]

Yes, i believe it's because your system is defaulting to /usr/bin/php rather than MAMP's. What happens when you type which php in Terminal? On 6 Jun 2014 04:06, "Joshua Michaels" [email protected] wrote:

Hey JP,

Having an issue with syncdb pull. When I pull from remote, the script is not updating either the site_url or home_url fields in the wp_options table. When you push, these get updated on remote fine.

Any reason why this may occur?

J

On May 29, 2014, at 9:37 PM, JP Lew [email protected] wrote:

Great, thanks so much for testing! Have some more features planned so will update you, On 30 May 2014 06:45, "Joshua Michaels" [email protected] wrote:

Hey JP,

Downloaded 0.3.1, copied my settings over in about 2 seconds to syncdb-config and ran it...worked beautifully.

Seemed to work a bit faster then before although i didn't have any rsync files to update.

Will let you know if I run into any issues but this is a great step forward.

J

On May 27, 2014, at 5:29 AM, JP Lew [email protected] wrote:

Hi Joshua: I finally got around to implementing the auto-update feature you requested. Would love to get your feedback on it, so please take it for a spin.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/jplew/SyncDB/issues/1#issuecomment-44604950.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/jplew/SyncDB/issues/1#issuecomment-45284007.

[joshuaiz]

Yep you are right, it says: '/usr/bin/php'

And it's not just for those links, it's all of them after a pull - I had to run srdbm manually.

So how do I fix it?

Thanks!

J

On Jun 5, 2014, at 6:22 PM, JP Lew [email protected] wrote:

Yes, i believe it's because your system is defaulting to /usr/bin/php rather than MAMP's. What happens when you type which php in Terminal? On 6 Jun 2014 04:06, "Joshua Michaels" [email protected] wrote:

Hey JP,

Having an issue with syncdb pull. When I pull from remote, the script is not updating either the site_url or home_url fields in the wp_options table. When you push, these get updated on remote fine.

Any reason why this may occur?

J

On May 29, 2014, at 9:37 PM, JP Lew [email protected] wrote:

Great, thanks so much for testing! Have some more features planned so will update you, On 30 May 2014 06:45, "Joshua Michaels" [email protected] wrote:

Hey JP,

Downloaded 0.3.1, copied my settings over in about 2 seconds to syncdb-config and ran it...worked beautifully.

Seemed to work a bit faster then before although i didn't have any rsync files to update.

Will let you know if I run into any issues but this is a great step forward.

J

On May 27, 2014, at 5:29 AM, JP Lew [email protected] wrote:

Hi Joshua: I finally got around to implementing the auto-update feature you requested. Would love to get your feedback on it, so please take it for a spin.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/jplew/SyncDB/issues/1#issuecomment-44604950.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/jplew/SyncDB/issues/1#issuecomment-45284007.

— Reply to this email directly or view it on GitHub.

[jplew]

You can add MAMP's PHP to your PATH.

However, I don't believe this should be a requirement for the user, so I will push an update inside the hour, please hang tight. On 6 Jun 2014 04:53, "Joshua Michaels" [email protected] wrote:

Yep you are right, it says: '/usr/bin/php'

And it's not just for those links, it's all of them after a pull - I had to run srdbm manually.

So how do I fix it?

Thanks!

J

On Jun 5, 2014, at 6:22 PM, JP Lew [email protected] wrote:

Yes, i believe it's because your system is defaulting to /usr/bin/php rather than MAMP's. What happens when you type which php in Terminal? On 6 Jun 2014 04:06, "Joshua Michaels" [email protected] wrote:

Hey JP,

Having an issue with syncdb pull. When I pull from remote, the script is not updating either the site_url or home_url fields in the wp_options table. When you push, these get updated on remote fine.

Any reason why this may occur?

J

On May 29, 2014, at 9:37 PM, JP Lew [email protected] wrote:

Great, thanks so much for testing! Have some more features planned so will update you, On 30 May 2014 06:45, "Joshua Michaels" [email protected] wrote:

Hey JP,

Downloaded 0.3.1, copied my settings over in about 2 seconds to syncdb-config and ran it...worked beautifully.

Seemed to work a bit faster then before although i didn't have any rsync files to update.

Will let you know if I run into any issues but this is a great step forward.

J

On May 27, 2014, at 5:29 AM, JP Lew [email protected] wrote:

Hi Joshua: I finally got around to implementing the auto-update feature you requested. Would love to get your feedback on it, so please take it for a spin.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/jplew/SyncDB/issues/1#issuecomment-44604950.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/jplew/SyncDB/issues/1#issuecomment-45284007.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/jplew/SyncDB/issues/1#issuecomment-45287488.

[jplew]

Hi Joshua: I just posted an update. When you get the chance please have a look. You'll have to update syncdb-config this time too, I added another variable, $l_php. You have to specify MAMP's PHP binary there, whichever one corresponds to the version of PHP your MAMP is using. Let me know if it's unclear or if your search and replace is still failing. Thanks, -JP

[joshuaiz]

Hey JP,

Just installed and getting the following errors:

./syncdb: line 1171: syntax error near unexpected token fi' ./syncdb: line 1171: fi'

J

On Jun 5, 2014, at 7:22 PM, JP Lew [email protected] wrote:

Hi Joshua: I just posted an update. When you get the chance please have a look. You'll have to update syncdb-config this time too, I added another variable, $l_php. You have to specify MAMP's PHP binary there, whichever one corresponds to the version of PHP your MAMP is using. Let me know if it's unclear or if your search and replace is still failing. Thanks, -JP

— Reply to this email directly or view it on GitHub.

[jplew]

woops, please try again

[joshuaiz]

Hey JP,

I set up a new local/remote site via BlueHost and ran into a problem where syncdb created a .bak file but not a .bak folder and thus it couldn't complete the db sync.

What I did was simply copy the .bak folder from my local directory to the web server and then syncdb was able to complete.

Not sure if this is BlueHost related or something else that I need in my syncdb-config file but just thought you should know.

J

On Jun 5, 2014, at 11:46 PM, JP Lew [email protected] wrote:

woops, please try again

— Reply to this email directly or view it on GitHub.