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

[TomD]

Improved rendering of remote pages - now everything is rendered locally and local assets are used even if remote target is selected. The remote target is only used for server connect data feeds.

I don’t quite understand the advantage of this change. Hopefully I’ve misunderstood how it works and what it’s for, but as far as I can see, I prefer it as it was.

The first sentence above suggests it’s performance-related - but if you want to see the results quickly, why not just use the local version, rather than a sort of remote version (but with local assets).

I think the error-reporting features introduced in 1.4 are really useful. However, in effect, they only work locally. Previously, I could switch to remote view and see errors related to missing dependencies (on the remote server only). Now, I can’t see this information.

local assets are used even if remote target is selected

This can produce rather confusing results. Eg I have a dynamic table based on a list of image files in a folder. In the example below, I am viewing the remote server in Wappler. Below this is FileZilla showing two image files on the remote server. The broken image of course suggests the asset/image is missing on the remove server - but it’s not; the image is missing on the local server. It may well be the case that on my local version I don’t have the same data (including images) that my client has on the live server. Seeing errors flagged because of this is confusing (and wrong I think).

Is this feature mainly for people who don’t have a local server, and just work remotely? As I say, I think perhaps I’ve misunderstood this change, but as far as I can see - at least in some situations - it has reduced some functionality (remote error checking) and gives misleading results (as in the example above). Would it be possible to have an option to revert to the previous behaviour?

[George]

The main idea behind this is they we are moving towards to more centralized final publishing action.

This is because most of the web developers have a local copy of the site that eventually get published to the live site.

Working directly with the live site is not always desirable as you might want to check if it is all working before pushing it to the live site.

In the previous workflow - you are breaking directly the live site.

I do understand that with the error reporting there were many advantages. We are looking of ways to integrate that also in the new workflow.

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.

[TomD]

This is because most of the web developers have a local copy of the site that eventually get published to the live site.

I would have thought a site might typically get uploaded in stages, over time (whether or not it’s actually ‘live’ from a public point of view). Sometimes just a page at a time, perhaps with a minor alteration to update an existing page.

Working directly with the live site is not always desirable as you might want to check if it is all working before pushing it to the live site.

I’m sure you’re right. I never work directly on live sites

In the previous workflow - you are breaking directly the live site.

I don’t understand what you mean. What’s being broken? Given you have a local server/database, the two sites are quite independent. I don’t know what was wrong with this arrangement. To mix the local and remote causes the issues/confusion I mentioned. I would have thought it makes it more difficult to test the sites or individual pages before uploading to the remote server.

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 don’t like this idea. It seems related to the ‘Publish’ button which I’ve never used and am sure I never shall. Apart from sites developing, and being uploaded to the live server, over time, updates and changes will inevitably be made. I can’t see that I would ever want to ‘hit the publish button’ in any circumstance. If that’s how some people work, that’s fine, but I don’t know why it has meant changing/breaking what I thought were some very good features. It didn’t occur to me that there were any issues in the way it was set up before.