I tested the Setup Wizard on a fresh Trongate install with the following scenarios:

✅ Fresh install: Let the wizard create the DB -> Admin login successful.
✅ Existing install (Existing DB): Admin login successful.
✅ Existing install (Existing admin account): Admin record was overwritten -> Login successful.
✅ Force-run: Triggered the Setup Wizard twice -> Everything works as expected.

I couldn't reproduce any issues during these tests. I suspect DC might be correct; the culprit is likely a specific column or table that isn't aligned with the new login module.

Thanks for testing, Balazs. DC is correct when there is an existing db with a `trongate_administrators` table without the new columns, like so:
At the setup wizard `create admin account` - the form loops with a red cross.
If I then manually remove the `trongate_administrators` table from the db and try again, the setup wizard continues without error.

Thank you for clearing that up, Simon. 👍🏻

Just edited `setup.sql` to drop the `trongate_administrators`, like so, and it works now without error.
Wondering now if there might be a more graceful approach - maybe warn the user of an existing table/ column mismatch because there is potential for more of the same 'red cross' looping, and the user wouldn't know why.

Thanks for catching those mistakes - I really appreciate the detailed fixes.

If I may, I'd like to point out something about the setup wizard that deserves an explanation: why does it ask you to confirm the base URL before taking you to… the setup wizard?

It does seem strange. For a few days, I was wondering the same thing.

But then I remembered the original idea.

If we know the base URL and have the right permissions, it should be possible to automate a large portion of the setup - similar to how the old desktop app worked. What’s there now is unfinished, but the plan was always to offer a fork in the road: one path automated, the other manual (the current flow).

To be clear, I realize you could theoretically infer everything - including database credentials - from just the base URL. But that feels like too big an assumption (to assume database credentials from a BASE_URL). If there’s going to be an automated path, I’d want it to mirror the proven approach of the desktop app: tested, deliberate, and not guesswork.

The biggest challenge for me right now isn’t technical - it’s the messaging and user experience around that choice.

Your fixes are very welcome. If you have any suggestions for how to nail the automated path as well then that would be great. As usual, the biggest problem is not the code - it's giving the user a good experience.

Timeline-wise, I’m hoping to wrap everything - both fixes and the automation flow - within about a week.

Thanks again!

EDIT: I'm going to think about this over the weekend. We'll be golden. Don't worry.

Thanks for the clarification, DC. That all makes perfect sense, especially the reasoning behind the BASE_URL step and the idea of offering both an automated and manual path. I agree that the hardest part is probably not the code itself, but presenting the process in a way that feels intuitive and safe for users of all experience levels.

The new setup wizard is already a huge step forward, particularly now that the old desktop app is offline. It lowers the barrier to entry significantly and gives new users a much smoother first experience with Trongate.

I also think the "fork in the road" approach is the right direction. Advanced users will appreciate the flexibility, while beginners can follow the guided flow with confidence. The challenge, as you said, is making the automation feel deliberate rather than "magic".

A few thoughts on the automation side:

BASE_URL = PROTOCOL/HOST/ URI/

I think this part is actually the easy win. We already have the BASE_URL from the current request URL and can reasonably assume APPPATH from there. That should remove a lot of the manual setup friction straight away. Even an exotic web stack setup that uses custom host names/ virtual host domains, like tg.local or test.myapp.


Database setup

The DB connection testing logic is already there, so perhaps the wizard could:
• Suggest a database name matching the project/folder name by default.
• Check whether that DB already exists.
• If it does exist, warn the user and list any tables that will be overwritten.
• Also provide a dropdown/list of all available databases so the user can choose an existing one instead.

From there, the wizard could check for required Trongate tables and either:
• Overwrite incompatible tables where necessary, or
• Preserve what it can with some migration logic.

Even just clearly showing the user what will change before proceeding would go a long way toward avoiding confusion like the looping red cross issue I hit earlier.

Unfortunately, I don't have the time right now to jump into the UI/UX side of things properly, but I'm happy to keep testing edge cases and feeding back anything I find along the way. We're definitely heading in the right direction with this.

Cheers,
Si