By David Pratt / Tags: seo, wordpress / No Comments / Published: 29-12-09
If you use the popular Lifestream plugin for WordPress, you might notice that there is no option within the plugin settings to toggle the rel=”nofollow” attribute on the links that it creates. If you are concerned that your site is “leaking pagerank” because of this, you can set all the links that the plugin creates to have the rel=”nofollow” attribute by default if you follow these few steps and manually update the plugin source code:
Locate the file:
\wp-content\plugins\lifestream\inc\core.inc
Find the function get_anchor_html and locate the line within that function that looks like (line 690):
$html .= ''.$label.'';
Update this line so that it becomes:
$html .= ' rel="nofollow">'.$label.'';
Save the file.
This is for version 0.99.9.5 of the Lifestream plugin for WordPress, but it is possible that the update would work for other versions too.
By David Pratt / Tags: quotes / 9 Comments / Published: 28-12-09
If you’ve not had a read through the stack overflow thread on great programming quotes I thoroughly recommend doing so – some good stuff in there! Here are some of my favourite quotes from the thread that I thought I might share here (not all of the quotes were referring to programming when they were made, but they seem very applicable nonetheless!):
“Walking on water and developing software from a specification are easy if both are frozen.”
- Edward V Berard
“The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.”
- Seymour Cray
With regard to adding more programmers to get a project done faster…
“Nine people can’t make a baby in a month.”
- Fred Brooks
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
- Bill Gates
“It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
- Hofstadter’s Law
“When all you have is a hammer, everything starts to look like a nail.”
- Unknown
“Good design adds value faster than it adds cost.”
- Thomas C. Gale
“Linux is only free if your time has no value.”
- Jamie Zawinski
Something David Parnas said in an interview:
Q: What is the most often-overlooked risk in software engineering?
A: Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.
On programmers of dubious ability:
“Better train people and risk they leave – than do nothing and risk they stay.”
- Unknown
“I love deadlines. I like the whooshing sound they make as they fly by.”
- Douglas Adams
“Think twice before you start programming or you will program twice before you start thinking.”
- Unknown
“Debugging is like farting – it’s not so bad when it’s your own code.”
- Unknown
“Confidence, n.: The feeling you have before you understand the situation”
- Unknown
“Good judgement is the result of experience … Experience is the result of bad judgement.”
- Fred Brooks
“If you pay peanuts, you get monkeys.”
- James Goldsmith
“I have not failed. I’ve just found 10,000 ways that won’t work.”
- Thomas A. Edison
“When debugging, novices insert corrective code; experts remove defective code.”
- Richard Pattis
“Your code is both good and original. Unfortunately the parts that are good are not original, and the parts that are original are not good.”
- Unknown
“In my experience, one of the most significant problems in software development is assuming. If you assume a method will passed the right parameter value, the method will fail.”
- Paul M. Duvall
“First, solve the problem. Then, write the code.”
- John Johnson
“Now I’m a pretty lazy person and am prepared to work quite hard in order to avoid work.”
- Martin Fowler
“Get it right. Then get it fast.”
- Steve McConnell
“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
- Brian W. Kernighan
By David Pratt / Tags: design, marketing, seo, zoocha / No Comments / Published: 17-12-09
I just thought I’d drop in a cheeky little post on here about a new start-up that I’m very excited to be a part of. We are a Hertfordshire based web agency that specialises in web design, web development, seo and marketing. If you’re looking for help in any one of these areas, or know anyone that could do with a bit of help from Zoocha, then please get in touch with us!
Hertford's newest digital agency
By David Pratt / Tags: css, drupal / 3 Comments / Published: 16-12-09
One of the things that irritates me about adding modules in Drupal, is that they often have their own stylesheets associated with them that get automatically added to the site upon module activation. Not always, but very often you’ll find that the rules within these supporting stylesheets result in one or more of the following undesirable side-effects:
- possess rules that clash, or are made redundant by rules that you already have in place
- control aspects of the module administration that a user would never see
- cater for features that the module provides that you don’t need, or haven’t activated
- offer browser and device support that is not part of the site requirements
- you have themed a modules mark-up, thus rendering its own stylesheet obsolete
Generally there is no easy way, or no way at all to disable these stylesheets from the admin or module settings.
If you took a typical Drupal setup with a Zen starter theme and add about 10 of the popular modules, it wouldn’t be unthinkable for the number of stylesheets to breach the 20 mark! 20 stylesheets!
Even before you start adding your own stylesheets...
I know that the stylesheets can be cached and served as one file, but when you’re debugging the CSS and adding new sections to a site of any real size, you will inevitably end up playing specificity wars and having to reset rule properties more often than you’d like. This all leads to bloated CSS that is a pain to debug and maintain.
To overcome this in the past and regain some sort of control over what CSS ends up on the site, I have adopted a code butchers approach and taken to ripping out the line seen below in the page.tpl.php file, and then just manually adding the stylesheets in the html.
print $styles; //bye, bye
That’s a problem solved, but another problem created in that sometimes you do actually want a modules stylesheet to be used. Determining the CSS file location(s) that a module uses can be difficult, especially when there are configuration options within a module that force different sets of stylesheets to be used such as in the popular fivestar module.
I’m sure there are probably better, cleaner ways to achieve this, but what I do now is cull the Zen starter theme.info of all superfluous stylesheets and then add the phptemplate_preprocess_page function within the template.php file with code that removes the remaining unwanted stylesheets, like so:
function phptemplate_preprocess_page(&$vars){
//Get the loaded stylesheets as an array
$stylesheets = drupal_add_css();
//Remove the default style sheets
unset($stylesheets['all']['module'] ['modules/aggregator/aggregator.css']);
unset($stylesheets['all']['module'] ['modules/node/node.css']);
unset($stylesheets['all']['module'] ['modules/system/defaults.css']);
unset($stylesheets['all']['module'] ['modules/system/system.css']);
unset($stylesheets['all']['module'] ['modules/system/system-menus.css']);
unset($stylesheets['all']['module'] ['modules/taxonomy/taxonomy.css']);
unset($stylesheets['all']['module'] ['modules/user/user.css']);
//Remove some of the popular module stylesheets - add / remove your own here
unset($stylesheets['all']['module'] ['sites/all/modules/cck/modules/fieldgroup/fieldgroup.css']);
unset($stylesheets['all']['module'] ['sites/all/modules/cck/theme/content-module.css']);
unset($stylesheets['all']['module'] ['sites/all/modules/date/date.css']);
unset($stylesheets['all']['module'] ['sites/all/modules/filefield/filefield.css']);
unset($stylesheets['all']['module'] ['sites/all/modules/link/link.css']);
//Set the styles
$vars['styles'] = drupal_get_css($stylesheets);
}This function will do the trick for all of the Drupal system stylesheets and a few of the popular modules. There is a big drawback to all this stylesheet optimisation of course, which is you’ll notice that your admin area falls apart and becomes completely unusable due to the fact that the supporting stylesheets aren’t present. To overcome this is simple in most cases – you just need to set your administration theme (Administer -> Site Configuration -> Administration theme) to use a different theme and all module stylesheets will be pulled in – I usually go for the comforting shades of Garland.
By David Pratt / Tags: drupal, seo / 9 Comments / Published: 03-12-09
I’ve just stumbled across a very useful internal function in Drupal that I thought I’d share here.
If you have a node that you know the node ID for, but you don’t know what the full clean url is (or how to generate it), then there is a handy function you should know about called drupal_lookup_path() that will get the full clean (pathauto) path for you. For example, a typical Drupal relative path such as:
/node/9999
Is easy to generate if you know the node ID, but if you pass it through the drupal_lookup_path function like so:
drupal_lookup_path('alias',"node/".$node->nid)
Then you will get the full clean path of the node based on the rules set out in the pathauto module. For example:
/band/future-of-the-left
This is very important for SEO. If the exact same content/page can exist on two different urls on your site, then you will run into problems with duplicate content and will have to start using things like the canonical link element to fix a problem that shouldn’t have been created in the first place.
Subscribe via RSS
Twitter