Site News

Site News / The Web / Wordpress — 14 Comments
21
Feb 08

Heart Internet Web Hosting: WordPress Trackbacks and Pingbacks not supported

I run a few WordPress blogs on this website which is hosted on a shared server by the UK hosting company, Heart Internet. I can genuinely say that this host provides excellent customer service and decent performance for the money I pay. In fact, I have never had any problems with them at all in the past.

More recently, whilst making a few postings on this blog and others (all running the latest version of WordPress), I discovered that whilst I was pasting links to postings on friends’ blogs into the body of my posts, no pingbacks were appearing on ANY of those blogs. I began to investigate and soon found out that not only were pingbacks not working to external sites (or my own blogs for that matter) but any outbound trackbacks were also unsuccessful. On the other hand, all incoming pingbacks and trackbacks were displaying fine – as they had been doing for a long time.

Convinced that this must be some problem with the setup of my WordPress installations, I disabled all running plugins, checked all relevant options on the Admin panel and tried posting pingbacks and trackbacks to various well-known trackback/pingback testing site (such as TestTrack)… however all this was still to no avail!

Finally, I decided to prove to myself that this was not me just being stupid and made a new clean install of WordPress on my server and tried using that to post trackbacks and pingbacks. As I had expected, even a brand new and shiny WordPress blog was unable to successfully send outgoing trackbacks and pingbacks. This left just one possibile source of the problem… my webhost!

So… I searched around to see if anybody else was experiencing the same problem – lo and behold there was another WordPress user in exactly the same situation. Here is the thread he created in the WordPress support forums.

I’ve just installed WordPress 2.0.4 and cant get pingback to work (trackback does)
My hosting company (shared server) are wondering if its because they block port 80…could this be a problem?

This sounds vaguely familiar to me!

Yes, it is. The trackback is an outbound connection on port 80. I would see if they could allow it for your account.

Um, 2.0.4? You do know that there are much newer versions, right?

Uh oh… sounds like trouble!

Ok – thanks – yeah I did know about version – but my hosting company www.heartinternet.co.uk has a one-click install version which happens to be 2.0.4!

Ooohh! How strange indeed – this other user is hosted by nobody other than Heart Internet. Could this just be a pure coincidence…? Anyhow, I figured a quick support ticket to Heart customer support should do the trick… just ask them to open up outbound connections on port 80 and we’re sorted… right?

Well… actually no! Here is the response I received:

Thanks for the reply. Sorry but I can’t do that, it’s a global change and so not something I can do for you. That’s disallowed to prevent recursive loops from occuring to the benefit of all customers on the same hardware.

Ouch! Whilst I do understand their point of view here, I would argue that its not just me who would benefit from this change. I’m sure that what with WordPress being the most popular blogging software out there and Heart Internet being such a big host, there are plenty of other dissatisfied Heart Internet customers who would also like to see their copy of WordPress working properly. To add to the shame, Heart even provide a one-click install option for WordPress, have a look at their description:

WordPress is arguably the most popular blogging software available today! It’s easy to install and use and will allow you to have a great looking blog in minutes. Please note that this feature will use one of your MySQL databases.

Ahem, so even the guys at Heart Internet admit how popular it is… yet they insist on keeping outbound connections on port 80 blocked… tut tut tut! Most other popular web hosts support outgoing port 80 connections, I really can’t see why they are being so stubborn?

So… it looks like for the moment I have hit a dead end and for the short term will be unable to make any outgoing trackbacks and pingbacks using the WordPress platform. Heart Internet support said that they would “gladly pass long [my] comments” to the guys in the suits but whether this will really have any outcome remains to be seen. My only other option is to move hosts, which I am reluctant to do. As I have already said, until I hit this problem, I was quite satisfied with my web host.

Anyhow, let this be a warning to anybody out there looking for a new web host. If you want to use WordPress on your site and would like to be able to make the most of Trackbacks and Pingbacks… I would suggest that you don’t visit http://www.heartinternet.co.uk/ but rather that you take a look elsewhere…

Site News / WL-HDD / Wiki — No Comments
9
Feb 08

WL-HDD Wiki Back Online

After a bit of a blunder I made when bashing the keyboard in the SSH shell the other day I managed to ruin my Mediawiki installation. Whilst the database was not damaged, all the server files were lost, including all of the images used on the wiki. Unfortunately all backups were at home on my old computer so I was not able to access them. I eventually managed to get my sister to email me the backup files and now the wiki is back online and everything is back to normal again. Even better, I’ve updated to the latest version of Mediawiki which should improve performance and security on the site.
Thanks for your patience, sorry for any inconveniences caused to anyone trying to access the wiki.

Linux / Site News / The Web / WL-HDD — 2 Comments
17
Dec 07

WL-HDD Wiki Downtime

I recently became aware of some MySQL issues with my WL-HDD wiki which have made the site inaccessible recently. I am currently working on the problem and hope to have it fixed as soon as possible. Please bear with me as this is quite difficult to do on an incredibly temporamental internet connection on the other side of the world (China) and without my own PC and tools.
Hope this has not caused too much inconvenience. If you are desperate to use a particular tutorial you can always use the cached version via a google search.
Will keep you updated on this.

Site News / Wiki — 2 Comments
11
Jun 07

Cracking down on Wiki Spam

After having long being plagued by spammers on my WL-HDD Wiki, I have decided to take measures to crack down! One of the main reasons for doing this is that spam decreases rankings in Google. Furthermore, when I am in China from July onwards, I will not be checking my mail as regurarly so spam would go unnoticed which could be damaging.I have therefore upgraded to a more secure and spamproof version of Mediawiki – v1.10

The best way to deal with the spam is to force wiki users to register before editing. Even better is to force them to confirm their email address before they can start editing any of the pages. To force users to register before editing, you will need user permissions such as these in LocalSettings.php:

# Edit Permissions

// Implicit group for all visitors
$wgGroupPermissions['*'    ]['createaccount']   = true;
$wgGroupPermissions['*'    ]['read']            = true;
$wgGroupPermissions['*'    ]['edit']            = false;    // Stop unregistered users from making edits
$wgGroupPermissions['*'    ]['createpage']      = false; // Stop unregistered users from making edits
$wgGroupPermissions['*'    ]['createtalk']      = false; // Stop unregistered users from making edits

// Implicit group for all logged-in accounts
$wgGroupPermissions['user' ]['move']            = true;
$wgGroupPermissions['user' ]['read']            = true;
$wgGroupPermissions['user' ]['edit']            = true;
$wgGroupPermissions['user' ]['createpage']      = true;
$wgGroupPermissions['user' ]['createtalk']      = true;
$wgGroupPermissions['user' ]['upload']          = false;
$wgGroupPermissions['user' ]['reupload']        = false;
$wgGroupPermissions['user' ]['reupload-shared'] = false;
$wgGroupPermissions['user' ]['minoredit']       = true;
$wgGroupPermissions['user' ]['purge']           = false; // can use ?action=purge without clicking "ok"

// Implicit group for accounts that pass $wgAutoConfirmAge
$wgGroupPermissions['autoconfirmed']['autoconfirmed'] = true;

// Implicit group for accounts with confirmed email addresses
// This has little use when email address confirmation is off
$wgGroupPermissions['emailconfirmed']['emailconfirmed'] = true;

// Users with bot privilege can have their edits hidden
// from various log pages by default
$wgGroupPermissions['bot'  ]['bot']             = true;
$wgGroupPermissions['bot'  ]['autoconfirmed']   = true;
$wgGroupPermissions['bot'  ]['nominornewtalk']  = true;
$wgGroupPermissions['bot'  ]['autopatrol']      = true;

// Most extra permission abilities go to this group
$wgGroupPermissions['sysop']['block']           = true;
$wgGroupPermissions['sysop']['createaccount']   = true;
$wgGroupPermissions['sysop']['delete']          = true;
$wgGroupPermissions['sysop']['deletedhistory']  = true; // can view deleted history entries, but not see or restore the text
$wgGroupPermissions['sysop']['editinterface']   = true;
$wgGroupPermissions['sysop']['import']          = true;
$wgGroupPermissions['sysop']['importupload']    = true;
$wgGroupPermissions['sysop']['move']            = true;
$wgGroupPermissions['sysop']['patrol']          = true;
$wgGroupPermissions['sysop']['autopatrol']      = true;
$wgGroupPermissions['sysop']['protect']         = true;
$wgGroupPermissions['sysop']['proxyunbannable'] = true;
$wgGroupPermissions['sysop']['rollback']        = true;
$wgGroupPermissions['sysop']['trackback']       = true;
$wgGroupPermissions['sysop']['upload']          = true;
$wgGroupPermissions['sysop']['reupload']        = true;
$wgGroupPermissions['sysop']['reupload-shared'] = true;
$wgGroupPermissions['sysop']['unwatchedpages']  = true;
$wgGroupPermissions['sysop']['autoconfirmed']   = true;
$wgGroupPermissions['sysop']['upload_by_url']   = true;
$wgGroupPermissions['sysop']['ipblock-exempt']  = true;

// Permission to change users' group assignments
$wgGroupPermissions['bureaucrat']['userrights'] = true;

To implement the force email confirmation feature, you simply need to add this line of code to LocalSettings.php:

$wgEmailConfirmToEdit = true;

Make sure that the following value is also true in LocalSettings.php

$wgEmailAuthentication = true;

Users will be notified when they try and edit a page to first confirm their email address. This only has to be done once.

Hopefully this should keep the spammers at bay for a little while and give me some peace on my holidays!

Here is where I found the information.

← Older Entries
Newer Entries →