Log in to participant center

I don't direct them to the PC after logging in, after donors might log in also. Additionally, it is possible to have participants that do not have PCs (they are non-fundraising participants)

Instead I replace the Login Link with the Participant Center link.

<div>
[[?xx::x[[S1:user_name]]x::
    <span id="welcome">Welcome, Guest</span>
    <span id="register"><a href="TRR/MyEvent/MyEvent?pg=tfind&#38;fr_id=1234&#38;fr_tm_opt=none"><strong>Register to Participate</strong></a></span>
    <span id="login"><a href="UserLogin?NEXTURL=TR?fr_id=1234&#38;pg=entry"><strong>Login</strong></a></span>
::
    <span id="welcome">Welcome, [[S1:first_name]]</span>
    <span id="logout"><a href="UserLogin?logout=logout&NEXTURL=TR?fr_id=1234&#38;pg=entry">Logout</a></span>
    [[?xx::x[[S48:1234:if-has-participant-center]]x::
        <span id="register"><a href="TRR/MyEvent/MyEvent?pg=tfind&#38;fr_id=1234&#38;fr_tm_opt=none"><strong>Register to Participate</strong></a></span>
    ::
        <span id="participantcenter"><a href="TRC/MyEvent?pg=center&#38;fr_id=1234">Participant Center</a></span>
    ]]
]]
</div>

Note: in the above the TeamRaiser id is 1234 and the name is MyEvent.

Ronica Smucker:

I'm confused. I thought that was what I was asking.

 

If you are already registered for our ride and you go to our website: canarychallenge.com and click on the log in button. It takes you to the greeting page with no link to the PC. So as a participant you are stuck at the page not able to access the PC.  So I thought it would be better to click the log in button and go directly to the PC.

 

You're saying it's not because a donor might log in but donors don't register for the ride.  

Right, but with the code I provided when they login and return to the entry page, there will be a link to the PC right where the login link was (assuming they have access to a PartCenter.)

Again, it is possible to configure a participant type to NOT have a PC and not do fundraising. And donors to not participate, but frequent donors might login so they don't have to retype all their personal info.

In either case, forwarding them directly to the PC would result in an error.

So what I do is...

Do you have a username? (I.E. Are you logged in?)

NO: Show a generic greeting and a log-in link.

YES: Show a personalized greeting and then check...

           Do you have a PartCenter?

           NO: Show a register-to-participate link.

           YES: Show a link to the PC.

// The attached shows this in both states.

Andrew Beyer:

So are those URLs actually valid? (I'm asking somewhat rhetorically, as I'm pretty sure they aren't valid... you need to percent encode the '?' '&' and '=' characters of the nested url to disambiguate them as reserved separator characters.)

 

I guess more practically, do they work? Have you done cross-browser testing to verify that these work as you're using them?

 

I've been doing percent encoding as nominally required on urls passed as parameters like that...but have found that it seems to break the fr_id rewriting that blueprints do when they are cloned into new events. I'm wondering if switching to your form, which while technically invalid, may well be corrected by the browser, while still working correctly with blueprints.

We've tested with the major browsers, but not Opera and the other smaller guys.

I encode the ampersands mostly out of habit. Convio does not encode anything in their links (gee, thanks guys) so it seems sorta pointless. I've never really heard you must encode* hooks and equal signs. The W3C validator permits them to be unencoded, even on XHTML 1.0 strict.

I also use this in the pagewwrapper so the Blueprint rewriting does not come in to play.

You could use unencoded URLS in your blueprint so the rewriting should work, and wrap them with the T1 tag to encode them.

[[T1:http://mydomain.org/site/whatever?foo=bar&fr_id=1234]]

* EDIT: My next post reminded me of an instance where I do encode everything in a URL... when it is a value in a qs parameter!