Restrict Product and Staging Environments to Publish Only

Feature Request
#1

Referencing this topic:

I believe that a Staging or Production target should NOT allow for the direct upload of any file upon saving a change. The risk of inadvertently making changes to these environments is too great. Files should only be pushed to the target if the Deploy or Publish buttons are pressed – and even then the user should be presented with a dialog reminding the user which target they are deploying to.

The main point being, that the workflow to publish to staging and production should be different than that of Development so the user is keenly aware of what they are doing.

Why?: "we have standardized our publishing"
Wappler 3.7.3 Released
#2
#3

As great as this sounds, a more broader and important feature to implement here would be to be able to manage various environments from Wappler itself and this could be a part of that setup.

Unfortunately, I don’t have a clear understanding of variables involved in switching between environments, so not creating a feature request separately.

But, if the team is considering upload options based on environment, it would be a better idea to look into the environment management feature as a whole.

#4

This is one reason why I have chosen not to use the Database Manager and FTP or Docker production targets.

While my publishing routes involve several manual steps, they are external to Wappler and I know they will always be safe from the problems Ken describes.

For me, having some operations always performed outside of Wappler is a benefit, not a disadvantage.

#5

I agree with this. I think it’s always been a weakness of Wappler that it’s too easy to make changes to a live site unintentionally. Like @Antony, I use an external database manager. I use an external FTP program, but also use the upload facility within Wappler for uploading individual files as it’s so convenient.

I haven’t had any problems for quite a while, but just this week, a customer’s site suddenly became unusable. I haven’t worked on this site for months, but I opened the project to look at some of the code. I don’t remember making any changes, but perhaps I tidied something up and pressed Ctrl+S without thinking, and, more importantly, without realising I had the production target selected. I didn’t know anything was wrong until the client contacted me. They couldn’t log on and most of the content on the site had disappeared. Replacing dmxConnectLib solved the problem. Presumably the change I made had triggered the uploading of some newer files.

I don’t think I ever made this mistake using Dreamweaver. Simply saving a file couldn’t cause any problems. You had to choose to upload (at least as far as I remember). Perhaps some more obvious visual sign in the UI to indicate what targer is current would help with this.

#6

I agree with all the comments here. I am completely used to the automatic uploading (via FTP) whenever a file is changed and like the speed of it. I now don’t generally have a local version of a site, I do it all on a real server so I can show the client and also know it’s working fine on what will ultimately be it’s final destination.

So, if this feature does make it into Wappler, I would like the option to keep the current way of working, stored in the project settings so it’s on a per-project basis, that way we can all work in the best way for us.

#7

Actually this was the whole point of the new target “usage” option. When marked as production or staging the auto upload will be disabled and only publish/deploy or manually ftp upload will be allowed.

We just didn’t implemented the functionality till now, because people were used too much of the auto uploading on live sites, like Tom :slight_smile: for quick changes of live sites.

So now that you fully understand its power and danger of the auto upload on production sites, we will implement the restriction.

4 Likes
#8

Now you mention it, I remember when the production or staging was added and thinking “what’s the difference?”

#9

For my app I have 4 possible targets behaving like this:

Local, Development - site updates when you save like it does now. Local is on your hard drive, development on a server.

Staging, Production - site is updated through the tighter process George and Ken describe.

I have a team of testers who will thoroughly test each weekly release of my app via the staging target and I don’t want to interrupt their work accidentally!

Oh, and publishing should definitely include a “Are you sure?” dialog box!

1 Like
#10
#11

This has been integrated in Wappler 3.7.3

No files will be auto uploaded on Staging and Production targets, but only on Development ones.
You can either manually upload using the file manager, or use the Publish option.

#12

Other than that update now, is there really any other difference between the three settings?

#13