Your default profile

[Joss]

Seeing Nico's reply in five modules about his default installation,made me think, what does your's consist of?

My default profile I am doing has the main modules I like, plus a very basic news system and some SEO fields I have used for a while.

In templates folder I have my own SASS arrangement, pocket grid, response.js, enquire.js, respond.js and a few other bits like html5shiv.

I have a couple of menu bits half ready to use with Somas menu module.

I have a docs folder with all my notes so I dont forget why I have the above in the first place!

I have a downloads folder with some jquery bits that are not installed and an elements folder with some layout tests for copying and pasting.

It has no templates constructed, but the components are there.

So, it really is less of a profile and . More of a kit.

A Few More Details

The core of what I am trying to do with this at the moment is the CSS setup using SASS. I am only just learning SASS, so this is as much as an educational tool as anything else.

My set up is currently this within /site/templates/:

scss/
	site.scss
	bourbon/
	components/
	pages/

site.scss is the main file that imports everything else.

This is a lightweight mixin library for Sass. It simplifies working with radients, borders, colours, tints and many other common tasks.

Pages will contain any scss directly related to a particular template/page. So, there might be a file in there called _home.scss that has anything extra just for home. Really there should be very little in here, but it just keeps things easy to find.

Components contain my main classes, so:

• _normalize.scss - the scss version 
• _breakpoint.scss - this imports the _mq.scss file. The breakpoints defined in this file correspond to the breakpoints for response.js. However there is no requirement to do this, it is just a starting point. The line $mq-show-breakpoints allows a visual note of the breakpoint in the browsed page. This needs to be commented out on production sites! Ignore the breakpoints at the head of the page
•  _colorscheme.scss - This defines colors for the theme and turns them into variables. Add whatever is required here.
•  _demos.scss - this is for playing around with ideas, often related to files in the /templates/elements/ directory. This needs to be removed from site.scss for production sites.
•  _global.scss - This contains core values that are used throughout the scss system.
•  _layout.scss - this is main layout elements that are reused throughout the site. However, elements that are unique to template/page should be placed in a relevant file in the /templates/scss/pages/ directory.
•  _mq.scss - this is file for sass-mq. The values at the top of the file are overwritten by the values in _breakpoint.scss.
•  _pocketgrid.scss - this is the pocketgrid.css file. Do Not Edit. 
•  _processwire.scss - this is for any styles that are specific to ProcessWire such as align image.
•  _typography.scss - All main typographical elements are in here.

My top level folder structure within /templates/ is:

• css - mostly the output of 
• DOCS (all my notes saved as .md and auto converted to .html
• elements - these are just useful bits. They are not linked to anything and are more a copy/paste library
• images - well, got to have one, don't yer?
• includes - a functions file, head and foot if I am doing it that way and so on
• js - all the js that is not on cdn
• scss (see above)
• usefull-downloads - literally a library of downloaded things that will get thrown away on production

And then there is the prepros.cfg file, the config.rb file for compass and a couple of templates.

[yellowled]

I have a project boilerplate that I use in basically any web project these days. It's not specific to PW projects, but can handle those fine just as well (basically by switching from .html to .php files). The quick and simple run-down of what this includes is:

• a set of SCSS files and partials which are not really a CSS framework (I don't like using CSS frameworks) but rather a solid CSS baseline and some extends/mixins, some of them for
• a collection of jQuery plugins and JS snippets that I find myself using time and time again; most of these were chosen because they are developed in a very solid way and available via Bower (I'll get to that in a minute)
• some basic non-HTML/CSS/JS files like a .htaccess, a robots.txt etc.
• some Handlebars/assemble.io layouts and partials, just because generating HTML from Handlebars makes it so much easier to generate static HTML sometimes (i.e. includes for navigations etc.)

A this is handled/tied together by a Grunt build script which takes care of way too many things to list here, but among other things, it takes care of combining and minifying CSS/JS assets, minimizes images, adds vendor prefixes to CSS, generates favicons and more. I usually start any project by building a static HTML prototype because I never learned how to design a web site in Photoshop or something. So even for PW sites, I will first build a small static HTML version, which hopefully covers and showcases all the page types/layouts needed later. That's my base for the PW templates.

Edit: Right, forgot Bower. It's basically a package manager for web assets (mostly JS/jQuery plugins, but not exclusively). Makes it so much easier to keep your JS plugins up to date, I don't even remember how I did that before Bower. Based on node.js like Grunt, so that's required.

For PW projects, I have a bare-bones template, which is just my version of the default template. Similar to the static boilerplate, this already includes some functions and page templates that I know I will use time and time again in projects. Or not. It is also already adapted to the static boilerplate, so it will work with its files and build script out of the box by just exchanging .html files with .php files. (Yes, while I type this I realize that it may not be that easy to understand as I think it is for, well, anyone but me.) Basically, I can just drop the templates files in the static prototype folder, adjust the build script a little and then convert static HTML into PW templates. It will use the same CSS/JS/image assets just fine.

As for modules, as I said in the “your favourite modules” thread, I usually try to only use modules if I actually need them. So, no modules included here.

[Joss]

I agree with what you say about modules. I have a couple already installed, and I have a little bunch of uninstalled ones which are there as much to remind me they exist as anything else!

I was thinking that the development environment/workflow also has an impact here. For instance, I have Bourbon installed with Bower as part of my SCSS kit. (more like a bag of bits!)

The current way I am working may not be ideal, but I am also a writer and composer so I am trying to compromise around all those things while having just one main work computer.

So, I have a filthy great big windows machine with three monitors (well, four if you count the optional screen for music to picture work). It is running windows 7.

I also have a small Ubuntu server with Virtualmin on it. It is not accessible from the outside world (a peculiarity of my current broadband set up), but that is not important. 

For each project, I create a virtual server (no mail or stats or anything) so that I am always working in "root". I just give them strange ending like dot bear, or dot bloke or something and then edit my hosts file in Windows. I create a samba share.

(Downside, I cant preview on my kindle since I cant edit its hosts file easily)

On my windows machine, I map a new drive to the /site/ directory of the project.

I then create a new Sublime Text project for the site directory.

I then add a new project to Prepros to the /site/templates/ directory.

I also create a companion folder on my windows machine and that is favourited in Adobe Bridge.

And I am ready to go!

Prepros deals with most silly things, So it does my SASS, it will minimize JS and it automatically converts md to html files, if I want. It also has live preview of sorts, but that is not a lot of help in the PW environment!

Part of what I am trying to do is put enough things at my fingertips so I can play with the imagination rather than search for utilities. It is not perfect by any means and maybe a terrible way of working. But it is educational

[yellowled]

Yeah, I have completely given up on running local dev servers altogether. The Grunt script includes a small local web server just to be able to server HTML files because sometimes JS won't work properly without a server. As for the whole MAMP/xampp/local Apache thing, I feel it's just not worth the effort. You only end up either having to deal with things that are set up entirely different on the live server or doing duplicate work.

I also don't want to fill up my hard drive with endless local versions of projects (I'm working on a MacBook Air with a rather small SSD, so hard drive space is kind of precious). So if I ever need a staging server (if only to be able to show clients work in progress), I use a dedicated stage on my Uberspace for that. Uberspace is a German web hoster which offers a really neat and convenient server setup including ssh access, so it's very easy to quickly setup a stage there. Of course, that means I can't do some work if I don't have a net connection, but then again, if I don't have that, I usually don't work at all anyway.

[OrganizedFellow]

I really like where this topic was headed. But it seems to have been hidden away.

I don't have a Default Profile, yet. But I have a boilerplate setup using SCSS > Bourbon/Neat. I don't have a github setup for sharing/viewing. But I really should!