Using Images in WordPress – Best Practices

I’m not a novice to WordPress Theme Design & Development. I’ve actually been doing it for a few years now and in recent years, it has become more than a hobby and is slowing shaping into a career choice.

However, I have a somewhat simple yet puzzling question to ask here…

Read More

Forever, I’ve been uploading the images I use through my custom themes into their own “img” or “images” directory under the themes directory under wp-content. Of course, for posts I just used the Media Uploader built within WordPress itself.

But, now that I’m trying to be more professional and produce grade-A work consistently I recently thought about how I handle my images. You see, using my old method I also did NOT use WordPress template tags for the image paths. I was doing the old fashion HTML method with it’s relative path and if I encountered a problem, I just put the WHOLE path in there to save time. That is a huge no, no. I’m well aware but this wasn’t client work…

Anyway, to get to my point – what IS the best practice for using images in WordPress? I’m now beginning to think more inline with this process:

For theme development I now have a “inc” directory within my theme’s directory that then has a “imgs” and “js” directories, etc. When designing the theme, I’m now using WordPress template tags for my paths to work properly throughout the theme. For my posts, I’m still using the Media Uploader and the normal /upload directory.

Is my new method the best practice? Thank you!! Again, I’m just trying to clean up my workflow and methods so I’m more in-line with the Codex and other top tier WordPress projects out there.

Thanks!

Related posts

Leave a Reply

3 comments

  1. I guess from the question you are asking, is there a way to code the image url that is better than typing in the whole url? This is what I do, to ensure that if the domain name ever changes…(which they do in my work because I always build the sites on a project domain and then move them over), you will want to do it this way:

    <img src="<?php echo get_bloginfo('template_url'); ?>/images/image-name.jpg alt="whatever" />
    

    You can also use this (and yes I know it is not the technically correct way to call css) when using css in a template:

    <style>
    #div {
         background-image: url(<?php echo get_bloginfo('template_url'); ?>/images/image-name.jpg);
    }
    </style>
    

    It works for inline css as well:

    <h2 style="background-image: url(<?php echo get_bloginfo('template_url'); ?>/images/image-name.jpg);">Some Title</h2>
    

    I think this is what you were asking…

  2. In my opnion, yes you are using it right. I always think in 2 main things when i develop wordpress themes:

    • Make it easy for my client
    • Make it portable

    I mean that you always use site_url() and all kinds of functions provided by wordpress instead of hardcoding urls. So if your client wants to move the theme to another domain it wont brake.

    For javascript and stylesheet be sure to use wp_enqueue_scripts and wp_enqueue_style
    and be sure that you include them only on the needed pages. This apply to front and back end. One of the worst and popular practice is to includes files everywhere no matter is we need them or not, making the site slow and unoptimized.

    So really no matter if you you /inc /assets or whatever you feel more confortable but its always nice to have all organized, and will help a lot if external people need to edit your theme.

  3. Your description sounds like a fine practice.

    A good rule of thumb is to use a WordPress function instead of hard-coding or custom-coding whenever possible. That way you achieve full portability to any WordPress installation regardless of any plugins or other dependencies. How you structure files within your theme’s directory is entirely up to you, but for ease of maintenance and scalability your method is a good one. Just make sure, as it sounds like you already are, that any paths to resources are utilizing WordPress functions to write the URLs.