I have an existing UI Builder app with 10 pages. These pages are destined to 3 different audiences: Students, Tutors, Admin. So I would like to separate into 3 UI containers.
I would like to:
a) Fork the existing container twice, remaining them so as to have an Admin, Tutors, and Students container.
b) Delete the irrelevant pages for each container.
c) Rename the default container accordingly
Aside from making sure that the login functionality applies to the pages within a group container, is there any other risk or issue I need to mitigate before doing this?
you can do all of this safely. I don’t see any points where something could go wrong. However, if you want to be able to quickly restore everything as it was, you can make a copy of the ui-builder directory in your files before you start (formally make a backup). This way you can restore everything back if something happens. However, as I said, all actions should go without problems. If there are, let us know.
After creating those copies please do not remove/rename the source ui-container.
Copying files takes some time, especially if you’ve got lots of pages/functions/etc., so the immediate removal might lead to problems with the target ui-containers, it doesn’t happen always, but a couple of minutes delay won’t be redundant. This is a known issue and we are going to fix it asap.
Our assumption is that currently, when one clicks on the link, they see the default page, and that if we rename the default container page to SampleTest_old, then they will see the new one. Is this assumption correct?
UI Container name is just for you as a developer, and you can publish it into any location, it means you can publish the same UI container into several places, for instance: ‘/web/first-version’ and web/second-version.
I assume your custom domain is mapping to the “web/bg” directory, so if you publish in the directory another UI container the proved link will open the latest published container
Yes, it’s possible, just publish your containers into sub directories, for example: web/bg/cont1web/bg/cont2web/bg/contNhttps://portal.brilliantgrades.com/contN/?page=sampleTest, or you can publish your container into web/cont1web/cont2web/contN and mapping your domain to the /web directory
We have a set of these files in these locations:
Our custom domain points to files/web/bg
We do not have other apps or need other apps.
I will of course make backups, but, if I conclude they are not used, would it be okay to delete the files in files/ui-builder/containers/default/, files/web?
However, when we create new containers from the Backendless UI, they are created in files/ui-builder/containers. Do I simply move them into files/web/bg as you indicate here?
the source files for the default container are located by the following path files/ui-builder/containers/default/, so do not delete anything here because you won’t be able to open the container in the UIBuilder designer. Instead of copying files manually, you have to use the “Publish” button to build/publish files of the container into a target directory
So the files in the following path files/ui-builder/containers/default/, are not working files, they are source files, like a template?
Because I confirm that when I click on file /files/ui-builder/containers/default/index.html from the Files section, this is not my index page that opens when I open portal.brilliantgrades.com, the index page is actually located at /files/web/bg/index.html. Is this normal?
But it is confusing as when I am looking at the index file in the UI Builder, the url appearing is the ui-builder folder. How does this work?
no, it should replace only affected files, for instance, the following folders will be replaced components, library, styles, theme, in other words, will be replaced only working directories and files and any custom files/folder should not be replaced