The presentation? Your firstborn child theme. Child themes 101+2.
I’m speaking at wordcamp atlanta this afternoon about themes and child themes. I’ll update this post with post-presentation notes.
Learn how to mod themes the right way. Using child themes you won’t loose your edits when there’s a theme update. (101) We’ll go over the advantages and how to set up a child theme. (102) Plus we’ll cover some tricks to make the process a bit easier.
Generally-speaking, the conversations have always circled around features: There are those that believe every feature you could ever imagine should be included like text color, font selector, and more. On the flip-side, there are those that feel WordPress themes should be finite and extra features should only be added when it’s niche specific.
He says the the main problem is theme bloat, but I think it’s more about the lock-in effect some themes have on users. If they customize it or add content via functionality provided by the theme, then if they switch they no longer have access to it (although the content does persist in the database, there’s just no longer an interface to accessing it).
If users are stuck in your theme because it’s the only way they know how to show their content then it becomes problematic. I’m curious as to how often users are going around changing themes though. Are they changing themes for more/different functionality or for a new look? I find myself changing a theme every couple years or so to update the site, but that’s usually in a whole redesign phase and not just switching around for fun. Should theme switching be more frequent?
I also see it from the user perspective. They just want to purchase/install a theme and be running, they may not have the patience or expertise to 1) find the right plugin 2) install it and set it up, so they’d prefer it be in the theme as a package deal.
Partly, I don’t see it a problem including CPT info in a theme, because that’s where you have to style it anyways, right? Users want their post types, but they also want the templates and styles and functionality/integration with the site that go along with them, and I think a theme is the easiest place to keep all that for the developers as well as the users. Plugin shouldn’t have all the styles for the CPT content and can’t have the template files because then if they switch the theme the styles conflict with the new theme. They may end up having to learn CSS to switch the theme anyways. The users are going to want their data displayed properly as well as it be accessible on their site. So if a new theme would not properly display or integrate the CPT data, then why have it included at all.
Eric does offer some alternative solutions:
Offer a Support License purchase option that allows users to follow tutorials for their own customization.
Offer free downloadable plugins that work exclusively with your premium theme that adds easy functionality.
Offer tiered theme versions–beginner, advanced and developer.
I like the idea of including a plugin to add functionality, but I’d suggest that rather than making it exclusive, make it work with any theme, just make sure your theme supports it (along with other popular plugins).
There is talk about making extra theme functionality ‘opt-out’ for those experienced enough to do so. Set a variable in the functions.php file or even comment out a block of code to remove some customization options to it can be done via a plugin. This, although more work, seems like a good option. Providing the features by plugin makes sense, but asking beginner users to do that extra work seems like unnecessary friction.
Also, it’d be nice if WP had a built in UI for custom post types and custom taxonomies and even custom fields and meta boxes in core. Lay users could then easily create content types and manage data. WordPress would be a tool to create your own custom CMS. Theme developers could create post types as well and then WP would be smart enough to detect data in a CPT table and include the needed UI. Then the users could create/manage content types so if they installed a theme that created a custom post type, since it was now in the database, it would stay even if the theme changed. There are many rabbit holes here, but I feel like I’m onto something and would be excited to see WordPress go this direction.
I needed to write this up about going responsive in response after reading Where to Start (by Trent Walton of Paravel) about getting started with responsive web design. Thanks for sharing your thoughts Trent, I agree whole heartedly. In my experience it is the same. I wanted to share his post and also add my commentary for the parts that I really think Trent is spot on. Some dynamite points.
Longer On-Ramps Have Benefits
I believe Trent is talking about the on-ramp of beginning to create responsive sites. But when I first read the headline about the benefits of a lengthy on-ramp I was thinking about the ‘pre-design’ work that goes into a website. All that work that comes before design and has always been super beneficial to proceed thoughtfully with content strategies, sketching, architecture, wireframes and prototypes. This ‘on-ramp’ stage is even more important in RWD. The time well spent upfront before getting into designs and especially programming really really pays off. Think through all scenarios and purposes and requirements of the site before you hit the ground running. Or else you may get to the finish line realizing you forgot the baton. This is so important concerning responsive from the beginning, when making wireframes for example, we really must think about the available space to render the content.
Design
It’s no longer for prescribing exactly what a site should look like. Instead, it’s used for quick layout exploration and asset creation. As for which view/layout size one should start with, I don’t think it matters. Remember, a single photoshop comp will only express a sliver of the layout potential a fully-flexible responsive site has. It’s impossible to accurately assess a responsive layout in .JPG form.
Yes! Agencies (and clients alike, but I feel that the agencies and developers need to lead the way) need to move past the relic ideal of pixel perfect websites. Not that they should look bad, but they should not all look the same. The nature of the web is to be flexible, right? Let’s embrace progressive enhancements and move on when old browsers don’t see it as nice as current browsers.
CSS
All my values are relative (em, rem, etc.) and based on the 100% 16px base, so I can move code around without losing proportion.
Yes, Again! We need to be relative and fluid all the time. We’ve all picked up some bad habits along the way, but RWD can be seen as a good excuse to remove these.
Breakpoints should always be dictated by our content. Not by `insert popular device of the day`. We should be starting to learn that we shouldn’t rely on any specific device or measurement, because they change all the time. Let’s FORGET device resolutions at the media query stage. These dimensions should be thought out earlier and influence our content strategy. Nothing wrong with using 480 as a breakpoint if it makes sense for your content, but don’t force a square peg into a circle hole. Who knows, next year all these circle holes may become triangles (or spheres) and then we’re stuck shoehorning the square we started with again or starting over. Weird analogy, but I’m just going to let it be.
Regarding Grids, I agree here too. It seems that when using a grid for Responsive Web Design I feel constrained to the grid more than I should. Plus I think it takes the fun out of the process of laying out the content as prescribed. I love the idea of ‘content coreography’ too. It really adds to the sense the required craftsmanship by the developers/designers behind the site well done RWD. It also makes me think of site creators as the directors who layout and present data and lead the story telling of the site.
I’ve said it before, but I’m constantly excited by the web design industry because as it is such a young field, we are still making up the rules and discovering as a community what processes are best. At the same time, the technology driving the field is changing so fast that just when we start to settle into a routine it all gets flipped on it’s head and we’re reconsidering everything again.
Please read Trent’s full article as I’m sure it’s packed with good nuggets for you too.
When making the transition to building responsive websites, the hardest part can be getting started.
I get my fair share of questions about how to choose a direction and chart out the first few steps from industry comrades and potential clients. It can seem daunting, so I thought I’d attempt to sum up a few of my own current thoughts on the matter.
Add CSS body classes for the parent page on all child pages and the parent page template on of a WordPress site with this body_class filter. Ever need to style all child pages of a parent page in the same way or have you wanted to access every child page of a parent page via css selectors for styling? What about selecting all pages that are descendants of a page which is using a specific template?
Building large websites gets complicated, even in WordPress. Large sites usually mean there are many subpages and sections to the website that may need to be styled similarly. I’ve found it helpful to add a page’s parent page slug to the body class to allow me to alter or target the page or group of pages via css. By default the themes I’ve used have been generous in adding classes to the html body element for easy css selection rules. Things like the post slug, page template, logged in status, page vs post (or custom post type), post id, author… you get the idea. While half the time I don’t need half of this and the other half the time I find myself needing more.
Place this code into your functions.php file and your html body element will have a couple additional classes if they apply. It will have a class delineating the slug for the parent page on all child pages as well as a class delineating the template used by the parent page. This lets me apply styles to a whole sibling-section of a site pretty easily by just targeting the parent-slug on the body. Also adding the template of the parent in case I needed to use that.
Walking through the code here we’re filtering the body_class function is how we are able to add this. We name our own function and give it a $classes parameter. Then throughout our function we can add classes to this $classes array and they will be output with the rest of the body classes. We need to hook into WordPress at the body_class function with add_filter and specify the hook and specify our own function to be called. In this case we grab the page properties of post_parent and the template of that parent. First set the post variable to reference the global scope, and then check to see if the post is a page with is_page. Then if the post object has a value for the parent (post_parent) we add the parent’s name to the classes array. Then we get the _wp_page_template meta data from the parent to find the template it’s using (if there is no template specified, then it returns default). This is added to our classes if it exists and then we return the classes array to the original body_class WP core function.
[cc lang=”php”]
/////////////////////////////////////////////////////////////////////////////////
// Body class adding page-parent
//
function cc_body_class( $classes ) {
global $post;
if ( is_page() ) {
// Has parent / is sub-page
if ( $post->post_parent ) {
# Parent post name/slug
$parent = get_post( $post->post_parent );
$classes[] = ‘parent-slug-‘.$parent->post_name;
// Parent template name
$parent_template = get_post_meta( $parent->ID, ‘_wp_page_template’, true);
if ( !empty($parent_template) )
$classes[] = ‘parent-template-‘.sanitize_html_class( str_replace( ‘.’, ‘-‘, $parent_template ), ” );
}
}
return $classes;
}
add_filter( ‘body_class’, ‘cc_body_class’ );
[/cc]
There are many more classes we can add to the body_class and like I said, sometimes you need more than what’s already provided and sometimes you need nothing. It all depends on the theme you’re using, what it provides and what your specific site and design require. What other classes have you wanted to see here? How have you filtered body_class to fit your site’s needs?
Add the viewport meta tag with a WordPress hook via your theme’s functions file to allow responsive web design and mobile-friendly themes
With all the responsive web design activity over the past few years, I hope that any theme or site we work on we’re able to make responsive to some extent. An important part of making a web site responsive is adding a viewport meta tag to your html. Without explicitly stating our viewport, the mobile browsers will scale down the website to fit into their ‘viewport’. This is a good thing, since if it was a full website and the browser didn’t scale it down, you’d only see the top left corner, or some small section of the site. This viewport was introduced by apple for iOS and has spread to most mobile devices since. There are viewport properties or parameters we can set with this meta tag such as width and scale and can even use some device aware variables (like ‘device-width’) to set these values.
A WordPress Meta Viewport Hook
I usually end up using the following hook to add a viewport meta tag to my head in wordpress. I set the viewport width to match the width of the device. Then I set the initial scale to 1. Some go and set the maximum-scale to 1 as well. This would prevent users from zooming in on your site. I advocate that we should allow users to zoom if they wish since it is a gesture they may be used to and may still need (no matter how nice your RWD is, they may need/want to see it bigger). RWD is about giving the user a better layout for whatever device they are on, not restricting how they view it.
[cc lang=”php”]
/////////////////////////////////////////////////////////////////////////////////
// Add viewport meta tag to head
//
function viewport_meta() {
?>
True developers strive to be DRY (Don’t Repeat Yourself) in code as well as workflow and process. Previously, I somehow ended up doing in many of my projects things that plugins could also do.
It’s great to code your own sometimes and if you have specific needs that aren’t addressed by something out there already then sometimes it’s required. I think there is a lot to be said for the state of the plugin community lately. There are plugins to offer solutions many needs beyond what WP core was built to handle.
I’ve found that many times plugins are better then rolling my own solution. Not because I’m a horrible developer (I hope not at least), but because there is real power in numbers.
First off, plugins benefit form the community or users and developers involved in making them work and making them popular. Choose plugins that have a good base of users so when the author or WordPress ships updates, there are many people reporting/testing compatibility issues.
There is a community of people thinking about how to solve recurring needs and many minds working together on something are smarter than one. This is how I’ve come to terms with paying for plugins for an open source and free platform.
It’s worth the expense in the time I save on projects. (Disclaimer: However, I don’t think we should be using a screwdriver as a hammer simply because we can make it work. If you end up hacking plugins to get what you need out of it, then you may be better off building your own.)
This past year, I resorted to using plugins for a lot of the basic functionality I found myself using over and over again on many sites. I’ve been pleasantly impressed. Here are my top 3 plugins of the year:
1. BackupBuddy
BackupBuddy by iThemes. Backuping up a site is pretty much essential for anyone who does web work professionally. Not only for security but also for moving sites.
As a developer I’m constantly moving a site from a dev environment to a production environment and vice versa. It was the bain of existence at times, because with WP, moving the site is more than just copying files via ftp. It includes the database and config files and settings in the database too.
BackupBuddy, has helped this become a fairly simple process that lets me export the whole site (database and all) into a zip file and then I can easily place the site on a new domain or environment.
The huge win for me is that I’m spending less time managing databases and more time building websites. Although I generally tend towards open solutions, this one has been worth the money spent many times over. (Even when they had an update that broke my database, it still saved me time in the end).
I mainly use this tool to schedule and automate my backups and save them remote locations either weekly or daily and to move my site between dev and production environments for testing and deploying.
2. GravityForms
Gravity Forms by RocketGenius. Forms are a part of every website I’ve built lately. I used to use CF7 and still am a big fan, but I ended up trying this form plugin out once and have been very impressed with the UX and UI. It has many features and is tastefully integrated into WordPress.
Some of my favorite features are that it saves the form submissions into my database and I can send complex notifications about the submission. It also has many field types built in. so if I need to capture someones email and shipping address, there are fields that will validate as such automatically!
True, I could write my own script to do this, but why spend unneeded hours to reinvent the wheel, and test the wheel and maintain the wheel.
There are many many plugins offered to enhance the gravity form as well, you can integrate easily with MailChimp, Paypal and WordPress itself (for creating user accounts or even content).
I’ve used gravity forms as a simple contact form, as a job application form, as a donate form, newsletter signup form and more. It’s nice to be able to rely on one plugin for all this. The support forum has always been helpful as well.
3. Advanced Custom Fields
Best for last in my list is Advanced Custom Fields by Australian, Elliot Codon. The plugin site lists many add-on plugins that extend the functionality. Hopefully you’ve heard of custom fields in WordPress already, and if not, they are extra data about the post (or whatever type of content you create with custom post types).
You can add an external link, a price, an address or anything you can think of. This isn’t too hard to do in a theme or plugin on your own and has been documented and tutorial-ized many times explaining how to create fields and saving them to the database and grabbing them from the databse… but it does get tedious.
And then there are all the different types of data you may want to store that you end up having to reprogram every time. Text and numeric values are simple enough, but what about a date, an address, an image or a relationship.
This plugin makes it not only easy, but fun to create custom fields. It adds easy functions for php to grab the data you need at the template level and the UI is entirely seamless with WP. There are many options for conditionally including or requiring the custom fields in the post edit screen etc.
I think this plugin truly transforms WordPress into an open minded CMS with style. Mad props for it not being added to the list of premium plugins (although some add-ons are for sale). I’d vote for this being added to WP Core and won’t likely work on another custom field project without it.
Progress
In all, it’s been a great year to be working with WordPress and it’s only getting better! I’m excited for the number of plugins that are getting better all the time geared towards easing the process of building sites. Equally exciting is the plugin repository at wordpress.org and the recent updates of being able to write reviews for plugins, I think this is a huge step towards letting the cream of the crop rise to the top allowing users and developers alike to find (and support) the best plugins out there.
What plugins have you found that don’t just save you an hour or add a bit of functionality, but that transform your workflow and help you live the DRY mantra?
I agree with this idea from Ryan that the web has big advantages. I am constantly hearing stats and projections that Mobile is taking over. And sure, I agree that I use my phone to browse more sites, but when it comes down to it I’m just casually browsing – not working. I love the post he’s links in the first line: Vibhu Norby has a detailed post on why his startup is pivoting from mobile first to web first.
Vibhu details that he’s done the mobile startup thing and has learned from the complications. He explains that most of these have been solved in the desktop browser already and a lot of it relates to usability.
Another big point is that mobile apps must be installed (actually they must be found, installed, opened and setup), whereas a web app can be as simple as a link- click, and then the user is already using it. Adoption is much easier on the web.
And even another point is updates and testing and whatnot. YOu can do various tests and even update the whole app relatively fast on the web. There is the one version to support – the live one. While with apps, you can’t do much in the arena of testing and updating is sluggish plus it relies on the user to update (some don’t know how to update and even less care).
I think a web app that is mobile friendly wins. You can give mobile users access, but they aren’t stuck on mobile. They can use it anywhere. While so many are talking about responsive design and produce sites that are device agnostic mobile apps are very device centric.
I’m a fan/advocate of future friendly at least, and strive for future proof (although I understand that’s near impossible). I also hold that there is ONEweb and mobile myths.
Astronomy has a lot to do with web design nowadays… This video teaches how distance is measured in space and discusses parallax as one way of calculating distance.
We need more articles like this that talk about process and how they are applying these new web mantras like ‘Mobile First’ and ‘RWD’ and ‘Design in the Browser’. These mantras lead us to think these techniques are very black and white, but there is a lot more to it than that. Like most everything else on the web: it depends.
Ethan Marcotte has become the father of Responsive Web Design and spent this whole day focused on principles, techniques, gotchas, examples, … all about building and how to build responsive sites. With a sprinkle of mobile first.
Compare process to print with a press – linear process has been co-opted for the web
discover, design, develop, deliver
Break down the one way process from design to develop. The workflow should cycle between design and develop.
Text:
How well does the layout adapt?
Do individual modules still feel usable?
Mobile First! – Luke Wroblewski
The argument: Mobile traffic has explided, new capabilities (touch, geo, voice, ubiquity), narrower screens force us to focus.
Think about these things earlier in the process gives a better end product
What value does each content have for our mobile users?
Mobile First and Design for Content First (really Content always)
500 Android – snapshot from google analytics: http://stephanierieger.com/the-trouble-with-android/
Will screen resolutions standardize over time? Who knows, we need to be thinking flexible, it is even the more future proof solution.
Grids
The History of Grids – Every movement in art can be seen as a response to another
Start design with a network of modules
…methods and rules upon which it is impossible to improve have been developed for centuries… -Jan Tschichold
Mark Boulton introduces “The New Canon” for web design
-Content out, not canvas in.
-Create connectedness
-Bind the content to the device
aworkinglibrary.com – change – Mandy Brown “rich designs can emerge from flexible roots… the web is not print…
it’s all about balancing the ease of dev vs ease of maintenance
Frameworks are very valuable for prototyping
Design your source code order. think about linear and layout at the same time.
Bandwidth
no correlation between screensize and connection speed (or price even)
a matter of serving appropriate images
a hack really: preloaders, cookies and race conditions (http://blog.yoav.ws/2011/09/Preloaders-cookies-and-race-conditions)
Each browser does this differently though and it’s not standardized.
Can we solve this with new markup? A new html element? Like th evideo or audio elements?
Video element can have media query attached and multiple source files referenced.
Backgrounds
stuntbox.com
background-position: 0 0; – x y; left top; 50px 0; 0 50px;
it’s a bit different for percentages: 50% 50% (centered). percentage for packground position is proportional to the image itself and the container. t places that point in the background image in that position in the container.
Resizing background images: background-size css property. Set in pixel based terms or in proportions/percentages. (not 100% supported, but can be used as progressive enhancement).
Media Queries
Descendant from media type style sheets: scree, print, handheld, projector…
display area and rendering surface
Think of the browser’s viewport as the display area and the display as the rendering surface.
Specify ranges with min- and max- prefixes for browsers above or below a certain threshold or breakpoint.
Long list of media query features: width, height, device-width, device-height, orientation, aspect-ratio, device-aspect-ratio, color, color-index, monochrome, resolution, scan, grid. These can be combined in statements.
Can combine media types as well.
Also keywords for mixing the statements: only, not, and
Put it into practice:
Looking at the weather module on the boston globe as an example. http://bostonglobe.com/
Don’t suppress things before discussing simplifying it.
How do you choose breakpoints?
(The only way I’ve ever learned anything, is by doing it wrong first)
Initial breakpoints: 320, 480, 768, 1024, 1200px
Set up the queries to support Mobile First
Mobile first workflow overview, start with one layout and additively add more.
Polyfills
css3-mediaqueries-js: slower, first on the scene.
respond.js: very fast, only tests for min-width and max-width, only ~3kb
There’s no real set of IDEAL breakpoints
We’ve been very focused on columns, let’s refocus on content! http://www.designbyfront.com/workinprogress/article/the-goldilocks-approach-to-responsive-design
Set major increments and have the smallest breakpoint totally fluid and then find breakpoints dependent on the design (content and typography) rather than devices. Let’s not choose our breakpoints based on devices, but let our designs dictate what looks best. paulrobertlloyd.com
Start with the smallest part
Advanced Layouts
Negative margins to break out of the grid
Box-sizing
CSS3 – the waiting game
Multiple background images
http://contentsmagazine.com/ Setting the top margin and absolute position to 5em/-5em, and the navigation is part of the main content. Smaller sizes the navigation is at the bottom and larger it is set to position absolute and fits inside the margin.
Use IE conditionals to load specific stylesheets for them. And use media=”only all” for the enhanced styles
Minify and combine/concatenate javascript files
Conditionally load assets (progressive enhancement – if a browser can’t be enhanced, let’s not load the files that would enhance it). Test for capabilities of device and not test for the device itself labjs.com yepnopejs.com
Constantly ask yourself: is this element content or an enhancement.
Fonts: sasquatchmusicfestival.com (fonts for web are usually pretty heavy)
Thinking about process and patterns
1. Width
2. Hierarchy
3. Density
4. Interaction