what2day

so... what did carlyn do today

Wordpress Intermezzo - RobinRCutler.com

Or the answer to  - So Carlyn, what happened to the Drupal Series?

It is still going, but I had an "Wordpress Emergency" to attend to.  My mom has a website. She's had it for a while but it has been neglected. I built it back in 2007 in Wordpress. While Wordpress was and is the best choice for this type of site,  it was a real hassle. Wordpress has made a number of changes for the better in the past four years. The custom menu feature alone saved me hours and an hours of custom php scripting ( I swear I wrote a function called know_who_the_freakin_ancestor_is_already() )

What brings the big change on now is that she has a lot of material for her new project. Also, it is going to be winter in New York - well it IS winter in New York, and what goes better with a cup of tea and snow outside than blogging?  Also if I didn't do it NOW... well things fall through the cracks, and she's a good mom.

I modified the basic Twenty Eleven theme because that is really the one she liked. I was going to use Deilcate, but in the end I think she made a good call. Twenty Eleven is very well documented because it is the default.  NomNom I think, might also be a good choice to make a child theme from in the future maybe, but I couldn't find it in the Wordpress.org theme repository.

I'm not going to go through the whole set up, but there are some key modifications that took me a long time to wrestle with, so hopefully this will save someone else time some day. A couple of them could be full on tutorials, but I've got to get back to Drupal!

1. Make a child theme of twenty eleven
2. Turn comments on pages off
3. Change the position of the menu bar relative to the image.
4. Make the header image auto select itself depending on the post category.
5. Change how sticky posts display on Showcase home (move them down to recent posts)
6. Auto Create More Tags for Content going on the Front page. 
7. Put child pages of the Front page at the top of the showcase template

1. Make a child theme of twenty eleven

The first thing I wanted to do is screw with the colors, and I started here - 

The bad things bout this tutorial is only that the CSS it gives doesn't have the gradients like the parent theme. By searching the style.css file of of 2011 for "#access"  you can copy and paste it's code into your own css file and tweak the colors there.  Do that second, after you have seen that the orange example works so you know that your color scheme will in fact take.

2. Turn comments on pages off

To my mind, comments are for posts, not pages.  I moved a copy of page.php to my new child-theme directory and changed

<?php comments_template( '', true ); ?>

to

<?php comments_template( '', false ); ?>

3. Change the position of the menu bar relative to the image.

I wanted the menu bar ABOVE the image because one of my header images is taller than the others. I think it is better when the menu stays in the same place. I did it purely in CSS. This isn't ideal because it makes the menu cover the image when the theme is scaled down, but it was taking me a long time to get it to work by changing the flow of the header.php, so I gave up and went with the CSS hack.  If I need to revisit this in the future I'll take a look at how the NomNom theme puts it's second bar above the header image. 

4. Make the header image auto select itself depending on the post category.

I didn't want my mom to have to think about a special image for every post, and yet, as we go I want the images for different categories to be different. I created a directory in my child theme's home directory called /images/headers and put images with names based on category slugs in there. This is not a good long term solution because it means Mom can 't change them herself.  (FTP isn't her thing... yet) Some day I'll look into adding a "pick image for category header" to the dashboard, but not this week!

5. Change how sticky posts display on Showcase home (move them down to recent posts area)

First there has to be a static front page and it has to have showcase.php as it's template. There is a flaw in the directions for this in the Codex, I think. They say to call your new page for the front "Home," but the is_home() function finds the blog home page and is_front() finds the real front page. Calling a page "Home" other than the one returned by the  is_home() function seems like a recipie for confusion, so I called mine Front instead.

I moved a copy of showcase.php to my child theme, took out all the code that it used for sticky posts and changed the recent posts section to be the following.

6. Auto Create More Tags for Content going on the Front page. 

The problem with the code above is that it dispalys the WHOLE post on the front page, which I don't like since my mom is writing some pretty long pieces.   I was having a hard time getting the excerpt_length hook to work (resolved, ish) So I went around it and made it so if the post doesn't have a more tag, I fake it.   I could have just insisted to Mom that she put More tags on all her posts, but she has enough she is trying to learn to remember to do each time to add that step too. 

7. Put child pages of the Front page at the top of the showcase template
Since I nuked the featured-posts section I wanted to adapt the concept of a highlighted area by using the children of the Front page as the content that shows on at the top of front page.

This is not perfected yet, but here is the code for starting off. It took me a tragically long time to trouble shoot this because as soon as I put anything that is a post related variable in my WP_Query it would return nothing. A flaw in Wordpress' behind the scenes is that the code (for good legacy reasons) some times uses the word "post"  (in function/variable names, etc) to mean JUST Posts and sometimes the word "post" is inclusive to mean Posts and Pages. Everything used to be a post, so it makes sense how it ended up that way, but it screwed me up writing the query, copying from examples that were about posts. 
. 

Drupal, Day 6 - Part 2: A bit of a punt on modules, Setting up a second test site, Features Module

Part 1: The Punt
So after poking around I realized that I think I want to just follow some tutorials on how to use some of the major modules rather than just install and poke around. It seems, like with drupal, the more powerful a module, the less it reveals what it can do to the casual observer. Also many of the modules are covered in later chapters of the dgd7 book. 

For Example: 

  • Pathuato (chapter 8)
  • Panels (chapter 5)
  • Entity (chapter 5)
  • link / media (chapter 8)
  • Rules (chapter 32)
  • Features (Appendix A)

I also want to examine the relaiotnship between Content Access, Organic Groups (chapter 5), Profile 2 (chapter 8) Workbench and having a shared database with an OpenAtrium install? - How do they work together? In what ways do they overlap? What will be best for the way CRASH Space works?  It seems like going ahead and learning a bit about Panels, Organic Groups and Entity like the book does in Chapter 5 is a reasonable next step, but I want to create an additional sandbox site on which I can be even more experimental.

Part 2: Setting Up a Clean Second Sandbox

Since I am about to start installing modules willy-nilly, It will be better to do that on a fresh sandbox site that doesn't bother the GitHub repository. 

  1. I created a new repository in $HOME/Documents/GitHub/CRASHSpace/ called SandboxDrupalSite using the GitHub GUI.  It gives you the option to opt-out of pushing it to GitHub, which I've done. 
  2. I then made a clean install with the following commands, It has all the modules I'm going to be using for now, I think.
  3. Then I set up a second database refollowing the instructions at http://drupal.org/node/66187 , except instead of making a new user I added the new database to the same user I already had.
  4. Next I stopped the MAMP servers and changed the settings on the Apache preferences in the MAMP GUI to be the new www folder in the new repository. 
  5. Then I restarted MAMP, went to http://localhost:8888/ and set up the site. 
    • Screen_shot_2011-11-09_at_3
  6. The very next thing was to re setup the Back & Migrate module, create a destination folder that is not .gitignored and do a manual backup to it. I suppose I could just not git ignore the database backups in these sites since they don't mater, but that seems like bad set-up hygiene.
  7. I zipped up the www folder, renamed "2011_11_09_clean_drupal_wModules" it and put a copy in the resources folder.

Part 3: The Features Module

I want to be able to move things from the Sandbox back to the test site flexibly, and I think that means learning how to use the Features Module, as this seems to be the mode of choice for making mini-models of certain types of configuration settings.  The test of this is going to be moving my "Suggestions" Feature from the old site, to the new site.

  1. Install Features on the old site by reconfiguring the MAMP to point back to the dev site
  2. Watching these videos: 
  3. Read this NodeOne article on how to design your features to make them the most easily configured by others in the future
  4. Also scanning the Features Documentation
  5. And eyeballing the project that is the outlines for best practices for creating good Features
The result of all this is I saw the feature looking good in the old site...
Screen_shot_2011-11-09_at_5

But in the new site,  Doh! No Taxonomy Terms! Apparently those are considered "content" and features are meant to share "configurations"...Hmmm. (More on creating Taxonomy integration with Features )  

Also, the Content Type, Content Suggestion also didn't seem to take and I'm not sure why.  The weird thing was, though, when i went to make again frm scratch, it seemed to already to exist somewhere in the ether because the two taxonomy fields were already associated with it.  I also seemed to start having a database field caching problem as I passed the feature back and forth, so I made a new Feature, and that works just fine. If I start having the same trouble with that one, I'll look into it more.

Now I feel like I can develop in one crazy wacky install that I can wipe out without much of a care, while still being able to preserve nifty "Features" as mini modules to the degree that other modules play well with it.

 

 

(download)

Drupal - Day 6, Part 1: Big List of Modules

Chapter 4 in dgd7 is all about modules.

The chapter authors start with some general notes about modules

They then follow it with a mega list of modules which is why I am publishing this day in two parts. This post is just the list. I'm going to use this page of links to go exploring.

I've created a gist that has a number of the modules I'm interested in listed, ready to drush. Perhaps not the best place in the long run to keep that, but it will do for now

 

The Whole List.

Primal

 

Additional Field Types

WYSIWYG

Webform Creation

Spam

Admin Interface

Content Display

Menus and Navigation

Community Building and Social Networking

Voting and Rating

Paths, Search and 404 Errors

Misc

NodeOne article (Not already listed above & interesting to me)

3 styles article (Not already listed above & interesting to me)

6 revisions article (Not already listed above & interesting to me)

More as they Arrive

 

Drupal - Day 5: Wrapping Up Views For Now

So In the end I followed along with all 23 videos from the NodeOne Series on Views. The tl:dr version of what I learned - 

  • What is available to you in any given menu in the admin section of Drupal changes pretty dramatically depending on what other options you have already selected. 
  • All the Drupal 7 oriented documentation is going to be a little bit behind where things really are now because it is still under such active development. If you aren't comfortable with that, wait another year. 
  • On Video 18 at time 4:48 Johann Falk actually pronounces the fake-user's name and it sounds credible. Go Scandanavians.
  • Oh, and he really likes tea.

The nice thing about working with views is now I can actually share some vaguely useful files because views are exportable to code instead of just being stuck in the database like everything else. 

Export_view

I put rough sample views in the resources folder of the github project. I also put up the same code for turning them into a module that was at the end of chapter 3.  It is untested because they were a little vague on how to use it since making modules is chapter 22.  I have just been copying and pasting into the window that comes up when you select the "Import" local task on the Views main page. Works pretty well.

View_import

These are the file names for the views in Day 4 are
  • memberList
  • SuggestionsContentTypeViews
  • listByAuthor
  • articlesList
The new ones are
  • nodeOne_upTo17_articlesList2
  • nodeOne_part13_TopLevelTags
  • nodeOne_part18_userJumpMenu
  • nodeOne_part20_contextualFilters_moreArticlesStuff
  • nodeOne_part21_contextualFilters_createLocalTab
  • nodeOne_part22_contextualFilters_createLocalTabWithSubItems
  • nodeOne_part23_related_myVersion

nodeOne_upTo17_articlesList2

This file has the following displays

In Image 1

  •  
    • Page: Main Listing (Articles List Tab)
    • Block: 5 at a time, paged (As seen in Sidebar 2)
    • Feed: Default RSS (the rss feed attached to the Block and main listing)
    • Attachment (the highlighted article at the top of the the block)
Screen_shot_2011-11-06_at_2

Image 2
  •  
    • Page: User Sortable Main Listing
    • Page: Exposed As Block
Screen_shot_2011-11-06_at_2

Image 3
  •  
    • Page: Grouped By Author
Screen_shot_2011-11-06_at_2

Image 4
  •  
    • Page: Grouped By Title First Letter
Screen_shot_2011-11-06_at_2

 

nodeOne_part13_TopLevelTags

makes a list of tags that have no parent.

Screen_shot_2011-11-06_at_2

nodeOne_part18_userJumpMenu

Make a menu that will jump to the page of the user selected from a drop down

Screen_shot_2011-11-06_at_2

nodeOne_part20_contextualFilters_moreArticlesStuff

Adds a contextual filter such that /articles-list-summary/username shows the articles written by that username.
/articles-list-summary returns a list of users with the numbers of articles they have written as the sort. 

Screen_shot_2011-11-06_at_2

nodeOne_part21_contextualFilters_createLocalTab

Changes the url pattern so that /user/%/articles gives the context, based on UID rather than name.
Creates a tab on that page, since that page already exists for other purposes

Screen_shot_2011-11-06_at_3

nodeOne_part22_contextualFilters_createLocalTabWithSubItems

Takes it one step further and has all content types, sorted.  The breadcrumb is a little wacky, though, since articles is the default page of the "content tab" you don't see it as a subitem of content. I'll have to learn a little more breadcrumb fu to make it work.

Screen_shot_2011-11-06_at_3

 

nodeOne_part23_related_myVersion

This one is quite a bit different than the one in the video. The video uses an extra module to relate nodes explicitly, but I instead went with a taxonomy based version by building on what he had covered in part 13 and the content type I created following the dgd7 example I created a tab on suggestion pages that showed other pages that also had the same Suggestion Type associated with it. 

Screen_shot_2011-11-06_at_3

Additional Modules Recommended

So on top of Devel for making fake content and Admin Menus for delving down with ease, whihc we suggested by NodeOne, the book goes on to suggest looking at the below projects. I only got Views Bulk Operations (already have Calendar)

  • Admin:
    • Views Bulk Operations "This module augments Views by allowing bulk operations to be executed on the displayed rows. It does so by showing a checkbox in front of each node, and adding a select box containing operations that can be applied. Drupal Core or Rules actions can be used." i.e. "Delete All"
  • Maps:
    • Open Layers "The OpenLayers Module and its submodules bring theOpenLayers JS library into Drupal. They enable users to combine maps from different map providers with data from Views and CCK input. The OpenLayers JavaScript library is open source, making it flexible and capable across standards as well as proprietary APIs."
    • Gmap "The GMap module provides an interface to the Google Maps API within Drupal. It integrates with the Location module to provide users a clickable map for entering latitude and longitude, as well as to display maps of Drupal nodes and users. GMap can be used to create interactive maps with various map markers and content in map bubbles, taking advantage of Drupal's other content management features. The module also provides a Views display plugin which allows users to display the results of a view on a Google map."
  • Calendars
    • Calendar "This module will display any Views date field in calendar formats, including CCK date fields, node created or updated dates, etc. Switch between year, month, and day views. Back and next navigation is provided for all views."
  • Styles and Displays
    • jCarousel "This module allows developers and themers to make use of the jCarousel jQuery plugin. It includes a developer API that other modules can use, as well as Views integration in the 2.0 version so that you can turn any list of content or images into a carousel."
    • Views Accordion "Views Accordion provides a display style plugin for the Views module. It will take the results and display them as a JQuery accordion, using the first field as the header for the accordion rows."
    • Views Infinite Scroll "Views Infinite Scroll provides a ? that enables views infinite scrolling ( autopaging, depaging, endless pages ...you name it) by using jquery.autopager plugin. using this module with views page display will load another page whenever the user reaches bottom of the page."

Drupal - Day 4: Chapter 3 Error message sorted, And NodeOne screen casts

Part 1: Page for a given user based on form field

Perhaps it is the left over halloween candy sugar high, but I was having trouble going back and doing the first example or even really focusing on how DGD7 is explaining contexts and relationships in this chapter.

It seems like Drupal 7 changed and continues to change, but I can handle it - especially with the number of screen casts out there.

The one that started me down the most useful path was is More Relation and Views found from the homepage of the Relation project which seems to be the hot new thing that my potentially usurp the References project.  But it didn't make any sense that in order to relate anything to users I'd have to install a whole module.

That screen cast led me to Taming The Beast: Learn Views with NodeOne, I skipped the 5th one, Part 5: Fliters and in the comments, finally the wording of comment made things become clear... 

Adding a relationship to see user filters + more

GÄST SÖN, 2011-08-28 00:08

I had this problem to, Ive managed to find what seems to be a solution. If you add a relationship of “content author”, more user filters will become available.

In the Relations Panel of THAT view (not some uber-relationshippy place that Drupal has and I just didn't know about yet)  if you add the relationship Content: Author

 
Screen_shot_2011-11-04_at_4

Then way more fliters about the User will show up...

Screen_shot_2011-11-04_at_4

And if you select one - say User:Name and configure it - on THAT dialog you make it clear that the user meant is not the person logged in but the author of the page.

Screen_shot_2011-11-04_at_4

So what I've learned is this: As you change your configurations you have to constantly go back and recheck menus to see if there are new options that magically appear. Gotcha.

I used the "expose this filter" option and got a page that displays all the content (of any kind) that any user (if you know their name) has submitted to the site.

Screen_shot_2011-11-04_at_4
Part 2: NodeOne Screen Casts

So now I'm ready to try to create some more with Views because I like control over data, and honestly, the chapter in dgd7 was not enough for me. 
So what I'm doing, with some basic understanding under my belt, is going back and watching all 23 of the Node One: Learn Views with NodeOne screen casts. It is taking awhile, but it seems worth it. 

Two Modules it introduces are the Devel module for generating fake content and the Administration menu module which provides dropdown menus for the admin section which speeds life up immensely. 

I've followed along to the point where I have made a little recent articles block with a link to a RSS feed and a members list. Both are shown in the following picture. I got a sql error when trying to display what roles each one of them had (like keyholder, voting member, etc) But I'm ignoring that for now. 

I'm still watching - only at 11, but I wanted an update for now.

Screen_shot_2011-11-04_at_9

Drupal - Day 3: Intro to Views

Last night I finally got the physical copy of dgd7 as it self refers. (I had been working off an eBook)  It is GIANT. Being on Chapter 3 feels way less impressive than it did. But that is a good sign - at the end of chapter 2 I felt like I had accomplished things and understood them in a way that wrestling with Drupal two times before hadn't made me feel. Perhaps it was easy b/c of the previous exposure, but at the end of Chapter 2 I've now:

  • Been reminded of needing to do a design process first (then given one)
  • Added a block to the front page
  • Made a content type (what it is structurally - blog post, page, movie review, whatever)
  • Made a taxonomy (category like stuff, but better) and applied it to the content type - actually 2 taxonomies and applied them the content type for different reasons. 
  • Made users with varying abilities to acces the content type
  • installed and used drush to load in a new module / check for back ups
  • installed and used git to back up locally and to GitHub (using the GitHub GUI, I know, cheating)

That is pretty huge.  But now for...

Chapter 3: Views

Views are crazy powerful. They are the visual nuggets that make up the site. I thought that was blocks the first couple of time I tried to figure out Drupal. "Block" like "Block of Code." Wrong. Blocks are merely a way to name different parts of the page. Views are where data gets sculpted into useable chunks of information. And you can control most anything it looks like, so the page is pretty opaque without guidance. It takes 4.5 pages just to explain what the different options are, much less how to use them. That takes another 2+ pages a pop. And this is what makes Drupal so so very powerful yet complete overkill for a blog. Use Posterous. ;-)

Views is also a module you have to get, actually. Go figure. Integral but not integrated - a little bit of noseyness lead me to the page on the Drupal site "Why isn't X in the core." Doh - Line one: "A common question, particularly by relative newcomers to the Drupal community, is "Why isn't feature X in core?""  Noob hat on. 

Here is a video overview with more tutorials after it: http://drupalize.me/videos/overview-views

The problem I'm running into today is that the first example in the book seems to not work in the latest version of Views.  Doh. The filters feature is very powerful and I can get them to work for things that aren't based on users, but user based filters throw an error:
Screen_shot_2011-11-02_at_1
I found a page on the Drupal site "Exception: SQLSTATE[42000]: Syntax error or access violation: 1064"   , that at around comment 8 seems to make sense.  This seems to be something that has cropped up since the book was written. Which I still like, despite this snag. Here's more on what the internet says about it:
I think this is something I'm going to go back and trouble shoot later, since I think understanding the fix involves watching this 20 minute video Using Drupal's View's Relationships, maybe. It also looks like some answers are on Page 82-84

In the mean time, decided to learn more about Views using a filter that already does work, (i.e. by content type) instead and when I get to page 82 I'll watch the video.

I'm not really sure why they didn't use the content type they had us make in the first chapter, "Suggestions," but I guess it is better for the group authoring process to have independent chapters.  And they couldn't really have known that author name would have gotten removed from filters? I don't understand why, yet. 

So starting with the idea of working with the suggestions content type I've proceded to make:
  • a page view that is a sortable table,
  • a block view that only appears in the "Triptych" area of the home page,
  • another version of the table view that has a "highlighted" suggestion based on what suggestion has the most comments.
  • I also made the tabed views example. Only so helpful without content.
  • I also did an-exposed-filters view, which is incredibly ugly, but it can only be seen by adminstrators anyway.

And that all has gotten me to page 82, where I stop for now... just 4 pages from the end of the chapter, but I'm starving...

 

(download)

Drupal - Day 2: Installing Drush and Git

So while I don't have time to do something as complete as 30 Drupal features in 30 days,  I will try to at least mention my progress most day so there is a record of things I do that aren't in the book.  It is good to be following along with a so far well written book. I don't have to think too hard about what to do next, most things work, and are what I want to know about next anyway.

Part of why I bought the Definitive Guide to Drupal is because right in front, right in chapter 2 it talks about Drush and Git. They are kind of low-level but priceless and most starter books push them to the back if they mention them at all.

Drush

Drush is a command line tool that makes a lot of the back end tasks of working with Drupal much much easier. There is a list of drush commands on the Drupal site so you can get a sense of what it can do.

I followed along in the book, did a little googling and did the following:

Those last lines, those last lines cost me a world of pain to discover. Like finally figured out the right search terms at 3 am world of pain and then I felt like a moron. 

I have already installed Drush on the crash space Dreamhost based dev server, done a couple of things with it, no problems.  With my local install, if I tried to do anything that talked to the database (read: anything useful) I kept getting errors about not being able to connect to the database and I couldn't figure out how to work around it.   I tried a lot of things and now my set up is totally different. I'll cover that on the git section because really those changes had no impact on this particular problem.

The deal is, when the mysql server and php are on the same machine they handle talking to each other a little differently than when there is another box that php has to connect to to make a connection. Php (and Drush is just a wrapper around php, now I know) looks where it thinks mysql is gonna put the socket and if it isn't where it is looking - you get the  "Can't connect to local MySQL server through socket '/tmp/mysql.sock'" message. 

Your choices are 
  1. Change where mysql puts the socket (seems dangerous)
  2. Change where php looks for the default sock in php.ini (didn't work for me, was too tired to really explore why)
  3. Create a sym link between where mysql want to put it and where php is gonna look. (Done!)
The negative consequence of this is now if there is more than version of mysql running they may get entangle, but I have pumpkins to carve and candy to eat today working is a good place to stop. 

Git

Git is also pretty new to me, and I'm using both the command line package and the GitHub Mac OS X GUI. Yup, I said it. THe GUI. downloading and installing them both is pretty easy, lots of instructions for that on the internet. 

I'm using the command line to commit changes as I go, the GitHub gui to interface with GitHub. It is still a little buggy sometimes when doing a big commit, but I'll live.

What I've done is this -
  • Made repository for a dev version of the CRASH Space site on GitHub
  • Opened GitHub GUI on my computer
  • Cloned it to the Mac, put it in my GitHub folder, because that is what I do
  • Moved all the web files into it
  • Uploaded them to GitHub
  • Totally destroyed my work space, including the sym link to MAMP/htdocs trying to fix the sql socket stuff
  • Deleted everything (carefully saving a copy of the settings.php)
  • Recloned the GitHub copy to my machine, 
  • renamed the web files folder www & put my settings.php file back into sites/default
  • Changed the preferences in MAMP to look at the now-labeled www folder inside the repo as the Apache root
  • Started the MAMP servers
  • Went to http://localhost:8888/ in my browser
  • Done. 
What this means is I did set the global git identity variables as mentioned in the book, but I didn't need to manually initialize the drupal_crashspace_dev repository because I let the GUI handle that already.

cd ~/Documents/GitHub/CRASHSpace/drupal_crashspace_dev/
git add .
git status
git commit -m "what just changed"

The above sequence can still be used by me in the terminal to commit changes from the command line. [UPDATE 11-2 ] In fact, always use those commands all the way down to the commit. If you leave it hanging out after add it seems to do weird things to the GitHub GUI. Others might be more robust, the GitHub GUI might be more robust when not making grand sweeping changes like large directory renames, too.  (thanks Matt!)

In addition the the Git Book and what is in the DGtD book, I really liked

They are both mentioned from the Git Book site and they are worth a look. Steele's is more advanced - he is an experienced svn user - but it has some great graphics that helped me form a picture in my own brain as to how I might eventually use Git.

Database Back Up

Database back up is why we have Git and Drush at all. The site pretty much is the database and the database is the site. The Drupal php files are the bones, the meat and the personality all are in the database. 

Apparently a lot of that is in Chapter 12, and there is a simple drush dump command you can do now, but I've opted to use for now the Backup and Migrate module.

In addition to reading that module's documentation, the page on files and media storage was useful, too.  The file location I picked is already ignored by .gitignore (sites/default/files/private) and my site isn't online anywhere anyway so I'm  I'm not going to sweat being too tricky about where the back up files go right now.

The thing that I really want to be able to do apparently comes in chapter 26.  We will eventually need to tease the content from the structure in the database so we can have a dev version and a live version of the site that don't share content/user profiles. But it is set up, and even already has cron job integration!

 
Screen_shot_2011-10-31_at_3

30 Days of Drupal? My local Mac OS X Drupal & Git set up for testing

So, I'm moving crashspace.org to Drupal. That was going to be a first quarter 2012 project, but it has been moved up a bit so we can disentangle from PayPal a bit more smoothly. 

The short version for my non technical friends who are wondering what I'm talking about (Hi Mom!) : Drupal is something you can use to create a robust website. It is overkill for many things, but not for us. Using it is a bit like walking into a mechanics garage, knowing all the tools and parts are already there to build one of about 1000 different awesome cars, but with no big arrow that says "Start Here."  This is why I got the book. This is why it is going to take me 30 days to get this right, at least.  Git is a software that lets lots of people work on creating the same program and also saves versions as you go along in case mistakes are made. 
For those of you who would like to play along I'm starting from scratch using The Definitive Guide to Drupal 7 as a starting point.  It looked like the book best suited to what I was trying to accomplish.

The first thing I'm having to do is rearrange  my work processes & technical set up to align with a GitHub oriented work flow. CRASH Space is a group thing and when I'm ready to pass this off I want it to be in good shape to do so with out any extra work that I'll can stall on.

This isn't a tutorial for folks with no web development background - but I'll go over my steps

Step 1: My set up of Drupal on a MAMP Install - sym link required
Very helpful for getting a local production environment up on a Mac: http://drupal.org/node/66187

I have my Apache server running with php enabled, but everyone says that Drupal and the default OSX install of the technologies Drupal uses don't really play well with each other. So I followed the instructions on the Drupal site for using MAMP. Btw - read all the comments on that post. 

MAMP creates a sandbox on your Mac of  Apache, MySQL and php.  But it does so in the Applications folder. Yuck. I'll never remember back my work up in there!  So I actually put all the files for my Drupal install inside my GitHub folder that I keep in Documents.

That requires one bit of of trickery to make the files run inside the MAMP environment - creating a sym link to the files in my Documents/GitHub folder inside the htdocs (web enabled) folder in the MAMP install way over in the Applications folder.  

 

 

It would have been fine to do this the other way around - let the files live in htdocs and make a sym link from my GitHub folder. What will not work is to just use the finder's Make Alias command. It isn't the same thing. It creates a special kind of file - one that is kind of neat to open in a text editor. Another thing to remember is that an alias file and what it refers to can be moved around and still work. Sym links just break. 

Step 2: Update .gitignore

.gitignore is the file Git uses to keep certain files from being tracked even though they live inside the folders you have labeled as containing the repository. 
My git repository directory structure looks like this

drupal_crashspace_dev/ (repository name, main folder)
     - drupal_crashspace_dev/ (webfiles)
     - Resources/ (folder where I'm going to put files I use in the development process)

Drupal, when you download and unpack it, has a nice .gitignore file already in there to keep you from uploading the login to the mysql server by mistake. Yay.

I added the references in that file - expanding the path - to my repository's main .gitignore as well so it looks like this:

Step 3: Follow along in the book until...
Screen_shot_2011-10-30_at_4
So far I haven't departed much from doing pretty much exactly what he suggests we do, and I'm just about to start Users and Roles. In fact if you follow along on the free kindle chapter, you'll be pretty close to where I've gotten.

Step 4: Upload to GitHub

It's alive. Well it's a twinkle in my server's eye, anyway.
More soon.