All Query Parameters wiped?

[Cheese]

Have seen this mentioned a few times and just noticed all of our Query Parameters are missing for one of our Projects after a crash. We do maintain backups thankfully. But where is the file that holds the Query Params located so we can restore it? Advice much appreciated!

[famousmag]

Inside the DmxAppConnect directory, it is the config.js

[Cheese]

Many thanks @famousmag! Couldn’t for the life of me remember where they were!

Will write it up as a Bug Report. If Wappler or the system upon it is running crashes for any reason the Project open within Wappler wipes the Query Params entirely! Am just happy we backup regularly. In our case there was no harm done. But for others it could be a real problem if they don’t have a recovery option…

[famousmag]

I’ve been ther my friend a lot of times…

Team is already investigating it.

[Cheese]

@famousmag

Team is already investigating it.

Had seen it come up a few times and remember you sharing the above image previously (just couldn’t find the thread). We run backups on our Projects once an hour so in the case of a loss we don’t incur too much damage. In general crashes are extremely rare thankfully! Hopefully the Team get to the root cause of the issue.

Thanks again!

[Hyperbytes]

There is also a bug relating to parameters and app ids. if you have a page with an app Id which is linked to query parameters and then change the app id of the page, all the linked parameters are also changed to match the new id, breaking links to all the former linked pages.

[Cheese]

Thank you for the heads-up Brian! Was not aware of this. We are quite strict with App ID’s. We set one and stick to it. Still don’t know why new Content Pages don’t inherit the Layout APP ID though!

[Hyperbytes]

Found it by accident when doing recent video on parameters and app ids.

Issue when changing App Ids relating to query parameter settings

Wappler Version : 6.4.0 Operating System : Windows Server Model: Node Channel: Beta Database Type: Hosting Type: Expected behaviour previously defined query parameter settings should be unchanged Actual behaviour When changing app id of a single page it changes the app id definition of any associated query parameters effectively breaking links in other pages See video for explanation appid-issue

[brad]

@Cheese

Thank you for the heads-up Brian! Was not aware of this. We are quite strict with App ID’s. We set one and stick to it. Still don’t know why new Content Pages don’t inherit the Layout APP ID though!

I also use the same App ID on the entire project I am working on and lost my parameters. Glad to know it’s just not me. Seems to me that it is just a UI issue as the parameters still work on established pages.

[Hyperbytes]

You can check the internal settings in config.js in the DMXAppConnect folder

[George]

I see that here is some fundamental confusion about App IDs.

So note the following:

App ID should be unique per page!

Otherwise if keeping all the same app id, you risk in loosing all meta data when renaming the app id.

So each layout page, content page etc, should ideally have its own unique app id.
Content pages without app id, will inherit the meta data from the layout page.

The whole purpose of having App IDs is that you create a metadata store per page that stays the same even when the page is renamed.

[Cheese]

@George

The whole purpose of having App IDs is that you create a metadata store per page that stays the same even when the page is renamed.

This sacrifices all Query Params and other data associated with the App ID (query params, cookies, data store etc). Surely the App ID should be based on the Layout page for that reason? So if it is a Public side to an App the Layout can have an App ID of ‘public’, and this is applied to all Content pages based on that Layout, and all changes to that APP IDs parameters remain intact? Whereas you may wish for alternative parameters for a Layout page for Admin, which would have the App ID ‘admin’, then any changes applied to this Layout will roll on those changes to the Content page based upon it…

Surely that makes sense and is more logical?

[Hyperbytes]

@George

Otherwise if keeping all the same app id, you risk in loosing all meta data when renaming the app id.

That is exactly the rational of the above bug report, is that really idea to have to give every page an unique APP ID and in the case of PHP redefine query parameters for every page.

Not really that big an issue for me now as i am pretty much 100% node based so params are defined in layout but problematic for PHP users.

[George]

@Hyperbytes

PHP redefine query parameters for every page

well yes - each PHP page has its own query parameters, you don’t have site wide query parameters.

[Hyperbytes]

would it not be more logical/ productive to have a new namespace created in the config.js when renaming the app id rather than redefining the existing one?

[Cheese]

We are not adverse to any suggestions that improve work-flow. Does need some thought as it has come up a few times when Users can’t see their parameters as the App ID is different to the Layout…

[sitestreet]

@George

App ID should be unique per page!

This has taken me by surprise. I make sure the App ID is consistant across the whole project so that query parameters and data stores are available across all pages. It would be a pain to have to recreate all the structures for every page.

Is that really how we should be working?

@George

The whole purpose of having App IDs is that you create a metadata store per page that stays the same even when the page is renamed.

But if we have the same App ID across all pages, they can still be renamed without losing all the query parameters, data stores, etc. so I can’t see why you would want different App IDs on each page.

I’m speaking from a PHP perspective by the way.