VirtualBox Screen Resolution

After updating to Ubuntu 11.04, the screen resolution got messed up. It refused to recognize the native resolution of 1280×1024, but instead just used 1024×768. What’s the point of having a nice large monitor if the OS can’t recognize it?

I first tried editing the xorg.conf file, using the instructions at metafilter.

That didn’t work, but a few other posts suggested installing the VBoxAdditions. I thought I had already done so, but reinstalled it again to be sure. Sure enough, after the restart, the screen showed up at the full resolution.

Another problem was that the ugly root theme kept showing, no matter what I did. Although it seems a bit dangerous, I finally tried creating some symbolic links to get the root theme to look the same as what I want to use. Instructions are on tombuntu.com

Advertisements

Expanding VirtualBox Partition

Trying to update to Ubuntu 11.04 on my trusty virtual machine today, I got a message saying that the disk was full.

Since the VM is just a file on my windows hard drive on which I have plenty of space, I thought it would be fairly easy to just increase the size of the file and thus give me enough space. Turns out there are a few more steps than that.

The first thing to do is to increase the size of the VirtualBox file. This can be done with the VBoxManage command from the windows command line.

VBoxManage modifyhd d:\ubuntu.vdi --resize 12200

Replace the filename with your own vdi file and the number with the desired size in megabytes.

This only adds unallocated space to the virtual computer. The next problem is to add this to the root partition. This can only be done when the partition is not mounted and thus requires booting from a live CD. I don’t have live CDs around but I do have a USB thumbdrive with a copy of Ubuntu on it. However, it’s not that easy to boot to a USB drive from VirtualBox. It involves fooling the system into thinking that the USB drive is actually an IDE drive.

Follow the instructions at agnipulse.com to see how to accomplish this. When running the command line command and when adding the vmdk file, run the command line and VirtualBox in Administrator mode, or it’ll fail with funny errors. This was mentioned in some VirtualBox forum threads.

VBoxManage internalcommands createrawvmdk -filename d:\usb.vmdk -rawdisk \\.\PhysicalDrive1

Which PhysicalDrive number the USB drive is actually at should be checked from Disk Management.

After booting up to the USB image, run GParted. Delete the extended partition containing the swap partition. Extend the primary partition then add the swap partition back at the end of it.

That’s it! Enjoy the glorious extra space now available on the root partition.

Hiding the Editor

The usual post editor can be hidden after all! Without removing support for it when registering the post type.

Add the following code to the constructor for the meta box class described in previous posts on creating custom meta boxes.

//hide editor if adding a new post of sermon type
		if( isset( $_GET['post_type'] ) && 'sermon' == $_GET['post_type'] ) {
			add_action( 'admin_head', array( &$this, 'hide_editor' ) );
		}

Add this as a function in the class.

	function hide_editor() {
		?>
			
				#editor-toolbar { display: none; }
				#editorcontainer {display: none; }
				#quicktags {display:none;}
				#post-status-info {display:none;}
			
		<?php
	}

The code for hiding the editor was taken from http://wordpressapi.com/2011/03/19/hide-wordpress-visual-editor-html-editor/

i18n

This post is on internationalization, specifically for the Chinese subsite. Those who have been following along will know that I have a custom post type for newsletters, and that this is displaying a link to the PDF file to be downloaded by getting the URL from the _wp_attached_file meta value. For the English version, it displays some text before the link (“Download MM: “). Obviously, this text should be in Chinese for the Chinese subsite. Looks like internationalization is a good way to achieve this.

Declare Theme Text Domain

Put this on top of the functions.php file.

load_theme_textdomain('theme_name', STYLESHEETPATH . '/languages');

Mark String as Translatable

The next step is to mark the ‘Download MM’ string as something to be translated. This is done by putting it in a special function __()

__( 'Download MM', 'theme_name' )

poEdit

This is a program which will get all the translatable strings out of the source code and create a .po file. It also provides an interface for supplying the translation and automatically generates the .mo file.

Rename Files

The final step is to copy the .po and .mo files to the theme’s languages folder (newly created). It is also necessary to rename them to zh_CN.mo and zh_CN.po so that the translated string would get picked up correctly.

Resources Used

The link on the WordPress Codex to the guides on the Urban Giraffe are excellent.
http://urbangiraffe.com/articles/translating-wordpress-themes-and-plugins/
http://urbangiraffe.com/articles/localizing-wordpress-themes-and-plugins/

Incorrect Download link for Subsites

Background

A custom content form for my custom newsletter post type wasn’t saving post content, thus my solution was to ignore the post content and generate it on the fly by getting the attached files instead. This worked beautifully in the main site, unfortunately, on the chinese subsite, wp_get_attachment_url returned something different.

Cause of Problem

It turns out that the _wp_attached_file meta value in the postmeta table is storing the full path to the link in the subsite. The corresponding value for posts in the main site only have the year/month/filename. They don’t contain the full domain name too. What this meant is that for the subsite, wp_get_attachment_url will add the domain to the front of the full link, thus generating an invalid link.

Solution

An email to the wp-hackers list had no responses, I’m not sure if it’s because nobody knows anything about it or whether the email got lost. Thus my solution is to filter the function output to strip out the extra baseurl which prepends the domain name. If this is necessary, the post meta is also updated so the next time this is needed, the correct output will be returned and there will no need to strip out the extra domain name again.

add_filter( 'wp_get_attachment_url', 'mbpc_wp_get_attachment_url_filter', 10, 2);

function mbpc_wp_get_attachment_url_filter($url, $postID) {
	$upload_dir = wp_upload_dir();

	//search through the url and see if it contains a 2nd instance of the baseurl
	$pos = strpos( $url, $upload_dir['baseurl'] , 1);

	if ( $pos !== false) {		//2nd instance exists
		$url = substr ($url, $pos);
		//update post meta so it won't have to find the substring on subsequent calls
		update_post_meta( $postID, '_wp_attached_file', substr( $url, strlen( $upload_dir['baseurl'] ) + 1 ));
	}
	return $url;
}

Newsletters for Subsite

Previously, newsletters on the subsite were put up with default Posts because I hadn’t done the necessary work for the subsite as well. However, to allow for a uniform admin interface, it makes more sense for the chinese newsletters to go up as ‘newsletter’ custom post types as well. Using phpmyadmin and SQL, I changed all the Posts in the subsite to newsletters.

Content Manager Rights

The whole idea is to let a layperson upload the weekly newsletters. This function already exists for the main site. However, to make it work for the subsite, I had to setup the Members plugin and roles all over again. Since everything is stored in the wp_options table, I just had to copy and paste the wp_user_roles option to wp_x_user_roles on the subsite, and copy and paste the members_settings option wp_options to the corresponding options table for the subsite. This has the effect of activating and configuring the members plugin with all the role types I had previously setup on the main site correctly configured on the subsite.

Newsletter Content Erased on Updates

A strangely blank newsletter post on the website brought this problem to my attention. When the newsletter custom content type is updated without a file selected for upload, the post content is erased. As this post type no longer supports the editor window, my guess is that the post content is never pulled from the database and displayed, so it’s just assumed to be empty on the update.

The first thing I tried was to force an insertion of the post content regardless of whether a file has been uploaded. However, this didn’t work. Although the post content did get updated correctly, the page seems to hang and finally just gives a server error. Not user friendly at all.

Examining the WordPress update and insert functions in detail led me to guess that it ends up in an infinite loop. wp_update_post() calls the save_post action. In my code, this calls wp_update_post(), which will then end up calling save_post again, and so on ad infinitum.

The solution I finally settled on was to modify the loop. Since the existing posts already use the post content to display the links, I kept that there for backward compatibility. However, if the post content is empty, the loop will get the children and generate the necessary HTML to display the download link.