Ganon's suggestion makes sense to me, but is not trivial at all.
To be clear, the problem is not with storing two files per trial : we already store up to 11 files per trial with the backup system.
The problem is how to design it. More specifically :
- How to ensure backwards compatibility ?
We can't just say "each trial stores one file for the release and one file for the editor" : there are thousands of trials out there, and I don't intend on duplicating all of them. The system needs a clear policy to know how to handle trials which only have a single file like now.
- How to adapt the UI for the user to understand what's going on ?
How do we make it clear to the user that the version he is editing is not the one that is visible to the player ? How do we make it so that the owner and collabs can actually playtest both versions : adding yet another button in the trial card in the manager ?
This change would also impact all layers of the AAO server-side code, from the UI layout to the way trial files are loaded, including permission checks as well since the permissions would not be the same on both files.
So no, not trivial.
On the other hand, I like the idea : maintaining both a "development" and a "release" version of a product is pretty much standard in software programming, and I guess this practice makes sense as well for AAO trials. It has added value because it enables an author to test changes before releasing them to the public.
And with that we're back to clear file permissions as well : either you have permission to load the dev file, or you don't.
So for that proposal, why not - it will just be a fair bit of work and anyone up for implementing it should discuss it with me first to plan the thing.
On the contrary, I still don't like the idea of a toggle between "people can access it in the editor or not", because I still don't see any added value.
If the trial is released, anyone can access the data, be it simply from using the browser's debugger while in the player, or just loading trial.js.php in the browser. Even if I add a check in the editor to refuse opening up on this trial, if a user wants to cheat, he can. Heck, any user can even entirely copy your trial data from the player, save it in one of their own trial and browse it in the editor as one of their own trials, and I couldn't do a single thing about it.
So what you are asking me here is to introduce a new setting for a feature which is only reliable towards people who are knowlegeable enough to open an editor URL that they never saw a link to (again, the link to the editor is never shown if you don't have permission to edit - in order to open someone else's trial in the editor, you need to know that it's possible, and more importantly you need to want it, it can't be a mistake), but too lazy to copy paste the trial data file.
On that proposal, my position still stands : no
, I won't add a setting for that. I could change the behaviour of the editor to make it just a little harder to cheat, but that's for everyone. I won't add a database setting in order to enable or disable an unreliable feature.