The default howdy greeting

The default howdy greeting

I like the WordPress ‘howdy’ greeting. It’s friendly and it usually makes me smile when I login to the admin dashboard. But for some clients, something a bit more elegant is in order.

Changing the text of the greeting is easy if you’re willing to get into the theme files. All you need to do is open up functions.php in your theme’s folder and add this code snippet:

Replace ‘Hello,’ with the message of your choice.

Replace the WordPress ‘howdy’ with a timely message that’s more personalized for you.

Or if you want something a little more fancy, we can set it to include a message appropriate to the time of day. To do that put this in functions.php:

New modified WordPress greeting

New modified WordPress greeting

For this one, you’ll need to replace the date_default_timezone_set with your own timezone (assuming you’re the admin). You can find a list of PHP-style timezone formats here. Then you may want to change the hours and the contents of $msg to fit your needs or language.

One issue with timezones – there’s no way to detect them automatically with an HTTP header and other methods like geolocation can be problematic. If you have a number of admins in different regions, you can try using this script to detect the timezone and modify the code above to include that so that the timezone will change for admins as they login, but that’s a bit beyond this simple tutorial.

I used to use respond.js to make IE8 media query-friendly, but that script stopped working for me suddenly last week in WordPress. I still don’t know why, but after several hours of trying to fix it I realized that I really didn’t need to. Why was I worried about media queries in IE8 anyway? I really wasn’t – my real concern was that I was serving the mobile-first styles to that browser instead of the desktop styles.

But I’m using Sass – have been for a few months now, I love it – and Sass makes it easy to deal with that problem. It’ll help you create desktop styles, sans media queries, and serve those exclusively to IE8 via conditional comments.

I found some good references for how to do this, but I was so frustrated by that time (it was late and I’d been banging my head on the desk for an hour or two) I had a hard time getting my head around any of them. Once I finally got it, it was an ‘aha’ moment! I’m writing this post in hopes that I can make it super-easy for you to use this technique if you’ve recently had a frustrating time with IE8 too.

Compass and Breakpoint

You’ll need to use Compass and the Breakpoint extension for this tutorial. Breakpoint is a Sass mixin that makes it easy to write media queries – learn more about what Breakpoint does here.

Get Breakpoint going by first installing it:

Then if you’re starting a new project with Compass, you can require it now:

Otherwise you’ll need to add this line to your existing config.rb file in your project folder:

Finally, you’ll need to import the Breakpoint partial into your style.scss file (after you import Compass):

And you’re ready to go.

Creating the Media Queries and IE8 Fallbacks

In your utility partial, or maybe in a variables file, add a media query using Breakpoint. It will look like this assuming we want a min-width of 760px:

(Read the examples here if you want more details on the different kinds of media queries you can use).

Now normally you’d use this in your .scss files like this:

And that produces this compiled CSS:

But because we want to take care of old IE by not serving the media queries to it, you’ll first need to add this new mixin to your utilities file (wherever you’ve put the Breakpoint media queries):

And then instead of the @include snippet above, you’ll use this one in your .scss files:

So instead of ‘@include breakpoint($grande)’ you’re using ‘@include grande.’

If you look in the compiled CSS file you’ll see this:

And then, you’ll just need to enable the .ie8 class for IE8 by using this conditional comment in the head section of your site:

Now IE8 will see your width styles and you won’t need to worry about it not seeing the media queries anymore. Sweet!

What you’ll want to do is create one of the new mixins for each breakpoint you add – so if you have 5 breakpoints, you’ll have 5 new mixins.

This works so nicely, and no need for any special Javascript to force IE8 to be mq-friendly. I hope you found this tutorial helpful!

References:

 

Recently I developed a WordPress site that uses a custom post type for Events. This is a typical event page – note the More Info section in the left sidebar.

The client needed to be able to insert a list of links under More Info, and the number of links will change for every event. I needed a way to make this super-simple for the client, so in the Events custom post editor, the links are entered one per line like so:

Then, I needed to convert that line break-delimited list into an unordered list for formatting… I had no idea how to do that but after some hunting around I found this post that completely answered my questions.

Then in my single-events.php template, I have this section including the wonderful code snippet from wordpressismypuppet that converts the entries into a standard unordered list:

So now the result is a ul under ‘More Info.’ formatted to match the other sidebar widgets. The client has a bare minimum of HTML to contend with and has control over what appears in the list – everyone’s happy!

After Denver WordCamp back in November and a really well-done presentation by Jeremy Green, I decided it was finally time to dive into Git.

As a mostly-solo developer, I’ve felt ambivalent about it, but I know that it’s very important, if not critical, when working with a larger team. So…

I got my OS version of Git here. I’m not much of a command-line person so I also checked out some of the GUIs – the one that I liked (not knowing anything about it yet except that it had a pretty nice UI) was SourceTree from Atlassian. Jeremy had talked about BitBucket being a good choice for hosting private repos, and Atlassian also makes BitBucket. Seemed logical.

Then I looked at some resources and started with this one: TryGit. I liked ts friendly UI and the step-through examples, it was easy to get going but it quickly got into more advanced areas (I’m not there yet). This was a good starting point.

So in the next WordPress project, I resolved to just jump in and do this. Note: this is super-basic – I’m only using this on my local machine at the moment, so bear with me. This is for total newbies.

I opened up GitBash (the included SSH editor), navigated to my project folder and typed in:

This creates a fresh new repository (repo) of project files.

Then I’ll work on stuff for awhile. I can check out what’s happening with Git by typing:

This will show me a list of all the files in my project that have either not been added to Git, or have changed since the last time I added them. To add a file to Git so that it’s monitored, type:

But it’s easier to just add all the files at once:

Then check status again and you’ll see a list of files that are staged – they’re ready to commit, which means adding them to the repository. To commit all the files in staging:

Name your commits anything you like, just make it descriptive. You can view all your commits with:

Then I work some more, and when I get to a point where I feel I can give my commit a different name (i.e. I’ve finished a task), I type:

And so on. That’s it – very easy, not too intimidating with the command line, and you’ve removed so much risk with just these simple steps. I actually haven’t used the SourceTree GUI yet – for what I’ve done so far, I’m now happy with the command line.

Now that this process has become fairly automatic for me, my next step is going to be setting up a remote repo, probably with BitBucket, and learning how to do those parts of Git. And how to make branches.