The title may strike you as a bit ominous, but fear not. Underscores, our popular starter theme for WordPress theme development, isn’t going anywhere. As we continue to push for consistency in themes and imagine what they might become with Gutenberg, we’re bringing our attention back to Underscores. 🚀 For the last year and a half, we’ve … Continue reading “The Future of Underscores and A New Committer”
When we think of space flight, we often think of the thing that gets us there: the shuttle, module or rockets that take us out of this world.
However, in the early days of space flight programs at NASA, one man realized how important control from the ground would be to quickly evolving missions. Christopher Kraft pioneered the creation of Mission Control, the place where dozens of engineers, scientists and staff on the ground assist the astronauts in carrying out their mission from thousands of miles away.
About the Flight Director, the person in charge of Mission Control, Kraft said:
[T]he guy on the ground ultimately controls the mission. There’s no question about that in my mind or in the astronauts’ minds. They are going to do what he says.
The notion of Mission Control makes a good metaphor for a WordPress theme. Themes sit at the center of the WordPress experience. They run the show. WordPress is the ship and rockets that get us there. Without a theme, the mission won’t be successful. Sure, at its core, WordPress is publishing software, but many more people interact with the front end of a site than its back end.
So how do we start thinking of themes as an experience, rather than part of the experience?
Design how the pieces fit together. Most themers see the parts of a theme experience as separate. I did too, until recently. When I say separate, I mean as different parts of one flow. We often create the theme and the documentation with little thought as to how customers get from the theme to the help text when they need it. We also don’t spend time on onboarding or setup with customers. All that matters though, and it can help get a customer to success and make them feel like a success. We need to pay more attention to how those parts connect for a better experience.
Be consistent. Themes in WordPress have this great strength because they can do nearly anything. Their biggest weakness? They can do nearly anything. This means how a theme behaves can vary widely from one to the next. We’ve tried to address this in projects like Underscores and the TUX (Themes User Experience) list, but you can never do enough. I’d like to see themes only vary greatly from the norm if it accomplishes an important design goal for the customer.
Mind the internals. Recently, we had our support team at WordPress.com share why themes frustrate our customers. So much of the frustrations boil down to what a customer might not have control over in a typical theme. Things like how an image is cropped or how WordPress Core handles some default data. Experimenting with how these types of things work for your customers can mean they’re happier in the end.
If you make these items a bigger part of your theme design process, you’ll have more control over your theme’s experience. And your customer’s missions will have a greater chance of success.
On WordPress.com, one thing we’ve been focusing on is making themes that just work. It’s a bit of a balancing act; it’s very tempting to allow customers to control every aspect of their theme, because it seems like the simplest way to give them what they want.
That idea may sound great to customers, but having panels of options in the Customizer and an armload of documentation to figure them out is daunting. You can change things, but you’re also faced with making dozens of small, similar decisions about various aspects of your site, and deciphering the purpose of various controls.
It is true that in WordPress themes, some options are necessary. When designing and building a theme, it’s important to distinguish what options fit the actual intent of the design, and what options are being added for the sake of adding them.
You can often figure out which is which by tracking common pain points.
One way to do this is through support requests. On WordPress.com, we have a dedicated, talented team of Happiness Engineers who interact with customers every day. As Gary Murray wrote in a recent post, support teams are an important link between our work and our customers, and an invaluable wealth of information.
For themes, the support requests often involve how to set up a theme or use different options (which is why making themes that just work from the get-go is important). But other requests have to do with customizing a theme in specific ways. Some are unique to a customer’s specific goals; others come up again and again from different customers, either in the same theme or across several different themes.
In the Ixion theme, we recently added an option to control the opacity of the overlay used on front page photos, after several customers asked about changing or removing it.
One purpose of the dark overlay is to ensure the text on top is legible against the photo. But if you’re starting with a photo that’s already pretty dark, the overlay isn’t needed and can make it hard to distinguish details in the photo. We were able to add this option while maintaining the original appearance, so customers who weren’t troubled by the opacity didn’t know the change happened.
Another feature that came from frequent customer requests was Content Options. A brainchild of Thomas Guillot, Content Options are a way for customers to make small visual changes on their site, like hiding the date, author name, or featured images. Rather than adding the options to individual themes, it’s a feature available in Jetpack and WordPress.com that themes can support. That way, the options are available in several themes and implemented exactly the same way.
Both additions were guided by the goal of keeping things simple, balanced with following actual customer requests.
When looking at adding options to a theme, there are a few things that can help to keep things simpler:
First, aim to make a theme that just works on activation. If the design’s not possible without multiple options, rethink it. If options are necessary to get the theme to work well with different kinds of content, find a way to make the theme more forgiving instead. Make the theme do as much work as it can by itself.
In a similar vein, make the theme make the decision. You could allow customers to switch a sidebar position, or make the header sticky, but unless it’s a very common request it’s best left out. Chances are, one option looks best and makes the most sense for the theme you’re building — use that one.
Use existing WordPress functionality rather than custom options. I don’t mean stretch the options beyond their original intent, just don’t reinvent the wheel. For example, look to use the custom header image or featured images in the theme before adding another image upload option to the Customizer.
When adding options, rethink your approach to customization. Alright, you’ve discovered your customers can’t live without being able to change their header’s layout. Rather than having separate controls to move each individual item — logo, header image, menu, social links, site title — is there another way to approach this? Aim for simpler, more opinionated controls to limit the decisions customers have to make. Basically, make your options smart.
Last but never least, user test, talk to your customers, and work directly with them when you can. They’ll help guide you to that point where your themes can help them feel empowered, but not overwhelmed.
Photo by Patryk Grądys on Unsplash.
Every few months I read a post about how the WordPress theme business has shrunk. The authors always reach a similar conclusion. Sales have dwindled. Competition has increased. Putting food on the table, finding a niche and standing out is near impossible.
It may not be so impossible though. With a new editing interface on the horizon, the theme landscape will change in a big way. That editing interface, and eventually better site customization, means we (those who create themes) will all have a chance to redefine what a theme is and means to people who use WordPress. It will be new, fertile ground to discover – the next chapter for themes. We just can’t make the same mistakes we’ve made before.
A long time ago, especially in Internet years, you could sell a collection of well-designed WordPress themes and make a living. These became known in the WordPress space as premium themes. What made them “premium” was loosely defined. They often sported a unique look or carried interesting features. As a consumer, premium themes always seemed more special to me. They took risks. That runs against what we say on the Theme Team at WordPress.com, where we do nothing but create WordPress themes: The only difference between a free theme and a premium one is the price.
As more and more theme shops sprang up, the feature race began. Many themes became as complex as WordPress itself. Designers and developers had less time to experiment because we spent more time glancing over our shoulders. What’s the next trend? What’s this other theme shop doing?
To correct for the complexity, the larger theme ecosystem became obsessed with standards. Like making sure a theme did things the WordPress way or always met “best practices.” The web industry as a whole also continues to obsess over and rely on build tools and frameworks, sometimes to a fault. They should solve technical hurdles for us. But do they? Sometimes they do at the expense of our customers. Make no mistake, I’m not arguing against best practices or tools. We do the same thing. However, the status quo, even if it means well, can blind you to what’s important.
What’s important, you ask? Our customers. Doing the invisible things that make their experience its best. Focusing on accessibility, performance and security. Making sure the the small screens look just as good as the large screens. Gutenberg, the project name for the new editing interface, will make one theme become many. A customer using a theme will be able to bend it many different ways – turning the focal point of the theme from its capabilities to its design.
Customers want their sites to look just right. They don’t want to learn a theme. So when the new age of themes begins, promise me you’ll focus on what they want. You won’t get distracted by the many different ways to extend this new editor or become mired in all the ways to prevent the abuse of customizing it.
This matters. Your customers need you. And you’ll stand out and put more food on your table.
At this year’s WordCamp Europe, some members of the WordPress.org support team brainstormed how we might be able to share support skills and strategies with the broader WordPress community. We decided to offer some workshops to share support knowledge, and the first one – by yours truly – has been announced. Details are below.
Hope to see you there!
Update: The recording, slides, and notes are available.
Providing support for your themes offers tremendous opportunities to educate WordPress users, from explaining how to make a child theme to offering simple CSS customizations. It also presents challenges, like figuring out how to help people who aren’t tech-savvy or need support beyond the scope of what you can provide. While many developers dread doing support, with some concrete strategies and techniques in hand, helping users doesn’t have to be a chore – and can even be fun! This session looks at how to make your themes’ users happy while feeling a sense of satisfaction from your own support efforts – a winning combination in the world of theme development.
Wednesday, August 23, 2017, 16:00 UTC. It will last for an hour and include Q&A.
The session will be run via videoconference and will be recorded and posted later for those who can’t make it. Please download the free Zoom app ahead of time. You can run Zoom on most desktop and mobile devices.
A link to the Zoom teleconference will be provided in the #forums WordPress.org Slack channel about 10 minutes before the session begins.
In her role as Theme Whisperer on the Theme Team at Automattic, Kathryn Presner provides support for hundreds of themes. She began helping people as a volunteer in the WordPress.org forums back in 2011 and was immediately hooked.
Featured image by Pixel Fantasy (CC BY-NC-ND 2.0)
The title may strike you as a bit ominous, but fear not. Underscores, our popular starter theme for WordPress theme development, isn’t going anywhere. As we continue to push for consistency in themes and imagine what they might become with Gutenberg, we’re bringing our attention back to Underscores. 🚀
For the last year and a half, we’ve experimented with a new starter-theme generator called Components. It was a way to make a few different theme “types” comprised of different components. The starter themes born from it brought with them more code and styles, and gave theme authors a bigger head start in their work. The generator we built to piece the different components together got complex quickly, though. We created a plugin to test builds locally and struggled with a seamless way to make many starter themes from one code base.
We learned a lot, though. We worked on Components at two team meetups, made almost 900 commits to the project and launched dozens of themes with it. However, we hit a point where we realized we had over-engineered parts of the project. The original idea is still solid: make starter themes do more by crafting them out of building blocks. But we didn’t hit the mark, so we’re retiring Components, and looking to bring some of what we learned there to Underscores.
In the last year, we’ve gotten a lot of questions from the community about Underscores and whether we had abandoned it. No way! It’s a stable project, and we enjoyed working on something new, away from it. It gave us better perspective and more ideas for the future of Underscores.
We also know that involvement from the community is vital. It’s been a while since we added our first contributor external to Automattic. To that end, we’ve given long-time Underscores contributor Ulrich Pogson commit access. He’s also a contributor to WordPress, most frequently as a member of the Theme Review Team. We’re excited to have his expertise and passion for world-class themes as part of the project. Please join me in welcoming Ulrich! 🎉
It’s always hard to let go of a project, in this case, Components. But it shouldn’t be, when you walk away with more knowledge than before. It has us excited and reinvigorated about Underscores and its role in the future of theming. And we’re glad Ulrich will help us along the way!
Meet Dara, a beautiful new theme crafted by Caroline Moore, now available for download via WordPress.org. Dara has its roots in a popular theme called Sela. Caroline tells the story of how one theme led to another:
Sela, designed and developed by the Automattic Theme Team’s Ola Bodera, remains one of our most popular themes — and for good reason! It has a softer, sweeter quality not often seen in business themes.
With Dara, I wanted to refine the user experience and include some of the things Sela users regularly asked for; moving the social links closer to the top, for example, or replacing the static image in the hero area with a slider.
As someone who hangs out in the crafty space, I see Sela and Dara as perfect for small businesses and entrepreneurs who want a softer look for their sites, but the themes’ flexibility and attention to detail make them lovely for personal blogs as well.
Dara supports several handy features for business users, like testmonials that let you highlight customer feedback — available through Jetpack’s Custom Content Types module.
Explore the Dara demo or check out how to set it up.
Meet Ixion, the latest theme to join our WordPress.org collection. Designed by Mel Choyce and developed by Caroline Moore, Ixion is a clean and professional theme geared to schools, non-profits, and organizations.
Put your most exciting news front and center with a custom header image and a call-to-action button, highlight three noteworthy accomplishments on the homepage, and – with Jetpack’s Custom Content Types module – use Testimonials to showcase your organization’s satisfied students or customers.
Visit the demo or take Ixion for a spin.
Now available through Jetpack, Content Options let users make small visual changes, like showing or hiding the author, date, featured images, and more.
Last August, we introduced a new WordPress.com Customizer panel called Content Options, which gives users an easy way to make small visual modifications across their sites – no custom CSS needed.
Content Options supports four main features: Blog Display, Author Bio, Post Details, and Featured Images.
Content Options are now available to self-hosted WordPress sites with the latest version of Jetpack (4.5). Theme developers can add support for Content Options by following the Jetpack guide.
Let’s look at the main features of Content Options in more detail.
Users can choose between displaying the full content of each post or an excerpt on the blog and category, tag, and date archive pages, as well as search results.
Default Blog Display
If a theme displays either an excerpt or the full post depending on the post’s post format, theme developers can add a “Default” blog display option to let the theme keep its default blog display settings. For example, by default a theme might always displays posts with the Quote post format as the full post, so a quote is never truncated, while other post formats like Standard might be always displayed as an excerpt.
On the single post view, users can opt to display the name and bio of the post’s author. This information comes directly from the author’s profile at Users → Your Profile, and their Gravatar image.
The post details section allows users to show or hide the post date, categories, tags, or the post author’s name.
Users can choose whether to display featured images on single posts and pages. They can also opt whether to display featured images on blog and archive pages, which include category, tag, and date archives as well as search-results pages.
WordPress.com users have loved the flexibility Content Options gives them. We’re very pleased that self-hosted sites can now benefit as well!
We have three Automattic-made themes now available on WordPress.org.
Rebalance is a fresh take on the classic Imbalance 2 theme. Designed by Mel Choyce and developed by Allan Cole, Rebalance is a contemporary portfolio theme for photographers, artists, and graphic designers looking to showcase their work, and features an elegant Masonry grid for displaying both blog posts and Jetpack portfolio projects.
Another Mel Choyce-designed creation, Karuna is a clean business theme crafted with health and wellness-focused sites in mind. With bright, bold colors, prominent featured images, and support for customer testimonials via Jetpack, your business’s brand is sure to shine with Karuna, which was developed by Caroline Moore.
Child theme Sidespied puts a new spin on Espied, a classic portfolio theme. Created by Tammie Lister, Sidespied shows off photos and images of all kinds in a clean grid layout.
I’ve used Vagrant for more than a year now and although it was crashing from time to time, I always managed to get it working again. Not last week. I don’t what happened, but enough was enough – I decided to pull the plug and look for a better alternative.
I thought about switching back to MAMP, as my needs are pretty straightforward. At the same time, I was also on the lookout for something a bit more modern, something that would allow me to use a custom *.dev URL like Vagrant and share my local site to the world without a headache. That’s when I found Laravel Valet (or Valet for short).
Valet is a Laravel development environment for Mac minimalists. No Vagrant, No Apache, No Nginx, No `/etc/hosts file`. You can even share your sites publicly using local tunnels.
It’s so easy I wish I’d switched to it a few months ago when it was initially released.
Don’t get me wrong – Vagrant is still great for big development environments. But for my own simple WordPress needs, Valet is the perfect tool which I would highly recommend to fellow WordPress developers.
The official documentation and the article written by Tom McFarlin on TutsPlus are both really clear, but I’ll share my own process in case you’d like to try it.
Install Homebrew:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Once installed, make sure you have the latest version of all the packages using brew update.
If you get an error, you probably need to update your .bash_profile. From the terminal, enter sudo nano .bash_profile. It will open the file. Add the following line to it:
export PATH="/usr/local/bin:$PATH"
Save and close (ctrl+X, Y then enter). Let’s make sure we reload the new file now with source .bash_profile in the terminal.
We need to install PHP 7.0 using Homebrew:
brew install homebrew/php/php70
We also need to install a database:
brew install mariadb
Valet requires Composer to work. If you don’t have it installed on your computer, run this in your terminal to get the latest Composer version:
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('SHA384', 'composer-setup.php') === 'aa96f26c2b67226a324c27919f1eb05f21c248b987e6195cad9690d5c1ff713d53020a02ac8c217dbf90a7eacc9d141d') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"
mv composer.phar /usr/local/bin/composer
First of all, we need to make sure we can install Valet.
From the terminal, enter sudo nano .bash_profile. Once the file is open, add a new line to it:
export PATH="$PATH:$HOME/.composer/vendor/bin"
Save and close the file (ctrl+X, Y then enter). Reload the new file with source .bash_profile in the terminal.
Now we can continue our installation:
composer global require laravel/valet
Once it’s done you will see a success message like so: Writing lock file. Generating autoload files.
Now we need to finalize the installation of Valet:
valet install
After a moment you should get a Valet installed successfully! message.
That’s it. Valet is installed and is running.
To start using Valet, you need to “park” it. Go to a folder containing all you sites, e.g. cd /Sites/, and simply type valet park. From now on, all the folders inside this Site folder will get a .dev URL. So for example, a folder named MyAwesomeWordPressSite will be accessible from http://myawesomewordpresssite.dev.
I downloaded the latest version of WordPress and created a new folder called… WordPress. So when I type wordpress.dev in my browser I’m being redirected to my WordPress site. On the first launch, you will have to install WordPress the same way you’d do on a server.
First of all, we need to start the MySQL server so in your terminal just enter mysql.server start. This step is pretty much the equivalent of vagrant up. You will have to do it every time you want to work. To turn it off just enter mysql.server stop (just like vagrant halt).
Then you will need a MySQL database.
In the terminal, run: (whatever is the name of our database here)
mysql -uroot CREATE DATABASE whatever; exit
If you prefer a GUI, I would recommend Sequel Pro to create and manage my databases. It’s free and it has a simple interface.
Name: Valet (can be anything) Host: 127.0.0.1 Username: root Password: leave it blank!
Now we can proceed with the WordPress installation.
If you run into an error like Fatal error: Uncaught phpmailerException: Invalid address: wordpress@ we need to update the WordPress driver. In the terminal run:
sudo nano ~/.composer/vendor/laravel/valet/cli/drivers/WordPressValetDriver.php
Add within frontControllerPath:
$_SERVER['SERVER_NAME'] = $siteName.'.dev';
Save and close the file (ctrl+X, Y then enter).
And that’s it… You’re done.
You can also have a Trunk version of WordPress. Just create a new folder (still in Sites), e.g. WordPress-Trunk, and checkout WordPress.
cd /Sites/WordPress-Trunk svn co https://develop.svn.wordpress.org/trunk/src/ .
So every time you want to update this install all you need to do is:
cd /Sites/WordPress-Trunk/src/ svn up
If you now go to http://wordpress-trunk.dev, you will see an error 404 because Valet doesn’t understand it’s a WordPress site. No worries. You just need to link the src folder to Valet (where the actual WordPress site is).
cd /Sites/WordPress-Trunk/src/ valet link
Now you can access Trunk via http://src.dev. As it’s not ideal as a URL let’s rename it to http://trunk-wordpress.dev:
mv ~/.valet/Sites/src ~/.valet/Sites/trunk-wordpress
Et voilà! You can access you freshly downloaded WordPress Trunk install in your browser with http://trunk-wordpress.dev.
