POLL: Handling related files and assets

As Wappler does a lot of things automatically, we need your feedback on the best way that suits you.

So suppose your page is using a lot of components and frameworks.

When would you like those assets to be auto updated? For example when new versions are available.

Do note that sometimes also include links need to be changed not only files, as version numbers can also be included in the links.

  • On page open - all related files should be auto updated and page links changed, but leave page in dirty state
  • On page save - update the files and links - then save the page
  • On project open - when the project is open auto update all assets
  • Have a special manual option - update assets
  • always ask me first - I need to confirm any framework or component version update

0 voters

So vote and comment the best solution for you

I see a lot of voters for always ask me first. Could you explain why you want this?

Because having weekly updates of components and asking for each one: do you want to update component 1.1.x to 1.2.x on this page each time might be a little too much. Also you don’t have a clue what is really changed

1 Like

I would not really mind how the updates are done to be honest but if I were given a small report after the update so I could check and update code where needed would be very handy.
In dreamweaver I would open a file and it would update and not tell me what was updated, so I did not even know what to test to see if it was working as i wanted it to.
The update on open or save option seems a little problematic as if i have a 20 page website, i would not want to open every single page for it to have the updates applied, so on project open to update every file in the project and send a report of what it did would sound perfect to me.

2 Likes

True - in Dreamweaver we dodn’t Had any other choice. But now with Wappler we have full control. So that is why i’m Investigating the best solution to meet your needs.

A report is indeed a good idea. Specially if you are updating a complete site. Not only new versions of components are updated but also a lot of pages as well if their includes need change. if we choose to do project/site wide update.

2 Likes

that s would be great!

1 Like

Any option that will not break the pages or sites is a good option. I’m always scared to do updates in fear it will break my sites.

Me too @brad, it is literally the reason i used Espresso for so many years, when I open a file and the code starts auto jumping around and changing I could literally feel my heart start skipping some beats.

My old workflow was open Dreamweaver add the component i wanted to a brand new page on a test site not used for anything, copy all code created and files added to my Espresso project and continue working, this was I could feel safe that in 3 years time I could go and make a simple text alteration without breaking anything that was previously working.

I do not blame DMXZone or Dreamweaver or Wappler for that as I know it must be almost impossible to keep backward compatibility spanning over years and years. I would imagine one version or even two versions behind would work fine, so a site I am actively working on for instance where Wappler will update the same site with each new software revision. But when the site has not been opened in 3 years and the client asks for a single image swapped out or a piece of text altered, what then, it might have been created in Wappler 1.2.5 and in three years we could be on Wappler 4, if we keep at a software update each week, then it will be 156 versions old software that created it, will it even recognize the code and how to update it to the latest, and if it does will it alter anything else.

If the client asked to change a single image I am probably charging a cup of coffee, i really do not want to be recreating his entire site because the software broke it.

How about an option saying, This site was created in Wappler 1.2.5 would you like to update the code to the latest available, yes, or no. Then the user has the choice, if they decide to update it, and it breaks, well that was the users choice.

Wappler version probably won’t matter, but the components used will. So that is actually the main question here of how to present indeed those components updates. Indeed many of them can be quite large and also there can be a lot of dependencies.

So updating one would require to update another one as well. There can be a whole dependency network going on. So there with lots of versions and dependencies it can get pretty complicated. For example like the npm dependencies.

https://lexi-lambda.github.io/blog/2016/08/24/understanding-the-npm-dependency-model/

That sounds like quite a pain to try and keep up with @George, would you imagine that because of this dependancy it would be troublesome to actually have a person open a 3 year old project created in Wappler in the latest version without Wappler almost needing to update it, otherwise how does a user make a change if they need to swap an image created with a 3 year old slideshow component when the slideshow component they are using is now more than likely vastly different.

I wonder if it might be an idea to update the Wappler Project manager to have an archival function so all your sites are stored in the archive, then on update of Wappler every single website in the projects panel gets updated simultaneously with the required code changes.

This way all old websites are updated with every Wappler component update and the Wappler backward compatibility only needs to account for a single version swap out to the newest. Otherwise how is a user going to open a file created years ago to make an alteration when its components could be so very different. Also it means Wappler never needs to get bloated with 10 old versions of components to account for this.

Just finished reading that linked doc @George, and all I can say is I am glad I am not you, haha, sounds like a absolute nightmare.

I have to admit, being a control freak myself, i find the idea I suggested of auto updating every site I have in Wappler automatically slightly terrifying, however on the other hand I would rather have all my websites updated on auto pilot to the latest once a week with a 99% chance of it doing a perfect job, as well as because it it did break a site or a component within a site Wappler will know what might have gone wrong.

Imagine opening a 5 year old website in the latest Wappler, if it went wrong, it would probably go very wrong, and the 5 years of changes it just made to the website would be far more difficult to track down.

I hope this makes sense, because if I read my own above suggestion, i think my immediate reaction would be oh my, please do not do that to me, but if you look at it more closely I personally think it makes more sense in the end of the day.

1 Like

So do I. For most sites, I usually have one or two zip files containing backups of the whole site. It’s a pretty common situation that updating a file causes a problem somewhere so I always want to have the option to revert while I sort things out. Just this morning I was investigating a 500 error and downloaded an error log from the server including:

image

I imagine some file was uploaded automatically and things got out of sync.

Having no control over updates would be very alarming. A warning at least - or perhaps an option to backup any overwritten files - would be good. I’m slightly concerned at the way Wappler uploads files in the background as it is - even without Wappler updates.