Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Social media login plugin for Keystone

See original GitHub issue

I’ve developed a social media login plugin that I currently use on my Keystone projects. My intention has been to publish it as an npm module called keystone-social-login (unless anyone has any better suggestions).

Currently it works by passing your instance of Keystone to the plugin, which then literally plugs itself into Keystone. Among other things, it redirects the Keystone signin url to a page that includes links to all the configured social media logins, as well as to Keystone’s login page.

While this “plug-in itself” mechanism has been working well for me so far, I would much rather see a more standard method for instantiating plugins. I was wondering, now that we’re creating a more plugable ecosystem for Keystone when it comes to fields and storage providers, if we intend to move ahead with a standard plugin architecture, similar to what was described in #185.

Creating a standard plugin architecture/API of this nature, IMHO, would allow Keystone to support a host of features that should not necessarily be part of its core functionality. A user-supported ecosystem of plugins would be of incredible benefit to Keystone’s growth. It would definitely bring us to par with other more “plugin-friendly” CMSes, such as WordPress. I’m personally not a WordPress fan and would choose Keystone over it every day of the week and twice on Sunday, but we can’t deny that it has an impressive plugin ecosystem.

I echo @dboskovic’s ideas in #185 and like the simplicity and elegance of @danielmahon’s suggested implementation, though I would personally advocate a slightly more robust API.

I guess my question to everyone is: Should I/we put off plugins of this nature until Keystone officially supports a standard plugin architecture (I would be more than happy pitch in and collaborate on this) or should we simply publish our plugins “as is” for the time being? Personally, I think a standard plugin architecture is right in line with the direction of 0.3.x.

Comments, suggestions and constructive criticism is always welcome!