How to set up a Walled Garden: Revision

Last updated by Ed Lyons

There are lots of reasons you might set up a walled garden.  Some uses would be:

  • A private company's intranet
  • A high school
  • An extended family
  • An organization's private network

There is one important thing for you to remember: Elgg was not meant to work this way.

Elgg actually can work this way just fine, but there are details you have to take care of to make sure things are alright.  But don't assume anything.

The big thing you want to do is set up the "wall" around your site (so no one can get in).  This was originally accomplished by putting a PHP gatekeeper() statement before the rendering of all pages.  This didn't really work well because (I am only going to describe this to show the issues):

  • Cron pages could not be reached
  • The lost password could not be reached
  • Certain "external" pages were out of view (about, terms, etc)

Fortunately, the new ways of doing this have taken a lot of this into account.  The new starting point is to not use the "walled garden" plugin, but to use shellcode's site access plugin, which is pretty good! It has settings for you to define what pages are in and out, with sensible defaults.

 

But what about access controls?

This ends up being big issue.  Why?  Elgg's out-of-the-box access levels are: Private, Public, Logged In Users (and groups, personal friend collections).

However, as soon as you have a walled garden, you have a problem.  What does "public" mean now? 

It turns out that there suddenly is no difference between public and logged in.  While it might not matter in the system, your users will get confused.  Also, what about "private"?  Many people who do walled gardens want to get rid of "private" - such as schools - who have figured out that having everything out in the sunshine means nothing inappropriate goes unnoticed.

Site owners soon realize that they either want "public" to go away for private adult sites so that people don't think stuff will be pushed outside the walls, or they want everything to be public for kids sites.

You have two choices now: 

  • remove an access level (levels) from the system entirely
  • change the rendering of the levels so that some are just not even shown

 

But of the two choices:  the first one (removing the level from the system) is really, really dangerous.  You don't want to do this as many plugins have a certain understanding of the world, and you're probably going to break something.  It might be OK to remove private, but you will be in a world of hurt if you remove public.  Only do this approach with a really good reason.

Instead, change the way they are rendered.  (insert code example here)

Changing the access names

This can be done by changing what they are called in the top level languages file, such as /languages/en.php

Changing the default, order in the access list

The order of the access options also matters a great deal.  If the default is "private" most people won't notice and suddenly, not a lot of content is accessible.  This might be OK in rare circumstances, but you want the default option to be the most applicable.

The best way to do this is to set it in the administration settings.  The other way to do it is in the rendering code in access.php - which you'll have to do if you need to change the order of more than one.  Again, this is risky.  There is a temptation to get the index of an element and put it somewhere else.  You'll say, "Well, that index is private, so I am going to put it later."

IMPORTANT

But... what you don't think about is that code is also used for groups.   If you remove or re-order elements, you will discover when creating or using groups that you get really weird results, as there are other labels and settings for those same numbers.  So when you make a code change, you need to check for the labels also so you don't move the group options.  [insert code example here]

 

History