Tag Archives: wordpress


Setting up live blogging that works with the latest version of WordPress

True to form, I want big things for my blog, but they aren’t easy. This time the idea came from a reader who wanted my commentary tweet series on current events to be done instead as a live blog, so that they could read all the ideas at once in one place and they would also remain easily accessible.

Great idea, except all the plugins I came across for live blogging were outdated and not working correctly with the latest WordPress, with the exception of 24liveblog, which I was not so keen on, as the content does not reside on my server, but theirs (though it is free and they promise never to take it down).

If you are fine with the content being hosted on another service, look no further, 24liveblog is good, and free and the resulting liveblog can be embedded on your site with a code provided.

I wanted to make the plugins work as I wanted the content to reside on my server AND I wanted it to make tweets linking to the post with each update.

So I have updated the live blogging plugin to fix several issues with tweets not getting posted to Twitter. You can download Live Blogging Plus it here.

The plugin is capable of delivering the live blog more efficiently using meteor, so I am planning to set up a meteor server for it to use. Stay tuned.

Enhanced by Zemanta

PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature

If you are trying to upgrade, and suddenly start getting errors like:

Incompatible Archive. PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature

Here are some things to check.

  • This basically means that WordPress is not able to unzip the downloaded packages to install the upgrades.
  • Check to see available space on your disk. If your disk is full you should try upgrading your hosting package or freeing up some space on the disk. One easy way might be to delete old image thumbnails in sizes you no longer use.
  • If you have enough space on your disk, it may be that specific downloaded packages may be problematic. Try to install a plugin you don’t have, and if that works, you should check to see if there is a mysterious folder called “Upgrades” [DO NOT CONFUSE WITH UPLOADS]. If this folder exists, it is worth deleting it to see ii that lets  you do the upgrade.
Enhanced by Zemanta

Free space in your WordPress install by deleting old image sizes

If you change your theme often, your uploads folder will accumulate thumbnails of images in many sizes that you no longer use. This consumes disk space unnecessarily. I wish someone coded a plugin for this, but failing that, a handy way to do this via SSH is:

find . -name *-250x250.* | xargs rm -f

Where 250×250 is the image size you want to delete. You could also try something like:

find . -name *-250x*.* | xargs rm -f

if you have multiple thumbnail sizes like 250×250 250×300 etc.

What I do is list images in the folders to see the unwanted sizes there, and run this delete a few times with various sizes. A more ruthless person could try something like:

find . -name *-*x*.* | xargs rm -f

I do not recommend this, as it can match several files that you may not want to delete, for example a file with a hyphenated name and the letter x in the last hyphenated word, like “wish-merry-xmas.jpg” for example, which wouldn’t be a resized image, but an original or worse, it could be another file and not an image at all, like “here-are-exact-directions-to-our-property.html”.

But if you have a lot of thumbnail sizes, you may feel tempted anyway. Two suggested precautions. Change directory to your uploads folder (you should do this in any case)
cd /path/to/wprdpress/wp-content/uploads
find . -name *-*x*.* | xargs rm -f

The other precaution to take is to specify extension.
find . -name *-*x*.jpg | xargs rm -f
find . -name *-*x*.png | xargs rm -f

This will give you some protection from inadvertently deleting non-resize uploads like “entertaining-extras.pdf”

of course, if you are a patient soul (or don’t have too many files uploaded), you could find the files before deleting to see if any other files are getting selected along with resizes.

find . -name *-*x*.*
and if all is well
find . -name *-*x*.* | xargs rm -f

Do you have a better method?

Enhanced by Zemanta

Configuring Varnish Cache for WordPress

Oh, so you installed Varnish, what good will it do, if most of your content is not cached? I went for the “Preparing Varnish/Wordpress? for a Slashdotting in 60 seconds or less… ” code provided on the Varnish site. Its rather ruthless, but I’m not particularly attached to seeing the logged in version of my websites that I want Varnished anyway. Few log in to them. Ruthless works for me. So here’s how to do it. Please note that there is a change of code since that sample was provided, which I have corrected below. Feel free to plug and play.

Edit your /etc/default/varnish file and edit the port and cache size in.

DAEMON_OPTS=”-a :80 \
-T localhost:6082 \
-f /etc/varnish/default.vcl \
-S /etc/varnish/secret \
-s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,1gb”

Port is at 6081, which you change to 80. Set the storage size as per your needs. Don’t obsess over it. You can always edit if needed later.

Then, in /etc/varnish/default.vcl paste the following code.

backend default {    .host = "localhost";    .port = "8080";    .max_connections = 30;    .connect_timeout = 4.0s;    .first_byte_timeout = 600s;    .between_bytes_timeout = 600s;

# Drop any cookies sent to WordPress.        sub vcl_recv {                if (!(req.url ~ "homeschoolingindia.in|phpmyadmin|wp-(login|admin)")) {                        unset req.http.cookie;                }        }
# Drop any cookies WordPress tries to send back to the client.        sub vcl_fetch {                if (!(req.url ~ "phpmyadmin|wp-(login|admin)")) {                        unset beresp.http.set-cookie;                }        }

You don’t have to configure everything. What you don’t configure falls back on pretty decent defaults. What is being done here is that all cookies are dropped so that the page becomes cachable, unless you are accessing login or admin, where you need cookies to be able to access. I had some trouble with interaction on the front page. No admin option was available, since this was the production version I was seeing. Making comments was a problem.

The solution was rather simple. I installed the Discus plugin to handle comments. It formats them rather nicely, magages efficiently, integrates reasonably well with wordpress, adds features like likes and shares along with the oh so fabulous lists of mentions. However, the bestest part is that it is delivered through javascript, so it is totally functioning when the page is cached.

Other problems likely may be using any analytics software from the server end. Since most requests will not reach the server at all, there is no way for the server to record hits and so on. Again, javascript to the rescue. What do I say. In my opinion, google analytics works best for my needs anyway.

So, you understand the theme of the matter, basically, you are not going to be pulling any customized pages. Javascript being rendered in the browser, couldn’t care less if it were served from a html page or php. Your adsense will work, so will analytics. Some “link selling” plugins that rely on php may not register as active with your providers, but then you shouldn’t be selling I’ll not comment on the ethics of that…. This site, AamJanataWide Aware and Nisarga run like that.

However, this brings us to the site that won’t work. A site that users login and use. You got that right. BuddyPress. Homeschoolingindia.in is not getting the varnish treatment. I guess you could do it so that you use varnish with non logged in users, if you have a lot of non-member visitors. I found it simpler to leave it out.

Two possibilities. The first is to exclude it through varnish. Either by passing requests through for target domain or configuring Varnish per domain, and not for this one. Please to also remember to exclude it in the cookie killing settings. Many possibilities depending on what you want.

The second option is what I did, because it was simple and I had an extra IP from my provider. Configure all sites to be cached to answer on one IP on your backend port 8080 in this example and those not to be cached to answer on port 80 (the regular port) on the second IP. In the default.vcl, in the backend configuration, replace localhost with the IP address serving sites to be cached on port 8080. Done. Your buddypress is now happily guzzling scandalous amounts of resources, while your other wordpresses are playing static html. ;)

There is more, much more, but I find that this is adequate for basic configuration. Later, as you get used to the cache, you will be able to analyze what is happening, and filter in more and more hits to the cache and reduce server load further, but that is another how to in itself, if at all I have the competency to write it.

This should keep your server from crashing under whatever it is that guzzles up memory.

Please note that these are my learnings as I struggle to find out things. I am not a professional. Only a  person who wanted to build a website. I am cutting through the massive finding out missions I had to take and providing the results of that learning. No guarantees, though whatever I say here is working according to my server.

If you would like something more tweakable (and complicated), with load balancing and multiple servers for one site, etc. Try here

Note: This post is old. Soon, there is one more coming up with more nuanced settings, and alternative vcls.