How are updates applied to existing Wappler projects? I haven’t given it much thought before - things have just seemed to work. However I recently spent some time debugging a problem which turned out to be caused by a change to one of the Javascript file in the dmxAppConnect folder - I had different versions on local and remote sites.
Are any updates made to files automatically when a project is opened or are they made when a particular component is used? I imagine if a component is used for the first time in a project, the current version will be used, but what if a component has already been included?
What’s the best approach - for updating local and remote versions?
Also, is the version of Bootstrap updated to the current one - or is it only changed if you manually update it?
I notice the Bootswatch version are still at version 4.2.1. I imagine these will be updated soon. In the meantime, if I wanted to have access to the latest versions from within Wappler, could I download the .css and .scss files and overwrite the existing files in the \dmxBootswatch4\Includes\ folder?
Updates of files are handled now indeed automatically for the currently selected target.
That is why when you select to a new target, you have to hit the publish button to synchronize it and update as well.
That is why we also want to move eventually to more push publish way of uploading sites, as you can see now, that it is not just a few files upload that you can do manually but a lot of related assets need to be uploaded as well. Also if we want also to offer some automatic building tools like resources bundling and minimizing - those can be easily done on the publish action.
Updates current are now done when you save a page. Then if any code of the includes is changed it will be also changed on the page. But usually just the includes change.
We are already looking for ways to improve the whole site update process, as the current one is not optimal.
For example to update shared site files like frameworks or component assets, we are considering to build an Update Manager - that will give you more power of what you want to update and what now.
And also do it site wide - when you open a project for example.
Also doing mass page updates is related and will be better handled when we implement the project meta database, so we know exactly which components are used in which files and can auto update only those files.
Thanks for explaining this. I appreciate it’s not a simple matter to keep everything up to date with each new release.
As I’ve mentioned before, I don’t think it would ever suit me to hit a publish button - unless I had control over what was being published. If every updated or missing file on the target was uploaded, this would rarely be a solution I would use.
If the files to be updated or added were listed, and you could select or exclude files, this could be a good solution. Or specifying folders to be updated - eg so any changed files in the dmxAppConnect folder could be updated/uploaded.
In any case, and particularly if the best solution might be a manual update, it would be very useful if a list of updated or new files could be made available with each release.
I see - I thought perhaps this was from another thread.
I just demonstrated to myself (unintentionally) the potential problem of updating files. I opened a site I had not accessed since before the last Wappler update and made a simple change to a file and saved. Unfortunately the target was set to ‘remote’ and the styling of the live site changed from the version on the left to the version on the right:
I used a custom version of bootstrap.min.css for this site. I don’t think Wappler allows for this at the moment. When there are options to exclude files, this won’t be a problem, but until then, I’m not sure how to prevent this sort of thing happening. I had a backup copy of the Bootstrap file which now has today’s date. Will this be sufficient to prevent Wappler trying to update it again (until the next Bootstrap update)? Is is just dates which are checked?
Exactly that is why we want to move to more centralized and controlled publish! So such mistakes shouldn’t happen any more!
So instead of switching yourself the targets and uploading separate files, you will just always develop locally and then when ready do a publish/synchronization action to specific target.
This will give you much better overview of what is going to be uploaded/published and why.
Also version control and backups can be handled that way. Because by “publishing” a site, you are marking a specific milestone/version of your site.
I can't imagine I would never want to do upload separate files (in fact I can't imagine this not being the normal way to update a site) . As a simple example: I might just correct a spelling mistake and upload a single file - I wouldn't want to publish a new version of the site. In fact there would be many such tweaks and updates which would only involve one or two files.
I'm sure whatever you come up with will work well - as long as it's not a requirement to publish a whole site each time.
In relation to this, Dreamweaver does have slightly useful feature: it asks if you want to upload the current file, including (or not) dependent files. It would have been a very useful feature if you could see a list of the dependent files before choosing the latter option.
