I’ve been moving my feeds from Apple Mail and Eventbox into a dedicated feed reader, to make it easier to manage and filter them. This was all going well until I tried to get my feeds out of Mail and discovered no OPML import or export ability (apparently, if you are a mac user, you won’t want this basic capability).

Thankfully, with the help of a very simple workout in Terminal (or an apple script) and a quick trip to the internet, this can all be fixed.Exporting the list

First of all, you have to get your feeds out of Mail. This can be done using a simple piece of code in Terminal:

http://www.mactipper.com/2008/04/leopard-only-export-mails-rss-feeds.html (or)
http://nasvel.wordpress.com/2008/06/19/export-rss-feeds-from-mac-mail/

The MacTipper link also includes a small applescript, which, when run, will export your list of feeds to a file or clipboard. Either is fine.

Making it OPML

You’ll still need this list in OPML format if you wish to bring it into another feed reader however, and for this there Peter Unold’s Plain Text to OPML Generator. Paste your list in here and then save the output back to a text file called feeds.opml using a text editor, somewhere you can find it easily.

It’s then a simple case of importing the OPML file into your feed reader (mine is now Vienna) of choice using its built in import capability.

UPDATE (12th April 2009): The WordPress folks seemed to have solved this problem now, despite their earlier refusal to do so. Cheers to them!

Newer, faster JavaScript engines pose a new minefield for web developers. Unlike XHTML or CSS, there is no JavaScript standard to rely upon.

For example, some of WordPress’s buttons and pop-ups seem to have broken in Safari 4.  Basically, it looks like the new JavaScript rendering engine doesn’t like their code.

The pop-up’s don’t seem to work, locking the window behind the pop-up mask, and some of the buttons seem to be non-functional.

I reported the issue and was told they “can’t” support beta browsers, but the issue goes deeper than that. If the code fails now it may also fail when that “beta” browser goes mainstream, and there was no indication that they had any intention of checking it.

UPDATE : WordPress responded to this post via email, so I won’t post their generally balanced but slightly grumpy response…

I’m really sorry I annoyed the folks at WordPress. They do have a great product, and I thought they’d like to know that it wasn’t working properly in Apple’s new browser.

Apparently not. Maybe I should explain myself further…

I guess we’ll just have to wait and see whether WordPress is still broken when Safari 4 gets a proper release, but my point was actually about Standards, and how developers can get tripped by them from time to time.

Automattic have claimed, correctly, that because this is a Beta release they won’t be supporting it. However Safari 4 Beta is the only browser (excluding developer-only nightly builds) to pass the Acid3 test for rendering. Acid3 specifically tests ECMAScript and DOM rendering. The browser’s WordPress currently support get at best 75%, so there will be some changes, and Safari 4 is likely to herald them, just as Firefox 3 forced some sites to change their CSS. There’s a good chance that the issues affecting WordPress will be seen elsewhere too.

Microsoft has been through a similar issue recently, trying to decide how Internet Explorer 8 should render old websites aimed at Explorer 7.

I’m sure the folks at Automattic know all this, other WordPress users have found the problem also. I did seem to annoy them however.

Safari 4 beta is fast, nifty and… has different tabs. You may like that, but I certainly didn’t. Here’s what’s wrong with Tabs along the top…

1. With multiple tabs open you can’t read the full title of the page. Fail!
2. Double clicking the title area minimises the window, so with Tabs on top, accidentally clicking twice while selecting a tab minimises it completely. Fail!
3. Information about WHAT you are looking at is now truncated (1) as well as being further from the window. This is important, because it requires more work to scan across the bookmark and URL bars than it does to simply meet the top of the browser chrome. Fail!
4. The same goes for targeting a tab with a mouse or pointer. Fail!
5. The close button for the first tab is a hairs-width from the “close everything” button. Don’t hit the wrong one! Fail.

One proposed advantage of having tabs at the top is that it takes up less screen real estate. But then, have you seen how big some mac screens are?? Most Mac users (except for smaller laptops) would run Safari at less than full screen anyway, just so it useable.

This seems like a big usability blunder for Apple, probably so that Safari 4 looked “New” or something. Ironically, the best menu bar feature for Chrome, its two control icons on the right of screen, don’t even appear in the Mac version of Safari 4. Safari on a PC can be run without menu’s on, which is tidy.

I don’t get it, Tabs weren’t broken. Why change them?

Thankfully, Random Genius. has found a fix. Just open a Terminal window, type…

defaults write com.apple.Safari DebugSafari4TabBarIsOnTop -bool NO

And restart Safari. Your normal tabs are restored, and you now get all the benefits of a very fast CSS and JavaScript rendering engine without the frustration.

For more ways to revert bits of Safari 4 you don’t like, visit Random Genius.

You’ve just updated a website design or finished a lengthy series of design iterations, and your CSS file has grown with every move, but chances are you don’t need half the selectors that are in there. This can be especially true if you have adapted a default theme, or are using a templating system that has inheritance, like that used by Drupal.

Using the combination of a good CSS Optimizer, DustMeSelectors, and a little bit of PHP, however, you can fix it in no time at all.

Optimize your CSS

Running your CSS through an optimizer is good practice. It will reduce file size, sort selectors, remove incorrect properties and generally tidy your mess. There are several available on the interwebs, but my favourite is Optimizer over at Flyspray.

Some good settings for the Floele@Flyspray CSS Optimizer are:

• Compression: High (puts each selector on its own line)
• Sort both selectors and properties
• Choose lowercase selectors and properties (always make your selectors lowercase)
• Remove last ;

This should spit out a nice, clean CSS file sorted by ID’s, classes and elements, and then alphabetically.  Once you get used to this, it makes finding your selectors a piece of cake, and ensures that the CSS specificity is uniform.

If you didn’t write your CSS like this in the first place, you may find that your site has now changed(?!), so you may need to go back and correctly weight or remove selectors (I usually find myself able to remove properties after ordering my CSS, rather than adding them).

Dust off 

Next, you want to know which selectors you don’t actually need. Thankfully, there is a Firefox extension which makes this dead easy, Dust-Me Selectors. 

Once you have installed Dust-Me, simply visit each type of page on your site and click the Dust-Me icon to scan your css. I usually visit some combination of:

• The home page
• One of every content type
• Administration pages
• Channel or aggregation pages
• Forums
• Log in page
• Any other special or unique page

At the end, you should be able to export a list of unused selectors to CSV from Dust-Me.

Cross Check

Here’s the annoying bit. Now, using the CSV list of selectors, cross-check this line-by-line with your original CSS file and remove anything that appears in both.

That’s what I started doing, but by line 10 of 256 I was over it, and decided it would be quicker to use PHP. So, here is the solution.

The code below will cross check your Optimized CSS file with a text file of Selector names to remove. 

There are some caveats with this script:

• It assumes you have optimized first, to remove errors.
• Selectors and their properties must be on a single line e.g.

 .style{width:100%;height:20px)
not
.style {
   width:100%;
   height:20px;
}

•  There are no comments in your files
• The selectors to remove (from Dust-Me) are in a simple list inside a text file, with a new selector on each line, e.g.

.style
.style a
.style h2 

Save the script in a new file called process.php, save your css into the same folder in a file called style.css, and your list of selectors to selectors.txt.

Hit process.php in your browser, and it should spit out a list of the remaining selectors, which you can copy back over your original stylesheet (but save a backup of the original as well).

You may want to run this list back through the Optimizer to remove duplicate properties and make it a bit smaller again.

<?php
/**
 * Compares a css file with a list of selectors and removes matching
 * Files must be in this directory
*/

process();

function process() {
	// Get CSS file (style.css) and read into a starter array
	$css_original = "style.css";
	$style_setup = file($css_original,FILE_SKIP_EMPTY_LINES);

	// Transfer that into a key, value array
	$styles = array();

	foreach($style_setup as $line) {
		//pull the definition off the end
		$kv = explode("{",$line);
		$selectors = $kv[0];
		$definition = "{".$kv[1];

		//break up the selectors
		$s = explode(",", $selectors);

		//add the selectors and definitions to the styles array
		foreach ($s as $item){
			$key = trim($item);
			$styles[$key] = $definition;
		}
	}
	// remove duplicates
	$styles = array_unique($styles);

	echo "Style.css completed\n";
	echo '<h1>Original Styles</h1>';
	print_styles($styles);

	// Get Selectors list (selectors.txt) and read into a single column array
	$css_remove = "selectors.txt";
	$selectorslist = file($css_remove,FILE_SKIP_EMPTY_LINES);

	//remove dupes and trim whitespace
	$selectorslist = array_unique($selectorslist);
	foreach($selectorslist as $item) {
		$discardlist[] = trim($item);
	}

	// Find matches in both files and create a keep and discard array
	$css_discard = array();
	$css_keep = array();\

	foreach($styles as $key => $value){
		if(in_array($key,$discardlist)){
			$css_discard[$key] = $value;
		} else {
			$css_keep[$key] = $value;
		}
	}

	// print remaining style to screen
	echo '<h1>Remaining CSS</h1>';
	print_styles($css_keep);

}

function print_styles($items) {
	foreach($items as $key => $value){
		echo $key.' '.$value.'<br />';
	}
}
?>

This is a simple script, and intended for a specific purpose, so you may find it doesn’t work in some situations – I haven’t tested it extensively. I also am not responsible if you accidentally delete CSS you really needed… you need to make those calls yourself. Best of luck.

Multisite installations in Drupal 5 were either simple or dangerously complicated. With Drupal 6, however, its much easier to create simple, inheritance-based multisite setups, using only a couple of modules and some theming know-how.

Domain Access and Virtual Sites

The two modules that make all this much simpler are Domain Access and Virtual Sites. Only one is required and they both have a different set of features, but each allows you to configure websites on different domains which share Users, Content and other basic features, without table prefixing or other nasties.

Domain Access

Domain Access is designed to manage “affiliate sites”, which may or may not need to share content and users. It’s very powerful and flexible, but add’s a requirement that all content is associated with at least one site. This can be set by default, but if you have a large backlog of content and its not all on the one site you have to configure this manually. Depending on how many nodes you have this may be a big job.

Otherwise, Domain Access has a strong feature set:

• Multiple hostnames per domain
• Configure offline & footer messages, as well as default homepage
• Provides menu blocks for each domain
• Optional table prefixing functions
• Set a default domain for site links
• Optionally require users to belong to a domain to see content for it
• Set the domain theme
• Automatically creates subdomains for each user
• Integration with Views, Organic Groups and Taxonomy Access Control 

To get Domain Access to work does require adding a few lines of code to your site settings file, and it will require a rebuild of your node access permission on install.

Virtual Sites

On the other hand, if you want a simpler solution, Virtual Sites is a good option. This module leverages the Condition module to check for various conditions and returns a Site configuration as a result.

While Virtual Sites doesn’t limit content or users the way Domain Access does, it gives you more configuration options and allows you to switch “site” based on any rule (or combination of rules) set in Condition (currently Hostname, Path, Site Folder or Custom PHP, which could be used to set on Taxonomy options as well)…

• Set different themes and theme settings
• Set different site information
• Add custom CSS or JS
• Set custom drupal variables
• Force a base url
• Set the site language

Conclusions

Both Virtual Sites and Domain Access offer a powerful set of features that allow the user to easily create new sites from their drupal installation. Domain Access is more suited to affiliated sites which want to control access and posting across domains, while Virtual Sites is suited to control and display of content at the theme level.