Merging 120 Sites into a Multisite Plone Solution (PSM14 Recap)
This is a recap of my presentation at the Plone Symposium Midwest 2014.
Managing Chaos: Merging 120 Sites into a single Plone Multisite Solution
WHO AM I?
- Director of Engineering, Six Feet Up
- Organizer, IndyPy, Indianapolis Python Users Group
What will we Learn?
This talk covers:
- Six Feet Up's multisite solution with Plone and Lineage
- How we went about consolidating 120 Plone sites into one multisite solution in less than 90 days
- How this improved performance
Discovery
Penn State has been a long standing client with Six Feet Up. The College of Liberal Arts asked us to look into the performance of their 120 eLearning course sites. We saw this as a great opportunity for them to save time and money by consolidating everything instead of maintaining all the separate sites.
Old Site Creation Workflow
Performance
One of the main issues with the old implementation was that there were 120+ copies of all the objects needed to create a Plone site. That means 120 catalogs, Quickinstallers, properties, registries, etc. There was a lot of needless duplication in the scenario which hurt the performance of each site. Since they were all housed in one Data.fs, there was no easy way to avoid the loading of all these duplicate objects.
Migration
How is it made?
For the department and course types, we utilized Lineage, an open source Plone product built by Six Feet Up. Lineage is a simple product that allows the course or department to appear as an autonomous Plone. It utilizes the NavigationRoot in Plone to make the navigation menu, search, portlets and anything else that does a search appear to be rooted at that level.
New Site Creation Workflow
Now, whenever a new course needs to be added, it's just like creating any other new content in Plone. In each department folder, there is the option under "Add new..." to add a new Course folder.
These course folders have additional fields for the author, course number and banner images. Things that were previously manually filled out are now just a part of the content creation process.
In addition to having the fields on the type, events are used to create content and automatically add faculty and staff to the course.
Permissions
Since we are still utilizing Plone and it's folder structure, we can still use the built-in permission system. Global roles and groups can apply to the whole site or local roles can be given to a user or group at a department and course level. This provides an easier way to manage users across the 120+ sites.
Disadvantages
There are a few disadvantages that come along with a system housed in one Plone site. If there was a need to split out a course or department into a new site, this would require a migration.
Since everything is in one Plone site, any add-ons or properties are going to apply to the whole site. It would be more difficult to restrict the functionality of an add-on to one particular course or department.
Advantages
On the flip side, having one set of add-ons to manage can be easier than 120 different configurations of installed add-ons. Upgrading or re-installing is more of a one-click process with less headaches.
Since the one Plone site houses all the content, it can be easily shared across departments or courses. No need for any external access, it can just be used directly.
Upgrading the Plone sites will be much easier moving forward. Instead of having to deal with 120+ migrations, there is just one.
The biggest advantage here was the performance boost that was gained. The system can handle the load of all those procrastinating students logging in on Sunday to finish their assignments much better now!
Learn More:
Thanks for filling out the form! A Six Feet Up representative will be in contact with you soon.
