linkto, wrong tag build

[Blastiko]

Hi all

In my routes.cfm:

.get("add-note", pattern="/abc/note/[key]", to="note##add");

In a cfm file i have:
#linkTo(route="add-note", key=1, params="live=yes", text="add note")#

html tag that i obtaing is:

pippo.com/index.cfm/abc/note/1&live=yes

it is wrong because i must obtaing:

pippo.com/index.cfm/abc/note/1?live=yes

infact first link doesn't work, but last yes

Where are i wrong?

Thank

CFWheels 2.2

Adobe ColdFusion 11,0,19,314546

[Risto]

I haven't seen that before. I'm using the same version of wheels as you and I have many linkto() with params just like you have and it writes the html with ?live=yes

Only other thing I can think of is try a reload. Sometimes it just magically fixes issues. I am using Lucee and I notice you have an older version of Coldfusion.

Are you able to spin up CF2016 or 2021 and see if works? Either way you have the issue so I hope the reload works.

[Risto]

Also, I use url rewriting but I don't see how that would make a difference.

linkto() uses URLFor() (line 599) https://github.com/cfwheels/cfwheels/blob/8985e13a80fd816cfafca4df767c398bcfc15daf/wheels/global/misc.cfm

[Blastiko]

Hi Risto,

Yes, generally if i try reload=true this resolve the problem but it come back whenever i start new work "session".

I'll explain: no work, then reload=true and it work for the rest of working day, but next day, when i open the page, the link is again wrong.

It seems that depend on a session setting or similar.

The solution by reload=true it is ok while i develop, but obviously it's no adoptable in a production environment.

I run into similar problem when i wrong a route and i used resources(name="users") instead of the correctly resources("users").

In this case the "name" key param caused the problem.

Can this help?

Sorry, i notice only now that i missing the "name" attribute in my route, the correct string is .get(name="add-note", pattern="/abc/note/[key]", to="note##add");

Actually i resolved modifying the route like this: .get(name="add-note", pattern="/abc/note/[key]-[live]", to="note##add"); but it is ugly (imho).

[Peter Amiri]

@Blastiko,

I think you should be able to use something like this:

.get(name="add-note", pattern="/abc/note/[key]/[live]", to="note##add")

That might look better as a URL and for SEO.

-Peter

[Adam Cameron]

On Saturday, 23 April 2022 at 15:43:10 UTC+1 Blastiko wrote:

Hi Risto,

Yes, generally if i try reload=true this resolve the problem but it come back whenever i start new work "session".

Have you raised an issue about this? It sounds like a fairly fundamental issue with routing resolution to me. And based on what Risto says, something that doesn't just impact you?

-- 

Adam 

[Blastiko]

Hi Adam

I think it is a bug because the function paginationLinks() is affected too.

I used this: #paginationLinks(route="users", linkToCurrentPage=true, class="...")#

When i open the page that contain this func i get this link: https://mysite.com/index.cfm/users&page=1

Obviously, it is wrong and cause error.

If i reload with reload=true in the url then i obtain the corret link: https://mysite.com/index.cfm/users?page=1

but this workaround it is not applicable in a production environment.

[Peter Amiri]

Blastiko,

I'd love to try to understand why you are seeing what you are seeing. My gut feeling is that it has something to do to the application or session timeout. Perhaps also an engine specific thing going on. But I'd like to see if I can reproduce it on my end. Here is what I see with the latest v2.3.0 stable release. 

My routes.cfm has the following:

<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="add-note", pattern="/abc/note/[key]", to="note##add")

.resources("posts")

.resources(name="users")

// 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()

// 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##index", method = "get")

.end();

</cfscript>

My views/main/index.cfm has the following:

<cfoutput>

<pre>

#UrlFor(route="add-note", key=1, params="live=yes", text="add note")#

#LinkTo(route="add-note", key=1, params="live=yes", text="add note")#

</pre>

</cfoutput>

And I'm getting the following results:

I also have the following routes:

As Risto explained this isn't normal behavior and I'd like to get to the bottom of it.

Can you describe more about how this problem manifests itself.

-Peter

[Peter Amiri]

I think I found the bug. It didn't turn out to be specifically the application or session time out cause I first set my application time out to 30 seconds with a session timeout of 10 seconds but no matter how long I waited, well into 5 minutes, I couldn't get the URL to get generated incorrectly.

Then I searched the codebase for the string "&" and it comes up in a few spots. One of them is in the file wheels/global/internal.cfm. On line 491 where the delimiter is being determined. There is a comment a few lines above it that says "When rewriting is off we will already have "?controller=" etc in the url so we have to continue with an ampersand." So I went back to your original post and you definitely don't have URL rewriting turned on. Then I looked at my test case and I did. So I forced my copy to turn off URL rewriting by adding "set(urlRewriting="Off");" to the config/settings.cfm file. When I reloaded the page I definitely have the wrong URL with an ampersand being used even when there is only one name/value pair after in the URL. So now that I can reproduce this behavior we can see about getting it taken care of.

[Peter Amiri]

The plot thickens...I'm still in the observation mode. I added the the following code to my views/main/index.cfm file:

<cfoutput>

<pre>

#UrlFor(route="add-note", key=1, params="live=yes", text="add note")#

#LinkTo(route="add-note", key=1, params="live=yes", text="add note")#

#UrlFor(controller="main", action="two", key=1, params="live=yes")#

#LinkTo(controller="main", action="two", key=1, params="live=yes")#

</pre>

</cfoutput>

I'm just adding a couple more calls using the wildcard settings in the routes table.

Here are the results with the various urlRewriting settings (on, partial, off):

This is what we get with set(urlRewriting="on");

This is what we get with set(urlRewriting="partial");

And finally this is what we get with set(urlRewriting="off");

You see that in all three cases the URLs generated when specifying the controller and action are correct but in the last case when urlRewriting is turned off and the route pattern in the routing table has "/" in it, the wrong delimiter is used to build the URL.

Try this as a work around for now. Set your urlRewriting to "partial" then the correct delimiter is used and all the URL match the same pattern. This may not be a bug after all is said and done, cause if your web server truly cannot do urlRewriting then pattern "/rewrite.cfm/abc/note/1?live=yes" wouldn't work at all. If your web server understands that pattern and is able to process it, then it is really a "partial" urlRewriting capable web server and you need to let the framework know that by using set(urlRewriting="partial"); in the config/settings.cfm file.