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.

In which I talk to myself a lot

More on setting up my first Drupal/Git/Drush site...

I've opted to ignore the multitudinous potential php settings for now, and am hoping things just work for the moment. Otherwise I'll keep procrastinating by fussing with server settings forever. I did find that my php version is easily changed by clicking edit on a domain in the dreamhost panel. And then my Drupal install moseys along much better.

If someone wanted to drop me a lecture/note about how I shouldn't be toying with D8 on a live server because [security] I'd actually be curious to know more.

Oh here we are, the php.ini wiki page for dreamhost: "We seriously aren't kidding about this" edition. Okay, yeah, still going to try not to mess with it for now. SO, moving along. Complete install using appropriate database. tum tetum.

Got hostname right, port default appears ok. Dreamhost phpmyadmin seems to have organized my dbs using the underscore I dropped in to differentiate test and production dbs. Hoping that's not a problem. Totally writing things to db now! whee. This is so nerve wracking, given how frequently things seem to break. Then I'll have to go back and clone to my root directory for my site, too, but not until I have something worth having up front.

meh, nuts. Admin menu doesn't display, just shows "array." Works fine on local. Maybe I'm not doing this quite right if things are that different. Also the whole thing is slow as all get out. oh, I needed to clear my cache. When did drush cc all go the way of the dodo? It's hard to keep up with a learning curve that keeps doing loop-the-loops.

ehhh I got distracted working frontend site building and haven't been keeping notes! I still can't get my search block to display, not sure why. Finally got my blog view to display the grid first by disabling the contextual filter (tho I'm still not sure why it was showing "3 2014" instead of "May 2014").

Now need to get my drush site aliases up and working so I can push the db up and see what happens. I suppose I might as well be doing my dev on my /test directory, since I'm not really doing dev so much as design. Heaven help me if I ever get to the theming part of the program here. At least my concept is super simple and minimalist. For now. Now where did I put my sketches?

Or I could just export the dang db and import it to the remote and deal with it later when I have slightly more time. It bothers me to do this the "wrong" way, though. Ok, export, import check. Then I just need to... definitely not the most elegant way to do this. Kinda broke things. Totally lost track of my git system. Maybe I should just get my site-aliases to work.

Note to self: fix things with chmod u+w. Finally got back to close to where I started by copying settings.php over. Somewhat easier to follow instructions for site aliases here. That plus the instructions in example.aliases.drushrc.php. 

Dreamhost specific Drush install instructions!? yes! ... no. That installs the old Drush, I need Drush 7, which requires composer, which requires that the php phar extension be enabled, which it isn't. Seriously, you've got to be kidding me. I just want to sync my database! Ok, got the phar extension working, though I *really* don't understand why it wasn't. See also (again) Dreamhost's wiki here on php settings.

Finally got Drush on the remote, more or less. So now running drush @test status locally at least comes up with a different result... "Drush 7.0-dev does not support Drupal" and "Fatal error: Call to undefined function conf_path() in /home/[me]/.composer/vendor/drush/drush/includes/bootstrap.inc on line 783" ...what? ok, maybe I need to do my alias a little different, can't get that until I run the install script again on the remote? Do I even remember how to do this part anymore?? ok, got drush site-alias @self copied, added to my drushrc.php locally, eventually got rid of a stray paren that was really messing things up, and finally drush @test status works!

... now I can try syncing my dbs. Which fails on the first try with "Error: no database record could be found for source @dev." erm. Ok, so both @dev and @test pass drush sql-conf. That's good. ...I'm completely at my wits end here. HELP.

And then I can set up an alias for my production site, which I haven't even provisioned or whatever yet- need to clone to site root, install, set up alias, and sync. Right? That should be easy at this point. ...right?

Eventually I will get to theming!

Useful bits of Drupal doc + site building init

Warning: contents are entirely stream of conscious/notes.

The best practices guide for Drupal has a lot of very important points to consider, but for my own technical edification, I'm focusing on just a few aspects. Handy list of core modules to become familiar with if not fully memorize, just so I grasp the breadth of Drupal functionality a little better. Right now I only know a few nooks and crannies! I'd love to do a big long workshop just to be taught, start to finish, how to build a basic site.

Read this next: Using test sites has some good starting points for setting up test environments, multiple servers, the sorts of things I need to be doing below (keeping test sites sych'd. synced? argh). I'll have a local install, then push to a test server (how to keep it private while being up with the same db/etc as my live site?), then from test to live. So the only problem is that my local dev env will be somewhat different from production. Forthcoming: post on Dreamhost's setup in relation to Drupal's needs. I've only posted my placeholder site up there with FTP and plain HTML files! No idea about dbs.

Ok, so. (don't even ask about that link, I don't know.) I want to actually develop my website. I want to do this with Drupal. Obviously.

Erm, or I could update my drush setup, instead. Went for a git repo this time, for my own sanity, but now apparently it needs something called Composer, too (Almost typed "composter." Guess where my mind is). I think it might be working now, hoping I don't really need to update all those php settings again. It's a wonder anything works, given how many configuration files I need to keep track of...

-Problem the first: Which version of Drupal? Do I go with D7 and have the benefit of contrib modules, established practices, lots of support? Or do I go with D8, which I'm at least as familiar with, probably more so, and get ahead of the curve and become more adept with what's to come? Keeping in mind that D8 actually incorporates bunches of modules that used to be in contrib, probably covering most of my immediate needs, but also keeping in mind that some things might still be broken, regular updates will be necessary, and the whole thing could break at any minute?

In my experience, breaking things is the best way I learn how systems work. Even though I know I'll have to rebuild bunches of times to compensate for my own learning and updates to core while it's in development, that will help solidify any new things I learn along the way. Too often I find myself figuring something out once, but then I don't run into the same situation again in my tiny bubble, so I forget it. Database setup, for instance. I need to get my head wrapped around how the DB works.

-Databases and test sites: Keeping local and test sites synchronized... using drush.
What is stored in the db? How does Drupal use its db? how is it accessed? Can I easily switch dbs? What would that be useful for? How do I move the live db back to stage and dev sites for testing? download a backup and connect? is there a faster way to get it re-connected, too? (drush!) Looks like I definitely don't want to use the same database for more than one instance of the site or I'll risk contaminating it with screwed up code. Probably reading the drush instructions for drush sql-sync will clear a bunch of this up.

What's a session variable, exactly? cookies?

Acquia cloud does this very nicely on its own with the drag and drop setup. Do I need a paid subscription to push to production? can I host my site somewhere that isn't Acquia and still use Acquia cloud? How much time should I spend playing with Dev Desktop?

What do I do on the backend v. the frontend? what will I use the CMS interface for, just content creation? Adding modules? Theming (this is a knowledge void for me right now)? Develop on a test, test the new thing, then install on the live site? What do I do frontend and what backend and then push? how much pulling should I do? I need to separate my creation phases (site building/dev and site maintenance/content updates)...

[TODOs are bold]

Drupalcon Prague notes

s one might expect, my lofty goal of watching the 20 or so DrupalCon Prague sessions I would have attended in person didn't quite work out... But here are some brief notes on the sessions I've looked at so far:


Frontend development; dancing on the tip of a hurtling rocket

This is almost verbatim why I wanted to be a librarian, and how I came to web development: "What we do as developers is provide content and provide access to that content. That is essentially the value we provide as professionals: There's information out there; we're making it possible for individuals out in the world to get to that content." -Jesse Beach

It's fascinating to think about how accessibility goals can be translated into more general applications later on. With proper DOM semantics and metadata the entire web could be twice as useful and useable.

From Not-Invented-Here to Proudly-Found-Elsewhere: A Drupal 8 Story
Alex Pott- This was marked beginner! I get the general gist, but the code examples were a bit over my head. Recommended reading on PHP- good, something helpful, recommended, up to date.

Drush Optimizations for Your Development Workflow & Drush- Do I Really Have To Use It?
Two sessions on Drush from Prague- One was all about convincing people to use Drush (already there, though not entirely clear on how it actually works with a drupal site... should, again, read the basic docs), and the other was adding Drush functionality to your contrib modules (so too advanced). Had I been in Prague, the "Getting Drush Installed" BOF would have been perfect.

Lisa Welchman Keynote: The Paradox of Open Growth
"Governance is about stewardship. It's about taking care of something." "It seems like it's really just for people who are developers. You could be more inclusive and welcoming" (slight paraphrase). Given that I know people try really hard with mentoring and so on, that seems unfortunate.

And then she brings up shape-note music as a standards practice! Crazy cross-over with my singing experience and hearing from my friend Lynn recently that she had just adapted (with her group) a traditional Chinese piece into shape note.

TBC...

In which I stumble over PHP

his post was originally just called "learning by doing," but then I was feeling so embarrassed about not recognizing PHP when I fell over it that I renamed it. This post is also on understanding the elements of hook_help() in general in order to write views_help(). Warning: contains questions that are not-stupid!

1. What does $output = ''; do, exactly?
This is most likely a PHP thing, which I have absolutely zero experience with. I know $ as jQuery, but now I'm not even sure that's what it's doing here. Yeah, that would be PHP- the $ indicates a variable. I've been avoiding learning PHP for the timebeing in the interest of focusing elsewhere without distraction, but a quick look through the PHP online documentation will help me with the syntax here. This explains why no one answered my pathetic pleas for explanation on this previously. I feel pretty dumb for not recognizing/thinking of this right off. The functions look enough like functions that I wasn't paying much attention to details, but... yeah.

So, question part B: why so many lines for defining $output? Why not in one big block? Is that just for readability, using a new line of PHP for what would be a new line of HTML? The first line $output = ''; is just initializing the output variable, or rather, defining it. Subsequent lines $output .= ''; are concatenating, or adding, those strings onto the previous definitions. Now I'm looking at coding best practices for Drupal and for PHP. This also spills over into question 2, below.

2. $output .= '<h3>' . t('About') . '</h3>'; What are the periods doing in there? 

The separation of html elements and the string to be translated makes sense, no reason to include code in translatable strings. The periods seem to be for concatenation of strings/elements in the $output variable, since otherwise just using = would reassign the entire variable.

In alexpott's Drupalcon Prague session From Not-Invented-Here to Proudly-Found-Elsewhere: A Drupal 8 Story, he recommends PHP The Right Way, which just happens to have a few more opinions on things than the standard PHP docs (new version in beta!).

In PHP The Right Way, we find a note on concatenation recommending that strings be kept under 120 characters, and that if they should be longer, to use concatenation operators (eg a period, . ) combined with indented newlines for readability. This method is recommended over using concatenating assignment operators (eg period equals, .= ). The example of what not to do looks exactly like our $output variable here.

... which means I found the right bit of doc! and that it's usually impossible to keep up with standards, best practices and the latest in code. Plus, I'm sure I'm still missing some reasoning and background here.

3. More on the translate function t():

In views_help() the translate function is part of the concatenated string assigned to $output. In point two, above, it marks the string "About" as translatable: t('About'). Whatever is inside the translate function is added to the database of strings to be translated into the current language from English, which is the standard. The translate function works with the Localization API to pick out which bits of text are translatable.

The Localization API seems to mostly do the work of targeting strings for translation either through a translate function or "known locations." The translate function identifies strings, and the Localization Server extracts them. You know, I'm a somewhat visual person, I just keep wanting maps for all these things.

EDIT: This bit from the Drupal JS API docs finally explains how the translate function works:

The Drupal.locale property works in conjunction with Drupal.t(), the JavaScript equivalent of the server-side t() function. It holds a collection of string translations so that Drupal.t() can then access the required string from Drupal.locale in order to translate what was passed into it.

4. What are these link tokens? ! is preferable to @?

After my preliminary expectations of easiness on this one were doused, I think I at least determined that this is not the same sort of token as the generic placeholder substitution token. It seems that instead of just using <a> tags, links are created using link tokens and an array. Previously, the links were marked with @, but from a comment on the views_help issue I've gathered that ! is the new @. Perhaps this is another PHP thing. Perhaps I will just go read my PHP books now and call it quits on this blogpost.


Read next: Working with JS in Drupal

And in the meantime: watch session slideshows from DrupalCon Prague! I'm so happy these are available.

And also, finally went to do something with Drush and found it not cooperating, so now I need to backtrack on that, put it back together, and hope that the latest version is really the right thing for D8. Oh, now I really feel dumb. Should have watched this session from Prague first, too. Somewhere in the process of downloading the latest, adjusting .bash_profile and connecting to the example aliases file, I broke it even worse. And creating a mysql file somewhere to cooperate with MAMP.

All this is in the notes on the Drush github page, of course, but after a while I just started feeling like a complete moron. Finally figured out that drush self-update is no longer included (I must've had a much older version installed earlier, not sure how/why), found a drush cheatsheet, and managed to uninstall my modules, check my modules, reinstall... I think I've got it now, but jeez. I keep getting stuck between versions, missing important documentation and feeling really lost, which is incredibly discouraging because then I can't even begin to do simple tasks. Hopefully if I just keep chugging along it'll all work eventually.

.ignore: Setting Up Local Drupal

y blog here is just going to be very dry for a little while as personal notes/documentation, apologies for that. Once I get some things set up I can filter tags/categories and have sections for tailored subscription... but right now I just need to set up a local install of Drupal 8.x (d8). There are instructions here on Drupal.org on setting up a developer environment (dev env), but I needed a few more steps along the way.

I would have very little idea what I was doing, even with all the documentation, if not for the Drupal Core Mentoring Office Hours, and particularly the very patient help of YesCT on the #Drupal IRC. I will definitely be back for the next office hours session I can get to. And... thank goodness "there are no stupid questions," 'cause boy are some of mine... non-stupid.

1. The above link includes some requirements for the dev env, but I needed to check a few background items, like PHP, to make sure they also fit the requirements for a Drupal install. Step one, actually, was making sure I had accounts set up on Drupal.org and DrupalCoreMentoring.org. I was also pointed at issues for the d8 dev env here, just in case anything listed there would trip me up along the way. 
2. • The one thing from the dev env list I was obviously missing was Drush, which isn't immediately necessary, but I figured I'd get it out of the way. The best way to install for d8 seems to be a git clone from the Drush project page, then following the instructions in the ReadMe to check that it's "using the same PHP as the web user." Question: Is that PHP version, settings, .ini file? 
   • It looks like typing "php -v" in the shell gives me info on whether it's the CLI variety or not (I'm not going to fuss about understanding that completely right now). 
   • Finally found more explicit instructions on command line install of Drush here. The video is the ultimate answer. 
   • However, got this error: The following restricted PHP modes have non-empty values: [error] magic_quotes_gpc. This configuration is incompatible with drush. Please check your configuration settings in or in your drush.ini file; see examples/example.drush.ini for details. Argh. [turns out there's an easy way to turn magic quotes off. oh well]
   • Ok, so then I go to example.drush.ini in the drush install directory and follow those instructions... Turns out my local PHP is out of date, hence magic quotes (deprecated a while ago). Installing new PHP and god-help-me configuring it. 
   • And back to the Drush ReadMe, I added an export PATH to my bash_profile specifying PHP 5.4, although MAMP is on 5.4.10 and command line PHP is 5.4.12... CL PHP ini file is at /usr/local/php5/lib/php.ini, MAMP file is at /Applications/MAMP/bin/php/php5.4.10/conf/php.ini
   • I want matching memory_limit 512M and time limit 120 seconds in both files, I think. Not sure about what this step is referring to, so hoping it's these two files, not that I should have just one .ini file. Changed memory limits to match. Question: where is the time limit? script execution or input?
3. Not a clue where I left off... I think the next step is getting my Drupal from version control via git clone.  This really ought to be easy... downloaded just fine.
4. Then adding the Git Deploy module. hm. Doesn't appear to be released for 8.x. Question: Do I need Git Deploy for patch work? 
5. Checking back on the dev env page for configuration and other steps... Just need to install? Will have to do that tomorrow.
6. Then that should probably do it, and I'll leave the rest for tomorrow. I think the next steps are finding a project, and I shouldn't need to mess much with this install until I have something to test.