Many sites employ a "front controller" pattern for one or more areas of their sites. You can recognize this by the way that the pages flow one to the other. For example, you might have a page that begins your registration flow that looks like this:
PAGE 1: https://register4myevent.com/event/myevent
That takes your registrant next to the page:
PAGE 2: https://register4myevent.com/event/myevent?param=true¶m2=Jim&type=exhibitor
Notice anything familiar between the first and second web addresses? (hint, the text is blue).
Up until you installed one of the InGo widgets, you really didn't notice or pay too much attention to this, but now, you've added the InGo Activator (aka Login) widget to the page, and you're confused. The Activator widget works fine on Page1, as you would have expected, but then appears again on Page2. If the widget has been configured to automatically popup when the page loads, even worse -- now it's annoyingly popping up for both Page1 and Page2. Worse yet, if your entire registration site/area uses the same base page as a front controller, then you're likely seeing this widget popup all over the place. Clearly not what you intended.
There are really two solutions to the problem.
Solve By Design (ideal):
The front controller pattern can be a very useful pattern and is employed by many, many sites. But what's really going on here is that you've injected the widget code in the wrong place at the wrong time. You need to judiciously inject the code into the page and/or use conditional logic to allow the page to "execute" the widget's code. Simply dropping it into the base page HTML template will by default make it appear any time the page is loaded. If the page HTML is being generated, consider moving the widget code INTO the generation process such that the Activator widget's code is generated only when the content specific to that page is generated. Do the same for the other widgets.
This is really the best approach to solving this problem but sometimes we find that our implementers don't have as much control over how the code is generated as we'd all like, and in some cases that's due to the underlying framework or business partners or organizational divisions.
Solve By Param (if needed):
An alternative solution is simply to circumvent the loading of the Activator widget with script. Place the following code into your page instead of the default code provided to you when your event was created.
<script src="https://cdn.ingo.me/widgets-loader/<<version>>/js/ingo.loader.widget.js"></script>
<script type="text/javascript">
$(document).ready(function() {
if (window.location.search.indexOf('reloadlogin=false') < 0) {
InGo.loaderWidget({
widgetId: "<<WIDGET ID>>"
});
}
});
</script>
Now set the next URL for the registration form to include the parameter "reloadlogin=false", for example:
https://register4myevent.com/event/myevent?param=true¶m2=Jim&type=exhibitor&reloadlogin=false
If you don't know how to do this ask an InGo support representative.
Once this additional parameter is in place test and verify that the activator widget no longer loads when the user is taken to the next step in the registration flow. Yay!
This again is not the ideal solution, so if you have multiple pages where the Activator widget is displaying or other widgets are "firing" then you'll need to take a deeper look at the design of the pages and how the InGo code is being injected.
Now your one page really can rule them all. Enjoy!