Please uncheck all options in Publish as default

Please can all the options in the Publish dialogue be unchecked. Muscle memory plays a part as I hit publish too quick and then get a whole load of errors about the database. Would be great if ALL options are left for the User to decide...

Screenshot from 2024-12-17 21-12-46

2 Likes

Same boat here, sometimes I forget to uncheck database update and then stress out until I get an error. I would like that one turned off by default. But I'd like to have Commit to GIT checked by default if GIT is used.

Wanna change this to a feature request so we can vote?

Needs to check if this is the case otherwise another thing that will drive me crazy having to uncheck it. YES we use Git but it runs via our custom production pipeline scripts... We do not use Wappler for Git versioning.

It would be great if we could set the defaults in the Project options.

4 Likes

PERFECT call Keith!!!

I'm certainly not opposed to a settings checkmark. Only has to be checked once. As it is, it only checks commit to git if Wappler Git is used and there is files to commit.

Or it should remember the Users previous selection and inherit that as the default.

1 Like

I don’t know why you would ever not want to clear old docker images so leaving that checked as default makes sense.

As for databases, I have projects that connect with external DBs so have no Wappler-managed DBs yet it is checked. It should either remember the last or have a default option in settings but either of those should be per project

GIT should be forced, but only for @Antony :stuck_out_tongue_winking_eye:. Only kiddin - it should have a project setting or remember the last project action

2 Likes

Git in the U.K has a slightly different meaning...

:disguised_face:

4 Likes

:+1:

If this vote doesn't go my way come January 6th...

:clown_face:

2 Likes

That’s cool…

I don’t use Publish either! :rofl:

1 Like

Ooooo publish is a cool feature and non invasive, just publishes changed files. But I TOTALLY UNDERSTAND, once us stubborn folk, me included, have a routine that works we are in no rush to change it! And if it ain't broke and all that... Is all GOOD, what works for you is what matters.

2 Likes

But in a normal situation you will always want to deploy also your database structure changes to the remote, because your code depends on them!

So why wouldn’t you want that?

Maybe you should check why are you getting errors during the database changes publishing in first place? Do you have some bad migration (changes) files in there?

How do you publish your database changes then? Manually?

I imagine there are quite a few Wappler users who use dedicated database management software, so don't need this option. Hopefully, if you don't use Wappler's Database Manager, nothing could happen to your database by using the Publish feature, but I worry in case it could (eg if I forgot to deselect the database option). Like @Antony, I don't use Publish.

Yes, that’s me… I use MySQL Workbench.

I can create views there… I have more views than tables.

And I can solve database riddles there with complex queries.

Remember I started my app using Wappler 5 years ago… and Database Manager hadn’t been invented then!

The question is: how do you apply the database table structure changes from the development database to the production database? You aren't working on the production database directly, are you?

And the huge irony is you organised a gathering so George could show it off and said you loved it!

3 Likes

Each new releases change is in a separate SQL file that I create and apply locally, and then apply to production as I do my own style production release.

I guess with this and GIT, I prefer to be moving around and applying files I can see and touch and understand, rather than relying on some software to do that for me!

1 Like