Category: WordPress Methods Series

WordPress Adventure: Final Update and Wrap-Up

required+themeslogoWell, my one-week adventure to discover the best methodology and workflow for WordPress site development to suit my tastes, skills and needs, has ended after a minuscule time overrun of 200%. Tonight, I made the last decision I had left when I picked required+ Foundation for my starter theme / mini-framework. I had the hardest time with this last step, in part because I wanted to get it right and in part because the damn ground kept shifting under my feet.

First, I eliminated Reverie because the docs looked pretty sparse compared to roots and required+, the other two candidates.

Then I discovered that roots had dropped support for Foundation, which I’d spent a lot of time selecting over Twitter Bootstrap as the core platform for my work, and gone with…you guessed it!…Bootstrap instead.

Then I very nearly made a classic mistake and took the word of some Web folks that required+ Foundation — which I really liked a lot — was stuck at Foundation 3 and had no plans to upgrade to Foundation 4. But before I eliminated it on that basis, I read their support forum and found they were already at work on a new release that will in fact be built on Foundation 4.

The required+ codebase is readable, well documented, support seems sharp and responsive and I like the way they’ve integrated Foundation. As added bonuses, it is fully responsive out the gate and ships with a nicely crafted and documented blank child theme. I’ve spent about two hours rummaging through source code and I’m comfortable with their coding style and the amount of commenting they include.

Meanwhile, I made two additional minor changes to my workflow methodology based partly on a video I watched of CSS guru Chris Coyier describing his personal methodology.

I had indicated earlier that I would wait to adopt LESS or SCSS for CSS development but Chris convinced me I should incorporate that in my workflow immediately. He’s a SASS guy and I’m probably going to be using LESS but the principles are the same.

And I decided that where I need JavaScript, I’m going to write my code in a pre-compiler and use CoffeeScript rather than raw JS.

keynote-logoThe one place I differ from Chris is in his use of Photoshop. I prefer to do my graphics work (such as it is; I’m not good at it at all!) using tools that are more comfortable. So I use some combination of Apple’s Keynote (a vastly under-appreciated tool), Graphic Converter, and my friend and business partner Chipp Walters’ ButtonGadget to create my simple graphics. I hire professionals when it gets beyond the basics.

So to summarize my final workflow decisions:

  • required+ Foundation as starter theme
  • always work on a child theme
  • Dreamweaver as primary code editor, layout tool, CSS creator/editor
  • Local development stack
  • LESS for CSS
  • CoffeeScript for JavaScript

So, end of road. Now I get to go back to work and start mastering this toolset.

I want to express again my great thanks to the folks on LinkedIn’s WordPress Experts group. A more knowledgeable, kind, courteous and helpful bunch of people it would be difficult to imagine finding.

 

Semi-Final Report on WordPress Best Practices Adventure

Well, I’ve gone one day over the time I allotted myself to find my way out of the inefficient ways I’ve been approaching WordPress development for the past year or two. But I’ve finally settled on a methodology that I’m going to stick with for a long enough period to see whether it pays the kinds of dividends in efficiency and effectiveness I expect it will.

To cut to the chase for those who are tired of reading these long posts all week, here’s my new WordPress setup and practice. It’s how I’ll build every site I tackle until I see something a lot better come along.

  • dw-wpstart with a starter theme based on Foundation for WordPress
  • create a child theme off that Foundation-based starter theme
  • edit the child theme files principally in Dreamweaver
  • design new page templates and tweak existing ones as layouts in Dreamweaver
  • stay with CSS rather than LESS or SASS for the moment, reserving the right to switch later
  • do all development locally within Dreamweaver CS5.5 using Live View and a local WP server setup for test

What Happened to Drag-n-Drop?

I looked closely at three different drag-n-drop tools for WP, hoping desperately to find one that would essentially allow me not to have to use Dreamweaver for design. I’m a big fan of direct-manipulation UI design. Unfortunately, none of the three held up to my testing even fairly early in the processes.

After discovering some real weaknesses in Ultimatum and Pagelines, I thought I had a winner in Elegant Builder from Elegant Themes. It’s a plug-in that will work inside any theme, which I felt was a big advantage. But when push came to shove, I discovered that it fell short on too many fronts. Without dropping into CSS, e.g., I was unable to figure out how to control image size and alignment, the Slider element was not nearly sufficiently flexible out of the box and Simple Slider was just a bit better than a Lego. Overall, I just felt limited and hemmed in by it.

That was a big disappointment on my adventure.

Why Foundation?

At last report, I had narrowed my choices of a starter theme to Bones, Foundation and Roots. This turned out to be by far the toughest decision in this whole process. That was partly because I quickly saw that this was perhaps the most important decision I’d make and because the contest among those three was awfully close. I bounced back and forth a dozen times before I made my final decision.

And even that decision isn’t quite final yet.

While I originally intended to pick the FWP theme itself, I soon discovered that it appeared to be all but abandoned. Its online forum hadn’t had a post by the theme’s creator since last August or by anyone else since December. I posted a question about its support and viability on LinkedIn and three other forums. Nobody answered in 24 hours.

But I really liked so much of what I’d seen in Foundation I was reluctant to let it go. Until I discovered that there are a number of starter themes out there based on FWP. So I surveyed those and narrowed my choice to:

Again, what I’m looking for is a minimalist theme that is easy to extend and tweak. If anyone has experience with any of these themes and can offer some advice, I’m all ears! I plan to put each of them through its basic paces and make the final choice in a day or two.

Why Child Themes?

After studying not only responses here and posts on other forums but also advice from seasoned WP developers, I concluded that a significant percentage of the successful ones were using child themes essentially all the time. The model makes eminent sense to me.

I know some folks believe that child themes impact negatively on performance. I suspect that is probably even true. But I’m not sure the overall impact is in and of itself a reason not to adopt what is clearly a superior methodology from many other respects.

Dreamweaver? Seriously?

If I didn’t already have a license for DW, I’d keep looking because it’s almost certainly not worth spending a few hundred bucks on a glorified direct-manipulation GUI builder and code editor.

But since I already have it and am comfortable with it and thanks to a great tutorial on the Adobe Dreamweaver forums on how to edit WP theme files with DW, it makes great sense for me from an effectiveness perspective to extend my DW skills into WP.

Why Not LESS or SASS?

This was a close call. But with DW to do the editing (and its built-in CSS tools are great!), I decided learning LESS (probably won’t choose SASS) was just one more thing to add to my kit bag and one thing I didn’t necessarily need right now.

So There You Have It! And Thanks!

So I’m off to make the final choice of a Foundation-based starter theme (though a few Catalyst advocates are not yet giving up convincing me to go that route) and then start developing my six new assignment sites — four for my own business, two for clients — following this methodology and tweaking where necessary.

I really appreciate all the help I got from the members of this forum, including some who answered in private mail rather than here on the public forum. Without your experienced advice and encouragement, this project might never have been completed or, if it had, not as well.

I look forward now to working in WP rather than on it!

 

Update #3 on My WordPress Adventure: Miscellaneous Findings

I eliminated Roots from consideration because it feels just a tad on the geeky side to me from a preliminary investigation.

You have to config the thing through a config.php file and you have to edit another PHP file to  setup custom navigation menus and post thumbnail sizes.

That’s two too many PHP files that must be touched for my taste.

I also eliminated Thematic for a similar reason. So I’m down to Bones and Foundation assuming I go the bare-bones starter route.


I wish there were some standards or conventions to define how themes are to be modified and extended. For example, some themes have all their contents in the library folder, others in the standard WP places. Some themes don’t even have a functions.php file but instead have two files: one called source-functions.php and one called custom-functions.php. Without study, it’s not possible as far as I can tell to determine which loads first and thus is overridden by the other, or precisely which one to use for custom functions we want to add. All of this may exist in WP Lore somewhere, but it’s certainly not easily accessible.


If I end up deciding to go with a fully-loaded theme, I have about decided to go with Catalyst. It  has a staggering array of things I can control via a property-sheet style interface and the notion of using a Dynamik as a Theme with dozens of “skins” creates a looser coupling between design and implementation. I’m somehow more comfortable with that notion.


At the moment, however, it seems likely I’ll settle on a minimalist theme over a decent lightweight framework or starter theme because the sense of lock-in I get from heavy-duty themes and tools like Catalyst is a bit too restrictive.


I have ruled out the major drag-and-drop theme approaches. None of them is quite what I’d like to see yet and, as with heavy-duty starter themes and frameworks, I’m just leery of the sense of closed-in restrictiveness that comes along as part of the gestalt.


At the moment, Elegant Builder is leading the pack for the drag-and-drop part of the story and as far as I can tell, I can implement it on just about any theme by anyone, which gives it another big plus.

I’m down to choosing a bare-bones theme to accompany EB. Bones is feeling a little too bare-bones. I feel sort of adrift on it. So I’m spending this evening and tomorrow morning running Foundation through its paces before making this choice. Elegant Themes’ Minimal is still very much in the running as well. I have a feeling this one’s going to come down to personal preference and taste rather than winning feature sets.

Then it will be Truth Time as I’ll have to make a decision between the two remaining combinations:

  • bare-bones starter theme or framework with EB for drag-and-drop layout of the easy stuff;
  • Catalyst (with the open remaining question of whether I can make EB work in Catalyst)

 

Status Report #2: Elegant Builder Plugin Looking Good As I Explore Starter Themes

I’ve been studying what next step to take in my adventure in WordPress development methodologies and best practices. I’ve decided that drag-and-drop frameworks are not a third option on my list but rather a distinctive new approach to front-end design and layout with (in the case of Ultimatum at least) some backend stuff baked in as well.

In the process of looking at d-n-d stuff, I ran across Elegant Builder from Elegant Themes. At the moment I’m wrapping up my assessment of using that plug-in with another ET theme called Minimal. I hope to complete that evaluation in the next 24 hours or so.

barebones_wpThen I want to try a really barebones theme (Minimal comes close but isn’t quite naked enough). Based on a number of reviews and comparisons (including a particularly pithy one here), I’ve narrowed the field of Starter Themes down to the following:

I clearly don’t have time to do a thorough eval on all of these (I have to get back to billable work at some point!) so I’m going to scour reviews in an effort to narrow the list to two which I can then spend a day each with actually building out the site I’ve been using as my test bed.

I’m predisposed to give Bones a try because of my son-in-law and WP buddy Jeff Soule’s recommendation. Thematic may prove too geeky for me. Roots and Foundation seem not too dissimilar: both support LESS (which I’ve decided I prefer to SASS), both use Foundation. Roots supports Twitter Bootstrap for front-end stuff while Foundation relies on HTML5 Boilerplate. Neither of those tools is WP-specific but they are interesting tools for sure.

I’m open to hearing experienced opinions.

 

Pagelines Bites the Dust in My WordPress Evaluations

Progress Report #1

I started out quite hopeful about using Pagelines for my WP development framework/platform. After spending two hours in preliminary assessment, I’ve been forced to take it off my list because it:

  • seems overpriced compared to other solutions
  • suffers from outdated and poor documentation as far as I can tell (complaints in their user forums and my own conclusion)
  • has a Web site with at least one very significant broken link which makes it quite difficult to explore it in any depth

All of these may be erroneous conclusions and certainly most of them can be fixed easily. But in a situation where I’m evaluating several alternatives and don’t have time to test all of them in depth, I have to screen out unpromising candidates early.

I’m still waiting for a demo site to be set up for me on Ultimatum (without which I cannot really include it in my second round either), so I’m moving away from the drag-and-drop approach to the minimalist starter theme / lightweight framework category where Bones has an early lead just because of recommendations from colleagues.

Great Discussion on WP Development Methodologies

My post about my new adventure in exploring how best to tackle WordPress site development (vs. blog work) has sparked a very interesting and informative discussion on LinkedIn. The richness of the responses and the care participants give to their thoughts are the main reasons I’ve long preferred LinkedIn to Facebook or any other social network when it comes to having a real discussion.

 

My Approach to WordPress Development Has Been So Inefficient

During the past couple of weeks, I’ve been reassessing my commitment to WordPress as my main site-building platform and seriously considering returning to my roots as a Dreamweaver user. In the process, and after consulting with one of the most intense WP developers I know, I’ve discovered that the problem doesn’t lie with WordPress but with my inefficient and perhaps wrong-headed tool selection and usage.

wplogoAs a result, I’m recommitted to WordPress but I’m completely altering my workflow and methodology. I’m writing this long post in the hopes that some other developer may run across it and save a lot of frustration, anxiety and agonizing effort that comes from not stopping to re-think the best ways to approach WordPress development tasks.

The Problems

As a quick summary, I was having a number of issues dealing with WordPress and its associated themes that, on analysis, turned out to boil down to a few categories of problems:

  1. I was constantly frustrated trying to identify which specific CSS object or element to tweak when I wanted to make a change to a Theme’s defaults. I am comfortable enough with CSS that I can almost always make the change when I spot its position, but styles.css and other theme-supporting stylesheets refused to yield their secrets to me all too often. I’d spend valuable time trying to figure out what the Theme developer named the heading in that widget or div so that I could adjust its vertical spacing or change its font.
  2. Trying to avoid problems of file synchronization while maintaining URL sanity, I tended to do all my development work right in the WordPress Dashboard environment, augmented by a few plugins. As I learned the hard way, the built-in editor sucks. And the inability to do multi-file searches meant that, once again, I spent a lot of valuable time figuring out where and in which file a specific change needed to be made.
  3. I’d spend hours finding a theme that looked as close as I could come to the design I had in mind only to discover that the way the design was achieved was awkward (at least to my mind) and difficult to decode. So I’d have to disassemble the Theme and put it back together again, negating the value of the theme in the first place.

There were at least a dozen other, lesser issues, but the more I studied the problem, the clearer it became that these were the core concerns I had developed over three years of working with WordPress.

I won’t bore you with all of the perfectly understandable reasons I had these issues; that’s not relevant to this discussion.