I had the privlidge of attending JSConf 2014 with the always-classy @wilson353. Here is the recap in pictures.
And a panoramic:
And a few videos:
I’m currently working on a website with a custom portfolio section. It’s making use of a custom post type called
project and two attached custom taxonomies called
service. The portfolio page exists here:
displaying all the projects. Each project live here:
Everything was going fine until I realized that my custom taxonomies were not as separated from the main blog as I would like them to be. Consider the following taxonomy archive URLs:
and the very similar pages already on the site:
etc. What I needed to do was to group the taxonomy archives under the portfolio page in the URL structure, turning
But how does one prefix a custom taxonomy URL in WordPress with a static value such as ‘
/portfolio/‘ ? The answer is pretty easy, it turns out.
All you need to do is add the static prefix value to the slug portion of the rewrite argument when registering the taxonomy. For example:
$serviceArgs = array( 'labels' => $serviceLabels, 'query_var' => 'service', 'rewrite' => array( 'slug' => 'portfolio/service' ) //was 'service' ); register_taxonomy( 'project_service', null, $serviceArgs );
After you make the update, flush your rewrite rules and you are good to go!
More info on register_taxonomy().
I’ve been attempting to move my localhost development copy of a WordPress environment to a test site on a client’s server. When talking it over with the team, we decided that the test site should be a WordPress network with one site for testing, and one site for production. This will allow for a much more manageable environment in the future, but presents an initial problem.
I want to do a database transfer from my localhost WordPress install to a web server running a WordPress network. However, I can’t blindly drop the DB and import my own because multiple options are set differently and there are extra tables in the network DB. I would use an export / import with the XML file, but that wouldn’t be able to download my media files, not to mention the plugin configuration & widget settings.
After mulling it over a bit, the easy solution hit me.
Why not first restore my localhost WordPress DB to a single install on a web server, then use the export / import XML on the network! I’m still out the plugin settings, but at least my media files can be downloaded. For this particular project, the site had hundreds of media files and 1 plugin, so I figured that option was close enough. Here are the steps I took in list form:
I was in OfficeMax the other day looking at new tablets and saw a setting on a tablet’s browser that said “format web pages to fit this screen”. That was the scariest setting I have ever seen in my life. Whereas styling and formatting have previously been solely in the hands of the web designer – it is now shifting to the user. Thus the age of the responsive website is here.
With the appearance of tablets, iPhones, and Andriods, the idea of a website being viewed at a single, desktop-sized resolution is going the way of the chimney sweep and IE6. Websites must be able to adapt fluidly to multiple resolutions or respond, rather, to different screens.
Redesigning my portfolio website seemed like a good way to get my feet wet in responsive web design, primarily because I now have a smartphone and time to kill. Let me show you what I’ve done to danielhoenes.com. The pictures are about to get meta in here, so hold on.
Firstly, some decision making was in order. I was really fond of my WordPress theme, Showcase, because of it’s attractive typography and custom post types (projects & portfolios). However, it had a nasty habit not being responsive. I decided to remake Showcase instead of starting with a new theme from sratch. The goal was to make it better, stronger, faster, etc.
Showcase used a 960px grid for layout, but immediately that wasn’t going to work, so I went through all the theme files and restructured (more-or-less) the grid to use percentage-based widths, margins, etc. Thankfully, there were a few good tutorials on fluid layouts and styling techniques.
In case you are curious, the page’s wrapper element gets a max-width set in ems (a relative unit) and all its children follow the formula “target / context = result”.
Secondly, it was just a matter of deciding how I wanted it to look on devices with narrower screens. The best source of inspiration for this was an exciting website I found on the topic, mediaqueri.es. I’ve taken my best guess on the ideal content flow and pushed the sidebar past the main content for tablet widths and smaller.
Heavily using the
float:left; css, I was able to make the discrete page elements play nice with each other in tight spaces. With two out of three formats down, all I had left was phone-sized styling. Thankfully, it wasn’t much different from the tablet rules. I changed some heading text sizes and margins, but nothing major.
One last noteworthy item would be the issue of image resizing. When you get down to the low width of a phone screen, some images are bigger than the page can handle. While there are 22 ways to handle responsive images, I chose a simple WordPress Plugin (WP Fluid Images) for the present time. Though if anyone would like to discuss techniques in the comments, I’m all ears.
So, I’ve spent most of the day with my good friend, Mr. Anchor Tag, and I thought I would share something I have learned about him today. Primarily…
Quick, what is the difference between <a href=”page.html”> and <a href=”/page.html”> ? It’s totally the beginning slash (/) before “page”. But does this make a difference? Turns out, yes it does. The first link without the slash is a relative link – the server will give the requested file from the same directory as the file that contains the link. The second link containing the beginning slash is called an absolute link. This means that the server will start from your website’s document root (www.example.com) instead of the current directory. For example, suppose the page containing these links is located at www.example.com/stuff/index.html. The link, <a href=”page.html”>, will go to www.example.com/stuff/page.html if the server has it. However, the link, <a href=”/page.html”> will go to www.example.com/page.html.
I’m Glad you asked. Suppose you are editing a page that is going to end up at danielhoenes.com/2011/12/archives/whatever/tag/blah or perhaps you are using a web application or CMS that is going to display your page at different URLS. The shortest way to link to a fixed resource (such as danielhoenes.com/logo.gif) is to use the /absolute link. No matter which sub directory your page gets put, the static resource will be found. You could also just include your whole domain in the link (http://www.example.com), but that is at least 10 extra characters and another problem. Domain dependency. Suppose you are now sitting between multiple domains. Your client has said “hey, I’d like to use this theme you are making me on tomatos.com and relish.com. Can you make that happen?” Well, with the absolute link – you can.