Nicholas Rowe | Front End Developer & Designer

Today I had to create a little landing page for one of our clients. one of the requirements was to have the landing page fill the screen no matter what height the viewport was. So this would fill the space up on a desktop, iPad for example.

I stumbled across a handy piece of jQquery that makes use of jQuery height element, below is the snippet:

function stretch_pc() {
var height = $(window).height();
var stretch = (80 * height) / 100;
thirtypc = parseInt(thirtypc) + 'px';
$("div").css('height',stretch);
}

$(document).ready(function() {
stretch_pc();
$(window).bind('resize', stretch_pc);
});

This is essentially a function that is defining two variables height and stretch. The height variable is simply just finding the height of the windows viewport. By reading the jQuery documentation here

The difference between .css('height') and .height() is that the latter returns a unit-less pixel value (for example, 400) while the former returns a value with units intact (for example, 400px). The .height() method is recommended when an element’s height needs to be used in a mathematical calculation.

The second variable stretch is going to be 80 percent of the viewport  * the height of the document and then divided by 100 to give us 80 percent of the viewport height. You may change 80 to match whatever you find sufficient, I opted for this as the height element does not take in to account any padding or margin, so you will get a bit of excess if you decide to have these in your css.

Lastly, after the function, the jquery will load on the document ready and initialise the function, making the ‘div’ height match the percentage defined in the function.

Further reading: jQuery Documentation

Source: link

As of recently, Internet explorer is no longer the #1 internet browser in the UK. Research shows that google chrome has now slightly surpassed Microsofts dominating commercial browser. Web designers rejoice!

• query_posts() function is commonly thought of as the simplistic and problematic way forward to modify a main query of a page by replacing it with a new instance of the particular query. It is bad practice as it re runs SQL queries and will simply not work and fail in some circumstances, this usually happens when dealing with post pagination. In the older versions of plugins and themes, this method will seen more, but it is strongly advised that any modern WP code should use more reliable methods; such as utilising the pre_get_posts hook.
• get_posts() function is a similar way to query in terms of usage and it accepts the same arguments with some minor differences such as the defaults of the query. It stil returns an array of posts but the important thing to remember is it doesn’t modify global variables and it is safe to use anywhere.
• WP_Query object drives both of the above queries behind the scenes, but you can also create and work this object on it own. It can be considered a little more complex as it has less restrictions and can have more possibilities, this object, as above is safe to use anywhere.

Original – Link

I strongly believe it comes down to your project, the scope and the functionality behind it all. The real question is about your clients needs and wants, ask yourself this:

- Updates - Are they going to want to do the editing themselves down the line?

I think one of the best aspects about a CMS is in it’s name. *A content management system*. Years ago when CMS were a lot more scarce than they are now, I used to have clients always come to me with questions like

 “I can’t update my website!”

 “I’ve got to get my webmaster to do that, but it’s going to cost me…”,

I used to be almost stumped when clients were reluctant to pay for changes to their websites and wanted some minor changes, I didn’t mind to do them myself but I always used to dream of a way that maybe they could go in to Dreamweaver and update the tables them self! Anyway that is kind of off topic, but I was trying to get at the point that a CMS offers easy content management with a WYSIWYG text editor to the user in which they can log in and make the changes them self with little to no knowledge of html/css and being IT savvy.

-  Time scale – why rewrite code that is already written? Save yourself some time with a CMS. (maybe a lot of time?)
- **Out of the box website** – A CMS such a wordpress/drupal/joomla can really save yourself some hard work and time. If you can just get the website that the client is needed, just rework the design to match the clients branding whilst still retaining the fundamentals.

- In built SEO – With the web becoming more popular for companies to have an on-line presence, obviously more websites are competing in the rankings. CMS such as wordpress bring a lot of in build pre packed SEO features that can save time and effort in the long run, neddless to say they aren’t by any means perfect with SEO, but In fact Google’s own Matt Cutts says WordPress is “made to do SEO well”. Source

- Support – I think this area of a CMS kind of gets overshadowed a little too much, when I have worked with a CMS in the past, may it be Umbraco (One of the best ever support communities!), WordPress, Drupal. They all offer great support on their forums, these guys have saved me countless hours by helping me with something on the forums. Props. Don’t be shy to ask for help! With these communities it is easy to develop your website and create additional features on your website. You will be surprised how much you learn by getting help from someone.

- Fast installations – All this may seems good but if you are unsure about setting up a CMS it may be a daunting idea in the beginning, don’t be put off though, I would say the majority of web hosting companies these days off the famous one click install software where a CMS such a wordpress, drupal etc can all be installed in a matter of seconds ready to go.

Overall I would say if you are doing small projects for yourself and you enjoy writing code, the fine, stick with the coffee and HTML editor, it’s fun and can be quite enjoyable learning the ins and outs of all kinds of coding from scratch. But personally I think the main benefit about a CMS is *time*. It does pretty much everything you want out the box and allows fast and easy development.

What are your thoughts on using a CMS? Do you ALWAYS use them? When do you and don’t you? I would love to hear your opinions on them.

I’m about to go all WordPress Geek 2.5 on y’all now. So, if you don’t want to look at PHP code or have no clue what a widget is, then you might want to take a break from this post.

WordPress theme developers. Pay attention.

Ian Stewart just created the “we need to kill the sidebar bandwagon,” and it’s about time you all hopped on.

The basic idea is that with all the things we can do with widgets, it makes no sense to call these widgetized sections sidebars at all. Why would we call a footer or a header widget area “Footer Sidebar” or “Header Sidebar”? You can even vote on this idea.

Since a few of you requested it, I’ll give you a tutorial on how to take full advantage of WordPress 2.5′s new widget interface.

The setup

This is totally new code straight from the development versions of my old and new themes.

The first thing you need to decide is what you want to widgetize. For the sake of this tutorial and the No Sidebar Bandwagon, let’s pretend our theme has no sidebars at all. I’ll try to avoid using the term “sidebar” as much as possible.

I’m going to keep this real simple. Here’s what our page layout will look like:

Header
Content Area
Footer
Each of these sections is widgetized. Take a look at what the setup of the basic page and widget panel will look like (click images for larger view):

Page Layout

Widget Panel
Adding widgets to the widget panel

Now, we need to put together a bunch of widgetized areas for our widget panel in the WordPress dashboard. Typically, we’ll put these in the functions.php file of the theme we’re using.

I’ve found the best way to do this, which is a lot less coding, is to create an array of all the sidebars we want to use. Plus, it’s much cooler.

Note: This tutorial uses text strings that are ready for localization.

<!--?php /***************************************************** Pimp out this page with an endless amount of widget sections. *****************************************************/ if(function_exists('register_sidebar')) { // Create widget names and put them in array 	$my_widget_name = array( 		__('Header'), 		__('Content'), 		__('Footer'), 	); // Define how we want our widgets to display // Replace ridiculous list items with custom style 	foreach($my_widget_name as $my_widget) : 		register_sidebar(array( 			'name' =--> $my_widget,
'before_widget' =&gt; '
<div id="%1$s" class="widget %2$s">',
'after_widget' =&gt; '</div>
',
'before_title' =&gt; '
<h3 class="widget-title">',
'after_title' =&gt; '</h3>
', ));
endforeach;
} ?&gt;

 
If that seemed a bit complicated, let me break the process down a bit. We’re first creating an array of all our widgetized sections. The reason we’re doing this is because we don’t want to have to write the second part of the code over and over and over. So, for the second part, we just loop through each widget section and register it.

Displaying your widgets on your blog

I’ll show you how to display this for your header section. It will be basically same for each of our sections.

<div id="header-widget-area">
	<?php dynamic_sidebar(__('Header')); ?>
</div>

Widgetize your site!

Now, you have the basic tools to widgtize your site in any way you want. You could create widgets for any section of any page you’d like. You could build a three-column all widget theme if you wanted. The only limit here is your preconceptions of what widgets are and what they can do.

WordPress’ built-in conditional tags are your friends. Use them.

If you’re using my Options theme, then I have a special tutorial for making many sidebars.

I encourage you all to start thinking about what more we can do with this.

JT - Original source