Although WordPress and WordPress MU share somewhere around 95% of the same code, there are many more differences between the two than just multi-blog support. Here’s a thorough analysis:

WordPress	WordPress MU
Supports one blog with multiple bloggers.	Supports multiple blogs and multiple bloggers. Bloggers can write for multiple blogs.
Famous for its “5 minute install.”	Setup is more involved.
No advanced hosting requirements.	Your host needs to support wildcard DNS to use the subdomains feature.
Instant installation (through Fantastico, etc.) supported by many webhosts.	FTP time!
Each user is assigned a role level (subscriber, contributor, author, editor, administrator).	In addition to the standard WordPress roles, you can also specify “site admins” who can add/edit/delete all blogs and users.
WordPress receives updates first.	MU users must wait for WordPress updates to be applied to WordPress MU.
Administrators can edit themes, plugins, and code files from within WordPress.	The Theme Editor, Plugin Editor, and Manage Files sections are all disabled for security reasons.
Plugins can be enabled/disabled by the blog administrator.	The site admin can opt to have plugins disabled altogether (the default setting), or allow blog administrators to enable/disable plugins that have been uploaded. Plugins can also be uploaded to a special “mu-plugins” folder, where they will be executed automatically on all blogs. (Some plugins won’t function property when run this way, however.)
If you have multiple blogs running standard WordPress, you’d need to upload plugin updates to each one.	Plugins for all WordPress MU blogs are stored in one place. Update once, and it takes effect on all the site’s blogs.
If you have multiple blogs running standard WordPress, you’d need to login to each one separately to access the administration.	You can switch between blog admins using a simple drop-down menu.
Allows you to use most HTML in your posts, but strips out PHP.	In addition to removing PHP, WordPress MU is more strict in regards to what post HTML it accepts. For example, it will strip out class/ID attributes, inline styles, <span> tags, etc.
WordPress allows posting via email.	WordPress MU lacks this feature.
WordPress lets you customize its list of update services.	WordPress MU doesn’t let you specify update services.

Are there any other differences between WordPress and MU that I missed? Let me know in the comments!

http://wordpress.jdwebdev.com/

http://wordpress.jdwebdev.com/#test

Sure, the Digg button’s behavior could be useful in some situations (like when anchor-based permalinks are used). But what happens when you click the “Read more” link on a WordPress post? Yep, it takes you to a URL with an anchor. Although this seems trivial, it could nevertheless result in:

• Your readers’ Diggs being split across two submissions for the same thing.
• Your Digg button showing a “Submit” option instead of its true Digg count.

Here’s how to fix it:

It’s pretty simple. This is assuming you added the Digg button to single post pages yourself as opposed to using a plugin. (If you use a plugin, check and see if the author took the anchor factor into account. If not, contact the author and send him or her a link to this post.)

1. Login to WordPress administration, then go to Appearance > Editor > Single Post.

2. Find the code for the Digg button. Here’s the typical JavaScript:

   <script src="http://digg.com/tools/diggthis.js" type="text/javascript"></script>

3. Insert this line of code right before that one:

   <script type="text/javascript">digg_url = "<?php the_permalink(); ?>"</script>

4. Click Save, and you’re done!

You shouldn’t have to worry about other buttons like those for BloggingZoom, Sphinn, and Scoop, since they don’t seem to have this anchor issue.

Social this post and share this tip with other Digg-using bloggers!