Tag: site

Notes on Switching Servers

Posted on January 14, 2011 in Websites by Jeff Starr

Switching servers & migrating sites can be a HUGE deal (or not), depending on things like:

  • Number of sites to transfer
  • Size and complexity of sites
  • Who is hosting your sites
  • Experience

I recently did this, switching from a 3-year run at ASO to my new home at Media Temple. Total of 24 properties, with WordPress running on around 10 sites. Past experience with VPS servers really had me paranoid about running out of memory. A few years ago, Perishable Press alone gobbled up 256MB of RAM at WiredTree, so add another 23 sites on top of that and needless to say I was extremely concerned about the migration from a shared-hosting environment to a (dv) Base account limited to 512MB RAM.

Continue Reading

More Redesign Rambling: Columns and Sidebars

Posted on September 6, 2008 in Perishable by Jeff Starr

After announcing my intention to redesign Perishable Press, I received some great feedback addressing everything from site architecture and navigation to appearance and usability. As the conversations continue, I want to spend some time thinking about usability, navigation, columns and sidebars. The current minimalist design features a single column layout with no sidebars. Content is located prominently front and center, with all navigational links appearing in either the oversized “footer” area or at the end of each individual post. As several people have pointed out, such navigational strategy (or lack thereof) discourages visitors from digging deeper into the site. Apparently, the pile of links at the bottom of each page — the menu, as I like to call it — requires far too much effort to decipher. I mean, really, just because it all makes perfect sense to me, doesn’t mean that everyone else will “get it” too.

Continue Reading

Thinking About a Redesign and Trying to Get Unstuck

Posted on August 31, 2008 in Perishable by Jeff Starr

I want to redesign Perishable Press. The current design was released around a year ago, and has received numerous compliments and criticisms. Compliments tend to focus on the theme’s minimalist sensibilities, while criticism is generally directed at the design’s poor usability. Personally, I find the “grey-on-black” color scheme to be very inspiring. Others, however, have difficulties reading the content, and that’s not good.

Continue Reading

More Server Mayhem

Posted on December 10, 2007 in Perishable by Jeff Starr

Just when I thought I had finally solved my web-hosting woes by transferring to a virtual private server, I am slapped in the face by the cold realities of server memory limitations. Apparently, WordPress-powered sites are extremely resource-intensive, requiring insane amounts of random access memory (RAM), something which does not concern those of us working from shared hosting accounts.

On a shared server, system resources are shared among the various accounts that reside on a particular server. When one of these sites takes a hit and requires extra bandwidth, it “borrows” it from the total amount of bandwidth available for the other shared sites, leaving them with limited memory and other server resources. This is one of the reasons that shared hosting can suck so badly at times. If you happen to be located on a server that hosts a few resource-intensive or unstable sites, chances are high that your site will not perform as well as it might if its neighbors weren’t such stinking pigs.

With shared servers, it is this sharing of server memory that enables WordPress-powered sites to enjoy their resource-hogging plugins without too many issues. Sure, sharing memory can sometimes be a drain when you are fighting with hundreds of other sites for that extra megabyte of precious memory, but at least your site doesn’t shut down if you happen to exceed the predefined memory limits. This is exactly what happened after I setup Perishable Press on my new virtual private server at WiredTree. To be honest, since this was my first move away from shared hosting, I really had no idea how much memory my site was using. Turns out that just this one site — with its reduced number of plugins and optimized content — was enough to gobble up every drop of the 256 MB of allocated RAM without even blinking. It was like, okay, site now online — oops, not any more — you just exceeded your memory limits and crashed Apache. Again. Ugh.

Continue Reading