Browsing all articles tagged with wordpress

Flattr this!

Rather hacky fix to sort out utf8 latin-1 post issues after export from a rather badly encoded mysql db in wordpress.

UPDATE wp_posts SET post_content = REPLACE(post_content, '“', '“');
UPDATE wp_posts SET post_content = REPLACE(post_content, '”', '”');
UPDATE wp_posts SET post_content = REPLACE(post_content, '’', '’');
UPDATE wp_posts SET post_content = REPLACE(post_content, '‘', '‘');
UPDATE wp_posts SET post_content = REPLACE(post_content, '—', '–');
UPDATE wp_posts SET post_content = REPLACE(post_content, '–', '—');
UPDATE wp_posts SET post_content = REPLACE(post_content, '•', '-');
UPDATE wp_posts SET post_content = REPLACE(post_content, '…', '…');

Not recommended, but I had a use for it.

Flattr this!

Over the last few weeks, we’ve been noticing an increase on hack attempts on wordpress installs and other CMS’s (eg joomla).

Most of these attack attempts are from Russian IP space (typically Ukraine), although there are also a lot of botnet attacks from hosed windows computers also (these come from a variety of countries).

To counter this, we have been pro-actively implementing a number of different mitigation solutions, ranging from upgrading clients CMS installs and adding captcha plugins where possible to prevent brute force password attacks, through to scanning for vulnerable files throughout all clients website, and updating them to non-vulnerable versions (timthumb.php being the major issue/problem child that we’ve found to be vulnerable/exploitable).

We have also implemented server-wide lockout systems for failed logins for wordpress using one of our existing protection mechanisms (fail2ban).

Some of you may already have noticed an additional question or captcha being asked during login to your systems.

(example below)

Screen Shot 2013-04-12 at 10.42.02 PM

This is for your safety – if someone hacks into an install, they typically then attempt to run additional items within an install such as malware.

We also have live monitoring for malware running on all servers, and have been quite proactive in upgrading installs which are capable of being compromised.

In the case of a site being compromised and malware being dropped into the site, our live scanner sends us an automated email and we actively investigate.

If we cannot resolve the immediate issue, and find the security hole, we disable the clients site and inform them of an issue, and the need to take further action.
(To date, we haven’t had to go that far though).

We’re not the only people seeing this, although its not well known outside of the web hosting community at this present time.

We believe in proactive solutions for these kinds of attacks, and our multilayered approach appears to have spared us from most of the problems facing others at this time.



Flattr this!

WordPress has a nice feature called Custom Post types.

(An overview for those that code for WordPress is here – )

We typically use the Custom Post Types UI plugin ( )  to create, rather than write code.  The end result is the same though.


This allows us to create specifically enumerated sets of content relatively easily.

eg – if you were doing a Site for a Client, you may need a Portfolio section for their web.

With custom post types, you can setup a Portfolio post type, and add various taxonomies (meta data to group or organize these posts by later)

eg  Category


Eg if it was for a web design firm, you might add values into the  Category taxonomy like





Then choose those categories when you add a new Portfolio post so that you can later filter by any of those fields.

So far so good.


We also use another Plugin called QTranslate ( )

QTranslate allows us to add multiple translations for a post, or taxonomy in the WordPress UI.

Its pretty nifty, and a good tool for those that do multilingual wordpress sites.


QTranslate seems to be a little funky about how it works with Custom Post Types though – essentially its a little hit and miss whether it actually populates the backend with translation options.

After a bit of googling I found a nice solution to force it to parse taxonomies.

Add this into your Template functions.php at the end of the file, and QTranslate will work properly.

function qtranslate_edit_taxonomies(){
'public' => true ,
'_builtin' => false
$output = 'object'; // or objects
$operator = 'and'; // 'and' or 'or'

$taxonomies = get_taxonomies($args,$output,$operator);

if ($taxonomies) {
foreach ($taxonomies as $taxonomy ) {
add_action( $taxonomy->name.'_add_form', 'qtrans_modifyTermFormFor');
add_action( $taxonomy->name.'_edit_form', 'qtrans_modifyTermFormFor');
add_action('admin_init', 'qtranslate_edit_taxonomies');

Flattr this!

Unfortunately, its back to the techie stuff for a few posts!

Here are my crib notes on installing NGinx on one of our client servers.

Add spawn-fcgi (cos its split from litettpd now)

cd /downloads
svn co svn:// spawn-fcgi

No svn..grrr

apt-get install subversion subversion-tools
svn co svn:// spawn-fcgi
cd spawn-fcgi
make install

spawn-fcgi should be happily installed in /usr/local/bin/spawn-fcgi now

make sure we have php5-cgi
apt-get install php5-cgi

Check spawn-fcgi runs –
In my case not, had to rebuild eAccelerator @#$@#$!, did that, and all ok

/bin/spawn-fcgi -f /usr/bin/php5-cgi -a -p 53217 -P /var/run/

Note port 53217 can be any unused port from some high unused number though to 65535
We’re going to be installing NGinx from debian packages, but probably better from source long term…

apt-get install nginx

pico /etc/nginx/nginx.conf

change some default settings

user www-data;
worker_processes 1;

error_log /var/log/nginx/error.log;
pid /var/run/;

events {
worker_connections 1024;

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;

access_log /var/log/nginx/access.log;

sendfile on;
#tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 5;
tcp_nodelay on;

client_max_body_size 8m;

gzip on;
gzip_comp_level 9;
gzip_types text/plain text/html text/css text/xml application/xml application/xml+rss text/javascript application/x-javascript;

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Now we add our virtual hosts in /etc/nginx/sites-available

pico /etc/nginx/sites-available

Lastly, we add our fast-cgi settings, using our port from above 53217

fastcgi stuff here