We’ve almost doubled in size in 2011. Thanks everyone! It’s been a great year… now everyone go and upgrade to a Pro account so we can afford all the servers! Seriously though… we’re going to take this success and turn it into limeade! We’re working hard to release some great new features and products, including our Heroku Plugin and the long awaited Blog Module. We’re also looking to grow the team, so if you know any Web Developers (could it be you!?) that are looking to join our rag tag team at Pagelime and help us with building the product, managing customer relationships, and executing some smooth marketing – send em on over to contact[at]pagelime.com.

One of our most popular features is the “Repeating Region”. However, it also causes quite a bit of confusion when you’re first starting out. Here are a few tips for getting everything working just like you expect.

#1 – You can make a repeating region editable!
If you place both a “cms-editable” and a “cms-repeat” on a Pagelime-able element,  you will be able to edit and repeat that piece.

Example: <div class="cms-editable cms-repeat" id="textblock1">Pagelime rocks multiple times</div>

#2 – Apply your styles to a class.
When we repeat a region, we need to place a new unique ID on it so that Pagelime can also target that element for editing. Because of this, any styles that you would like to see repeat, need to be attached to classes. We bring all the classes to the newly created element after a repeat action has occured

Example: <div class="thiswillbesaved blue cms-repeat" id="thiswillbechanged">Pagelime rocks multiple times</div>

#3 – Wrap everything completely
If you want to repeat a table, image, or create blog-like functionality wrap everything. Don’t do multiple repeating regions. Just take the whole set of elements wrap them in a div or span and place the editable classes on that. Feel free to make as many editable regions within there as well, but make sure to keep rule #2 in mind.

Example:
<div class="cms-repeat" id="whatever">
<p class="cms-editable" id="title">I change my mind:</p>
</div>

From now on, on Premium Accounts only, Pagelime will back up not just the content history (as we have done so far) but also full page code each time a user publishes a page. We will securely store a copy of the page source code, as it was right before we upload the new version.

So here’s how to use the full code backups:

From the Content History panel, you will be able to navigate to a list of available full page backups:

When you click this link, it will take you to a list of available backups sorted by date:

Click on a backup to pull up the source code as it was right before that publish occurred.

That’s it – no magic.

We securely host all of the backups, they are accessible only by you, and each access request generates an access token that is valid for only a certain short period of time. This way we ensure that all your data is extra secure.

Yeah… I know… clearly this is long overdue. We’ve been so busy making Pagelime better we never took the time to get our social networking in order. Like our page, get discounts and beta access to new features in the future.

Oh yeaaaaaah click here.

What is a CNAME?
From Wikipedia:
“A CNAME record or Canonical Name record is a type of resource record in the Domain Name System (DNS) that specifies that the domain name is an alias of another, canonical domain name. ”

From Tom’s Brain:
“A CNAME is like a subdomain, but instead of pointing to files on server, it points to a completely different domain. The big perk is that you can reference it in a URL the same way you would the original domain.”

Setting up a CNAME:
Your CNAME is setup where your nameservers are located.
This consists of 3 parts:

• Part 1 is picking the type of record, usually you get a few options: “A, MX, CNAME, etc”. Guess what? What? Pick the CNAME. Got it!
• Part 2 is picking the hostname/alias. This is the wordyouwant.yourdomain.com. So if you want to have changeyerstuff.websitedesignkingpin.com, you would place “changeyerstuff” in this box.
• Part 3  is the value/destination/pointing to/domain/referrer. In this case since you’re using Pagelime it will always point to “cms.pagelime.com”

Registering your CNAME with Pagelime:
Go to your Account Settings, in the CNAME box put the full CNAME record, continuing the example from above you would place “changeyerstuff.websitedesignkingpin.com” in the box below.

Some things to keep in mind!

• CNAMES are just like any other DNS level change they take some time to propagate across the whole internet, sometimes as long as 48 hours, so if it’s not working just wait a little bit.
• When it’s configured correctly the page will be light gray with your logo centered. If you’re still seeing the black and green Pagelime login screen you’re doing it wrong.
• CNAMES are not subdomains, there are no actual files on your server there, you can’t upload other stuff to them, or try and create custom pages. It’s a pure DNS level redirect.

That’s it! Good luck.

• The background of Pagelime is not white (#fffff) it is actually slightly off white (#f9f9f9).
• Transparency (alpha channels) do not show up, as we deal with many different browsers. We suggest everyone just sets the logo background to #f9f9f9
• While there are no constraints on height, the maximum width is 200px. If you don’t want scaling issues or extended load times I would resize and optimize manually before uploading.
• From a theme perspective it makes everything look more custom built if you select a color in your logo as an accent color in Pagelime. Your clients will be impressed, and everything will look more polished.

That’s it. If anyone has anything they want to add, or has any questions, feel free to leave them in the comments.

Bonus Coverage: Lime Rickey Recipe!

3/4 oz fresh lime juice
1 oz simple syrup
3 dashes Angostura bitters
6 – 8 oz club soda

Pagelime now has Per Page Permissions (and added alliteration!)

This has long been one of the most sought after requests from the Pagelime community. As a Pagelimer you can now limit the pages that your clients can access to on a per user basis.

What this means for your clients:

1. You can stop Jack from changing Jill’s bio to “Second place tumblr” all the time on their About page.

2. You can allow Neo to change Neo’s page as well as Morpheus’ page, but Morpheus’ can only change his own page. Whoa.

3. Lucy can see all the pages on the site and publish them. Charlie can only see his page, and not even publish that. AAUGH.

What this means for you:

1. More power! You now get to play god with your clients, giving them permissions to edit their site as you see fit.

2. More money! You can now charge them for this feature as a line item on your invoices.

3. More control! Get granular baby! If you have a client who has a friend who is always breaking stuff… keep them off the homepage. Or if you hate that client only let them on the homepage. It’s your call!

It’s in Pagelime right now. It’s a Pro only feature (aka. give us some of your green!). We know you will love it.

- The Lime Guys

Quick tutorial:

1.  Make sure you enable “Per Page Permissions” in the features of the site you want to use.

2.  Add some pages to the site map either by using “Site Pages” or just browsing to them via your websites internal navigation

3.  Browse to the user you want to enable permissions for in the “Users and Permissions” section then click on the “Permissions” tab.

4.  Click on the plus icon next to the website(s) you’ve enabled the feature on.

5. Click on the checkboxes for the appropriate permissions on the appropriate pages. (If you click the checkboxes inline with the site, it will add or remove all permissions across all pages.

6. Save your changes and you will be all set!

Simple stuff. Just the way we like it around here at Pagelime world HQ.

Here’s what happened, how it affected us, and what we’ve done since to mitigate this issue:

• The North Virginia region of the Amazon Elastic Cloud infrastructure had a major set of issues with their storage: the Elastic Block Store (the EBS). The EBS is meant to be a highly redundant form of storage with very low rates of failure, where any single disk failure should not affect availability of the actual data. Turns out this isn’t exactly the case: the entire block store seems to have become unavailable within a number of regions.
• A number of web companies were affected, including Foursquare, Reddit, Quora, and HootSuite to name a few. A number of web apps like ourselves assumed the issue would be resolved promptly.
• Amazon took about a day to repair the issue, at which point service was restored, and things began to operate normally. This puts our current uptime at 99.4% for the year. We need this to be better for both our users and our peace of mind.

Here’s why we use Amazon AWS and not a custom brewed hosting solution:

• Amazon AWS is fast. It gives us really good response times, and the storage performs very well for the price. Which allows us to keep our costs down for our users, while providing the best service.
• Amazon AWS is highly available. It allows us to host servers in Virginia, North California, Ireland, and Asia Pacific at the same time, so that a Pagelime server can always be available to close to where you are.  The same goes for their simple storage service: S3.
• Amazon AWS is highly scalable. We can provision new computing and storage resources very quickly. It puts scaling into our hands.

An ideal setup with AWS should not have failed even in the outstanding scenario we had over the past two days. Here’s why ours failed:

• All of our data is stored in multiple availability zones (around the world) by both our databases and our data files stored in S3. This worked like a charm, our database immediately failed over to an available instance, and our data was un-affected. This is good.
• The same goes for servers hosted in multiple availability zones. Only the ones in the US-East zone were affected. This is good.
• However, for speed of use, Pagelime caches all of the data files, such as content, images, and documents, on Elastic Block Store volumes… the very volumes that failed completely. This cache allows us to quickly publish content without a lot of round-tripping between the database and the servers. This crippled us for a day, and we’re fixing it.
• Pagelime also runs the publish engine from ONE single destination. The reason is that we want the publish engine to always originate from one IP address, so that firewalls and hosts can white-list us. This publish engine happened to be in the affected zone. We’re fixing this as well.

Soon after the outage happened, we initiated plan B, and began to migrate all of our cache/engine to a different availability zone. This was great as an emergency response, but we want to be resilient to these failures in the future. Here’s what we’re doing to prevent this from happening again:

• We are purging the publish cache. From now on, the data will be published directly from the data store. This may result in longer load times when you press the publish button, or when you publish an image gallery, but it should reduce the potential of future failures. We unfortunately have to cut this performance optimization for the sake of reliability.
• We are adding code to the Pagelime application that will actually fail-over in the software itself to different storage models should one appear to be failing.
• We are creating a backup publish engine in a different part of the world. And for those folks who have bypassed firewalls, we will send this IP out as well, to be added to their web host’s firewalls.

We’ve learned a lot from this. We were really proud of our cloud infrastructure, and the speed / reliability we were getting for the price. After this incident we’re a bit sobered, and we realize that we need to put even more effort into it.

We’re grateful for the outpouring of support we’ve received from you via email. Thanks for standing by us – we’ll make sure to pay it back in kind.

The first bug is occurs where sites that had been working suddenly stop working (or never work in the first place). We’ve narrowed it down to a specific issue. Somewhere in the last 3 weeks many server hosts have upgraded their FTP servers to 220 ProFTPD 1.3.2 Server. To confirm you are experiencing this specific bug, click “Browse” in the site settings and then the log should look like this

It appears to be primarily with IX Webhosting, but ProFTPD is a common component of many hosts. If you could please leave a comment with the domain that is failing, and where you host your sites (Host Gator, Media Temple, etc). We’re actively working on rolling out a fix for this ASAP.

The second is a bug with our iPhone app on original iPhone 3G phones. It appears like the app loads quickly, then crashes immediately. We’re looking for people with iPhone 3G’s (NOT 3GS) to help us beta test a fix before our next release.

Thanks! We’re always trying to get everything fixed as fast as possible. Happy New Year everyone! Go get some more clients!