I don’t deserve the credit for this, praise goes to everyone who’s contributed to it on this forum, not least @stevesoftwareservice who developed the excellent logout promise (sorry couldn’t thank you on the now-closed post Steven).
However, since the combined attached has plagued me since joining Wix, I thought I’d try to help other newbies. Specifically, what’s the code block to accomplish a basic login, log out and dedicated sign up path that actually works, and be able to have different buttons for sign up vs log in - ie remove your dependence on the Wix login app . For such a basic and ubiquitous corvid code block, it’s surprising the answer isn’t in one place, and I hope it’s worth assembling together for those who struggled as much as I did.
[Note to Corvid pros - there’s still one bit I can’t do - route to the default log in vs. sign up, depending on user intent - that seems to be hardcoded in member sign up for the default form and has no location routing options, but if there’s a way you know, maybe you can add it, and I’ll update this with the solution, and credit you].
My code almost certainly isn’t neat, I’m an amateur, but at least it works without bugs. I’ll take any suggestions for improvement.
Just want the code? Skip to the bottom section. If this is your first time here you might want some of the context and basics first.
This is the stuff I wish someone had told me
Managing Sign Up, Sign In and Sign Out
So new Wix user, you’d like to improve on the slightly disappointing log in functionality that you’re presented with when signing up for one of the various apps which provide it? You fancy
- a custom form with your brand and colours on it
- for both Sign-Up and Sign In
- including social Sign Ups
- with a different routing for log in vs. sign up so you can build a Sign Up process
- and a Sign Out that directs the customer to an exit page of your choice
The bad news
No one really tells you this. Unless you’re a pretty experienced full stack js dev, and very happy digging around the Google and Facebook authentication APIs, you can’t do all of this. And while you may be tempted to try, many of us have lost weeks, or longer to just that attempt.
The good news
You can do most of it if you’re prepared to make some compromises, and it’s relatively easy.
What Compromises do I Need To Make?
There are a bunch of ways to fork this but to keep things simple, I’m going to suggest the following two routes.
Either
a) Pro: A social login that works
Con: But with limited site branding on the sign up/log in page itself
Or
b) Pro: Complete control over branding and experience of the sign up/sign on process
Con: With no social login
There are plenty of guides to path b - custom sign up and log in - on this and other forums, so this guide won’t cover those, but none of those paths, unfortunately, give you social login. The one that does provide information, I personally have not been able to make work - not so much on the Wix side, but on the complexity of dev that’s needed to get OAuth and FB equivalents to function. If this post spurs good answers there then it’ll be a good thing.
It’s the path (a) that I’m focusing on here as it doesn’t appear to be consolidated in one place and for anyone planning social login as a requirement for any sort of 3rd party integration, making that path useful and functional is crucial. I’ll give some context that you need as complete newbie, then a code explanation.
Some Quick Context - Default Pages & Colours
Default Pages - Unlike many other website builders, the big attraction for Wix is it’s one big sandbox, you can pretty much customise what you want, how you want. That has some complexities that I won’t get into, but it does mean your world is pretty unrestricted. So when you encounter a restriction, you’re not expecting it - that can waste time while you figure out it really is a roadblock. These roadblocks can have different limitations - sometimes the colours, the design. In some cases, such as Wix Groups, there’s no access to any corvid API based functions, effectively it’s an unchangeable black box excepting colours. The important thing is to know in any roadblock is what the restrictions are and then not waste time attempting to adapt them. 99.0% of the time, in my experience, you’re better off working with them or avoiding any dependence.
Log In Pages are by probably the most common roadblocks that we encounter as a community mostly because they cut across all the industry verticals. You can’t code them, you can’t redesign them, you can’t change them, add to them or mess with them in any way. You can’t even change the words “Log In” to something post-Unix, much to the horror of my UI friends.
All you can do is avoid them using the route (b) above, including the compromises above (there are some minor settings tweaks depending on the app you’re running, I’m not covering those - the most important shared one Is choosing what shows first - sign up or log in, more on that in appendix). But this excludes you from social login and for me, at least, that was an unacceptable compromise. Arguably in 2020, any site without social login looks a little amateur, even if it’s not an integration dependency. Let’s get into the login default then:
Those two default pages - Log In and Sign Up
Here’s the good news: Depending on the template you chose for your initial site colours, you may already have noticed from my screenshots that you CAN recolour them. You may not know how: site colours. You may have played with these areas when you set up your initial site colours, and you probably used the left-most column to define the main colours you work with?
Well, that column also determines the colours of your default pages, so if you’re committed to this approach you may have some colour remapping to deal with, it shouldn’t take long. In my case, my rightmost columns are now used for main site colours, and I’ve adapted the left column specifically to manage colours on default pages. File any attempt to remap colours in the 99% of the time point above - you get what you’re given, including any colour conflicts with other default pages that you wish to colour differently - that’s the compromise.
Once you’ve got the colours right for the default pages, so they look at least in keeping with your site, it’s time for a Corvid Intro and then some code.
Coding your site for sign-in/out code with a sign-up path.
Scenario
This assumes
-
You want a separate sign-in vs. sign up button
-
You want to drive the sign-up path to a different place than the sign-in path
-
You want your sign-in button to read sign out when a customer has logged in
Enable the Corvid development tools - if you haven’t done this before, look at the top nav in your Editor between Tools and Help , you’ll find the Dev Mode section, hit the blue Turn on Dev Mode button. Nothing scary is going to happen and there’s very little you can do to mess things up unless you let your toddler play around.
If you’ve never done this before two new things will pop up:
You’ll get a window at the bottom that you can plug code into, by default it’ll open for the page (not the whole site), and look something like this.
You’ll also get a new panel pop up called “Properties” which we’re going to need, so if this doesn’t show, or if you close it and need to reopen it, you can find it as a new addition to your tools menu highlighted below.
You may also get a sidebar that pops up, you won’t need this and can close it with the highlighted arrow button.
Now, go to your homepage, if you’re not already there, and create three buttons. You can change style or text at any time so no need to get design perfect right now:
Sign Up
Sign In
Sign Out
Drag the Sign Up button onto your header, the put the Sign In button next to it. Then drag the Sign Out button on top of the Sign In button. By default, it should end up in a layer above the Sign In button but if for some reason it does not, you can use the Arrange button on your normal tool to ensure it does. Your header may not look particularly pretty, and you may not want those buttons exactly as you have them - no problem, you can change all that later, this is just to show you how it works.
If you’ve closed the properties tab, reopen it, and then click on the SignUp button. You’ll see it has an ID, it’ll be called something like button22, this has nothing to do with any text you put in the bottoms.
You can click on that ID field to edit it, change the name to aSignUp making sure that you follow the same upper and lower case. When you click anywhere else or hit [ENTER] the new ID will be saved.
Now do the same with your Sign In and Sign Out buttons.
Button ID
Sign In aLogin
Sign Out aLogOut
Now we’re going to set up how those buttons react to our code. If you’ve closed the properties panel, reopen it, we’ll be using that for settings.
First, make sure all the buttons have the ‘Enabled by Default’ checkbox selected - you should have a blue tick there. If not, tick it.
The for just the Sign Out button, click the field that says ‘Collapsed on load’, you’ll notice the button gets some chevrons and seems more faded out. That’s because the instruction tells it to only appear when we tell it to.
In the next section down called ‘EVENTS’ you’ll see an event that says ‘onClick’. You can leave the Sign-Up and Sign Out buttons alone, but for the Sign In button, you’ll want to edit that field.
Click the + icon that appears when you hover over the onClick section. By default the button will autocomplete its new ID and the event, so all you need to do is hit [ENTER]. The Sign In button will now have a click event called aLogIn_click.
Now we just want to check links. By default buttons don’t have any links, but in case you copied a button, hit ‘Change Text’ on the Sign In and Sign Out buttons - check that the ‘Where does it link to’ field says ‘Add a Link…’ and if it doesn’t remove the links.
For the Sign-Up button do the same, but this time add a link to whichever page you’ll be using for your sign up path. If you don’t have that yet, just link it to any secure page other than the homepage so you can see it working. A secure page could be a page in your default secure section, or you could add a new page and play with the permissions tab to make a login required (eg. members only)
[strictly speaking, we can manage all of the above with code, I’ve done it this way to make it most easily editable for newbies. Similarly, I haven’t chosen to change the text of a single log in/out button, which in any event makes Steven’s code harder to use.]
Now we’re going to add some code. Look at that bottom section which should say HOME Page Code, or something like that depending on what you called your home page. You’ll notice that our actions have created a new piece of code.
export function aLogIn_click(event) {
//Add your code for this event here:
}
We actually don’t want that code here, so select it all and delete it. You can leave the original $w. onReady code as it was. Now click on the site tab, the one below the page tab. We’ve changed tabs to made sure our code applies to the whole site, not just the home page. You should see the same standard code that will say something like this.
// For full API documentation, including code examples, visit https://wix.to/94BuAAs
$w.onReady(function () {
//TODO: write your page related code here...
});
Feel free to select it all and delete it. Don’t worry the existing code isn’t actually doing anything for your site, it’s an empty bottle. Then select all of the code below and paste it into the site code.
import wixUsers from 'wix-users';
import wixLocation from 'wix-location';
$w.onReady(function () {
if (wixUsers.currentUser.loggedIn) {
$w("#aLogIn").collapse();
$w("#aSignUp").hide();
$w('#aLogOut').expand();
} else {
$w("#aLogIn").expand;
$w("#aLogOut").collapse();
$w("#aSignUp").show();
}
$w("#aLogOut").onClick(logoutAndRedirect);
function logoutAndRedirect(event) {
Promise.all([wixLocation.to("/"), wixUsers.logout()]);
}
})
export function aLogIn_click(event) {
wixUsers.promptLogin().then(() => {
wixLocation.to("/yourloginarea")
}).catch((err) => {
let errorMsg = err; // "No member is logged out"
});
}
export function aSignUp_click(event) {
wixLocation.to("/yoursignupjourney");
}
The final thing to do is to replace the green areas with those applicable to your site. Note that when Wix does redirects within your site it knows you’re abcsite.com, so all redirects are structured assuming that is your homepage. So imagine your want customers after login to end up at abcsite.com/myloginpage, then you write that simply as /myloginpage
-
Where do you want customers after they have logged out of your site?
/ assumes they return to the homepage, if you want a different page replace that. -
Where do you want already registered customers after they have logged into your site?
“/yourloginarea” replace yourloginarea for the page of your choice -
Where do you want new customers to go after sign up?
“/yoursignupjourney” replace yoursignupjourney for the page of your choice
Make sure you leave the “” in, they’re important to make the code work.
Once you’ve done all that, you can either publish your site or do a 0% exposure release to test out the code. Unfortunately, you can’t test it as a preview since you’re always logged in.
All the best, Hilary.
To help me know if I should do more of these
- If you followed this, did it work for you?
- Was anything unclear?
- Was there a task you needed that wasn’t covered?