Multilingual websites are becoming more and more common these days as WordPress becomes increasing popular and even more powerful with an enormous community. When starting out a multilingual site, there are a number of things to consider and some important elements to keep in mind from the very early stages of the project. In this post, I’ll try and highlight just a few main things, as every site (or Multisite) installation will, of course, vary on a per project basis.
I love Sass, and I love using icon fonts.
However, I do not like the limitations of using inline non-semantic, presentational markup to place these wonderful symbols, e.g.
<i class="fa fa-trash-o"></i>
What if we could keep the embellishments in our stylesheet, minimize the HTML markup, and keep things a bit more semantic?
I think we can, and this is what we’ll accomplish in a few steps. I first came across this approach from Jayden Seric’s post, Fun With Sass & Font Icons.
We’ll be using the Font Awesome icon library for this example. Font Awesome offers a comprehensive library of icons, and they’re all free and GPL compatible.
Have you ever wanted to add a filterable portfolio to your personal site to showcase your content? In this post, we’re going to include simple scripts for you to add to your existing theme to help make it easy to add a filterable portfolio to your project.
Tools you’ll need:
Recently Chris Reynolds brought up an issue he was experiencing with one of our client projects; he was struggling to compare the current active status for plugins in a multisite network between internal dev servers and a WPEngine staging site so that he could debug some issues that were occurring.
Everyone on the project wondered if there was some easy way that we could get a snapshot of what each install had going on. The only requirement that Chris wanted was an easy copy/paste way to get the cumulative status from each so he could compare side by side. This set my brain running and I was granted the task to explore what could be done to accomplish this.
We’re excited to say that several members of the WebDevStudios team will be in attendance at PressNomics 2015! It’s almost here!
For those of you who aren’t familiar:
PressNomics is a conference that was started by Joshua Strebel, CEO of Page.ly, in an effort to create a space where the economics of WordPress could be discussed by the “who’s who” of WordPress business owners and innovators.
WDS has attended for the last few years, and our own Dre Armeda is known as “The Godfather” of PressNomics. After all, the idea for PressNomics was inspired by some good old-fashioned Skype brainstorming over whiskey and “Josh-tinis” (ingredients: top-secret) about what Joshua and Dre would like to see develop in the WordPress community. While Dre was focused on WordCamp San Diego, Joshua stepped forward to make their vision a reality, and PressNomics was born.
The first PressNomics started with a mere 125 attendees, but in a few short years, has grown dramatically. This next PressNomics is anticipating 270 WordPress minded folk to skill-share, network, and examine the industry that has been born of our favorite platform’s flexibility.
Will we see you there? If so, make sure to let us know! Brad, Lisa, and Dre will be in attendance; be sure to say hi if you can! We’ve created a small resource guide below–here’s a few things you definitely don’t want to miss (oh, and a few places you’ll be able to track us down for that hello!):
When I think about a few “game-changers” in regards to how I build websites today compared to ten years ago, I would have to say that WordPress and Sass have completely enhanced the efficiency of my workflow as a designer. One of my favorite features in Sass is the ability to write inline media queries. While there are a number of methods, determining which is best for you and your team is just a matter of coding style and personal preference.
Hands down, the greatest benefit from using inline media queries is the speed of writing and maintaining code. Imagine this scenario:
Imagine this scenario:
You need to make a change to the main navigation so you edit
nav.scss only to wonder why you don’t see the changes you just made to the menu items. Taking another look at your sass partials, you realize you may have to edit some, or maybe all of these files in order for your change to display properly.
Inline media queries allows you to write and edit each selector in one place. This gives you a much better grasp on what every element is doing at any breakpoint.
The only downside is there isn’t an ideal way to intelligently combine media queries during post-processing. While there are some methods and tools available, I think the issue could use another resolution. On the other hand, leaving these inline media queries in your compiled CSS does not seem to affect performance too much.
Custom Post Type UI has been around for the better part of five years and is one of WebDevStudios’ oldest plugins in the WordPress.org repo. It has amassed over 640,000 downloads and maintains a rating of 4.6 out of 5 stars.
Since its initial release, it has largely maintained the same user interface and has only had minor tweaks through its evolution. However, that consistency meant it hasn’t kept up with the evolution of the WordPress admin since the days of WordPress 3.0, including the huge change from WordPress 3.8.
As a result, I wanted to give the the plugin a UI overhaul for the next major release, and I hope the new version provides a better, more easy to use user experience for our existing and future users. I also used it as a chance to refactor the existing code and make it more maintainable and customizable by 3rd parties. Everyone wins!
However, I need beta testers to make sure the upgrade goes smoothly and no settings are lost in the transition from 0.8.5 to 0.9.0. I also need new users to make sure it’s usable and not confusing.
That’s where YOU come in!
Things I need tested by both current and new users include:
- Seemless migration from 0.8.x to 0.9.0. No behavior lost. The migration will be automatic, but making sure the provided settings match in the new UI needs to be checked.
- If you have existing post types or taxonomies registered by CPTUI 0.8.x, check that their behavior remains as it was before.
- Importing and exporting between sites using 0.9.0. This will be one of the new menu items available, and all of the data should be provided for you automatically–you just need to have a post type or taxonomy set up on one site, and not on another before clicking import.
- Get code functionality. This one should be familiar to you already from the previous versions, but we need it to provide all of the expected values when set, and not empty values when not set.
- General usability of the new UI. Is it more clear how to do things? Worse?
- If you have multisite, that needs a really good tire kick that I will be doing myself as well soon.
- Any bugs you find.
- Translation updates, if you’re fluent in more than one language.
When I started doing web development, I think I started the way a lot of us did. You have a site you want to work on, so you connect with FTP, download a file, modify it, upload it back up, and then refresh the page to see if your changes worked. This process doesn’t really work when you’re working with a team of people, or on a site that people are actively going to. If your teammate edits the same file as you, someone’s changes may be lost, and if you upload something with an error in it, you may break the site for people currently browsing it. This isn’t a fun process.
The solution to combat this “cowboy coding” is to not work directly on a server, but rather on a server that is on your local machine. There are a ton of ways to do this, and I’ll walk you through what I do.
When doing any sort of design or development, you want to work locally. This is the best way to develop, and has tons of benefits. Like these:
- Faster. No waiting for files to upload via FTP before you can refresh your browser and see your changes.
- Easier debugging. Because everything is running on your system, setting up and using xDebug or other debugging tools is quite a bit easier.
- Don’t need an internet connection work on things.
- Less fear of screwing up. When working locally, you’re free to experiment and play around, as your work is not affecting current users.
I use Vagrant and a nifty tool called Varying Vagrant Vagrants (VVV) to power my local development. This, coupled with some tools I’ve written to make my life easier, is a very enjoyable way to work locally. I’ll walk through setting up VVV, as well as a helper tool VV, and how to use both.
If you’re a long time WebDevStudios fan and/or one of the brilliant people we’ve had the fortune of connecting with through the WordPress community, you’re probably familiar with the Professional WordPress books written by Brad Williams, David Damstra, and Hal Stern. The third edition of Professional WordPress is set to be released this Thursday, January 15th, and we could not be more excited about it!
In honor of the book’s release, we’re giving away one copy of Professional WordPress (signed by Brad Williams) and one Raspberry Pi, a nifty little credit card sized computer (you can read more about it here) for your own tinkering.
I sat down with Brad and asked him a few questions about Professional WordPress and working with WordPress in general. Read his sage WP insight below, and then use the Rafflecopter link below to enter yourself in the giveaway.
If you were wondering whether WebDevStudios has a new look, you have one keen eye! What better time to start fresh than at the beginning of the year? For many folks, the new year is a time for reflection, reassessment, and setting the bar that we each measure ourselves by just a little bit higher, and WDS is no exception.
We have been around for quite some time now; for those of you who aren’t familiar with our history, WDS started as a two man operation that is now a team of over thirty folks. The site you are familiar with has been our mainstay (with a few updates here and there) for the last five years; we’ve grown so much since then and we wanted to launch a new site that reflected not only who we’ve become, but who we plan to be.