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.

OWW: Tidying up

o, how about that acronym? It is sort of descriptive of how my brain gets to feeling after too many hours staring at the screen. Here's a post on some trouble-shooting of the last two posts, and tidying up any loose ends that I can.

First, the original list post was confused about what element tags to use for embedding HTML content. I started with embed because it sounded like what I wanted to do, but it's actually "for an external (typically non-HTML) application or interactive content." Then I found object, which "will either be treated as an image, as a nested browsing context, or as an external resource to be processed by a plugin." And finally iframe which I had really thought went the way of the dodo for some reason, and which "represents a nested browsing context." Sooo...

Second, hopefully related, the embedded HTML doesn't show up in Google Reader. By switching to object tags, I did get it to at least display alt text. Turns out this is indeed a security problem with RSS feeds.

However, problem B is that the entire embed shows up as an empty frame for at least one reader using (you guessed it) Internet Explorer (IE. Abbreviations will carry into future posts). I suspect this has something to do with cross-site restrictions/same origin policies, or possibly just content blocking. Looked up user agent switching and (yay) Chrome has a built in feature to switch user agents from the developer console. However, everything displayed just fine when I checked the blog through the IE emulators, so I dunno.

The original list has now been tidied up, streamlined, and the stray notes I had in there for my own benefit have been relegated to drafted blog posts. I probably shouldn't blow any time styling it, but it's tempting. I would at least like to standardise some nice classy, plain styling for future documentation purposes.

Also, since this entire blog ought to be transferred to my domain in the near future, I'm not sure how much will be lost in the translation, so I'm not futzing about style too much right now. I did settle on using courier bold to highlight code terms, but then discovered that the code element does the same thing, so will use that henceforth.

Oh yes, and I had intended to use some pre and code elements in my TodoList file, but they didn't display properly on the first two tries. Turns out the < and > are still interpreted as HTML, so substituting in "&lt" and "&gt" respectively was necessary. It's worth noting that all of my HTML/CSS coding is happening using only TextWrangler, having upgraded from TextEdit. Someday fancy software (especially for previewing work) would be nice, but right now I like this basic approach.

Phew. I like fixing all the little problems, but it can certainly get a bit tedious. All my librarian research skills sure are coming in handy!

Gitifying the OneWeekWebsiteList

ote to self: document as I go, not after the fact. It felt a lot like I was running in circles trying to find documentation and n00b help as I was working on this, so I didn't take notes along the way. A lot of the point of this first step was to familiarise myself with a few new systems (Git, GitHub, Terminal, Unix command line, Vim), as well as just publishing my strategy for creating a bigger, better website for myself. The entire project is more about learning than having a finished product (although it would be nice to sell a photo again, someday), so each post is intended as a reference for myself, as you'll note from the links peppered throughout the text below.

I apologise in advance, too, for these posts likely being very dry, incoherent and plentiful. I'm often writing from the top of my head and focusing on developing and documenting rather than fine literary prose. Coincidentally, my horoscope for today:

Once you break down a task into manageable chunks, you'll discover that your challenges are not really that hard. You are absolutely capable of meeting the goal you projected at the beginning.

Essential breakdown of Gitification of The List:

• Wrote project todo list.
• Thought about purpose and use of list- dynamic, changing, updating steps as I go to keep track of overall process.
• Translated list into HTML 
• Created GitHub repository (repo) for new project, cloned repo onto local drive
• Updated and committed ReadMe file on GitHub
• Discovered that this threw my local clone out of sync, figured out basics of git pull.
• Finally figured out how to control the vim editor in Terminal (thanks largely to the patient human who helped me with basic commands) to add messages to merges and commits when I forget to use the -m option .
• At this point, the list was basically done, and pushed to GitHub. 
• Researched how to publish a repo to the web so that it looks like an actual page. I had seen a friend do this with a basic design portfolio, but couldn't find a simple button to push in order to see repo files in anything other than raw code. 
• Turns out I had to create an entire new branch in my repo, move everything, and when it still didn't seem to be working, realised I had left off the obvious !DOCTYPE declaration.  Actually, I could have just left it and popped in a reference or something. oh well.
• Had also found this Google Style Guide, which mentioned that some element tags are optional in HTML5. So I guess my dunderheadedness over formatting my initial list file wasn't actually critical, but I haven't implemented the recommendations yet. Also ran it past a W3C validator. 
• Meanwhile, I just need to get the published OneWeekWebsiteList.html into my blogpost, somehow, in a way that would save me from updating said blogpost every time I modified the original file. I found the embed element in the HTML5 spec to be a simple solution. Presumably there's some way I should have done this with PHP or scripting or one of those things I don't know how to do yet.
• So, one properly sized embed element and a div element with simple border later, the list mostly worked as dynamic content. 

Unfortunately, I couldn't discover until after publishing that the embedded HTML file doesn't display in Google Reader. It's visible in the RSS feed itself, so the problem comes somewhere in the aggregator?

I would love to hear about better solutions to this problem, as I just went for the first option I could find in the interest of moving forward. I've also just now switched to an object element, since embed seems to be intended for non-HTML content. Any thoughts?

One Week Website

ow, in all fairness, this was a very optimistic concept on my part. I can put together a decent looking personal website in a week, no problem. Getting through the entire process I've outlined below, blogging and documenting each step, including research, references, background, backend, comparison shopping, self-analysis and content transfer? Not so easy.

The idea, however, in documenting the entire process is that I, and anyone else who cares to poke around, can review my notes and see the progress I've made and the time/effort I put in to doing a relatively thorough job. Thoroughness might actually be a fault of mine. I have a need to understand everything about a topic, to understand how the wheel works before I drive the car, etc. I can't just install WordPress (WP) and go with it, I need to understand how the backend works, how my data and files are structured, how I can query that database, and why that form is the right choice for me.

This means my initial process is slower than would be ideal, but I think the payoff in the long run will be greater. I have learned to let some things slide for the time being, marking them to revisit later when I have enough background to understand them better.

First, I need to figure out how to track this list. Do I want to Gitify (version track) it? repost at the end of each sub-post? certainly link back to the original list with each execution of a list item. It seems like a version-tracked version I can update and reference would be best... without having to republish every time I make a change. So I'll have to embed the list (published github page) itself:

ps. Yes, this looks ghastly. I need to publish and then iterate. I hear this is a thing you do.
pps. I see the embed doesn't work in Google Reader. Will have to figure that out, too.

A Bountiful Update

gnoring the many iterations of the issues mentioned in the previous post that came up in the process of attempting to put together this post, here's a few more recent photos of one part of my garden. Somewhat recent. A few are from as early as March, when the bulbs had just started blooming, others are from mid-June, when the veg really started getting bushy.

I may regret hosting these photos on my own domain in a week or two when I find a longterm solution, but heck, I wanted to get posts up. The next post might just go back to using Picasa for sanity's sake. The entire blog may move as well, to make it easier to reference various directories.

...But this is a gardening post, and I digress.

These are dated photos, so just know there's more growth, plus a second bed of veg not to mention a third bed of herbs. As soon as it's not so terribly hot the stack of bricks (all found in the yard) will become a small patio...

Technical Testing Tribulations

ay back in November I finally staked my claim on a corner of the internet by registering and hosting a website under my name. I had stalled for almost a full year, thinking there was too much I would want to research before pinning down a registrar/host. Turns out that was the easy part (once I realised I didn't need a slew of dedicated servers in the former Soviet Bloc).

After choosing DreamHost at the recommendation of a friend and a popular website (Lifehacker, who recently re-affirmed DreamHost's dominance), all I had to do was learn how to code an entire website. And not just any website, one that would display a photographic portfolio dynamically and interactively and [buzzword] and [so on]. Ok, so I haven't quite gotten to that part yet, but the site exists and is a decent placeholder.

The holdup is that I'm the sort of person who can't just throw up something pre-fabricated and call it a day, I have to learn how to code the entire thing myself, learn databases and cascading stylesheets, from scratch. Maybe once I've done that I could take an easier route, but without understanding the background it seems too much like cheating. Besides, most of the point was giving myself opportunity to learn, given that my photos probably aren't going to start flying off the shelves (there are some up, but they, too, are placeholders).

So in the meantime I've just been using the web export feature in Adobe Lightroom (a god-send for those of us who like cataloging, integration with other applications and services and powerful but simple tools). The problem I'm leading up to is that I'd like to stop hosting the photos I use in blog posts on Picasa and move them all over to a dedicated storage folder on my website. Heck, someday I should move this blog there, too.

The problem is that to use a photo in a post, I need to have a link to the .jpg file that will never change, or at least use a relative link to just "/kitten.jpg" rather than "http:// blah/folderA/section56/kitten.jpg" and so on. So that's one solution. But I also need the photo to link to a gallery view on my website, so that the clicker can browse through other photos from my blog, and also use spiffy navigation controls to browse by keyword or just mosey back through other parts of my portfolio.

I'm not going to list how much of that I have no idea how to accomplish, because it's too overwhelming. But, I've written an entire blogpost about it now, so that will hopefully motivate me.

Oh, and the reason there are random photos of pie here is because they're hosted on my website, just... not very sophisticatedly.