module Jumplinks

[Mike Rockett]

34 minutes ago, Jason Huck said:

An option to automatically pass along (but otherwise not match on) query strings would be ideal...

Yeah, it can be quite a tough subject - but a checkbox should cover it well-enough. That said, do we trim out any included query string so it does not get matched if the checkbox is selected?

34 minutes ago, Jason Huck said:

A configuration option to automatically assume trailing slashes are optional would also be very handy, for the same reason. That way admins wouldn't have to remember to append ? to the end of every source URL.

This is a good idea, but I can imagine some would want a little control over it. Perhaps a global strict mode for trailing slashes (off by default, allowing both to match)?

34 minutes ago, Jason Huck said:

Another issue is that source URLs are URL encoded when stored

Jumplinks 2 no longer encodes the URI/Ls, and it is like this by default as Eloquent is used for DB interactions. However, JL1 should be decoding properly - I'll look into this. (Update, see next post)

Edited October 11, 2016 by Mike Rockett

[Mike Rockett]

31 minutes ago, Jason Huck said:

path/to/this,that&theother/

This wouldn't get matched anyway - PW only allows certain characters in page names (via htaccess), and so this wouldn't be picked up. That said, JL2 has support for unicode, provided that rule 16b is turned on in htaccess. However, commas are still not supported, nor are ampersands. This rule does not apply to query strings, however.

[Jason Huck]

17 hours ago, Mike Rockett said:

Yeah, it can be quite a tough subject - but a checkbox should cover it well-enough. That said, do we trim out any included query string so it does not get matched if the checkbox is selected?

Perhaps two options when creating a new rule:

[x] Source URL may include a query string.
    [x] Append query string to target URL.

You would only use these options if you did not need to match on the contents of the query string or use it to determine the correct target URL.

 

18 hours ago, Mike Rockett said:

This is a good idea, but I can imagine some would want a little control over it. Perhaps a global strict mode for trailing slashes (off by default, allowing both to match)?

Perhaps global options like so:

[x] Trailing slash is optional for source URLs which do not end with the following extensions:
    [.html, .htm, .php, .aspx, .cfml, .pdf ...]

I suppose you could include the ability to override at the rule level, but would it even be necessary?

 

[Mike Rockett]

@Jason Huck - both of those look good to me.

Regarding the first one, perhaps those options should become unavailable the second the question mark is entered?

I did think about that second one, but didn't think about filtering extensions. Perhaps a simple check for \.([a-z0-9-]{3,5})...?

[Jason Huck]

7 minutes ago, Mike Rockett said:

Regarding the first one, perhaps those options should become unavailable the second the question mark is entered?

How would you distinguish between a literal question mark and its current use to make the previous character optional? Would it have to be escaped, or is that syntax changing in v2?

 

9 minutes ago, Mike Rockett said:

I did think about that second one, but didn't think about filtering extensions. Perhaps a simple check for \.([a-z0-9-]{3,5})...?

I configurable list of allowed extensions would ultimately be safer and more flexible. People create all sorts of crazy URLs, and we don't know what someone might need to allow/disallow.

 

[Mike Rockett]

Just now, Jason Huck said:

How would you distinguish between a literal question mark and its current use to make the previous character optional? Would it have to be escaped, or is that syntax changing in v2?

Because FastRoute is being used, only [/] will work in Jumplinks 2 - however, the migrator will automatically convert any saved in the old format to the new format. In fact, JL1 was only using the new format before, but then support for /? was added later on.

2 minutes ago, Jason Huck said:

I configurable list of allowed extensions would ultimately be safer and more flexible. People create all sorts of crazy URLs, and we don't know what someone might need to allow/disallow.

Also true... Perhaps I should then default it to the ext parameter type then?

[Jason Huck]

2 minutes ago, Mike Rockett said:

Also true... Perhaps I should then default it to the ext parameter type then?

Makes sense to use the same list for both purposes, as long as it's configurable. For instance, in a current project we have to handle requests for .pdf files that are now served via a PW-powered download page.

[Mike Rockett]

26 minutes ago, Jason Huck said:

Makes sense to use the same list for both purposes, as long as it's configurable. For instance, in a current project we have to handle requests for .pdf files that are now served via a PW-powered download page.

Yeah, we should just default to whatever ext uses.

[Mike Rockett]

@Jason Huck - I've added your suggestions to the roadmap (last two points under additional features).

[Zeka]

Hi @Mike Rockett and thanks you again for your effort for solving my previous problem, but here goes new one.

Old site urls:

products/poulty.html
en/products/poulty.html

New site urls:

products/poulty/
en/products/poulty/

On new site just "products" is real page, poulty is url segment and I redirect usr segments without ending slash to url with ending slash. That is way I use ending slash in wildcards. 

Wildcard

Source: products/{name}.html/
Destination: products/{name}/

In this way it works as expected, but it doesn't cover multilaguage urls, so I try to use additional wildcard

Sorce: {lg}/products/{name}.html/
Destination: {lg}/products/{name}

I get in debug

404 Page Not Found
Checked Mon, 17 Oct 2016 15:16:23 +0300
Request: http://site.dev/en/en/products/sheep.html/
ProcessWire Version: 3.0.37

Scanning for jumplinks...

[Checking jumplink #1]
- Original Source Path:       about-us.html
- Compiled Source Path:       about-us.html

No match there...

[Checking jumplink #3]
- Original Source Path:       products/{name}.html/
- After Smart Wildcards:      products/{name:segment}.html/
- Compiled Source Path:       products/([\w_-]+).html/

No match there...

[Checking jumplink #4]
- Original Source Path:       {lg}/products/{name}.html/
- After Smart Wildcards:      {lg}/products/{name:segment}.html/
- Compiled Source Path:       {lg}/products/([\w_-]+).html/

No match there...

No matches, sorry. We'll let your 404 error page take over when Debug Mode is turned off.

As you can see in request url I have this (double "en" slug) 

Request: http://site.dev/en/en/products/sheep.html/

insted of url in address bar 

http://site.dev/en/products/sheep.html/

I don't have a clue why urs changes in request url. 

What do you think about that? Maybe I do something wrong in wildcard?  

[Mike Rockett]

@Zeka - Jumplinks currently doesn't have support for multi-language sites. This will change with Jumplinks 2, where multilanguage will be implemented and quite helpful for most scenarios.

I'm not 100% sure what's happening in your case, but is it safe of me to say that Enlglish is not the default language on your site? I ask because Jumplinks uses the following piece of code to determine the site root (to prepend to the request URI) and the site root is being detected in a language that is not the default, which adds an extra en/ as that is the English site root.

$siteRoot = rtrim($this->pages->get(1)->httpUrl, '/');

So, in your case, $siteroot is en/ and the request URI is en/products/sheep.html/, which will cause the double en/. If this is the case, then I will need to change the way the module picks up on the site root.

[Zeka]

@Mike Rockett Yes, English is not default language.

I have this setup: 

/  - default lang
/en/ - English
/ua/ - Ukrainian

So if I have understood you correctly, the best workarout in my case is to use separete wildcards for non default languages? 

[Mike Rockett]

1 hour ago, Zeka said:

So if I have understood you correctly, the best workarout in my case is to use separete wildcards for non default languages? 

Unfortunately not - as you have experienced already, this will cause the language segment to duplicate because the way I see it, the site root URI for the English language is en/ and not /. So even if you have separate jumplinks to match your default language and other languages, you will have the duplication issue.

I will need to push a fix for this as soon as I can. But first, I need to replicate your issue on my end.

[Mike Rockett]

@Zeka - As I've been focused on Jumplinks 2, I completely missed that you are declaring your wildcards incorrectly. {lg} is not a valid wildcard in Jumplinks 1, and so it is treated as a string literal. You need to add :segment to that in the source only, and it should work. So your new source would become:

{lg:segment}/products/{name}.html/

In Jumplinks 2, {lg} will be a valid wildcard, and will default to the [^/]+ regular expression.

Please try the above and let me know if it works. Thanks.

 

For reference, this is the result on my side:

404 Page Not Found
Checked Mon, 17 Oct 2016 18:06:32 +0200
Request: http://playground.local/fi/product/chair.html/
ProcessWire Version: 3.0.36

Scanning for jumplinks...

[Checking jumplink #2]
- Original Source Path:       products/{name}.html/
- After Smart Wildcards:      products/{name:segment}.html/
- Compiled Source Path:       products/([\w_-]+).html/

No match there...

[Checking jumplink #1]
- Original Source Path:       {lang:segment}/product/{name}.html/
- After Smart Wildcards:      {lang:segment}/product/{name:segment}.html/
- Compiled Source Path:       ([\w_-]+)/product/([\w_-]+).html/
- - Wildcard Check:           1> lang = fi -> fi
- - Wildcard Check:           2> name = chair -> chair
- Original Destination Path:  {lang}/products/{name}/
- Compiled Destination Path:  /fi/products/chair/

Match found! We'll do the following redirect (301, permanent) when Debug Mode has been turned off:

- From URL:                   http://playground.local/fi/product/chair.html/
- To URL:                     /fi/products/chair/

 

[k07n]

Hi!

I have a jumplink with wildcard:

source: index.php?id={id}
destination: {id|oldsiteid}

I don't know when (after PW3 update, or Jumplinks module update), but this jumplink stopped working,
site.com/index.id=123 just redirects to site.com now.

Any ideas why it's happens?

[Mike Rockett]

2 hours ago, k07n said:

Hi!

I have a jumplink with wildcard:

source: index.php?id={id}
destination: {id|oldsiteid}

I don't know when (after PW3 update, or Jumplinks module update), but this jumplink stopped working,
site.com/index.id=123 just redirects to site.com now.

Any ideas why it's happens?

These kinds of redirects become somewhat tricky as requesting index.php is the same as requesting the root of the site. I have worked around this, but it would still be better to do this via an htaccess redirect. Unfortunately, it would be mean two redirects as you are using a mapping collection.

Just after line 129 of your htaccess file (part 13, regarding "www"), add the following:

RewriteCond %{REQUEST_URI} ^\/index\.php [NC]
RewriteCond %{QUERY_STRING} ^id=(\d+) [NC]
RewriteRule ^ /index_php/%1? [R,L]

This will redirect, for example, /index.php?id=321 to /index_php/321.

Now, change your jumplink source to /index_php/{id}.

 

[k07n]

3 hours ago, Mike Rockett said:

These kinds of redirects become somewhat tricky as requesting index.php is the same as requesting the root of the site. I have worked around this, but it would still be better to do this via an htaccess redirect. Unfortunately, it would be mean two redirects as you are using a mapping collection.

Just after line 129 of your htaccess file (part 13, regarding "www"), add the following:

RewriteCond %{REQUEST_URI} ^\/index\.php [NC]
RewriteCond %{QUERY_STRING} ^id=(\d+) [NC]
RewriteRule ^ /index_php/%1? [R,L]

This will redirect, for example, /index.php?id=321 to /index_php/321.

Now, change your jumplink source to /index_php/{id}.

 

Thanks. I use nginx, but I get the idea.

[Peter Knight]

Hi @Mike Rockett

If I have 2 non ProcessWire files on my site and want to redirect A to B, will PW handle that for me?

I'm guessing not and that I need to manually edit their html or the .htaccess file?

Just assumed that they would be redirected as even though they're not PW pages, they're served up within a PW site.

[Mike Rockett]

Hi @Peter Knight

If they are served up in the PW site, then the 404 event won't take place, so Jumplinks won't even start the process at all.

mod_rewrite/mod_alias would be the most efficient in this simple scenario.

[tpr]

I tried to use "|" in the selector but didn't worked:

[[template=tutor|event,name={pagename}]]

Result:

domain.com/[[template=tutor%7Cevent,name=...]]

Using only "tutor" or "event" works fine though. Is this a bug or is this not supported? (v1.5)

Plus a question to v2: will it have a feature to add a name to each jumplink? That would make it easier to see what the jumplink does, e.g "Redirect old events to page Events". They would be even searchable using the browser search feature or with filterbox feature of AdminOnSteroids.

[Mike Rockett]

3 hours ago, tpr said:

I tried to use "|" in the selector but didn't worked

Sorry about that - more than likely an oversight on my end. Will review and see what can be done.

3 hours ago, tpr said:

will it have a feature to add a name to each jumplink?

When I began working on this module, naming support was present. In the first alphas, however, it was indicated that this was not the greatest idea, and so the feature was removed.

Jumplinks 2 uses Datatables with a filterbox. Most of the time, you would find that a name contains a keyword from either the source or the destination, and so you could enter that specific keyword into the filter box. Per your example, that title would have the keyword event in it - searching for that would yield pretty much the same result. As such, I don't plan on adding name support, especially considering the bulk it adds to the user interface.

[Mike Rockett]

@tpr I have pushed 1.5.44 which fixes the selectors issue.

[tpr]

Thanks, works like charm!

As for the names I trust your experience  Anyway, such names (descriptions?) wouldn't do so much harm to the UI.

[Mike Rockett]

9 minutes ago, tpr said:

Thanks, works like charm!

As for the names I trust your experience  Anyway, such names (descriptions?) wouldn't do so much harm to the UI.

Interestingly, that does look quite nice. I've emulated that with one row on the new design, and it would definitely need a little tweaking. My issue, though, is that the UI would like quite inconsistent, as you can tell, when some links have descriptions and others do not.

(Note: The Type column has not been finalised yet - there will be SVG icons there, as per previous screenshots.)

I know this is maybe not the perfect idea, but what about a tooltip? That way, it doesn't reduce the density of the table, and you can still easily see the description of a link if it is not easily understood.

[Macrura]

just chiming in.. wanted to +1 for the idea of names/descriptions;
and i would have no problem with the inconsistency of some not having descriptions.. hopefully it's not too much extra work (?)