Getting up to speed on CSS tools

I did this backwards. It should have been mixins, Sass, Smacss, Compass, Singularity. Then again, sometimes starting and the end and working your way back lets you see the bigger picture and understand how it all fits together. Says the girl who started Drupal with core contributions.

Singularity (compass extension)- ratio-based grids (quick walkthrough video here), very easy to make different widths $grids: 1 2 3 2; Also can use px, pt. Integrates with breakpoint- add an @include breakpoint(30em){@include grid-span(2, 3);}. Very cool, super easy way to get responsive design out fast.

Mixins-  A mixin is an at-rule used to define a ruleset than can then be *reused* in other rulesets. Yay reusable code. I think mostly as a n00b I'm always surprised when things like this aren't a given- it makes perfect sense to be able to define a thing and then plug it in wherever you need that thing. But is this the same thing as the mixins Compass is using?

/* define a mixin */
@mixin .muffinstyle {
display: inline-block;
background-color: blue;
}
/* use a mixin */

p .bakery {
include: .muffinstyle;
border: 1px solid red;
}


ok, Stackoverflow question on the CSS at-rule here. So basically anything preceded by an @ is an instruction for the user agent, rather than styling rulesets. I've been using @media, @font-face and so on, but hadn't really thought about the construct itself. Here's MDN on at-rules and W3C on CSS syntax (this one's really helpful). There's a very handy graphic and description here on CSS statements and their subsets, at-rules and rulesets.

Compass- Ok, so there are CSS mixins, then there are Compass mixins... which are just a predefined set of CSS mixins? oh. And then Singularity pairs with Compass. I get it. /several hours of digging and reading later.

Sass- This also makes all kinds of sense. Things like variables to hold info in a more logical spot while you're writing, then output a fully fleshed out CSS file at the end. Saves on typing, mistakes, and again with the reusable code. Compass is for writing Sass. Got it. Wow, nesting. So logical, so tidy. Ah, and we're on the new version that uses curly braces, which seems a lot better than just indenting anyway. I do not generally approve of dropping semi-colons and such even if it *is* more minimalist.

Smacss- I really appreciate this- organizing, categorizing, approaching css in a logical fashion rather than throwing properties left and right and hoping it all works out. See my next post on approaching a problem, too. I might disagree with a couple things Snook says (and this book is a little old already), but his general point is spot on. I think this will fit into my brain even better after my next two or three tabs, too... Things start getting interesting once we drill down to the "module" level. Goals: increase semantics and decrease reliance on specific HTML

Next: More depth from Legacy CSS with Sass and SMACSS and modular SASS development using SMACSS and BEM.

In other predictable news, something here needed homebrew to install... I think it was a Ruby update. I have Ruby 1.8.7, but would like to have the current. Probably doesn't matter. But I think to update I need homebrew and homebrew last I checked needed xcode and 10.6.8 does not the xcode have. BUT. I think I can install the sass/singularity/compass package with just ruby. I hope. Later. Not now. Because this is always ridiculous, and generally why I'd rather stick with simple, low-level stuff.

Next: Creating a Drupal 8 Theme with Sass, Singularity & Breakpoint

Comparison of Arrays, briefly

So. Everything is an object. That was js, right? An object can be an association between a key (name) and a value. Which makes an object sort of an array, right? Because an array is a collection of key:value pairs. If key is a name, that's an object, if it's an index value, that's an array. Key:value pairs. Yep.

Examples from things I have some familiarity with:

JavaScript array creation:
var myArray = ["element1", "element2", "bunnies"];
console.log(myArray[2]);  
//prints "bunnies"

jQuery object (more than just an array):
var divs = $("div");
console.log(divs);  
//prints "[0: div.container, 1: div.logo, 2: div.content...]"

PHP:
$animals = array("dragon", "giraffe", "hedgehog");
echo $animals[2];
//displays "giraffe"

Python Lists (mutable, homogenous):
>>> colors = [['blue', 'red'], ['sage', 'vermillion']]
>>> colors[-1][0]
'sage'

And Python Dictionaries (essentially objects/associative arrays):
>>>dict = {'nonfiction': ['Pollan', 'Berners-Lee'], 'fiction': ['Tolkien', 'Asimov']}
>>> dict['nonfiction'][1]
'Berners-Lee'

And Python Tuples (immutable, heterogenous):
>>>tup = ('a', 3, -0.2)
>>>tup[1]
3

Java (fixed length):
String[] rabbits = {"fuzzy", "hoppy", "ears"};
System.out.println(rabbits[1]);
//prints "hoppy"

C (Closest to Java. Info from Learn C the Hard Way. I hadn't touched C before today, forgive me.):
main(){
char name[] = "Petunia"; 
//creates array of chars {'p', 'e', 't'...etc}
printf("name is %s.\n", name);
printf("or also %c %c %c.", name[0], name[1], name[2]);
}
//prints
name is Petunia.
or also P e t.

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

Learning is easy, doing is difficult

veryone knows this - the potential for failure increases with the amount of work you're doing. What I need to keep in mind is that it will also plateau and decrease as I gain experience and skills over time, and that it will take time to get there. Patience is not always easy.

I learn by winging it, charging into a project and trying to do everything right away. Once I figure out that I can't bulldoze my way through, I start getting a sense for what I need to know, then I can backtrack and fill in the gaps before going forward or finishing up. It's not necessarily a great strategy, and sometimes leads to excessive frustration and going in circles, so I try to recognize when I'm just wasting time beating my head against something.

One of the things I thought I should do before I get too much further is just to go through some of the basic and general documentation for Drupal, so I have a better sense of how it works on both the front and back end. Sometimes when I start thinking I've got a hold on things I just glance over at the #drupal-contribute channel on IRC and feel humbled. Anyway, some disjointed notes:

Understanding Drupal- the basic stuff, explaining the system from the front.
Drupal 8.x API reference- all the stuff I've felt clueless about; hooks, menus, useful things when you're poking at core.

I had a poke around DrupalSites.net to see if anyone had something like what I want to do... no luck. Mostly I need to be able to use taxonomy terms on photos and blog posts (and whatever else I may add) and be able to search, sort, combine, filter etc for browsing (hello Views, my new best friend). And I'd like to be able to upload and update directly from Lightroom. I have a Lightroom plugin that lets me upload to Picasaweb and update files remotely without having to touch the site itself. So that's most of my needs, apart from some static pages for "About" and whatnot (see previous post): Taxonomy and ease of upload/modification.

...And someday, e-commerce. At that point, possibly authenticated users who can create little albums of my photos, save and share combinations that explore how each photo speaks to another through composition, color, subject, mood. I'm seeing this with draggable stuff, a large "desktop" where "prints" can be moved around freely, just as you would when laying out a gallery show using contact prints. But that's all someday. Maybe not even until after the D8 release, so going backwards to a D7 site would just flatten my little brain.

Cron jobs- at last I know how this works in the filesystem. (I'm less sure why I kept the bit below:)

• status: A bitmapped field indicating the status of the file. The first 8 bits are reserved for Drupal core. The least significant bit indicates temporary (0) or permanent (1). Temporary files older than DRUPAL_MAXIMUM_TEMP_FILE_AGE will be removed during cron runs.

All caps is a constant?


I plucked out a new task from the queue for myself, since it looked pretty easy and writing documentation is always a good way to learn more. While I'm in the API docs, I thought to check out how hook_help() works (keep in mind here that I know zero PHP, only some jQuery, and a bit of JS generally). Now I not only have a better idea what I'm trying to write for views_help(), but I have context for understand how hooks work. whee! I've only drafted some text so far, but might go ahead and make the patch so it can keep moving forward. 

There's a doc for writing the help text itself, but I still need to figure out/understand what exactly output=. does and if there's a more sensible way to deal with the translation bits t() than adding them in by hand, not that that would be super difficult in this case. Maybe somewhere in the Multilingual Support docs... Localization API? ah-ha. Well again, at least now I sort of understand all that. 

I think that's enough for one post, more later!

An Introduction to jQuery [notes]

inally getting on to actual jQuery! This about sums it up: "...we can use jQuery to perform its core functionality: getting some elements and doing something with them." All this reading is well and good, but I need to actually be querying and scripting in order to really understand. Therefore, I think it's time to go back to Codecademy for the jQuery lessons as soon as I read through jqfundmentatals.

The jQuery Fundamentals page links to the CSS2 spec on CSS Selectors, but there are some changes in the CSS3 spec. Memorizing the spec details isn't the most critical thing for me right now, and I have a pretty good grasp of combinators and pseudo-elements, IDs and classes.

The trouble with W3C specs, of course, is that user agent (UA, aka browsers) implementations may vary. Pseudo elements: I should try out :first-letter for drop-caps (though it wont help with my image drop-caps).

Q: So what exactly is a jQuery object? What does one do with it once it's created? Where is it stored and what is its lifespan? Backing up slightly, what does a regular old JS object look like?

A: As usual, I'm complicating things. Your generic JS object looks about like the code below, using literal notation to make the comparison easier. "All objects in JavaScript are descended from Object; all objects inherit methods and properties from Object.prototype, although they may be overridden" (MDN reference) "Objects are a collection of properties, and properties are associations between a name and a value"(more MDN). If a property is a function, then it is a method for that object. Pretty much everything in JS is actually an object. (see also: prototypes and classes)

var Bunny = {
ears : "long",
tail : "puffy",
hop : function (height) {
console.log("Hopped "+ height);
}};

The jQuery object is a JS object in that it stores elements and has methods, but it is an array-like object that just lists the DOM elements from the query. An array-like object has key:value pairs, but the key in this case seems to just be the index.

var a = $('div');
console.log(a);
/*returns from my blog homepage, more or less:
{
0: div#navbar.navbar section,
1: div#Navbar1.widget Navbar,
2: div#navbar-iframe-container,
3: div.body-fauxcolumns...}
*/

The jQuery object can be stored as a variable, or just called once and used, otherwise it disappears after use (?). I'd like to better understand memory and troubleshooting leaks (StackOverflow discussion). Basically, it looks like as long as there's a reference to an object, that object has memory allocated to it.

"Truthy" and "falsy" are a little ridiculous sounding... what's the difference between those and just true/false? Anything that evaluates to True is truthy, to False is falsy, but there are other possible evaluation results as well, like NaN, undefined, null, and any number of things – these are not specifically True or False, but they have trueness or falseness ascribed to them. It's descriptive instead of referring to the specific True/False booleans that you might return. This short article from 2011 explains it much better than I am (and I like his zebra).

Helpful tidbits:

• $() is a function. Functions in JS are objects and have methods and properties. $() always returns an object, and objects are always truthy.
• $( 'li' ).eq( 0 ).is( '.special' ); to find whether the selection using .eq() to select a specific single{ element matches the parameter in the .is() method (selector, DOM element, jQuery object, function); returns boolean.
• Use getters and setters (methods) to do things with jQuery objects. Iteration over elements can be explicit (.each();)or implicit (.html();), and you can chain methods together on a single selection. 
• Then we also have filtering, .not(); .filter(); .has(); on selections, which are more or less "without," "within previous selection," and "contains," respectively. ...many more methods here in the top hit on Google for "jQuery cheatsheet" (includes CSS selectors!). I'm a visual person.
• Plus, find other items/make other selections relative to a previous selection with things like .children();, .next();, .parent(); etc and add to existing selection with, by george, .add();
• More on how to use jQuery in the context of your basic HTML page here from the jQuery folks.

That's probably enough for now. I have a bit more of the jqfundamentals page to read through, then back over to Codecademy, then moving on to "JavaScript: The Good Parts." Please comment if you notice something I've got wrong or that could use clarification.

Drupal dev env sans MAMP... almost

nother day, another blip on the learning curve. Today I attempt to set up a local hosting environment without using MAMP. Unfortunately, it looks like the doc regarding this manual set up is from 2008, five years and several OS updates out of date, which means I'm winging it, finding new directory paths, etc. At some point later on I may spend some time updating the documentation for all this, but not until I have a full grasp myself.

I'm going to start back here with requirements again, while looking at the manual setup of MySQL and PHP mentioned above. So I'm also looking at this manual setup blog post over here, which should at least point me in the right directions. Managing databases from cli (command line) is not really what I wanted to be doing here.

1. Apache server. Got it, version 2.2.22. Comes with OS X, all I have to do is turn on web sharing... which I seem to have left running and should probably turn off more often. Configuration is in httpd.conf. It's apparently very debatable just which httpd.conf file I should be working on, or whether I should use a separate file like username.conf. Either way, they are here: /etc/apache2/httpd.conf or /etc/apache2/users/username.conf This part I did previously with /Applications/MAMP/conf/apache/original.
• Question: what exactly is this /etc/ directory? Heck, what are all these invisible directories? I really don't know how the system works that well, and Mac OS obscures all the useful things from the average user (eg not me, who somehow permanently turned on "show invisibles." Wish I remembered how...)
2. MySQL: downloaded, install... fix socket? can't find mysql.sock? Oh, initialize grant tables, maybe that's what I'm missing. Need mysql user? Checking that with dscl. Find proper PATH for bash profile, think I got that. Also checking info on MySQL site here for security and initial setup. And here to get mysql OS user account set up? But then that's outdated too, and the data directory is actually /usr/local/mysql/data. And I can't get mysqld_safe to work either. Ok, permissions are wrong on my error log? checked using shell> ls -la /usr/local/mysql/var, but it still says permission denied. And I need a mysql connection extension thing? mysqli? GAH. Alright, I give up. I can connect via cli to MySQL if I turn it on in the prefpane. Not a clue about that extension though. 
3. Attempted to use Homebrew, but it turns out that it needs XCode, which is only OS X 10.7.4+ and I'm on 10.6 something. At this point, I would like to upgrade, but, more software costs...

Then checked back on the original issue I was following that was messing up MAMP, and it seems there's a patch that fixes the issue, so provided that works, I'm back to figuring out more of Git, rerolling, and possibly creating patches. All of which is really not that difficult, but these background headaches are pretty killer.

And I got my Drupal install page back up, just had to reset my MAMP port to 80. And thank goodness, configuration goes smoothly, no more errors. So the lesson here is that I need a backup server/db environment and more knowledge of how to configure the whole shebang. I'll work on finishing that setup some time when it will be a challenge and not a headache. 

Now on to more patches! yay!

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. 

Local/Drupal: complete!

k, picking up from where I left off yesterday - configuring and finishing the local install of Drupal. References: dev env set up page and installation/configuration instructions. Instructions focus on command line tools, so that's good. Thank goodness I had already installed Git and know a few Unix commands or I'd really be behind the curve on this.

1. Neat, here's a handy list of best practices for CMS usage. Completely agree about backups, and definitely need to test mine for the WordPress site I'm maintaining. ...Documentation can be such a rabbit hole; if I don't stop myself I'll just keep reading for hours.
2. First we check system requirements, which I already looked at yesterday. Double checking in more detail now. I will want to enable clean URLs on my own site later on.
   • Web Server: Apache, check. Apache Virtualhost configuration file would be httpd.conf, I think, so I change the AllowOverride to "All" there.
   • DB server: MySQL is what MAMP uses, with PHPMyAdmin, so I should be set there. Not sure how to check what rights my account has or how to change max_allowed_packet, so I'm hoping everything just works. And my PHP is obviously already connected to MySQL. 
   • Good lord I wish I knew what I was doing.
   • Might need to up my memory for my own photography site later on. Maybe by the time I do that, I'll have plenty of experience and it'll be straightforward.
   • My favorite words today: "Enabled by default." 
   • On the bright side, I feel pretty confident about my skills once I have things installed. It's just finding all the configuration files and prying out info about new systems that's challenging.
3. 
   Download instructions not relevant, already have the local directory and Dreamhost has its own instructions that I'll use for my site later. oop, actually I do need to drop the Drupal folder contents into my specified web root, or just redirect the web root. I "woohoo'd" when I saw this in my browser. A little soon for the woohoos, perhaps.
   
   
4. Oh hey, Mac specific install notes regarding PHP, MAMP and other things from my last post. Whoops. Also this note on CVS repository... Question: is this relevant, and wouldn't the Git functionality supersede it? I should figure out how to keep my local version up to date. I bet that's later in the instructions... 
5. Looks like Drupal will create its own DB, so I'm off the hook for that... Might have to adjust settings.php, but I know where to find it, so I'll come back to this step if the install script throws an error. 
6. Checking my MAMP install against the instructions here. Hm. Well this is saying I DO need to create my DB (and here are those pesky user rights from above). hm! all these instructions overlap, so I'm just going to stick with this one, then check back on the INSTALL.txt instructions, and really everything should work fine anyway. Really appreciating the detailed instructions on this link for db creation (necessary or not). Found max_allowed_packet here, too. 
7. Annd filling out the db info on the install page... looks like I wont need much more from the help docs at this point, though I do wonder if I should do "minimal" or "standard." Standard makes sense for testing, rather than custom, right? right.
8. Ok, I think... I think that's done. I get the site login page, changed some settings as in the MAMP local instructions above, db works, only thing I feel stupid about is not installing in the directory I should have. Question: how could I move the entire shebang? What's connected? MAMP needs the location, but the installation script wrote a whole bunch of db links I'm not sure about. Not critical, just irritating to my file system.

And with that, I move on to the rest of the dev env instructions and start my first patch/module/test!

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

Overloaded - Journaling some progress

his will be a less coherent post than usual, just because I'm in process a lot sooner than I thought I'd be. Going back to my Grand List, the intent was that I would research several different CMS platforms (Drupal, WordPress, Joomla etc) before choosing one, or even deciding that a full fledged CMS was too heavy for my purposes. In an ideal world (I've been using "ideal" more lately. hm. Self-awareness?), I'd probably design my own database and create the whole thing from scratch. Since that would require being a db architect, it would take quite a lot longer than winging it in a CMS.

More recently, I had decided to go with WordPress, simply because I have some experience with it already and would be building on that, rather than learning yet another new skill set. I had been thinking that Drupal was the more sophisticated option, and that I could learn yet more awesome new things by installing it, but second-guessed myself into a corner. Really, WordPress has given me some pretty big headaches over the last couple of years.

This past weekend was the National Day of Civic Hacking. Within a span of four days, my whole outlook and project list merged onto a gigantic, fast-moving highway of projects, people, inspiration and busy, busy schedules. Now I find myself wrapped up in Code for DC, a project to map migration and DC school boundaries, hopefully getting further involved with Girl Develop It, and throwing myself at Drupal Core.

The big problem here is that every single thing I just listed has not just a physical group and projects, but Hackpads, Trello boards, Google Groups, Meetups, Twitter accounts, GitHub accounts, CKAN site, IRC channels, calendars, forums, websites and good lord do I have a lot of tabs open. I think I linked up with everyone from the weekend, signed up for everything I needed to... at this point I'm just hoping that anything important will ping a notification to my email, otherwise it'll be lost in the aether.

But back to Drupal. Let's just take a look at where I'm at, mostly for personal reference. I signed onto Drupal.org, and to DrupalMentoring.org. Joined the DC Drupalers meetup. Have [just] four IRC channels up in preparation for the Office Hours later tonight from the mentoring people (who I hope will be able to give me dummy points on installation and patches and link me up with an appropriately straightforward project [open issue]).

Some questions, having just read the Drupal overview here (front-end installation stuff) and nearly every other page I could find after that:

• Why XHTML?
• What exactly happens in terms of nodes, paths, blocks, users when a page is requested? How does the request play out?
• Wait, so bootstrap, which isn't bootstrapping, or Bootstrap? argh. But sort of like the WordPress Loop, yes?
• I've really got to learn PHP/more PHP. What are alternatives to PHP? How else can web pages be dynamic?
• So there are issues listed on Drupal.org and DrupalMentoring.org... how are they related? Same thing, different interface? (oh, I see, they're linked and the Drupal.org is the main page for info comments etc)

... a bit brain-dead right now, which is unhelpful given that the mentoring office hours are in... an hour!

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?

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.