What do you use for your CMS and how does it integrate with LO?

Tanna Lewis

Firstly, would love to know in general what others out there are using for a CMS and how well it works with LO. Please share!


Then secondly and more specifically, we currently use Luminate CMS but are exploring creating some WordPress-based microsites. For those of you using WordPress (or something similar), how do you integrate it with LO? How do you handle user authentication as the user moves back and forth, and can you still serve customized dynamic content to your LO-logged-in visitors on your WordPress pages? Maybe using APIs? Would love any kind of direction!


As always, thank you all so much!!!

Tanna

Brian Mucha

We use RE. Works okay with LO, which is a little disappointing really. Orgs are handled very differently - plenty to read about that on the community. Setting up sustaining gifts isn't quite the same too. Stuff along those lines. Luminate was acquired, so you'd expect that - though I dearly wish BB had done more to bring them together by now. I've heard a while ago that the ultimate plan is to have RE and LO actually share a common database, but that must be a decade away if ever.


We use ImportOmatic, which does a lot to smooth things out between the systems. And Omatic can also import data into RE from pretty much anywhere else.


As for integration the story is better. Luminate has a Single Sign On API. (http://open.convio.com/api/#single_sign_on_api) Luminate can be either master or client. With LO as the master, the user authenticates against their LO account from the other CMS, and the user would then be logged into that CMS too. So you could use the CMS's tools for controlling content access and customization, just as though the user was normally logged into WordPress or whatever. This is exactly like using your social media login for other sites. Except here you are using your LO login for Wordpress.


That's a bit of heavy lifting to get working though. For most uses I don't do all of that, since the CMS doesn't really need to know about the logged in user at all. I mostly want a sub-navigation line at the top to show their name and a link to edit their profile and such, and to gain access to LO controlled resources like the constituent's data. For that you can just do client side authentication (http://open.convio.com/api/#single_sign_on_api.login_method.html) and then subsequent API calls. In this case the user's browser knows the user is logged into LO, but the CMS does not.


This is all JS/AJAX stuff... Show a form on your site which calls the LO login method and receive a session cookie along with some basic bio data. Now you can display the logged in user's name with a little JS in the callback. Next call other methods - passing that session id to return or submit authentication-required data.


Check out Noah's Luminate Extend library on GitHub. It makes all this far easier. He even has a way to do something like S120-Tags (or maybe more like mail-merge placeholders) to display api data on page, which addresses a lot of the dynamic content part. Anything more complicated could be done with a little JS.


B

Tanna Lewis

Thx much for the response, B! Login method basically aside, say on the WordPress-based homepage you wanted logged in users to see conditionalized content, such as a feature slide which only shows to people in a specific LO group. Which method would be the best bet in your opinion? And would it probably be total drama to configure? I still haven't personally worked with APIs in LO, though Noah built out an Interactions-related API form for us a while back, so we should be at least all set to start.


Also probably should have noted in original post, I basically hope to avoid iframes, but we did sort of poke doubtfully at the idea of iframing the WordPress content in a Luminate CMS page or LO pagebuilder page. Thoughts?


(And, FYI, reason for desired WordPress use is that our staff managing the Luminate CMS side of the websites finds it difficult to work with and likes the WordPress UI and simple plugin options.)


T

Brian Mucha

"likes the WordPress UI" - It looks like English, but those words don't make sense together.


I'm sure they are handled better than I remember, but I wouldn't be a big fan of an iFrame either.


If you go with the APIs I think there will be some work getting your framework written and in place and then it should be pretty easy to expand and reuse. It can be frustrating to debug.


There is an API to get the groups a constituent is a member of. (http://open.convio.com/api/#constituent_api.getUserGroups_method.html) So you could call that and check if the group in question is one of those returned. Easy. Then that same JS could show or hide a DIV or whatever.


But of course there is still a bit of drama. Group membership is cached - so unless that group is rebuilt on a schedule the call will probably be inaccurate. I stumbled on that once a couple of years ago using the S45 tag, and Noah* suggested a fix. You make a second query-based group that just grabs all members from the first group and rebuilds periodically, and then use that duplicate group with your API call. A bit clunky but workable.


Another issue is the wait for the API call and response. That could take milliseconds to several seconds, so your content would stay hidden until you get the response. Not intolerable, but it could be noticeable.


Additionally, since this is all client-side, your content is just hidden using css and still appears in the source code. It's not *security*. That would be more complicated.


B


* Someday Noah will quit and Luminate will slowly implode like the house at the end of Poltergeist.

​​

Tanna Lewis

Okidok, no worries - you are speaking my language with the rebuilding group business - have had to do the exact same for some other conditionalized content. And as always, you are setting me on a path, my friend! Will start working on APIs when this gets more pressing. Thank you so much!


AND thank you for a couple laughs. Poltergeist reference especially made me guffaw loud and maybe scare some people around me. Hope we never lose you here, either, Mr. Mucha!

Daniel Hartanto

Hi there


On your statement of "Also probably should have noted in original post, I basically hope to avoid iframes, but we did sort of poke doubtfully at the idea of iframing the WordPress content in a Luminate CMS page or LO pagebuilder page. Thoughts? "


Checkout / Google for "headless CMS" approach (pretty sure latest Wordpress has that mechanism, similarly on Drupal 8 you can create a View querying your specific content to be spit out as JSON where you could then call through REST API to render somewhere else (in this case on a Luminate Online pagebuilder for example)


Use Luminate Online pagebuilder instead of LO CMS -- this is because LO CMS can't handle https at moment, and when it comes to REST API, lots of them requires https nowaday (not necessarily talking about implementation of headless CMS, but if you are doing rest API with google etc)



As for Single Sign On with Luminate Online


Recently got a chance to do so with external 3rd party/vendor CMS -- check this out
https://www.diabetesfoodhub.org/


Basically the login/registration section/page are Luminate Online that is iframed on that CMS,, they are responsive iframe -- btw there is a responsive iframe library out there https://github.com/davidjbradshaw/iframe-resizer which I have been using for couple of our projects.


Last not least, the whole communication between the two ends are powered by the use of HTML5 postMessage (i.e. when LO authenticated the logged in, it sends message to the other end telling this user is logged in and interval check to see if one is still within active session login at LO or has timed out thus the other end could react accordingly; also using postMessage to pass new info about 'new user' that hasn't have account on that other site/cms yet logging in because she/he already has an account in our Luminate Online system.


regards,

Daniel

Tanna Lewis

Thanks so much Daniel! So glad to hear from you, my friend!! And that is super super super helpful. Pinging you by email with more...

Elizabeth Makayed 2

Tanna,

Integrating Luminate with Wordpress is definitely possible. One way it can be done is by creating a custom plugin that would use the Luminate API to check for user's logged in status.

I have also ran into cases when the API integration on the product-level wasn't possible. In those cases, we used a purely JS-based solution. We would check for user logged in status by making the API calls and then storing user's information in a cookie. Then within the site the conditional content would be rendered based on the cookie settings.


Server-side integration with the product is always the preferred method as it will allow you to take advantage of the product's native features. However, it is not always the best approach due to the high cost of development or site requirements. Basic JS approach may be an option in such cases.


We used the purely JS approach was used to integrate an AEM website with Lumiante https://www.savethechildren.org/. Also, we used the same approach to integrate Drupal 8 site with the luminate for BCIU: https://www.bciu.org/


Hope this helps you move forward in your project.


Elizabeth

Tanna Lewis

Thank you, Elizabeth, that is indeed also helpful since, as it is now, our staff who oversee the CMS side of things don't plan to do anything too fancy at first, so that may provide a simpler start. But I don't want us to go too far down a path without planning for (and fully understanding) the bigger things. And def don't want to lose any of the aspects of LO that make for creating a more powerful, dynamic user experience. Thanks much for some more good ideas - greatly appreciated!!