firstly, apologies for the small novel below
I upgraded from ignition 8.1.34 to 8.1.36 yesterday and have come across an issue that seems inconsistent and hard to reliably replicate, so I thought I might post here to see if anyone else has seen this.
For this example, I have two pages defined
path
view
/things
Things/AllThings
/things/:thing_id
Things/ThingDetail
the view Things/ThingDetail has a parameter thing_id which is used to grab the data of the specific thing to show.
So going to /things shows a list of everything, click an item and it will navigate you to the details page for that item at some path like /things/1234
This general idea of a list of stuff you click an item and open a page with the details using a url pattern like this is a philosophy we have chosen to use in multiple places and it has worked well... up to now.
with 8.1.36 if I go to /things I get the detail page instead of the list. There seems no way to get to the page with the list, like the ignition web server is matching the url to the detail page somehow.
for now, I have modified the page url to not match and it works again, for example, the detail page is now thing instead of things e.g. /thing/:thing_id
Not all the places I have this pattern in place are affected, it's about half. I tried to make another project to recreate the issue but I don't seem to be able to.
I had a look at the json for the page list to see if there were any differences between the items that work and those that don't, like the order of the elements in the list, but it all seemed to match between working and broken.
I'm not sure if this is actually something to do with 8.1.36, as the attached project shows the behaviour on 8.1.30, 31 and 36.
This project was upgraded to version 8.1.36, not created from scratch in 8.1.36.
In our production project, we have fixed the issue by deleting the page definitions and recreating them half a dozen times. Now it seems to work again. Very odd.
Pretty sure this can work only by accident. Simply don't make parameterized URLs that share a root path with anything else. For the "show all" case, inject a bogus ID.
Although we got it working again, I did indeed change the paths to be singular for the detail item as I can't trust that the web server will respond as I expect.
However this has worked reliably until this point (perhaps by chance) and in fact, I would say that /things/xyz is definitively not /things. they are two different end points and should never be confused IMO.
What is the difference to having two pages declared like /level_one and /level_one/level_two. They are two different end points, two different keys in that page -config dictionary (I suspect looking up in this dictionary with a variable endpoint part is at play here). Just because one part of the path is a parameter does not change this. Would you ever expect to get the /level_one/level_two content when you asked for /level_one? I believe this is an actual bug that should be resolved.
Anyway, thanks for the feedback, onwards we go, always learning and adapting
I would agree with this only where the keys are constants. Once you need a path fragment to be dynamic, you pretty much need the prior part(s) to be unique, or complexity skyrockets. Which is where my "accidentally" statement fits.
Don't hold your breath waiting for this to be fixed, or to even be classified as a bug by IA.
its definitly not standard web behavario for this to not work.
However since you cant change the order in the ui, its probably better for it to not work to avoid even more confusion problems with orders.
Some more explanation in the docs would be helpful too
