IBM’s web content management system has long had a feature called syndication. Syndication is used to move content from one server to another. In the typical environment, content is authored in one server, goes through a workflow process and finally gets approved. Once approved, that content then needs to be delivered to the production servers where our site actually lives. Syndication is the server process that understands when content is approved for publishing and pushes it to the correct production servers.
In the scenario above, you may end up with different users in the authoring environment than you have in the production environment, so you need a way to adjust permissions on the content after it gets syndicated. IBM’s WCM has a tool called Member Fixer that does just that. In the past, running member fixer was always a manual process unless you went to the trouble to write some scripts. If member fixer was not run, we tended to see issues with content not appearing correctly because of permission issues.
Now, however, WebSphere Portal 8 allows you to configure member fixer to run every time content is syndicated. Kalairajan Swarnam posted a blog entry at developerWorks that talks abut running Member Fixer after syndication and how it helps with the new Managed Pages feature of Portal 8. You can read hist article here: Member Fixer with Syndication.
What’s important about this new capability is that portal pages are treated now like content in Portal 8. This allows business users to create and publish portal pages just like they could always create content items. The syndication process will push portal pages from one server to another. It is really important to run Member Fixer after syndication so pages don’t end up with permission problems. By following this best practice, you will ensure your portal site won’t mysteriously lose pages.
