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 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.

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]

My Dad Thinks Git is Just an Expletive

irst, reviewing some of the Git documentation. The Git book is probably my favorite piece of instructional material available on the interwebs today [that I use/have encountered so far]. Now that I've been doing some branching, checkouts, commits, etc, I'm feeling a lot more confident about this, but wanted to just skim back over things anyway. Also this Git cheatsheet is too pretty.

Some things to clear up:
: The R words: Rebase, Revert, Rollback.
: The difference between Fetch, Pull and Rebase.

• Rebase is actually a merge, I just happen to use it to integrate the newest origin/8.x into my local branch. Merge is a three way merge, rebase pulls in commits from another branch, rewinds your current branch and replays all the changes sequentially to get you back to your current commit with the other branch merged in. Mostly this makes things neater and erases the history of the working branch, making it look like you've been on the master branch the whole time. Easier to merge into the remote later, too.  
• Revert means to undo a specific commit without deleting it from the commit history.
• Roll back, on the other hand, is resetting HEAD to the commit you've chosen to roll back to. This deletes any newer commits entirely, taking you back in time permanently. I think what Git Tower calls Roll Back is git reset <commit>?
• Git Fetch only fetches an update from your designated remote. 
• Git Pull pulls that update down and merges it into your current branch. 

My previous questions about Git were things like: how do I use it to track a site in production? I was thinking I would install it remotely on my host and update there.  I think I should work on the site locally and then push up to my server. Haven't actually looked into that yet. This handy dandy bit of documentation on d.o (Drupal.org, I have gathered) should have plenty of info on Drupal web dev with Git. The most difficult things there will be handling the databases and figuring out why I need development, staging and production sites all up at once. I don't think I'm understanding the latter properly.

Now, all I have to do is get a super good grasp of PHP and JavaScript. Right. Starting with the JS and JQuery fundamentals here.

Then later, for fun, I'll poke around a local install of D8! whee! If I could figure out local hosting well enough I'd broadcast my experiments publicly using my handy-dandy built-in Apache server... but that honestly is a total side-trip that I shouldn't take right this moment.

TDL! Finish configuring local hosting capabilities outside of MAMP and figuring out site-serving capabilities. Also read more "history of the internet/web" books, because it fascinates me. Also find those studies referenced in Tim Berners-Lee's book regarding emergent properties of the www.

Drupal 8: Some things learned

ust a quick recap on my last reroll. A wonderfully patient mentor and I spent far too many hours poking at the comments and working back through the entire reroll to figure out exactly what was up. In the end, my original question got answered and some further clues were found in the issue comments. And, I think I finally got the hang of Git/Git Tower (thanks to the commenter on my last post, too)! It felt really good to be flicking between branches and understanding what was where. I need to further define all the "R" things for myself, Rebase, Revert, Roll-back... Just to get things clear.

• The first helpful thing was the discovery that I was rerolling from the wrong patch. #64 was the actual last successful patch, and #65 (which I had been working with) was just to correct a typo, but also introduced an unintentional error, which no one noticed until #81 posted an interdiff. Note to self: also be sure to add an interdiff when needed and other helpful things as YesCT suggested like links to instructions and better notes on exactly what I did. 
• One helpful mentor also pointed out that patches/interdiffs could be applied in reverse with curl https://...blah.patch | git apply -R
• It's also worth remembering to diff a rebased branch against your HEAD branch so you don't wind up with a diff file that includes all the commits between when you started your working branch and the current update of origin/8.x. If that makes sense. I wound up with a very clogged diff by leaving a branch a little too long.
• Glancing through the interdiff between #64 and #65 added in #81 helped me find the typo in question and then simply modify that file and run the diff. 
• The biggest problem, and my original question for office hours, was where to put the contents of a test file that had been wiped from 8.x in the intervening year. Eventually we wound up putting that chunk of the patch in a deeper testing directory, but I never would have known where to add it on my own. 
• The method my mentor used to find that test file I think involved searching for other pieces of the previous, now absent test file, where I had just been searching for the parts of the test file affected by this patch. Still not super confident about this grepping business and I feel like I've heard it belittled somewhere as one of those things newbies abuse/misuse. Could be wrong.
• Apart from that, the rerolling instructions were pretty spot on. There was a question of branching, and I think everyone just has different styles with regard to pulling down the most recent commits of 8.x and then creating a new branch for the issue you're working on, plus then a temporary testbranch to test the new patch on. 

I'm mostly not tagging mentors here so as not to be a bother/presumptuous/something, but I continue to be grateful for their patience and helpfulness and willingness to spend time bringing new people into the fold. ... resisting the urge to start singing Guys and Dolls here, though I once played one of the Mission Band members on stage.

Now moving on to a JS issue, and first spending some time brushing up my skills there thanks to some prescribed reading. I'm always torn about whether I'd prefer to read tech books on the computer or in print. Staring at the screen for ages gets to me, but a print book is too disconnected from the associated topics (and less searchable). I'll just have to take regular breaks to stare at my blooming sugar snap peas instead!

Drupal 8: Understanding the reroll process

ow that I'm trying to work on a slightly more involved reroll task, I'm coming up with a bunch more questions and some realizations about my workflow. First of all, I need to make sure to use my own time efficiently and not spend hours and hours trying to sort things out instead of taking a break and attacking a different problem. Secondly, I need to familiarize myself further with Drupal as a CMS before I have much chance of patching, rerolling and otherwise contributing to the open source project.

Also I badly need a better notetaking system because Blogger just lost my entire two page blog-post notes I had written here. @%#&! Text files, sadly, would be an improvement. I think I likely also said something about how to prioritize my time in order to become a highly useful Drupal contributor! This probably entails becoming more familiar with Drupal generally, working with it as a CMS, poking around the file tree etc.

This is the second reroll I've looked at, but the first to really be any fuss. Apart from sorting out the reroll system and infrastructure (which I think I've mostly got now), it's being able to parse the code on my own, rewrite it if necessary (?) and in this case update a year-old patch. This should actually be really easy, but I'm just figuring it out, so bear with me.

On applying the patch to the last commit it was known to work with, and then rebasing from the current version of 8.x, I got the following output. Only one conflict, which is nice. What do the lines marked "M" and "A" here mean?

$ git rebase 8.x
First, rewinding head to replay your work on top of it...
Applying: Applying patch from https://drupal.org/node/1008402#comment-5963414
Using index info to reconstruct a base tree...
M core/lib/Drupal/Core/StreamWrapper/LocalStream.php
A core/modules/system/tests/file.test
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): core/modules/system/tests/file.test deleted in HEAD and modified in Applying patch from https://drupal.org/node/1008402#comment-5963414. Version Applying patch from https://drupal.org/node/1008402#comment-5963414 of core/modules/system/tests/file.test left in tree.
Auto-merging core/lib/Drupal/Core/StreamWrapper/LocalStream.php
Failed to merge in the changes.
Patch failed at 0001 Applying patch from https://drupal.org/node/1008402#comment-5963414
The copy of the patch that failed is found in:
   /Users/E/Sites/drupal/.git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

If something is deleted in HEAD but modified in the patch, wouldn't that mean it isn't needed any more and should also be removed from the patch? Or else that chunk of code has been moved elsewhere. I'd like to just glance at the current commit for 8.x, but Git Tower doesn't seem to want to let me do anything without committing any/all changes in my working branch. That seems rather unhelpful, so perhaps I'm missing something about branch checkout?

Why does it look like the reroll instructions are saying I need to rewrite the code in question? I don't have specific experience/context for this patch, so not confident enough to really understand what's going on with it.

Some steps to clarify for myself before I move on from this:

• Understand output of rebase/apply above: M and A are pretty definitely "Modify" and "Apply," as I had assumed (other options were "Merge" and "Add.") "Modified" and "Added"! 
• Is file.test still in HEAD? Looks like no? There is no file.test in HEAD, from what Git is telling me. Unfortunately, branching is still giving me issues, and now I seem to have a stray un-named branch and some commits that Git Tower is hung up on. meh. Trying again... Appropriate commit to pull, should I lose things here: git checkout -b symlinks-old fe01ab6e16a73a
• Ah ha. Ok, so yes, file.test is no longer in core/modules/system/tests/, but it looks like tests have been sorted out a bit, so maybe that chunk of code is somewhere else. In theory, what should happen here is that I ... have 8.x to diff against, and a branch checked out for this reroll. I attempt to rebase in my working branch, and when it doesn't work, I ... add the bit of code that used to be in file.test to wherever it might be now, then git add (being careful not to add files.test back in to HEAD accidentally), then hit rebase --continue, then keep going with the reroll instructions.
• If not, did the code in this patch move somewhere else? What I did here was an attempt at using grep to search for a line from the file.test file anywhere in the tests directory. No luck. Tested my grepping (sp?) skills by just searching "symlink" and that pulled up a lot, but not the specific line from the file this patch was attempting to modify. So, looks like that test was just deleted/moved somewhere in the last year.
• Does that mean that the testing part of the patch is no longer relevant, or that it should be incorporated into a different testing file? This is something I'm not experienced with, so can't attack. Will add comment to this effect in a bit, once I double check that I'm not just missing something easy. The lovely mentors at office hours are great for nudging in the right direction.
• What does comment #61 have to do with this? #61 is just updating the patch to match the changes to the D8 test files, which seem to move around a lot. I had a look at some of the previous patch versions, and my previous bullet is definitely the case. I just can't be quite sure of where to put the tests, or where they went if I'm just not finding them appropriately.

::Take break for dinner and something not-the-computer-screen. I would've succeeded with the two hour task routine if I hadn't lost my notes. Really. Hoping office hours tonight are helpful and that nothing breaks this time (last Monday I spent 75% of the office hours mopping up a broken bottle in the pantry. sigh).

Some goals for this week: brush up on PHP, play with a functional install of Drupal as a CMS so I know what I'm looking at working on the backend. Kind of excited about using Drupal.

An attempted re-roll and several more hurdles

ssignment the second! With the help of Git Tower to tidy up my git messes, it's time to try out a re-roll. Or at least, futzing around with a patch until it works. This one was assigned to me during the core mentoring office hours, which meant it was already rather late at night. I couldn't work on it for at least 10 hours, so inevitably someone else had a whack at it first. Not a problem, always good to get things done, and I kind of like the competitive aspect there.

However, the posted reroll failed the automated tests, and a subsequent comment indicated that a single element was missing from that reroll that had (presumably) been in the previous version. Hokay. So where does that leave me? If it's missing just one thing, that one thing can be inserted and then tested again, yes?

Problems: I need to make sure I'm testing accurately, refreshing my entire local repo every time. I need to figure out exactly what is missing and where it goes. Update patch file. Test again. Upload. That seems easy, right? It's the technical details of how to do all that correctly and the first time that I get hung up on and unsure about. I need a lot of practice.

1. Actually, on this one, I'm going to take a close, side-by-side look at the two versions of the patch and see if I can isolate the missing bits, drop them in, and call it a day. This should also clue me a little more regarding patch structure. I get the concept and the diff and the +/-, but parsing all that together on read through will take some practice. Doing this manually seems to have worked, my patch applies.
2. Also going to try doing it this way, per berdir on IRC: "one trick would be to apply the previous patch over the current one with --reject, then the file should be added but all other changes would conflict and you can ignore them" 

And said patch passed tests and was reviewed affirmatively, so I guess it's ok. Frankly I'm amazed that things don't get broken more and that so many contributors are also patient mentors. Or my sample from the IRC is skewed, but I'm definitely grateful for that patience. 

Or rather, I'll try that second option as soon as I seriously sort out how to get my branches to work. Seems like changes I make on a checked out branch are still affecting my local head? That doesn't seem quite right. And meanwhile, 8.x doesn't seem to be working with MAMP anymore and I think that's enough for one night. Really looking forward to getting more experienced with all this.

Backtracking: Git review

ome time ago, I installed git and set up a repository or two for personal projects. My needs were limited to keeping track of what I had done and being able to backtrack if I needed to. Obviously, I've been vastly underutilizing git's capabilities, so today I'm going back through some documentation to brush up my existing skills and to add a few more, specifically checkout and branch.

Thanks again to Jesse, who walked me through branching and checkouts via screenshare on Saturday. Otherwise I had things more or less right: pull updates down, wipe db, settings.php, /php and /config files from sites/default/files. I'll want to set up a nice script to do this for me at some point. Note to self: seriously, list of things to do "later." Takeaways: get a GUI for git, test a branch/checkout, and "git is Sliding Doors." Loved that. Oh and try out Sublime. And find a budget for software. phoo.

1. Install a git GUI. Git Tower is reputedly the bestest, and in the interest of being on the same page, I think I'll just go with that. Free 30-day trial, yay. I do actually like command line, but for things like branches, it does seem like a more visual interface would be helpful to understand where I am. 
2. Get totally distracted by WWDC stuff. Lament not having every single piece of new tech as it debuts. 
3. Do some reading/research. Really should have gone through the Drupal Git Documentation earlier. Very helpful. This video on further git usage (sandbox creation, pushing, etc) will be handy later. Note to self: I need a way to differentiate between these learning posts, there's a bit of overlap. Might as well create an SSH key while I'm here... My interpretation of "Patch" is basically "structured diff merged into existing code." Seems very straightforward.
4. Start fresh with a new clone of 8.x in Tower, changing directory to user/sites/drupal instead of my documents/[complicated] directory. 
5. Test making a branch and checking it out - nice folder structure in the sidebar. Not quite sure about adding patches though. It seems to apply, but then I get a bunch of things in the status tab. So do I then commit those to my local branch? Does the curl method I've been using do both? Learning yet more software, I guess. Will have to work on that.

Later: reading through some tasks and instructions on drupalmentoring.org in preparation for tonight's office hours. Ask about task assignment and review. Figure out what the heck less and more are/do.

Drupal: Re-checking that last patch?

oday I went back to take a look at the patch I reviewed yesterday, and it looks like it needs a little more review. Unfortunately, by the time I got to it, I think the patch was behind HEAD again, despite a rerolling earlier in the day, but on my second attempt after re-cloning, it seemed to apply ok.

While I'm here, some notes on my updating procedure. I'd love to find some more streamlined notes on this, will have a look in a sec.

• The method I've been using is just to git pull (super minimal instructions) changes down without examining and merging (slightly more detailed, includes "what if patch doesn't apply") as individual steps. Git pull usually resets the install... I think. Or it did every other time I used it, but not this last time. Question: what's the best way to test that I've got the latest and greatest down properly?
• So since that usually requires a reinstall, I also have to wipe the db from phpMyAdmin in MAMP. 
• Apply patch using curl, check with git diff
• That seems to be it, then I just reconnect to the now empty db during the install process. Usually. I guess this update didn't change anything in that vicinity?

Supposing that I have the newest HEAD (I have gathered this is what the latest version is called) down, let me just make sure I have everything clean and fresh and double check that the patch isn't applying... wipe db, pull, patch. Nope-ity no. 

Time to learn something new! Or just muddle around and feel silly about things, we'll see. What to do if a patch doesn't apply: Applying a patch manually, copy error msg into issue, "re-rolling" and adding to issue queue. 

First I want to test if I get that error I found in my last post without the patch applied. Nice fresh copy, connect db, test. Error is still there. Question: Should I create a new issue for it, if I can't find it elsewhere? 

hm. Ok, now the patch is applying again. Maybe that was just me? And just pulling doesn't reset everything, so how do I uninstall in order to start over? Seems silly to wipe the whole thing and re-clone each time. Grah, ok, wiped sites/default/files/php and /config_*, ditched settings.php and replaced it with a fresh copy, reloaded. 

Retesting patch... only partially works. Noted as best I could on the issue, but am so uncertain about the quality of my testing environment that I don't trust my reviewing capabilities. There's got to be a better way to set up and test without having to completely wipe and re-clone, but just pulling doesn't always reset? Rather confused and going to bed. 

First Patch for Drupal 8.x

hew! Now that everything is set up, I'm back to the dev env page to get my first patch down, in, tested and confirmed. Hopefully I can get this done before someone else jumps on it. I kind of wish there was a check-out system for issues– oh I see, they're assigned, got it. So, here's my first issue for patch review: Remove drupal_add_css() from book.module.

Actually, step one: blink, get glass of water. Thanks to Jesse for plucking out a nice easy issue for me to start with and being so encouraging about my progress. 

1. Apply the patch: 
   • First, git pull in Drupal directory. Sigh, right, of course. Configure again. Argh, so now my settings.php file wont write itself. Whelp, no idea what that was about, but I fixed it by creating a new default folder. I think the permissions had gotten screwed up on the previous, probably my own doing? Ok, wiped the entire thing, re-installed, re-db'd, reconnected. 
   • Pull down latest version of the patch. Finally found more detailed instructions on where to download the patch to here, 'cause I wanted to be sure. Went for "curl http://drupal.org/files/[patch-name].patch | git apply -" Didn't get any errors, so that seems to have worked. 
   • Run git diff to see changes... shiny, looks just like the view from the issue tracker. Will have to figure out how to use git diff a bit later. Note to self: make list of things to do "a bit later."
   • hm, but if I look at the module code, I'm not seeing the second addition from the patch. ohoh, duh, because that's a deletion, not an addition. Right!
2. Enable the book module: Well that was easy, yay. This is, I'm a little sheepish to admit, my first time looking at the inside of a Drupal install. But look, the extend tab, logically, is modules, right? And then I just click this handy checkbox... The super easy, obvious UI is making me so happy. 
3. Put some articles into a book: Articles, or book pages? I'll do some of both. 
4. Verify that book.theme.css is still loading: tested by a) inspecting elements with Chrome dev tools, and b) using jQuery to find specific selectors in the dev tools console. Seems to work fine. Yay!
5. Set the issue to "Reviewed and Tested by the Community" or "RTBC": Done. Wrote a nice, hopefully brief enough comment detailing my steps and mentioning the error I got for an unrelated (I think) issue. [Any issues I work will be recorded on my Drupal.org profile (you have to have an account to see my profile, but this issue is here).]

That should be it for now. I'll have to go find another issue to work on next! Well, right after I know that last one went ok. And maybe do a little more reading on patches and contributions and things. 

.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. 

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.