@neokoenig While trying to build up my templates I may have discovered a bug in the URLFor() function that was introduced with https://github.com/cfwheels/cfwheels/commit/b5521d68ddf1ba46bcccd8241060df05a8c7e370#diff-53fb5848da39e7b3637d1ba65[…]dc9cefb64baf007c3528dad1f9c956 This break simple wildcard routes. This may have been why some people were getting frustrated going through the simple tutorials and having the multipage linking not working. To test my premise, open up CommandBox, create a directory, and download my Hello Pages template:

box
mkdir testURLFor --cd
install cfwheels-template-hellopages

Now start your server. You'll see a page one that has some links to page two which has some links to page three and then back to one. There are three sets of links on each page, the first uses a named route, the second specifies just an action, and the third specifies the controller and action. You'll see this links work fine and you can navigate to the next page using any of the links. Now go to your address bar and specifically go to

/index.cfm/wildcard/one

you'll see a similar page with links to get you to the next page. I turn the first link into a static text cause we don't have named routes for the wildcard controller. Now you see the wildcard links are broken. They only contain the controller name. It's not the routing engine cause you can go to the address bar and enter

/index/wildcard/two

and

/index.cfm/wildcard/three

and the proper page comes up but the link that are built by the LinkFor() function are broken. Now go into

/wheels/global/misc.cfm

and comment out the else if block on line 669-672. Now reload your app and visit

/index.cfm/wildcard/one

and you'll see the wildcard links built by specifying only the action or the controller and action now work.

Interesting - paging @David Belanger

No worries. It's probably a good thing since I have been breaking it as I've been building it more and more. Anyway, I think I'll keep going with some more templates and then jump back to the CLI to incorporate the templates into the NEW wizard.

Hello all - I'm currently on the Texas Eagle Amtrak train heading for Dallas- best part of this trip... very little Internet 😉 I promise to have a look on Monday when I'm back in the office

@David Belanger @neokoenig welcome back. I hope your night-vacations were pleasurable and your day-works were fruitful. So I just spun up this test again. The issue is that if the wildcard is used the route name in the params is getting set to wildcard. So your code will make it take presedence. I think the quick fix for this would be to modify your code to ignore the named route if it equals

wildcard

. I can submit a PR if you agree with my assesment.

The thing is, unless I'm going crazy, I'm pretty sure that named route is suppose to take precedence if you put all 3 into the URLFor. Can you show me the screen shot for page two?

I don't disagree with your statement. If the route is mentioned it should take precedence, but I think there is more going on here. Let me try to illustrate what I'm seeing. If this warrants a zoom call or you want me to package my files and send them to you. So here is what I have. rotues.cfm

<cfscript>
// Use this file to add routes to your application and point the root route to a controller action.
// Don't forget to issue a reload request (e.g. reload=true) after making changes.
// See <http://docs.cfwheels.org/docs/routing> for more info.
mapper()
	.get(name="one",   pattern="one/",   to="main##one")
	.get(name="two",   pattern="two/",   to="main##two")
	.get(name="three", pattern="three/", to="main##three")
	// The "wildcard" call below enables automatic mapping of "controller/action" type routes.
	// This way you don't need to explicitly add a route every time you create a new action in a controller.
	.wildcard(mapKey = true)
	// The root route below is the one that will be called on your application's home page (e.g. <http://127.0.0.1/>).
	// You can, for example, change "wheels##wheels" to "home##index" to call the "index" action on the "home" controller instead.
	.root(to = "main##one", method = "get")
.end();
</cfscript>

So you see that the only routes being defined are the three routes in the main controller, the wildcard route, and the root route. Here is the directory structure of the views directory:

├── helpers.cfm
├── home
│   ├── _dumps.cfm
│   ├── one.cfm
│   ├── three.cfm
│   └── two.cfm
├── layout.cfm
└── main
    ├── _dumps.cfm
    ├── one.cfm
    ├── three.cfm
    └── two.cfm

This is the contents of the _dumps.cfm partial:

<cfdump var="#params#" label="params">
<cfdump var="#urlFor(route='two')#" label="urlFor(route='two')">
<cfdump var="#urlFor(action='two')#" label="urlFor(action='two')">
<cfdump var="#urlFor(controller='home',action='two')#" label="urlFor(controller='home',action='two')">
<cfdump var="#urlFor(route='two',controller='home',action='one')#" label="urlFor(route='two',controller='home',action='two')">

So on each page I dump the params structure as well as what urlFor would return if one specifies a route name, an action only, a controller and an action, and finally a route, controller, action combination. I've attached some screen shots that show me calling the six different pages by manipulating the URL line by calling the pages via named routes and wildcard routes. You will see that if the named route is used either by itself or in a triple combination with the controller and action then the url for the route is returned. But if the action only or the controller and action are defined then the returned URL is often invalid.