One Site, Two Servers: A Cascade Server CMS Solution, by David Dent


Published on

Sites requiring an intranet and a public version present a special challenge to Cascade Server developers. In this presentation, David Dent from the United States Naval Academy will show how his team approached the problem.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Hi, I’m David. I’m here from the US Naval Academy in Annapolis, MD. This is my second User Conference and my first as a speaker. I hope to do more as I learn more about Cascade server.But right out of the box we encountered a challenge and I am here to walk you through how we approached the problem and eventually solved it. So let’s get started.“Two servers, both alike in dignity, in fair Annapolis, where we lay our scene…”The Naval Academy has two web servers. We have a lot more than two servers, but these two are dedicated to serving web pages. We call them “Webster” and “Washington”
  • So why two servers?Some of it is historical, but there are three primary reasons. Policy, Security, and Accessibility. -- This policy is “Navy Wide” and we can’t change it.-- For security reasons we hold the safety of the Mids and Staff very dear and so we are sensitive (perhaps even too sensitive) to possible risk.-- Most of these applications are for things like class selection, services on the Yard and system maintenance, but interconnectivity is useful enough that to break it would cause a disruption.
  • We try to limit departments and groups to a single site, but sometimes it is necessary.In those cases this is a typical split. One person, usually assigned by the department head—and sometimes a midshipman—is responsible for maintaining these sites. They are given a “web account” that gives them access to their site directories on the servers and from there they are expected to maintain the site.When they are created we try to make sure that they are as close as possible in order to insure consistency. But it rarely lasts forever.
  • Pretty soon the situationdevolves. Links to files are usually the first to break as the maintainer forgets to update both sites. Or they upload updates to the wrong place.Second to break is any page that lists classes, staff, projects….they get forgotten. Then someone forgets that they have two sites -- often when the midshipman who was maintaining the pages graduates and someone else is dumped into the hot seat.Lastly there is the dreaded “old site folder”. One of my first projects coming to the academy was cleaning out an old site folder with 30GB of files that had accumulated in it from successive redesign efforts on the part of midshipmen.SIDEBAR:I don’t want to give the impression that Midshipmen aren’t committed to the sites they are responsible for. A Midshipman’s schedule is very regimented and they don’t have much free time to devote to full blown web site maintenance.  Between Academic, Athletic, and Professional ( Military ) commitments they are left with only a few hours each week for extra duties. To be honest, I’m always impressed by the Mids who volunteer to maintain sites.
  • So, when we decided to use Cascade Server we got excited about re-using content. We got excited about being able to remind people to update files (using workflows).We got excited that we could have a universal template that everyone was using. And it supported “multiple destinations”It had a strong security ModelIt was non-techie friendly. Surprise revelation: A lot of the Staff and Professors of one of the best tech schools in the US are not web-savvy.
  • So we got our initial site designed by the staff at Hannon Hill and I immediately started tearing it down to see how they did things. It was very educational. I learned a lot and basically decided to rebuild from scratch. I kept the one Hannon Hill created to refer to, though. “Waste not, want not”I created a common site for “universal” assets. I imported the CSS sheets and graphics we use for intranet and public sites. I created a template in the common siteI created Metadata sets and Data Definitions in the common areaI created Configuration sets in the common areaAnd then content types in the common area---At this point I created sites and base assets in those sites.
  • I created common transports because with only one server you only need a single login for each server.I created site-specific destinations because each site had its own folder on each server.The idea was, you could publish your pages to the folder on the server you wanted them to appear on.
  • Here’s where it got weird.
  • We considered this solution. It has the advantage of allowing us to specify destinations by configuration.But we ran up against the same problem with files as before. (go back one slide)This solution only addresses pages (which have a destination)…Not files.
  • If a client has an intranet and a public site then they have two sites. In order to facilitate shared content while maintaining server-specific formatting we use a “clone content” page picker field.
  • This is what it looks like to the user.
  • The is_USNA() code construct is part of a PHP library that is attached to every page. SIDEBAR:USNA calls it’s campus “The Yard” but for us in the ITSD “In the Yard” means: at the Academy, Alumni Association, Athletic Association, and the Prep School in Rhode Island.  A civilian university could translate the concept into satellite campus’ or a State University system like SUNY.It allows us to have content on the public server that is intended only for users within “the Yard”. Links to intranet pages and filesMidshipmen-specific instructionsLinks to applications for faculty and staff onlyThe best use we’ve found for this is the site that only needs minor information for intranet users and so may not require en entirely separate intranet site to maintain.
  • When they are published. independently. They look the same, but are styled in the “server style”Note, the sites have different banners, menus, stylesheets, and “searchbar” linksAnd when one page is updated the other is also automatically updated, eliminating the need to maintain two identical pagesFor files we encourage the intranet pages to link to public files rather than duplicate both. It saves space in the database and on the servers.
  • In the future we hope to see some sort of improvement to Cascade Server that would allow us to specify a destination on an asset-by-asset basis.
  • Thanks for following along with me on this process.If you have any suggestions or comments, please share them.
  • One Site, Two Servers: A Cascade Server CMS Solution, by David Dent

    2. 2. WHY TWO SERVERS?Policy• Navy policy only allows us one public-facing web server and domain.Security• Some Intranet pages contain “security sensitive” information. (i.e. midshipman brigade movements)Accessibility• Our intranet server is the gateway to many applications only viewable “on the Yard”
    3. 3. WHY TWO SERVERS? INTRANET PUBLIC• Homepage • Homepage• Contact information • Contact information• Links to files • Links to files• Photos of work • Photos of work• Course descriptions • Course descriptions• Faculty bios with pictures • Faculty bios• Midshipman Project Briefs
    4. 4. WHY TWO SERVERS? INTRANET SITE PUBLIC SITE• Homepage • Homepage• Contact information • Contact information• Links to files • Links to files• Photos of work • Photos of work• Course descriptions • Course descriptions• Faculty bios with pictures from last year• Midshipman Project Briefs • Faculty bios (last updated 2008) • An “old site” folder
    5. 5. CASCADE SERVERReusable ContentExpiring ContentConsistent DesignMultiple DestinationsStrong Role – Group – User security modelNon-Techie Friendly
    6. 6. USNA CMS SERVER metadata set content type base pagetemplate data definition base page custom content type configuration set content type base page configuration set Common Area Site Area
    7. 7. USNA CMS SERVERcontent type base page custom base page content type transport Intranetcontent type Intranet base pagePublic transport Public Common Site Area
    8. 8. CONTENT TYPEMy content types (whichare shared in a commonarea) can’t publish to asite-specific destinationSo everything getspublished everywhere.Pages that are securitysensitive were gettingsent to the public server.
    9. 9. EDUCATE ON PUBLISHINGInitial Solution.Have the usersuncheck thedestinations andconfigurations whenpublishing sensitivepages.
    10. 10. EDUCATE ON PUBLISHINGRoadblock.How do you handlefolders full of files ormixed intranet andpublic pages?
    11. 11. LOCAL DOCUMENT TYPESSecond Solution metadata set content type base page template data definition base page custom content type configuration set content type base page configuration set Common Area Site Area
    12. 12. CURRENT SOLUTIONcontent type custom custom content type content type base pagecontent type base page base page base page Intranet transport Public IntranetPublic transport Common Public Site Area Intranet Site Area
    13. 13. CLONE PAGE Intranet Site This Page is the same as the public page Just a reminder for the user This is the original page
    14. 14. IS_USNA() Is_USNA() is a PHP subroutine that is included but isn’t integrated (yet) into the Format/Data Definition of our “Standard Template” PHP code does require #START-CODE and #END- CODE wrappers. This is considered an “advanced” feature for our users.
    16. 16. IDEAL SOLUTION
    17. 17. THANK YOU C. David Dent @MrDave2176