I'm building a site where we want to have a 'members only' area. The content for this area will be managed within MT, but only visible to registered MT users.
Before starting this project I had assumed that I could use the 'IfLoggedIn' tag to wrap around anything I wanted to be protected.
However, after digging around this does not do quite as advertised!
All it does is wrap the protected content with a div styled with display:hidden. Not good for content which is private as anyone could view source and see it. Plus, if you don't have JS enabled it doesn;t work at all!
Has anyone come up with a solution to this? We are thinking we might need to build a PHP version which reads the MT user cookies. A fair amount of work but might be the only way?
Reported on Movable Type 4.2
For now, unfortunately it is. You can embed PHP code into your published pages that will read the cookies and show people content accordingly. Shouldn't be **too** much of a problem, but it is an inconvenience.
Thanks for the info Mike. As I suspected!
Members/protected content is an area where MT really falls behind competitors like Expression Engine.
That is sadly true. There was a good plugin that provided support for this in the past, but the developer stopped maintaining it.
You may find this to be of interest.
Well there it is. I have been struggling so much with this issue. IfLoggedIn is laugable in that it doesnt do what we need it to do and besides it doesnt work anyway!
"You can embed PHP code ... Shouldn't be **too** much of a problem" Ah. I see. And to that I say B.S.
B.S. I say! I shout from the rooftops, B.S.!
Moving to WP will be a pain but if I cannot make private some entries and pages then I'm done with MT. WordPress has had this for some time, why is this so hard for MT? Why dont they buy Arvind's Privacy plugin, create a team to develop it further, debug completely, and document it. Release it to the world and be done.
Actually, rant aside, why don't they do that?
Is MT ready for prime time?
I think this was caused by the fact that MT-Protect just worked well enough on 3.X that it was never an issue, and Privacy worked for the first release of 4.0, ergo it fell off the radar. You are right, it is an issue. I'm not a 6A guy (just a plugin developer), but I posted your comment on the MTOS mailing list.
Before you jump ship, give them a chance to respond.
Protected content is exceptionally difficult to do "right" in Movable Type because of its static publishing model. To truly resolve whether a reader/visitor can view content or not, a dynamic publishing system is preferrable (technologically speaking). One reason for that is that if you TRULY want to make something private then those who are not permitted to see it should not even see an abstract. As far as those people are concerned the content can't exist.
MT can actually be a GREAT system where that is not a requirement. For example this use case:
* user wants to see a list of content for sale
* user can view an abstract, but cannot see full content without a purchase
But when privacy is truly a concern, there can be no risk of exposing content to an unintended group/user. To ensure that then the privilege to view content must be evaluated in real time.
Now, technically that is POSSIBLE with Movable Type, but I sincerely doubt MT could really scale in that scenario. If this was a private intranet, I can see it work. But it could never do the kind of robust privacy controls that Vox, Flickr, LiveJournal and the like do.
Just my 2 cents.
Byrne, MT could certainly be extended to do it and I believe it really has to if it is to push to be a viable alternative against the likes of EE.
We (in fact my colleague Mike) built a PHP privacy plugin in a couple of days and we've never built a plugin before. It works great for the project in question, using MT users and having permission levels by using MT user groups. Not ready for a public release, but look what we did with no previous MT plugin experience. With all the resources SA has there should be no reason why this cannot be rolled in as part of the core.
EE has a membership/privacy system and is gaining a lot of traction. If MT wants to push for the CMS space then it *has* to have members area functionality.
That's exactly what Byrne described, but says won't scale. Perhaps that should be qualified to "it won't scale as well as a true static publishing model". But, depending on how it worked it doesn't have to scale horribly.
You could make it scale better if there was a way to ONLY post process the pages that required post processing, but that may or may not be an easy thing to do.
We are getting around the scaling by using modules and module caching. I'm sure with the MT resources of SA they could do something that would scale.
Why not have MT blogs unprotected by default. Then they work as they do now. Turning on protection for a blog (where some or all of the blog might be protected) turns on the dynamic element used for the protection. It is only needed/called when needed then, not slowing down blogs that don't need it.
I've said this before. If MT want to be a viable CMS they *have* to find a solution somehow. So saying 'it won't scale' is not the point. There needs to be a way to make it scale.
Easiest is likely to make a separate blog and put htaccess and htpasswd files in that folder updated from the mt member db perhaps/cookies.
There mt is good in easily publishing to a folder.
But Bruce, that means an apache login box. Fine for a intranet perhaps but not for a public facing site where branding is key.
User login needs to be part of the site IMHO.
Matt, I've implemented this now three or four different times, in different ways, under static and dynamic publishing. If you have some budget for the requirement, you can contact me via email: http://endevver.com/