Later, I learned that the problem wasn’t always the developer; often it was a misunderstanding due to a client’s lack of code knowledge. After explaining that Microsoft doesn’t even support Windows XP and IE7, and that turning each mockup into a functional prototype could take at least five additional unpaid hours, the light would come on and the apologies would flow. If you’re a future website owner or prepping for an online rebrand, you don’t have to know how to build your own website, but you should at least know a little bit of code. Just in case you still don’t believe, here are a few reasons why everyone should:
The quest for knowledge is never-ending. We all want to be masters in our respective fields, but we also know that there is, especially in the tech universe, an ever-expanding number of things to bone up on. So, how do we get there? How do we learn every single thing we need to know? Let’s find out!
The holiday swing is getting kicked off right with WordCamp Saratoga Springs this weekend on November 21st! Damon will be there; he is one of the organizers and kicked butt to make this happen!
Although I find it hard to believe that any of our regular readers are unfamiliar with WordCamp (come on, now!), for those of you that are completely green: WordCamps are events held all over the world where WordPress nerds unite to share their skills, insights, and learn a whole lot from a bunch of other smarties.
We picked out a few sessions that especially caught our eye, although we know they are all going to be amazing. If you’re going, make sure to grab Damon and say hello!
Designers face many challenges that are often discussed and pontificated on, from Grunt to typography. What’s worth emphasizing is what happens before and after the design is created. Design isn’t just about one thing, and in order to be a designer of any consequence one must be able to sell.
How could this have happened? You planned so well! And let’s be real: you’ve probably made the most perfect project plan you’ve ever constructed…at least since the last one. How could someone have such a disregard for this picture of perfection you’ve worked so hard to achieve?
I’m just going to come out and say it: This will happen (to some degree) with any project your team will embark on. The true test is how you roll with the punches. Here’s a few tried and true ways you can keep your team on track and pivot with the best of them!
“Harmonious” may not be the word a lot of clients and agencies/freelancers would use to describe their relationship. Perhaps many would even land on a more negative term. Why is it that we hear of the bad cases so much more often than the good ones? Are designers and stakeholders simply destined to be nemeses, playing an eternal game of tug-of-war over button placement? Are developers and clients set to battle over feature bloat until the end of time? Personally, that doesn’t sound fun or productive to me. I’d like to propose a better way of doing things. First, let’s get a few misconceptions out of the way.
Out of the box, WordPress has pretty great support for external object-cache implementations. Even its built-in object-caching helps WordPress be more performant and avoids redundant non-performant function calls and DB lookups.
One of the challenges we have faced at WebDevStudios is the way WordPress handles including/loading an external object cache and determining whether the default implementation is used. I won’t go into all the details, but the part we have had issues with is the fact that if there is an object-cache.php file in the wp-content directory, WordPress assumes an external object cache exists and it should not include or perform its built-in object-caching implementation.
After each major release of BuddyPress, the BP community discusses (in the Slack channel!) what to include in the following release. BuddyPress 2.4 is no different and includes a few new bells and whistles.
We recently completed a site for a client with content in several languages. I’m no stranger to internationalization, but the majority of multilingual sites I’ve worked on used a default language and then included content in only one or two more languages. This time around, the client had content available in English, Russian, Chinese, German and a few others that also used a Latin character set.
The design comps used a web-safe non-system font called Canaro, which we set as the default in our sans-serif font stack. The client provided a Chinese language font that was unfortunately not web-safe, so we set Hiragino Sans GB and Microsoft YaHei as the other two fonts in the stack.
Hiragino is a beautiful font and the latest version of OSX El Capitan does some pretty nifty stuff with it when you’re typing in Japanese (so I hear). However, we started to get bug reports that the Russian language site was looking a little odd in Safari on OS X.