Custom Bootstrap css replaced by Wappler update

[TomD]

======== TEMPLATE BUG FORM ========

Wappler Version : 2.5.1
Operating System : Windows 10

Expected behavior

Updating Wappler should not automatically overwrite a website’s css - even if the update includes an update to Bootstrap. It can cause catastophic results, without any intentional action or confirmation from the developer.

Actual behavior

If you’re using a custom Bootstrap theme, Wappler doesn’t take this into account when doing an update which includes a new version of Bootstrap. Making any change to a file within the site will cause the existing Bootstrap css file to be replaced - potentially ruining the design of a site (possibly without you realising it until the site owner contacts you).

How to reproduce

Having updated Wappler, make a change to any file and save it. Bootstrap will be updated - which of course will not cause any problems in most cases. However, it may cause serious problems if you’re using a customised version of Bootstrap, and it may also cause problems in the future, even if you’re not using a customised version (with future versions of Bootstrap).

If you’ve created your own theme, using the method described in the Bootstrap documentation (and covered in an excellent tutorial by @ben, then this customisation will be removed. (I’m not referring to changes made to a custom.css file.)

This issue has been raised before - when Bootstrap was updated previously - but the problem remains. I stopped uploading from Wapper for a while, but it seemed that replacing the ovewritten version with the correct version solved the problem, and Wappler would leave the correct file unchanged - so I went back to using Wappler’s FTP feature.

Unfortunately, it now seems that Wappler does more checks and whenever a file is saved bootstrap.min.css is overwritten if it doesn’t match the uncustomised version. The only solution I’ve found, apart from not using Wappler’s FTP feature, is to mark the css file as read-only. I think this is a serious problem.

Would it be possible, at least to have an option, for Wappler to display a message every time it is going to replace files on the server, except for the files you have actually selected to upload? As I mentioned, this is the second time I’ve had css files overwritten in this way. Other problems occasionally occur with updates - having a list of files which are going to be replaced would help avoid such problems or fix them if necessary.

[TomD]

To give an example of what I mean, here is a site I’m working on. The version on the right is how it appears after saving a file, since the last Wappler update. Fortunately this site isn’t live. Another site was live and suffered a similar fate.

[George]

How did you customize your Bootstrap 4 files Tom?

You usually have two options:

1. changing the bootstrap Sass variables and compiling it
2. using a CSS overwrite file, to overwrite the settings you won’t

When Wappler updates Bootstrap 4 files - it does just a timestamp check of the files. So only newer files are replaced. That is indeed unfortunate when we deliver a new version of Bootstrap 4 - you current will get overwritten.

So if you compile it on your own you will just need to recompile it with the new version,

If you were using method 2 and just having overwrites, then you shouldn’t need to change anything.

[TomD]

How did you customize your Bootstrap 4 files Tom?

Option 1: changing the bootstrap Sass variables and compiling it

So if you compile it on your own you will just need to recompile it with the new version,

I think this is good option for a site under development; it’s probably wise to use the latest version in this case. However for existing sites, I don’t think people generally update css files because a new version of the framework they used has been released - and I don’t it’s reasonable to expect or require them to do so. I’m sure the vast majority of sites using Bootstrap are not yet using version 4.4.1 (wappler.io is an example) - and most of these probably never will.

It can be a lot of work updating and testing compatibility etc. if new versions of frameworks are released. Typically it’s not required and not desired (or paid for) by the owner of a site; in these circumstances a developer would be unwise to make such changes.

I have sites which are 5-10 years old which I tweak occasionally but essentially they are as they were originally. Hopefully they’ll be updated at some point, but until that point I certainly wouldn’t want any software overwriting any files on the site automatically. Inevitably things will break, the site owner will be unhappy and I as the developer will be left with extra work to do. I keep an old copy of Dreamweaver just to maintain a few sites like this because Wapper breaks them as it is. This is not much of an issue (some of are very old). What is an issue is Wappler breaking sites created from scratch in Wappler.

I think this will become more of an issue as time goes by - as more updates are made, and Bootstrap 5 and 6 (or something quite different) are released. It’s of course impossible for you to predict what will happen in these circumstances, but what I think is predictable is that if Wappler continues to overwrite files like this, without the developer having any control, there will be more and more problems.

As it is, Wappler basically doesn’t support custom Bootstrap themes - and I think it should, but only to the extent of giving the necessary control. In this respect (and only very few others), I think Dreamweaver was superior to Wappler. I never worried about what might happen if I made a simple change to a page and uploaded it.

[Teodor]

This whole workflow will change.
As George explained in a similar topic a while back:

Confusion caused by new feature - using local assets combined with remote target

Ideally we want to have a local dev / live site targets - and you do everything in the local/test target - and finally just select the live target and hit the publish button to publish the ready site live.

This will give us many advantages as also post processing your site before publishing. As your live site might not be a copy of your dev environment - but a very minified and compiled version of it.

But still way have a way to go to achieve this like database connections per target and a whole new publishing workflow.

As for different Bootstrap versions (5, 6) - this will never be an issue as these are separate major versions so version 5 will not be auto included on page containing version 4.
You will have to manually select it.

[TomD]

Thanks @Teodor. I’ve just read throught the topic you linked to. The main reason I started that topic was about the confusion caused by showing remote images in a local view of the site. I had forgotten about this, but as far as I can see, this is no longer an issue and the changes I was referring to were reverted. I’m not sure what this has to do with the current topic.

That’s good to hear about future versions of Bootstrap. However, the issue remains - that overwriting custom versions of Bootstrap (version 4 and future version), automatically and without any option of a warning message, will cause problems.

[Teodor]

I’m not sure what this has to do with the current topic.

The whole publishing workflow will change (local dev / live site targets), as explained in the quote i posted, so this will solve the issues you are having with auto uploading files.

[TomD]

I remember being rather alarmed by what George said in that topic - but I probably didn’t understand what would be involved. In any case, I’m sure it will excellently implemented.

Confusion caused by new feature - using local assets combined with remote target

Ideally we want to have a local dev / live site targets - and you do everything in the local/test target - and finally just select the live target and hit the publish button to publish the ready site live.

I always use local and live versions as it is, but as for simply hitting the publish button… I daresay some people work like this, but I suspect most do not. Like @Dave, I have never touched the Publish button and wish I could remove it. It’s like a bomb at the bottom of the screen which I’m careful not to step on.

Anyway, as long as the new publishing workflow offers more control and helps avoid the current issue (and similar issues in the future), I’m sure it will be a great improvement.

[Teodor]

We are referring to an advanced publishing options, not like we have it currently. The current publish button compares the files on the selected target and uploads just the changed ones.

We mean a real publishing, with version control, minifying files, webpack integration. Your live target will never be changed without you first test everything in the local and dev environment and then build + publish the changes you need.

As soon as we have more news about this, we will share more info.

[TomD]

Sounds great - as long as ‘build + publish’ can just mean upload the current file, and nothing else. Most of the time, that’s what I do (after the initial stages when lots of files will probably be uploaded).