Category: drupalcon2015

I spent Friday morning/midday at the Mentored Core Sprint. It was a weird mix of extra-hand-holding and being thrown in the deep end, at least for me. I had 99% of my environment set before I got there or in the first 10 minutes: I already have a Git client (yay Tower!), and since I was up at 5:15 am AGAIN that morning, I went ahead & installed MAMP, then installed Drupal 8, so when I got to the sprint (early, see also 5:15 am) all I had to do was clone the main Drupal repo in Tower, install Chatzilla, and rediscover that my nickname was already registered. (Thankfully using an old default password.) I couldn’t get xdebug working, but got told that wasn’t strictly necessary.

But then…I don’t anything about applying patches. I don’t have object-oriented programming experience. I do some PHP, and I can usually work my way through it, but I’ve realized that in the Drupal parlance I’m a site builder, not so much a developer. And I was in a giant conference room with probably hundreds of other people, and really really really nervous about doing something wrong.

What I probably should’ve done was find the documentation team and offer my wordsmithing skills.

What I actually did wasn’t too bad, though. I found a bug in Views tagged “novice” that actually just needed someone to see if a bug was still a bug. So I walked through the steps — which also meant creating a new content type and fields in Drupal 8, and getting the hang of a few different parts of Views that I haven’t used much — determined that the thing seemed to work as intended, and posted some screenshots to the issue. I’m pretty proud of that, TBH. It was an environment that managed to simultaneously trip both my “student ahead of the class” thing and my “fake programmer” anxiety. And yet I did a thing, on what was marked as a Major bug.

After all that, and a little lunch, I was all the brain fry (did I mention 5:15 am?), so I did a little work-related stuff. But before I took off, I went to one of the organizers to say thank you. Because whatever was not quite right for me, it was pretty amazing that all of this was happening. She asked what I’d done, and I explained it, and she wanted me to get up and say something. Which OMG NOPE. Still, she gave me a couple of stickers, which ok, I’ll take that.

With that, me and my luggage were off away from DrupalCon. It was a good week. I feel like I managed to balance on-time and downtime, meeting people, catching up with people, seeing a few sights, and knowing where my boundaries were. I only went to two parties, and that was PLENTY. (It’s kind of reminding me of some SxSW experiences, and I feel ambivalent about that. I really wish there had been a game night or something. If I go again in the future, I WILL organize one this time.) I learned a bunch, and also created a bunch of mental bookmarks: things I need to come back to and explore in more depth on my own.

[context: at some point Google Site Search is probably going to be prohibitively expensive. is this a good alternative?]

Lucene is an underlying search technology, from Apache, in Java. Same as Solr.

big diff from Solr is that it’s clusterable? is that something that matters for us? I’ve no idea.

also, I have no goddamn idea what they’re talking about now.

solr-vs-elasticsearch.com

“if you just want to search all your nodes, use Solr” ok then. (esp better integration with Search API?) so there’s that, I guess that’s the super-short answer to my question. not that there’s not super-neato stuff in Elasticsearch, and who knows, maybe by the time we price out of Google Site Search (does _that_ work with Search API) it’ll be ready for prime time.

undoing delete?

problems with concurrent editing

the issue of distributed content generation

….

demo of a module for D8 — I’ve already forgotten the name. [nb: Multiversion]

tree showing split “revision tree” when editing in two sites that are supposed to be in sync.

[so is there a D7 contrib module that works like Cascade’s Recycle Bin? because we use that all the time.]

the speaker’s notable modules are UUID & Deploy? which I should probably look at both.

oh wow this gets complicated fast. and this might be going over my head a bit. :\

some in-session researching:

how does Deploy play nicely with Workbench Moderation? Does it?

for Recycle Bin like functionality: see Killfile?

this is all quite high-end (the advanced level was quite correct) but it’s fascinating.

{oh I just heard Greg.}

this question: ow my brain.

forward revisions? O.o — oh, like Scheduler, or Draft in Workbench Moderation.

Right now I feel like I’m gonna need a week with a whiteboard and a brand-new Drupal installation.

I’m not 100% sure if this applies, but it’s intriguing since Justin is already using Grunt for CSS & JS tasks (compiling SASS, minifiying, etc).

I really wish DrupalCon were set up like Confab in one very specific way: I like having a table to set my tablet/notebook on for typing. The height of these chairs combined with the height of my legs means that it’s quite awkward typing on my lap, the whole thing wants very much to go head over heels and fall off of my lap entirely. Then add in the knitting, which is mostly helpful in listening, but it’s hard to have ALL THE THINGS in my lap simultaneously. Confab’s setup with rows of tables was so much nicer than just rows of chairs w/out tables.

what about testing that’s more than just “clicking around” (I guess that’s the point of something like behat?)

what ARE D’s tools for deployment?

Grunt Drupal Tasks

“it has opinions”

Gadget “easy to start a Drupal project with Grunt Drupal Tasks”

feels very rabbit-hole. I’m not quite sure I get what’s going on, but maybe… actually, Justin might like that for that other thing he’s thinking about….

actually, I think I’m going to try this, if I can get Justin to help me get Grunt & Yeoman set up.

but omg sleeeeeeepy.

this might not be related, but does Hobsons have an API that we could connect with for building forms?

separate Grunt file for the theme — sort of like what Justin does now?!

again: what would it be like for the web team to be able to do our own theme deployment? or module deployment specifically for Features-generated modules (ie, content types with associated views, etc)?

the guy sitting in front of me has the USDA foreign agriculture service website in his browser, but with the url of localhost. so that’s a thing.

gitforteams.com

Features, Git, & Drush!

I’m wondering if I really want more command-line-ish access, or if Justin does. Especially with committing theme changes.

Also, I want to do some sketching about what the ideal flow looks like for theme, module, structure, and content.

I’m not making a lot of notes in this one because there’s SO MUCH content in the slides, and TBH I want to walk through it with my actual test site. Plus that thing about wanting to sketch. I’m having thoughts about overall process as well.

I want all the more resources, except maaaaaybe the videos?

(plus also I need to watch The Princess Bride again.)

the architecture, and complexity, of a drupal site is based on module selection.

nice runthru of heuristics for module selection.

special cases

panels (“is it done the drupal way or the panels way?” and this is why I’m always skeptical)
display suite
views
“I have this layer of complexity…do I use it?”
domain access
organic groups
rules (turing complete, apparently. “infinite complexity”)

avoiding building the homer-mobile.

data structures

[I don’t know if he’s talking about content types, but I’m feeling like I kinda need a full do-over of the Fields of Study content type]

ok, yes.

“every time someone tries to save a week’s worth of work on the building side, they create a month’s worth of work on the maintainence side”

site building smells

taxonomy: number of vocabularies, general size/complexity of vocabs

content types: number of types, overloaded with fields, do the lines between content types make sense, would taxonomy, entities, etc be better?

in all of this: is there a reason for this to be here?

documentation!

use the description field on the content type, taxonomy/vocab, menus, blocks

in views there’s a place to write comments about the view itself! “this display’s comments”

only add  complexity deliberately
name things carefully
comment liberally { every time you see a textarea just start typing }

that was really good, lots to think about. (and short!)