A funny thing happened on the way to site-building

It all started when I tried to sql-sync my database from my local setup to my remote test server.

drush sql-sync @dev @test
ssh: Could not resolve hostname @dev: Name or service not known

hm. So I google my error and find an issue on the Drush Github project for the exact same problem. Awesome! it's already been fixed. So I just need to update drush.

Having previously installed drush as a git repository, I cd over to that dir and and do a git pull. yes? Well along the way I notice that the drush github page now suggests installing with Composer instead, so I decide to update to that process. Probably I could've just stuck with my previous method, but in the interest of doing things "the right way"... this is where I keep getting myself in trouble. Ok:

composer global update
#tried composer -V and global update just to see where I stood...
Warning: This development build of composer is over 30 days old. It is recommended to update it by running "/usr/local/bin/composer self-update" to get the latest version.
...
Composer could not find a composer.json file in /Users/E/.composer
...
drush (master)$ /usr/local/bin/composer self-update                                                             [Composer\Downloader\TransportException]                                  
  The "https://getcomposer.org/version" file could not be downloaded: allow_u
  rl_fopen must be enabled in php.ini...

Sigh. So I fix allow_url_fopen. I run composer self-update. I try to install drush again... composer.json?? It took a bit more research to get this right, and I honestly don't remember what I did now. But here's what it wound up as:

{
    "require": {
        "drush/drush": "dev-master"
    }
}


Swell. I think at this point I managed to run the command to get drush re-installed. Now I've got the version of drush with the fix for my original issue! or so I thought... I took a closer look at the code fix for the ssh problem, found that file in my install and compared. The code didn't match, but the hash when I had updated with composer showed it was the most recent version! I had the new updates, but I also had the old git clone of drush. Guess which one my shell was pointing at?

Eventually. Eventually I check which drush, where drush, what drush?? and find my bash_profile export PATH pointing in too many directions (wrong!: /Applications/drush/drush:/.composer/vendor/bin:), which if I'd been paying slightly more attention I might've noticed in step one of installing with Composer. Removed the old path, kept the .composer path and I think that's when it finally worked.

At least I'm pretty sure that's what happened. By the time I was done with this I had completely forgotten that I was trying to sql-sync. So I finally, finally got back to that and it actually just worked. So now I need to figure out pushing the rest of my initial local dev stuff up and after that it'll all be pushing code up and pulling data down.

It's going to be really weird doing front-end work after spending so much time on configuring and getting things to just function... one day at a time.

Useful things I just did

Environment setup for ssh stuff on my server. Eventually found and edited my bash_profile. Remembered how to vi and unix properly. Can't remember what I was originally trying to do.

Setting up SSH. Basic stuff. Understanding SSH.

Oh yeah, here's where I started, Drupal on Dreamhost.

/me clambers back out of rabbit hole to find a new one to explore...

oh, and adding an alias to my bash_profile alias ll='ls -la' for more verbose file listings. Cause otherwise I can't *see* .bashrc, say, without at least ls -a.

Crash course: clone local, push to server, bam, test site.

More or less. Reminder: Installing Drupal. Includes db setup.

Page two of install gives me "no data from server." ... what? the first page is fine, but I click "english" and it gives up? It's not even a WSOD!

Sweet bunnies. Upgraded MAMP, again, broke things. Eventually remembered to change my mysql password in /Applications/MAMP/bin/phpMyAdmin/config.inc.php (I had changed it away from 'root' at some point, for obvious reasons).

wooo finally got through the install script. Since I've only done core stuff before I don't really know what all I should use for a production site- username, site name, that sort of stuff. Just going to wing it.

So this is probably one of those stupid questions, but do I have to go through the install script every time I push up from dev to stage and prod?

So trying to push from my local dev environment to my test directory on my dreamhost server: fails, gives me a fatal, no directory, not a git repo message. I think I just had my ssh url written wrong, so switched from ssh://user@server/files/stuff.git to user@server:files/stuff.git and that seems to work. But now I'm not quite sure what that did for me- "This directory is not the working tree, where you edit and commit code. Rather, it is simply the central location for the git objects and history..." ok, so I still need to clone from there to test site. hm.

ok, so now that I'm drawn myself a nice diagram of where my branches and repos and whatnot are, plus associated dbs, I think I can keep moving along... somewhere I had a thing for using drush to keep sites synched... Can't handle adding that into the mix right now, just going to try getting my site up and running first.

With a little help from the git pages, cloning into mysite/test so I can try just a plain install on a live site with a real db. Then I just need to figure out how to pull the db back to local (I think an export will have to do for now, lest I find myself in hours of drush trouble).

... I should really probably be doing this with D7, not a totally random variety of D8. I'll just hit mysite/test and run through the install script real quick... My php installation is too old??? you can't be serious. *checks dreamhost info* ... php 5.2.17.

*Head-desk*

Nobody say anything. TBC after some coffee, methinks.