Do you have a route with path /:service/:function/:country/:state/:city and was this route above the other route? Then it is not a bug, it will return the first route that it matches, and that route matches the url.
But /staffing-agencies/ matches /:service/ since :service is a parameter and matches everything until the next /. It sees the staffing-agencies as service parameter.
/staffing-agencies/ is not a parameter on the URL, the first parameter is /:service/
These are two different pages, one has /staffing-agencies/ as the beginning of the URL and the other does not.
I have pages with multiple parameters that need to return the appropriate page, not just the first parameter.
You can see the route below, âstaffing-agenciesâ is not a parameter, and so the rendering page should at least load /staffing-agencies/ but it doesnât, instead itâs loading the route below:
You can see the page it should load is also very different:
In what order are the routes? The route paths are being parsed on the server when it receives a request and then checks the url which page it should load by the first route it matches. The meta tag on the page does nothing else then getting the parameters out of the url, you will then see the service parameter will contain staffing-agency.
If I have 2 routes like: /:firstname/:lastname pointing to the page user /detail/:product pointing to the page product
I visit url /john/doe then it will load the page user, the parameters will be firstname=john and lastname=doe.
Now I visit the url /detail/wappler, I expect it to load the page product, but it doesnât. It loads also the page user, the parameters will be firstname=detail and lastname=wappler.
Changing the order of the 2 routes fixes the problem since the product route is more specific then the user route. The parameters match all, it becomes a regex like /\/([^/]*)\/([^/]*)/.
Thank you @George - Iâve checked those out just now. I believed that I have done this correctly, a per this section â Use forward slash (/) to indicate hierarchical relationshipsâ on https://restfulapi.net/resource-naming/
But if itâs not possible to have a completely dynamic directory based around the url parameters (and in nearly all cases multiple parameters) iâm a bit lost with all the work done on this directoryâŚ
Here is an example of my structure, Iâm not sure how I would sort what is or what is not concrete as they all play a role in the directory.
This actually is a general topic how routes work, not really Wappler specific.
In your case however you have a lot of ambiguous routes because you have fully parametrized all route segments!
So for example:
/:service/:country
And
/:service/:function
Are two exact same routes with two parameters, so your website does not know which one to call as they are both expecting two general parameters, so only the first will be used always.
It doesnât matter that you named the variables differently - they are just names for placeholders. Essentially the two routes in that case are exactly the same - just a arbitrary path with two sediments of any kindâŚ
So you should really make your routes much more strict by specifying static parts so that there is clear resolution.
Iâm really not sure how to do this then. We are transferring an existing site that uses this exact URL path for itâs dynamic directory - so the URL will always change.
I canât make the path stricter as the url path is made up of all those variables.
Looks like this isnât a bug as Patrick mentioned, so you can remove it - just looks like I may not be able to achieve what I need to.
You can be sure that the routes are
/football/:country
/basketball/:country
âŚ
/tennis/:country
And not /:sport/:country
Why donât you do something like this or any other route that leaves no ambiguity.
/service/:service/country/:country
/s/:service/c/:country
/s/:service/f/:function
It wouldnât change the amount of routes you implement.
You are just âprependingâ a path part so that the routing engine is capable of disambiguating.
/:service/:function is the same as /:service/:country
But /s/:service/f/:function is not the same as /s/:service/c/:country and you only added two fixed path parts to the above routes. Those fixed path parts wonât change ever and are enough for the routing engine to understand they are different.
Ok, I understand what you are suggesting now - thank you for clearing it up.
It does however mean that the url structures will change and therefore impact pre-existing traffic (considerable) volumes changing the url path - and this is 100% what Iâm trying to avoid doing.
The two examples above donât donât appear to be doing this, and considering they would also have thousands of variables I canât see it making sense to have fixed paths?
Pretty devastated if I canât make this work somehow
You can leave one route called /:service/:cf and in the SC file just query against a table that contains all the possible countries or functions and if you get a match for a country or a function you know what other backend logic to perform. Itâs just and If/else matter.
@mgaussie That could be a good option too. Not actually using the redirect in the routing but the SC action step.
So you receive in /:service/:cf those hits that are processed by a specific SC file that queries database to check if it is a country or a function.
If country
redirect to /s/:service/c/:country
else
redirect to /s/:service/f/:function
That way you keep old links working and you start migrating traffic to two better constructed routes. Eventually you can remove /:service/:cf route when you see the traffic that comes through there is minimal.
Thank you Jon, I really appreciate your input here.
I am really trying to find a solution that does not result in changing the URL paths, short or long term.
I was looking at routing and using a âcontrollerâ which I donât fully understand or know if is at all possible in Wappler / NodeJS, but I believe thatâs what is used on the existing project - so in Wappler terms that would be I guess taking the parameters from the URL, checking the DB and then telling the F/E what to show, so perhaps a single page and a combination of partials (noting they used PHP and a Symfony templating engine).
Worst case scenario for us is changing the url structure, so trying to find a solution that avoids that as we likely already have to do that for the profile part of the pages (the old team use an underscore in the url path for the persons id, but this is also causing issues in wappler so will likely need to move to a hyphen).
Iâd be happy to share the existing project with you in private message JonL as a fyi, so you can see what Iâm referring to.