Welcome to the Question2Answer Q&A. There's also a demo if you just want to try it out.
+1 vote
in Plugins by
edited by

I am using a plugin to redirect after the event of receiving the "verified"  badge (this badge is received when the user confirms his email - after registration). I was able to build the redirect after the email-confirmation itself, but it creates a conflict with the badge plugin. So I am trying to redirect after receiving the badge "verified".

Since the part of it was tested before, the error must be in
one of the bold parts below:

        function process_event($event, $userid, $handle, $cookieid, $params) {
                                require_once QA_INCLUDE_DIR.'qa-app-users.php';
                                $logeduserid = qa_get_logged_in_userid();
                                                $url=qa_path($request, $urlparams, $rooturl, $neaturls, $anchor);
                                                header('Location: '.$url);

By the way, when this event happens, this is the line of the qa_eventlog table


2015-03-08 07:14:30|| 18| estudante| NULL| badge_awarded| badge_slug=verified

Finally, myPage is a previously defined page and there is no error in my error_log file.

Q2A version: 1.7.0

1 Answer

+1 vote
selected by
Best answer

The trick is no event is fired :) This line is responsible for inserting the row in the ^eventlog table. Considerably tricky, if you asked me.

Some other alternatives to do what you want:

  1. Hack the core here. Something like this should do the trick if ($userconfirmed) { qa_redirect('faq'); }
  2. Duplicate the confirm page. Apply option #1 in the newly created confirm page. Redirect all traffic to the confirm page to the newly created confirm page.
  3. Use a function override in qa_complete_confirm. What I don't like about this approach is that it seems better than what it is. It has the same effect as the others but as it is a plugin somehow seems better but it is not. Only valid if you want to distribute your modification, of course.

Any option will tie you to a given Q2A version and, when upgrading, you'll need to see the impact of this change in the new Q2A code. IMO, I think the first one is the best. When upgrading to 1.7.1 (or whatever version you want) you can make a diff of the original 1.7.0 and then see the lines you've changed (core hacks). Then analyze the impact on 1.7.1 but this is something you will have to do regardless of the approach.