Old-style (defineTour) tours were written against an API without the automatic next buttons. Automatic next buttons should not be generated for old-style tours.
This was reported by Jake Orlowitz and affects The Wikipedia Adventure (an on-wiki tour using the old API).
Version: master
Severity: normal
Thanks for logging this Matthew. I assume the quickest fix here is to suppress automatic next buttons for defineTour versions. Is a there a longer term shift we should be making to switch over to the 'new model' (and will the new model accept our fancy named buttons and changing landing pages and automatic message through the Edit:API?)
(In reply to Matthew Flaschen from comment #0)
Old-style (defineTour) tours were written against an API without the
automatic next buttons. Automatic next buttons should not be generated for
old-style tours.This was reported by Jake Orlowitz and affects The Wikipedia Adventure (an
on-wiki tour using the old API).
(In reply to Ocaasi from comment #1)
Thanks for logging this Matthew. I assume the quickest fix here is to
suppress automatic next buttons for defineTour versions.
Yes, that's what I'm going to do (in the library, so you don't need to fix it in the tours).
Is a there a longer term shift we should be making to switch over to the 'new
model' (and will the new model accept our fancy named buttons and changing
landing pages and automatic message through the Edit:API?)
Yes. defineTour is already deprecated, and I encourage you to move over to the new API. We would like to remove the old API at some point, but have no immediate plans to do so.
You should find the new strictly more powerful (I don't believe any features have been removed, and if you see that, it is probably a bug). You should not have a problem with custom named buttons or your custom edit actions.
It provides some important new features. For instance, when they click "next" (i.e. >) , you can dynamically choose which step to go to based on arbitrary logic (e.g. whether they have a string in the textbox, as one example). You can also transition to arbitrary steps (not only the next one with shouldSkip, and the logic for those transitions is more flexible. There are also transition actions, so you can e.g. end a tour when they complete an edit.
Also, I think you'll find it more readable. E.g. instead of having "//20", and everything forced into a long array, each step is defined in its own statement. You're free to use variables to hold steps, and steps also have meaningful names (e.g. "returnToEarth", or whatever is useful to use). This should make refactoring easier.
I forgot to add, there is now built-in support for back as well, if you use the new API.
You just call e.g. returnToEarth.back( "whateverStep" ) or returnToEarth.back( whateverStep ). It will also look more consistent (both with other tours and between next and back within your own tour).
gerritadmin wrote:
Change 164025 had a related patch set uploaded by Mattflaschen:
Turn allowAutomaticNext off for tours using the legacy API
gerritadmin wrote:
Change 164025 merged by jenkins-bot:
Turn allowAutomaticNext off for tours using the legacy API
gerritadmin wrote:
Change 164152 had a related patch set uploaded by Mattflaschen:
Turn allowAutomaticNext off for tours using the legacy API
gerritadmin wrote:
Change 164155 had a related patch set uploaded by Mattflaschen:
Turn allowAutomaticNext off for tours using the legacy API
gerritadmin wrote:
Change 164152 merged by jenkins-bot:
Turn allowAutomaticNext off for tours using the legacy API
gerritadmin wrote:
Change 164155 merged by jenkins-bot:
Turn allowAutomaticNext off for tours using the legacy API