Becoming a Drupal Core Mentor

t's finally time to start doing something I should have done long ago: mentoring new core contributors! I've spent a small chunk of time as a mentee, setting up my own development environment (dev env), finding issues in the mentoring queue and on Drupal.org (d.o), and interacting with other core contributors. While writing documentation and doing rerolls has been a great way to learn Drupal, the real rewards have come from working with other contributors. It's been a great comfort to know that I can ask for help on IRC, and can always find a mentor online during the core mentoring office hours.

And the bonus is that teaching others is the best way (for me) to learn things! So I went to YesCT for some advice on where to start. Here are a few resources she pointed me to (in addition to this big page o' mentor resources):

First of all, the most important thing to remember for everyone in the Drupal community is that "we are all mentors." This blog post from YesCT is pretty much what I was trying to say in para #1, but she says it better. Being friendly is the best way to encourage new contributors to come back! See also: WebChick's comic about her first encounter on IRC with "the Drupal Community on a Bad Day."

Next we have a key component of being a mentor: reviewing new contributor's work. This requires knowing how to review the contributor's work, and how to review a patch itself (to check that it was done correctly). Sticking with the theme of constructive criticism, gentle reminders, helpful pointers and other supportive input here. Teaching contributors how to interact and communicate with others is a great way to keep everyone positive and engaged.

As a side project, I'd like to help update dm.o and d.o to merge issue task instructions with the regular issue queue, essentially add functionality to the d.o issue queue. Todo for me: read through these related core mentoring on d.o issues. I had just recently noted that having contributor task instructions linked on d.o as they are on dm.o would be much easier than googling them every time I start work on a new issue. Turns out there's an issue for that! (there's also a google doc I won't link to here, but, note to self...)

Then we've got resources for planning a sprint, which I'd really like to do at a Drupalcon in the near future, but am currently lacking a topic to sprint on. If anyone needs a sprint co-leader, I'm happy to help!

Part of sprinting of contributing is going to be getting everyone set up with a local environment to work with. At an event like Drupalcon, or even something on a smaller scale, this can become problematic if everyone is downloading new software etc at the same time. So here are the Drupal Community Tools Download Instructions (dctdi. Tech is almost as bad as gov't with the acronyms). We've also got an Austin specific Core Mentoring page here and of course the perennial dev env setup page here.

Phew. So far I've had a look at most of those pages, but I need to go back and read the issues for dm.o->d.o as well as go through the mentor resources links thoroughly. It's just really great to have a specific goal and project to work on! I enjoy contributing on issues, but with the current D8 beta push it's been hard to find anywhere I fit in lately. Tallyho.

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!

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. 

Web Design Process: Yet More Lists

ll right, first things first. Before I go trying to put my website together willy nilly, I need a plan, a master list of desired components and functionality, and a general idea of how to get from here to there. Disclaimer: I have not actually done this before! I've worked on sites designed by someone else, I've done some super basic HTML/CSS work (like my pesky resume and my placeholder website), and I've certainly spent plenty of time thinking about it and reading and researching. So here goes:

Things I'd like from my site:

• A Gallery of photos: no commenting, prints for sale, easily populated (Lightroom export?), cataloged by keyword, location, highly searchable, and someday I'd like it to include interactive collaging
• About/info page: bio 
• Contact: email, links to me elsewhere like twitter etc, RSS for photos and blog?
• Blog: old posts from blogger + new posts, shiny layout, browseable, comments, share buttons
• Portfolio: other design work, samples, articles, projects, certificates, whatever else
• Someday: a sandbox area near the portfolio for projects in progress, something to do with Github? 
• Aesthetic: simple, lots of white space (or black space), nice OFL (Open Font License) fonts and thin lines, simple image display, good navigation, one animation/movement/interactive element on top page. 

The basic steps outlined below are a combination of my notes from several sources. I learned most of the prototyping and user-testing steps from a class called Human Computer Interaction taught online by Scott Klemmer from Stanford. Not my favorite class on Coursera due to some frustration with the peer-grading setup, but nonetheless informative.

I also discovered that a local web design etc firm called Clikzy Creative posted their entire design process to their site so that clients will know what they're getting into. My process will be a bit different, of course, but it's good to know how a more formal environment would handle the same task.

• Essentially: "Discovery, Site Map, Content, Wireframe, Mockup, Revise, Develop, SEO, Launch."

The Moxie Design Studio also has their process up on their website. They do a bunch of websites for local Alexandria businesses, so I had seen their work quite a few places already. They also list a general set of project prices on their site, which is somewhat unusual, but very helpful since I had no idea what I should be charging for my work.

• So again, an essential process looks like: "Discussion, Goals, Mockups, Revisions, Development and Programming, Soft Launch and Client Training, Full Launch and two weeks included Support." 

It's really hard being independent and not letting clients take advantage of you by asking "just a quick question" that actually takes half an hour and is billable. And that's just one reason I'd rather not work for myself!

Back to my own website. A few basic steps to get there:

1. Define required elements - site map (above)
2. Find appropriate platform
3. Wireframing, prototypes, mockups - grids?
4. Testing it on unsuspecting potential users - feedback and revision
5. Build, develop, whatever you want to call it
6. Design details/ illustrations? Finishing touches
7. Later additions: animation, better databases? E-commerce... 

Each step along the way will probably be a bit more involved, but that should give me a good starting framework to go on. Don't mind me if both my website and blog suddenly disappear while I'm shuffling things around...

OWW: Tidying up

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

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

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

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

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

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

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

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

Gitifying the OneWeekWebsiteList

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

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

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

Essential breakdown of Gitification of The List:

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

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

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