This form has now expired.
This form has now expired.
We are removing the slimstats plugin entirely because:
We will not be retaining the old slimstats analytics data, it was wildly inaccurate to begin with and even more so after the page cache was put in place. We will work to implement the open source piwik analytics for a completely free alternative, but we don’t have a specific deadline yet.
Thanks for your understanding!
A site blackout plugin has been installed on blogs.law. We had several requests for this feature from bloggers. However our creation of this blackout plugin does not constitute an official endorsement of a specific cause or policy. Bloggers on blogs.law always have complete control over the messaging on their blogs. Please consider this plugin another tool to increase the impact of your voice.
The options should be fairly self-explanatory, but to clarify:
We’re now running wordpress 3.3.1, the latest and greatest from Automattic. This is a bugfix release of the 3.3 release, AKA “Sonny”. About this release. . .
We’ve installed a new plugin to let you use custom CSS styling on your blog. Have fun!
Keep in mind some CSS features are sanitized/removed for security’s sake, including:
We’ve installed a google analytics plugin – you should see a “Google Analytics” choice under your “Settings” menu in the wordpress backend.
We’ve also installed a network-wide google analytics code to let us see activity on a broader basis. This doesn’t disclose any information to the blogs.law tech team that isn’t already available in the web server logs. We may not keep this network-wide tracking code in place permanently, depending on how well it jibes with our internal site-wide analytics.
Thanks for your patience, a lot of you have been waiting for better analytics for quite some time.
Short and simple – we’ve updated to WordPress 3.2. The video on this post about the new release goes through the new features pretty thoroughly.
Thanks for blogging!
The datacenter that hosts blogs.law.harvard.edu is shutting down from Friday 6/10/2011 at 9pm to approximately Saturday 6/11/2011 to 9am, a duration of 12 hours. This maintenance window is necessary to allow University Information Services to upgrade power infrastructure.
Most Harvard staff, students, and employees should already be aware of this planned outage, but we were remiss in notifying our non-local or alumni bloggers earlier. We apologize for the short notice.
We will be returning 503 error codes for page requests. More info on why at google’s webmaster central blog. We will have staff and extra equipment on hand to ensure a smooth transition.
Please see this post for details on new features in WordPress 3.1. Most noticeable will be the site wide toolbar you see when you’re logged in.
Also, be sure to check out the “Gravity Forms” plugin, which is a great way to create custom forms to collect data or create feedback systems for your blog.
We are frequently asked about our wordpress deployment by universities, NGOs and other institutions that’re interested in setting up their own multiuser blogging platform. We’ve been answering those questions on an ad-hoc basis – this page will serve to collect the most common questions and hopefully be something we can refer to interested parties. First – see our Project Info page if you’re interested in the early history of blogging at Berkman.
Notes: Answers are current as of 1/27/2011. This document does not represent the official position of the Berkman Center, Harvard Law School or any other entity.
Ubuntu LTS (multiple flavors). Any *nix would be great.
WordPress requires MySQL. There was a PostgreSQL fork a while back that died off pretty quickly. We have a well appointed database server (you’ll get a cert warning from this link as it’s using a self-signed SSL cert: the SHA1 fingerprint is CF:DD:34:9D:B8:CD:E0:B9:EE:E8:1D:0F:FE:A9:1F:33:36:58:0D:7C) that shares duties with many other sites and applications – the database server is not a virtual machine and has directly attached storage to maximize IO (all the normal stuff you’d do to create a high performance database server).
Our wordpress application server (again, you’ll get a cert warning because of a self-signed SSL cert, same SHA1 as above) is a xen VM with 3 gig of ram and 4 cores. We run nginx as a caching front-end proxy to our apache backend. I packaged up this nginx config as a plugin, along with sample configs, info here. My talk about high-performance wordpress (along with an overview of our nginx deployment) at Wordcamp Boston 2010 is here.
Hands down – the nginx caching proxy. Some requests are VERY expensive – RSS feeds, for instance. A caching proxy (or perhaps WP Super Cache) is a necessity. A default, uncached wordpress deploy IS NOT going to get you far.
You definitely want a physical machine to maximize MySQL IO. You should tune it properly for the large amount of RAM you’ve surely installed in it.
Your wordpress app server needs multiple cores to maximize concurrency.
Be sure to use a PHP opcode cache – APC has been nothing but unicorns and rainbows for us.
We could probably handle double the traffic with our current hardware, and nginx can load balance for us if/when we need to use multiple wordpress application servers. Our performance problems have not been related to our MySQL server so far.
No. We will install custom themes or plugins occasionally for special projects, but only after a thorough audit and after all development has taken place on a completely separate system.
A couple, but we’re factoring those out and have even contributed one to the wordpress core. We expect to be on a completely clean wordpress core by Summer 2011.
Yes and no. We use apache’s mod_auth_ldap to protect some private blogs, but we don’t use it to populate users inside wordpress. This has worked out fine, with few complaints from users about having a separate account. It also has the advantage of allowing those who wouldn’t be in a university LDAP server to have accounts – alumni, contractors, collaborators, consultants, etc.
Anyone with a harvard.edu address.
For comments, we use Akismet. It does a pretty good job, but it seems to be losing effectiveness over time. Either that, or the sheer volume of blog spam has been increasing – most likely it’s a combination of both. We also suggest that blog authors have comments close automatically on old posts (after, say, 30 days), and that they moderate comments to devalue us as a target.
For spam blogs or malicious users – requiring a harvard.edu address is a pretty high barrier. That said, we do have issues with compromised accounts, or university affiliates attempting to exploit us via linkfarming. We enforce our terms of service and view linkfarming as injurious to the university and against the spirit of this endeavor. Defining what’s spam can be a bit like defining obscenity – to paraphrase Justice Potter Stewart’s concurrence in Jacobellis v. Ohio, “you know it when you see it.”
We host personal blogs, project blogs, the entire web presence for various working groups, archives of administrative updates, and a whole slew of other types of content. It’s perhaps best shown rather than told through a very small selection:
We wanted an open source multi-user blogging platform and it seemed the best choice at the time. We’ve been very happy with it, and there have been real improvements to the core features WITHOUT the core team throwing backwards compatibility under the bus.