The Overview page, now shinier than ever

Following on from our initial announcement, I’m happy to announce we have a new version! We’ve listened to feedback and made many improvements. We’re also making expanding the closed beta! One of the points mentioned in feedback was the potential for extending the plugin, examples including Google Analytics traffic widgets on the overview page etc.

The second iteration now comes with more developer documentation explaining how to:

• Add your own events
• Use multiple event logs
• Custom logging outputs
• Custom html for logtable events
• Hook debugging tools

Although there are developer notes on the WordPress.org repository, we’ve decided to maintain a page here where we can possibly show a broader range of information in the future, depending on the take-up of the plugin.

Template tags

Spots provides 2 template tags for developers named icit_spot and icit_get_spot.

icit_spot

This template tag echos out a spot:

icit_spot( $id_or_name, $template );

It takes the following parameters:

• $id_or_name: Required. A numeric ID or the name of a spot as a string.
• $template: Optional. A string used in a call to get_template_part()

icit_get_spot

This template tag performs the same function, but it allows the developer to specify wether to echo the result, or return it as a variable:

icit_get_spot( $id_or_name, $template, $echo );

It takes the following extra parameter:

• $echo: Optional. Defaults to false. A boolean to indicate whether to echo the spot content or just return it.

Basic Usage

You can use spots to replace boilerplate text in your themes. If you have areas in your themes where typically you would hard code the text you could use the following code:

if ( function_exists( 'icit_spot' ) )
    icit_spot( 'Copyright' );

The above code would output the contents of a spot titled ‘Copyright’. If the spot does not exist it will be created as a draft. Spots in draft mode are only visible to logged in users with editing capabilities.

Templates

The plugin will initially look for a file in your theme using the get_template_part() function. If you have a file called spot.php in your theme that will be the default template for all spots. The icit_spot() function can take a second parameter for the template part to use for example:

if ( function_exists( 'icit_spot' ) )
    icit_spot( 'Copyright', 'copyright' );

The above code will make the plugin look in your theme folder for a file called spot-copyright.php to use for the output. If not available it will fall back to spot.php and if that is not available it will simply output the spot contents.

Use templates when you want to display a featured image from a spot or if you require some additional/alternative markup for the spot. Spots are just like posts, so in the templates you retrieve the contents of the spot using the_content() just as would in the loop.

Basic spot template example:

<div class="spot">
    <?php the_content(); ?>
</div> 

Spot template with featured image:

<div class="spot-with-image">
    <?php
    if ( has_post_thumbnail() )
        the_post_thumbnail( 'medium' );
    the_content(); ?>
</div> 

Additional

There are many filters and hooks available to get even more out of spots, so drop by the plugin homepage or use the forums if there is something you need to do with spots but aren’t sure how.

Typically Snarky Image (source not known - found all over the interwebs, so let me know if it's yours)

Online snark towards IE, particularly in Twitter, is really common and I keep seeing comments in my timeline like these:

Love that WordPress might be dropping IE6 support in 3.2. You might as well take care of IE7 while you’re at it.

- @jschuller

or

sometimes I wonder if going around the globe, uninstalling every single copy of IE, is less time-consuming than debugging

- @RobPoort

or

What’s sad is how much of a time suck #IE really is for developers. Think of the billions spent on just debugging for IE!

@Dr_Overdose

And they used to really wind me.  Happily they don’t any more.  I’m over it.

So why did they wind me up?  Because the amount of time and energy expended in whinging about Internet Explorer in the industry is ridiculous.  It hasn’t changed in five years either.  The whinging is still there. It just never stops. And it needs to.

It’s an Environment Problem, Stupid

This is where I’m going to no doubt draw some criticism, quite possibly from my colleagues even, but here goes:

Internet Explorer, from version 6, is as much a limiting part of our web environment as the potholes and bumps in our roads are a limiting part of car design.

A car designer is powerless to change the roads in your city or country, just like you and I are powerless to make enterprises change their browser of choice. They don’t care about whether it makes a bit of extra work for us, they care about how much extra work upgrading will be for them.

Of course we can take the moral high ground. IE8 is more secure than IE7. IE9 is faster and more standards compliant. Good, solid reasons for upgrading. But no more likely to be listened to than the advice a car designer from Lotus might give to Greece about the environmental and safety benefits that surfacing their roads to a higher standard might bring. Greece has other priorities than listening to a car designer, and enterprises have higher priorities than listening to the advice of web developers.

So What’s the Real Answer for Enterprise Users?

We found a very real problem for our clients – the back-end of WordPress is a pretty poor place to work in with IE6 and sometimes poor in IE7.  It’s usually passable in the latter, but in some enterprises we found that IE7 installs were so locked down that some functionality, particularly within third party plugins, just wouldn’t work well or was so slow as to be unusable.

In the end we recommended that content teams should be allowed to use Firefox or Google Chrome internally. In all cases so far this advice has been heeded. With Chrome it even has the advantage that it can be installed by users even on Windows PCs with very locked down permissions because of the way it’s coded to not need any admin access. That means you can probably get your content managers running a decent browser without any involvement from IT. Portable Apps on USB sticks can also be run, meaning Firefox and other tools can be made available.

But do check whether that might not be in breach of local IT rules – I wouldn’t want any of you to get into trouble now.

And for Web Developers and Designers?

In terms of web development we’re all going to have to do our best with progressive enhancement. The interconnect/it site works perfectly well in IE6, but has different features to when it’s view in Firefox, and different again if viewed in Chrome.

There are points when you have to make a judgement call. Is it worth supporting that last 5% using out of date browsers? Well, that depends. It’s simple maths – if, say, the cost of supporting a browser with 5% share of your site’s traffic is less than the profit you make from those visitors then you continue to support it. Don’t complain, just do it. That’s the only possible business case you have to make. It may not be fun, but if you’re a professional it’s the only thing you can do. If you’re a hobbyist then support whatever browser you feel like – it’s entirely your choice, and don’t feel obliged to support minority browsers when you’re not making any money from your sites.

1. Removing the auto capitalisation of ‘WordPress’

   When version  3.0 was released a fairly simple filter appeared called capital_P_dangit. This was committed to the core by Matt Mullenweg for the purposes of brand reinforcement. Suffice to say many in the community weren’t thrilled by this passive-aggressive pedantry for a multitude of very good reasons but that’s another story (you can read all about it in Justin Tadlock’s article on the subject).

   // remove capital_P_dangit
   foreach( array( 'the_content', 'the_title', 'comment_text' ) as $filter )
       remove_filter( $filter, 'capital_P_dangit' );

2. Change excerpt length

   The default excerpts in WordPress are reasonable but rarely fit with the design you are working to. Alter the number of characters returned in an excerpt with the following snippet.

   function theme_excerpt_length( $length ) {
       return 80; // 80 characters long
   }
   add_filter('excerpt_length', 'theme_excerpt_length');

3. Change the excerpt truncation text

   You can alter the text that appears at the point of truncation, ie. ‘[...]‘, to anything you want, including a useful link to the post page.

   function theme_excerpt_more( $more ) {
       global $post;
       return '&hellip; <a class="read-more" href="'. get_permalink($post->ID) . '">' . __('Continue reading') . '</a>';
   }
   add_filter('excerpt_more', 'theme_excerpt_more');

4. Adding contact methods to the user profile

   On every recent project we have had there has been a need for extra user data, such as Twitter username, FaceBook URL and so on. The user profile screen can be edited using a combination of action hooks but WordPress also has a very simple way to add extra contact methods.

   function more_contactmethods( $contactmethods ) {
       $contactmethods['twitter'] = 'Twitter username';
       $contactmethods['facebook'] = 'Facebook URL';
       return $contactmethods;
   }
   add_filter( 'user_contactmethods', 'more_contactmethods' );

5. Removing the inline stylesheet from galleries

   By default WordPress spits out an inline stylesheet whenever the gallery shortcode is used within a post. The reasoning is that users can control the number of columns each gallery has and the sizes of the images within them as well as a few other options. While it is a noble quest to give users more power over their images it also allows them to screw things up in new and exciting ways when using a custom theme. Adding style tags within the body of an HTML document is also invalid markup.

   Thanks to Safirul Alredha for this code:

   // remove gallery shortcode styling
   add_filter('gallery_style',
       create_function(
           '$css',
           'return preg_replace("#<style type=\'text/css\'>(.*?)</style>#s", "", $css);'
       )
   );

6. Replacing the gallery shortcode handler

   While the above snippet does a good enough job in many cases I still find the built in gallery shortcode function to be questionable. For example you can change what HTML tags the gallery outputs with (the default being a semantically poor series of definition lists) but there is no way to set theme defaults without parsing post/page content and adding the attributes to the shortcode programmatically. This is a bad idea for general use themes because it will screw up peoples sites if they switch to another theme in future.

   The shortcode can be rescued however by simply removing it and replacing it with your own callback:

   // replace gallery shortcode
   remove_shortcode('gallery');
   add_shortcode('gallery', 'theme_gallery_shortcode');
   
   function theme_gallery_shortcode( $attr ) {
       global $post, $wp_locale;
       // create your own gallery output...
   }

   You can alternatively use the built in shortcode’s internal filter ‘post_gallery’ to change the output and handling of the standard shortcode attributes.

7. Adding custom post types to search results

   Hopefully any custom post types that are set as publicly queryable will be included in the search results by default in future releases of WordPress but for now you can use the following code:

   function search_post_types( $query ) {
       if ( $query->is_search )
           $query->set( 'post_type', get_post_types( array( 'publicly_queryable' => 1 ) ) );
       return $query;
   }
   add_filter( 'the_search_query', 'search_post_types' );

8. Adding custom post types to the main RSS feed

   This can make sense for some sites if you want an amalgamated feed of all your content. We use an array filter in this case to get only those post types that have taxonomies so page-like content is ignored.

   function feed_post_types( $vars ) {
       if ( isset($vars['feed']) && !isset($vars['post_type']) )
           $vars['post_type'] = array_filter( get_post_types( array( 'publicly_queryable' => 1 ) ), 'get_object_taxonomies' );
       return $vars;
   }
   add_filter( 'request', 'feed_post_types' );

9. Enable post thumbnails

   This is one is pretty straightforward. Make use of WordPress 3.0′s post thumbnail feature in your theme.

   add_theme_support( 'post-thumbnails' );

10. Enable shortcodes in the text widget

    This little trick makes the text widget into a much more powerful tool. It’s used on this site to add an author list to the widget space in the footer, avoiding the need to code a specific author list widget.

    add_filter( 'widget_text', 'do_shortcode' );

A developer has just done a nice little piece on spellchecking. In 1984 it was ferociously hard. In fact, if you wanted a decent spellchecker in your custom application you had to pay dearly for the priviledge. Today it can be accomplished in a few lines of code.

It means that what was once going to cost you £100k to add to an application is now a few pounds.

Similarly, when we develop we offer up lots of wonderful functionality at incredibly low cost, because we’re just pulling in something that’s already been done. But if someone asks us for something custom, the price leaps up. They don’t always get it.

So here’s how we do it:

Step 1

We don’t know if the problem’s been solved before, and we don’t know how long it’ll take us to solve it either, so we give what may be considered to be evasive responses. We need time to research. Someone has to pay for that. Depending how interesting this research is to our business model, we may subsidise it. Otherwise, the client pays.

Step 2

If we find the problem’s already been solved, we still need to test the solution to make sure it applies well to the client’s requirements.

Step 3

If all is well, and the solution is found quickly, the client gets a call to say “yup, no problem, it’ll take us x amount of hours.”

But if we found no solution, we have to estimate how long it’ll take to develop the solution. And that’s hard in a commercial sphere. People don’t expect to spend much on R&D – they just want solutions.

So we do spend a lot of time trying to get people to understand the difference between solutions, and development. Just like a DVD player is a £30 piece of kit if you buy one from Sanyo while it would cost millions if you tried to make one your own from first principles. It shocks folk, but it’s an important message to get across that all developers need to take on board and to pass on to clients, or they end up stressed and trying to do the impossible on very low budgets.

But let’s assume you’re dealing with a typical, decent developer who doesn’t take the long route, or dangerous shortcuts.

There’s some nice research covering this, such as Boem, Abts Chulani [2000] which is worth reading if you’re interested by this kind of stuff.  But it’s heavy going, and doesn’t give a nice neat figure for lay people to understand.

So now I’m going to give the answer that many want to hear:

For each line of code produced in a 3GL non RAD environment the cost of your development is likely to come to around £20-£25 per line of new code.  And about £100 per hundred lines of re-used code.

Doesn’t sound too bad… that includes testing, development, refinement, code reviews and so on.  It’s based on the idea that most good developers can produce around 50-100 lines of code in a day if left alone and in peace.  Some produce reams of code, but it’s often poorly optimised and thought out and likely to bite back in years to come.  The cost also takes into account the design of that code before anyone touched a computer, and the various support staff required.  If a developer is working entirely alone and is self-supported with his PCs and the like, then his productivity drops so the project takes longer, but the cost shouldn’t change too much.

And don’t forget that cheap code is often bulkier than expensive code.  Which means nobody can look at a 1000 line program and actually say “Oh yeah, that’s £20k’s worth.”  Somebody needs to assess the quality of that code.

What we will say is that in general, if we’ve written you 1000 lines of fresh code (ie, no cut and pasting or reuse) it could well have cost you £25k by the time it’s fully tested and delivered.  A really big project, like, say, implementing a worldwide global payroll system for a major corporation may have five million lines of code and a final bill (including analysis) of around £125 million.  Not at all unreasonable, believe it or not.

So yes, code is expensive.  And that quick report you’d like us to knock up?  Maybe it’s not so quick.

To save costs it’s worthwhile looking at RAD (Rapid Application Development) methods, but in that you’ll end up with slower, more bloated code.  However, it can be a perfectly adequate approach and we use it all the time for simple data management back-ends and the like where performance isn’t that critical.  Sometimes we’ll generate 20,000 lines of code from a three hour job… but it gets the job done.  Albeit a little slowly!

And I totally get it.

In fact, a failure of how standards apply to web pages is one of the reasons why, until really quite recently, I’d avoided having anything to do with Web Design. I hated it. I hated that even if you structured your code correctly it would look right only in half the browsers you tested in.

Well, this is going to change over the coming five years. Standards will become far more important, and odd hacks will slowly fade into the background. Browsers, my friends, are going to have to become a whole lot less forgiving.

And there lies the rub – with tougher browsers, building websites will become a lot harder for non-technical types. In fact, it could become near impossible. On the upside, tools like WordPress will be able to offer more choices to the user because the code will know that what it outputs to the browser will work.

So the internet’s going to get a lot better in the coming years… but if you’re not prepared to work hard at it then becoming a web developer or designer is going to become far tougher.

So you need to be able to generate passwords on the go and the solution is Password Maker – a great way to have safe, difficult to crack passwords which works beautifully as browser plugins.

The nice thing is that if one password is found out because of a compromised website, because PasswordMaker generates a different password for each site, you’re still secure everywhere else. Of course, if someone finds out your master password and works out what your encryption settings are and knows that you’re using such a system then they can get in to everything. But you’re not that careless are you?

You may want to reduce down the characters in use for passwords a little so that you don’t get characters that many sites don’t like – for example, WordPress doesn’t like slashes.

Make a note of the exact character set, encryption method, lengths and so on. You may need these at some point. However, without the master password, this information is of limited use, and you don’t have to write it in a way that can be understood by anyone else but you.

Make a habit of using this system wherever possible. You’ll find life a lot easier, and more secure, if you use it consistently.

It’s quite simple – we use Mantis Bug Tracker.   It’s not as powerful as some, but we’re a three man company – a more heavy solution would probably simply be going over the top with things and would carry a support load that we simply wouldn’t be happy with.

In other words, it’s a great fit for our needs and requirements today, and for the next few years.

Steve McConnell in Code Complete (a book which criticizes the widespread use of the waterfall model) refers to design as a “wicked problem” – a problem whose requirements and limitations cannot be entirely known before completion. The implication is that it is impossible to get one phase of software development “perfected” before time is spent in “reconnaissance” working out exactly where and what the big problems are.

It’s worth following the link.

I think software and design processes often end up trapped within this circle where nothing’s ever perfect. The iPhone isn’t perfect, for example – it may be ever so pretty, but it’s quite rubbish at Bluetooth connectivity, for example, or sending texts. In fact, it’s rubbish at a lot of things. One of its smartphone rivals, the N95, has a habit of crashing in certain situations, and flattening its battery in two hours because it’s furiously running an application in the background.

Same with websites. Our company site, Interconnect IT, will never ever, in my opinion, be perfect. Unless we simply devoted all our energies to that site – but then we’d have no time to work on client projects. We’re still a three man company, so we can’t have a £200k site. But we can be clever and cover 95% of the requirements.

With client sites it’s even trickier – we have to interpret a clients’ requirements, write them down, and send them back in a proposal with a rough mock-up, pricing and structure. They’ll read it quickly and usually accept. But once started they’ll look at the design, try it out, and realise that actually, the front page should have a simpler message. That may mean a restructuring. A week later, someone may point out that the colours they preferred have negative connotations in certain cultures.

All these require changes, sometimes at a late stage, and sometimes involving a lot of work. At some point, someone has to simply say – “OK, that’s good enough!”

Other clients, however, quite like the waterfall method. We have forms for certain business sectors, with consistent requirements, where they simply tick off what they want and like, choose an off-the-shelf design, and a couple of weeks later we deliver the website – all loaded up and everything. They then sign-off, or they ask for some revisions – images changed, copy edited and so on. It’s particularly suited where a small and busy firm needs a website, but it’s not really crucial to their business – it simply provides a service to people who already know them. Dentists, for example.