More global options needed on UI for server connect

Wappler General How To
#29

Right now my main problem is reading redis connection string from an environment variable.

This is my core deviation:

because of this:

But I wouldn’t mind an advance flag in the project settings to avoid overwritting constantly changes to core files. Why? Because I believe there is a group of users that more or less know their way around the framework and are pushing the boundaries of it constantly that would appreciate being able to change core files until a core improvement is added by the team.

I once waited 18 months for a very simple change that allowed me to use Scaleway S3 object storage.

Change this:

let region = 'us-east-1';

to this:

let region = options.region || 'us-east-1';

Thanks to being able to deviate core files I was able to continue the project instead of writing every single week to have this implemented and mess with your roadmap.

Soon one year will have passed since I reported the impossibility of defining the redis connection string as an environment variable.

Maybe you can think of a way of adding that advanced boolean/flag to avoid this situation so we can keep pushing the framework forward without flooding the forum with our nagging.

1 Like
#30
#31
#32

I think @patrick can take care of those. He recently changed the core so ENV variables are parsed so it might just work already if you enter them as expression in the server connect global settings, tge redis connection there

#33

I don’t quite understand what has changed here.
There is a project updater flow in place - and if you don’t respect the decision when NO is selected, what is the point of even having this?

The current flow, as of 4.6.2 which I am on, is perfect. I update a project when prompt is shown. Change core files as I need and continue with my work.
OR, If I don’t update a project, I already have the changed core files and I can continue without any other changes. If the Wappler UI/functionality breaks, its on me that I have not updated the project.

Wappler should not force any file updates.

Like Jonas has correctly mentioned, the changes made here might take years to show up. I shared a list of changes I do 21 days ago, without any update or reply on the progress.

If there is something else behind the scenes why you NEED to change these files, give a setting to disable it please.

#34

image

I might be missing something as I don’t have the full picture but I don’t understand what’s the added value of this check against file contents. I might be wrong but I’ve never seen a bug report on the forum that was due to someone changing core files.

1 Like
#35

We have switched to file context check instead of just date check because file dates are unreliable.

For example if you use git - all files will get the current dates on pull or checkout, as git does handle file dates.

So your files will never be overwritten and that is why we used to get many reports of not updated core files.

So the Updater handle the file checks now well and you can indeed choose to update or now but then per framework indeed as we can’t have mixture updates that will create incompatibilities.

So it should be all fine but Sid is having problems with other files that update automatically like the config files.

So that is the confusion because we do not update those as they are not considered core files but user files. However config files are stored per target so are updated on target switch. So that is what makes it a bit confusing.

If you have other files wrongly updated @sid do let me know.

#36

Oh ok. I understand now. Thanks for the context. So the problem was not with people like sid and I modifying those files. It was because some files were not being updated. I’m guessing this is a formal fix for the workaround of “delete your lib folder” and restart wappler.

Ok this is now clear for me and I understand the change.

Nonetheless it’s still a problem for the people that keep ahead of the framework for whatever valid reason. Sometimes we can’t wait for something to be added to the core and we need to do it yes or yes for the sake of the project.

Considering both points from above here I offer a new alternative instead of adding an option to completely remove file content check.

  1. Be able to mark a single file as “do not check for changes” and “check for changes” in the “file browser” or the “project updater”. Similar to an “add to gitignore”.
  2. In the project updater these files will show up with the following icon but in red image with a tooltip “The file won’t be updated by Wappler on content change”

Now everytime we start Wappler or run the project updater we will see(and won’t forget) that we have a file marked like that. If someone marks it by mistake they will be reminded each time by the project updater. And for those like us that do it on purpose we get a remind to push for the core change while giving us the flexibility to continue our project.

Flexibility is key for Wappler. The contrary leads to a slippery and “bubble”-ish path.

Edit: If you really want to make this a very advanced option. Let us go into our Wappler account and mark it as “Expert mode” aka “I understand the risks”. Then make the Wappler desktop app read our account setting from account.wappler.io instead of making it easily available in the UI for all users. Or even go further and mark yourselves our accounts as “expert mode” so only a few of us can actually mess with core files.

#37

Oops sorry for the inconvenience - found the silent core update issue @sid.

Seems we also updated the core files silently on server action save. This is no longer necessary.

Now all core files will be copied or updated only on project open or create.

Will be available in the next update

2 Likes
#38

Perfect. That should do it.
Have been waiting patienty to upgrade since 4.6.2… Finally will be able to do it! :slight_smile:

#39

Great news. Thanks @George

#40

Also will be improving the App Connect components file updates. So their files are not auto updated on insert but only with the Updater, so upcoming improvements will be:

Wappler and App Connect Components

  • Greatly improved component include and linking to pages. Now missing script includes are automatically inserted on page save if missing
  • Main layout page is now auto saved when includes are added to it.
  • Updating existing App Connect component is done now only with the Wappler Assets Updater on project open, or when the updater is called manually
  • When adding App Connect components which files are already available in the project - those are used.
1 Like
#41

One potential issue is where files might be referenced remotely or stored locally. This cropped up recently in relation to Tagify. In this example if you choose to store the file locally, Wappler adds the remote link too when the file is saved. Could Wappler check for this situation?

#42

6 posts were split to a new topic: Allow App Connect components to use CDN paths

#45
#46

Was this feature (using env variables in core files) ever implemented?

I’m on 4.7.3 and tried using the expression in server connect global settings, but got an error in the console when the server started up. Had to edit the redis.js file to allow using env variables.

#47

Environment Variables are now available in Wappler 4.9.0 UI:

#48
#49
#50

This topic was automatically closed after 2 days. New replies are no longer allowed.