Update: Apologies to the author of Hyper Cache, the error isn’t cause by the plug-in. The error is being caused by DB Cache Reloaded. After updating the site to 3.0 final I was getting the error on the update page, disabling DB Cache Reloaded fixed it.
Update 2: DB Cache Reloaded has now been updated and works flawlessly in 3.0, get it here.
I’ve been eagerly awaiting the release of WordPress 3.0 (due any day now!). I plan on making a few changes to my blog once it is released so decided to try out Release Candidate 1 on my development server. At first it all went fine, upgraded the database no problem… then a blank page. Weird! After a couple of page reloads the sparkly new dashboard popped up (it’s not that different, although it does look greyer). Clicking around the admin area I could see this blank page error was randomly occurring on different pages; bugger!
My immediate thought was a plug-in I had installed, as I’m sure this rather large error would have been picked up while testing the WordPress core functionality! Looking at my Apache error log the following error was listed:
1
[error] [client 127.0.0.1] PHP Fatal error: Call to undefined method wpdb::get_blog_prefix() in dev.nooshu.com\\trunk\\httpdocs\\wp-admin\\includes\\user.php on line 260, referer: http://dev.nooshu.com/wp-admin/edit.php?post_type=portfolio
The error is too vague to actually help, but after a little investigating (and from a hunch I had) I disabled any plug-ins involved in page caching; namely DB Cache Reloaded and Hyper Cache. Unfortunately disabling them still didn’t fix the error, so I decided to remove them completely (db-config.ini, advanced-cache.php and db.php removed from the wp-content directory). Suddenly no more blank page errors occurring! Huzzah!
So if you come across the same problem, then check what caching plug-ins you have installed. When 3.0 final is released I’ll be doing a fresh install of both plug-ins. Hopefully that will solve the issue. They are both quite popular plug-ins so I’m sure others have had the same issue.
Over the weekend I stumbled across a video link, released (I assume) by Flickr. The video is a visualisation of the last 7 years of commits into the Flickr Subversion repository. Wow, there’s a lot of work been done to Flickr over the past 7 years! What’s even more interesting is you can easily create the same type of visualisation with your own project using an open-source project called Gource.
Gource is a version control visualisation tool developed by Andrew Caudwell. At the moment it supports Git, Mercurial and Bazaar but it is also possible to use it with Subversion (SVN) with a few extra steps. I’ve created a video for a project I’ve been working on with another developer for 9+ months. The video isn’t as active as the Flickr one but its still interesting to watch and see how a project develops right before your eyes.
The videos produced by Gource really illustrate how much work goes into projects over time, with each developer ‘shooting a laser’ at each file created / changed / deleted. Files in the same folder are clustered together, lines in-between these clusters link them together depending on the folder structure.
Creating the videos is fairly simple, I’ll give you a step by step guide how to do it using an SVN repository below. You will need:
First you will want to grab a copy of Gource and extract the zip file to somewhere easily accessible. I’ve used ‘c:\gource’ as you will be using the command line so it’s simple to find. Extract Python into a similar directory, I used ‘c:\python31′. If you don’t have the SVN command line client installed, install it and note down where it’s installed too.
Next you need to export the SVN repository log file to an XML document. To do this open a command prompt and locate the SVN client directory. Now type:
This command has exported the SVN log file to an XML doc that you should see in your SVN client directory. Since Gource doesn’t support SVN natively, the log file needs to be converted into a format Gource will understand. To do this copy the XML log file and this python script into the python directory. To convert the log file type the following from the command line in the python directory:
Great! Now time for the fun part! You now have a log file (my-project-gource.log) that Gource can understand, so copy it to the Gource directory and bring up the command line. To generate the video created above I used the following command line:
The command line is pretty self explanatory, I’ve set the size of the video I want, and hidden a few elements that weren’t needed. The “-s 0.1″ is an important command as it sets how quickly the visualisation runs through the log file. It’s worth experimenting with different values until you are happy with the results.
If you look in the README.TXT file thats in the Gource directory it gives you a whole list of options that are available to experiment with, there’s hours of fun in there if you really want delve into Gource.
Saving the video
This part actually took me longer to complete than generating the video in Gource; due to a few video encoding issues I was having (Grr!). Capturing the video is simple (once you know how) and uses a program called Fraps. Fraps is usually used in the online gaming scene, it is used to capture full-screen video and save it into an (uncompressed) video format. Once installed it will sit in your taskbar waiting for a full-screen video to kick in which it can then capture.
Play your Gource video from the command line in full-screen and press F9, this is the hotkey that triggers Fraps to start recording. Once complete, your video will be saved into the ‘\fraps\movies’ directory. The video that has been saved is in an uncompressed format so it’s likely it will be a large file (mine was around 700MB for 2 mins at 1280 x 720). This size isn’t very practical so it’s time to convert it to a smaller more portable format. For this we use the excellent VirtualDub by Avery Lee.
Once VirtualDub is installed it only takes a couple of steps to compress the video down:
Run VirtualDub and open your Fraps video file
From the Video menu select ‘Compression…’
Choose the codec / compression settings you wish to use (I used the XviD codec single pass)
From the file menu select ‘Save as AVI…’, once compressed you are done!
As simple as that! The file produced will be much smaller which you can then upload to Youtube / Vimeo as you see fit. Gource may not have a huge number or practical uses other than eye candy, but it’s a superb little tool that I will be using again in the future.
Over the past couple of weeks I’ve been working on a number of WordPress projects, all of which have needed some basic photo gallery functionality. As I’ve mentioned before in previous posts, NextGEN gallery is my WordPress gallery of choice, there really is nothing that comes close to it in terms of features and customisation (that I know of, if there are others post a comment!).
To add a gallery (or album) to a post / page is as simple as adding ‘[ nggallery id=x ]‘ to the post content… super! One issue though… what happens when you allow a client to edit and add new pages; well what usually happens is the tag gets deleted or changed, the gallery breaks, client panics and the virtual world ends (well not quite, but close). A technique I have been using to help solve this issue involves using WordPress custom fields and the excellent Get custom field values plug-in. You can grab the custom field values directly from WordPress using get_post_meta() but the plug-in makes it much easier.
Digging through the nggfunctions.php file in the NextGEN gallery plug-in folder reveals a whole host of useful functions that can be easily called directly from inside your WordPress theme. So say you wanted a gallery in a post page, but didn’t want the client to have to remember ‘[ nggallery id=x ]‘ every time, simply add this code next to your content in the single.php file:
Add a custom field of galleryID with an integer value linking to the relevant gallery and you’re done. Now the client can pick out the galleryID custom field from a drop-down since WordPress remembers the custom fields used. Much easier for a client to remember than adding the tag every time.
I highly recommend looking through the nggfunctions.php file, here are just a few functions that are available:
nggShowAlbum(): Show a whole album depending on the ID.
nggSinglePicture(): Show a single picture from an ID.
nggShowRandomRecent(): Show random image(s) from a certain gallery.
nggShowSlideshow(): Show a flash slideshow pulling images from a specified gallery.
I have used nggShowRandomRecent() quite a few times in the past few months, here’s a quick example:
1 2 3 4 5
<?php //Show 6 random images using 'my-template' from gallery 4 //(order, number of images, template, gallery ID) echo nggShowRandomRecent('random',6,'my-template',4); ?>
Pick 6 images at random from a selected gallery on page load, very simple and effective.
Note: When using the random images function make sure you don’t have any WordPress caching plug-ins running on the selected page, else it won’t work as the page gets cached on first load. It took me a good 15 minutes to figure out why the function had suddenly stopped working due to this slight oversight.
One of the many new API’s available to developers with HTML5 is the Drag and Drop API. Drag and Drop is nothing new, it has been available for quite a few years now using JavaScript libraries (Prototype + script.aculo.us, Mootools, jQueryUI, YUI), and even in IE; HTML5 drag and drop is based on work done by Microsoft in 1999 (wow!). That being said, each library implements it in their own specific way, usually this isn’t a problem but it means all developers on a team have to know how that library works, which isn’t always the case. Luckily the HTML5 D&D API promises to level the playing field by supporting drag and drop natively in the browser using vanilla JavaScript (but how long it will take for this to happen is anybody’s guess).
It’s an interesting time for JavaScript libraries with these new native browser API’s coming out. I’m guessing it will be a case that if the browser supports drag and drop natively the method will be used, if not then fall back the the library implementation. For the developer this should mean no extra code, but for the library authors it could be a little tricky as browsers gradually roll out native support. Browser sniffing is never a good thing, but if browser vendors don’t agree on it’s implementation it may be required.
To see how HTML5 drag and drop works I’ve put together a simple little experiment. The experiment allows you to drag a thumbnail image onto a drop area to load a larger version of the image using the canvas element. It’s easy to see how this could be adapted for use in an e-commerce shopping cart or an online web application (perfect for iPad users!). Note: I’ve only tested in FF 3.6, I don’t want to get into the cross-browser issues (yet!), but for more information about what a mess it seems to be take a look at “The HTML5 drag and drop disaster” by Peter-Paul Koch.
It’s fairly simple to start using the drag and drop API, you just need to add a couple of attributes and events to an element to make it drag-able, then attach events to the drop element to do something with the data from the dropped element:
1 2 3 4 5 6
<!-- Our dragabble element --> <li draggable="true" ondragstart="event.dataTransfer.setData('text/plain', 'bonfire'); event.dataTransfer.mozSetDataAt('application/x-moz-node', event.target, 0);"> <imgsrc="images/bonfire.jpg"alt="bonfire"id="bonfire"> </li> <!-- Our drop area --> <divid="drop" ondragover="dragDrop.imageDragOver(event);" ondrop="dragDrop.imageDrop(event);" ondragleave="dragDrop.imageLeave(event);"></div>
Now create a function that will fire once an element has been dropped; this will collect the data from the element and do something with it:
{ //.....
imageDrop:function(event){ //Does the drop contain node data? var isNode = event.dataTransfer.types.contains("application/x-moz-node");
var imageData; //Look for node data first, fall back to plain if unavailable if(isNode){ var nodeData = event.dataTransfer.mozGetDataAt("application/x-moz-node",0);
imageData = nodeData.id; }else{
imageData = event.dataTransfer.getData("text/plain"); } //Pass the data to the image load function this.loadCanvasData(imageData);
//Prevents page jumping to the image
event.preventDefault(); }, //..... }
As you can see from the example above, it is possible to pass different types of data to the drop element. These include plain text, links, HTML / XML, files, images and document nodes. I’ve used the document node data by default and have added a check to see if the dragged element has any node data attached to it, if not it falls back to plain text data. You can see this check in action by dragging image two over the drop area. The background will turn red signalling that there is no node data attached. If you wanted, you could restrict what data type accepted by the drop box, but I added a fall back instead.
The example only took a couple of hours to put together, it may be very simple but it demonstrates how easy it is to implement the drag and drop API into your web application (assuming all browsers agree on how it should be implemented!).
I’ve written about my Frog CMS usage in previous blog posts; where other CMS’s can be a little overkill for small websites, Frog CMS fits perfectly into the gap. Unfortunately as much as I like Frog, the development seems to have stopped. The last stable version was released on the 26th April 2009, over a year ago. There’s no need to panic though, a development fork has been created called Wolf CMS which is building upon this superb little CMS and making it even better!
At the moment there’s very little difference between Frog and Wolf as you might expect, so migrating from one to the other is fairly simple, a wiki page has been created with instructions on how to do this. As it says on the page it’s probably best to decide between the two versions now since there’s still little difference between them, but this could change in future versions (version 0.6.0 introduced a number of large changes). So there may be a point where it isn’t (easily) possible to jump between the two versions.
So what are the differences at the moment? When version 0.6.0 of Wolf CMS was released on the 1st February it added a new core plug-in called ‘BackupRestore’, allowing admin users to easily backup the Wolf CMS core DB tables. I’ve been using an external plug-in to do this on sites I built, so having this feature added as a core plug-in is nifty addition. Other features include:
Admin users can now uninstall plug-ins, including the db tables
HTTPS Support added to the admin area for greater security
You can now preview a page before it is published
It’s great to see that such a useful little CMS hasn’t been left to stagnate and die out, the roadmap for Wolf CMS looks promising, so fingers crossed it has a bright future ahead of it. I think it’s time to migrate my Frog websites over to Wolf…