module Jumplinks

[Mike Rockett]

Moar updates: Finished working on named types for parameters, which was the base param-type before ({name:type}). As you can see below, we're testing with {fileext:ext} which converts to the regex format for FastRoute to handle:

Request URI: string(12) "AboutUs.html"

Matched Jumplink Object: object(stdClass)#5 (4) {
  ["from"]=>
  string(113) "{page}.{fileext:aspx|asp|cfm|cgi|fcgi|dll|html|htm|shtml|shtm|jhtml|phtml|xhtm|xhtml|rbml|jspx|jsp|phps|php4|php}"
  ["to"]=>
  string(7) "{page}/"
  ["deepClean"]=>
  bool(true)
  ["origFrom"]=>
  string(20) "{page}.{fileext:ext}"
}

Captured Parameters: array(2) {
  ["page"]=>
  string(7) "AboutUs"
  ["fileext"]=>
  string(4) "html"
}

Parameter 'page' cleaned (deep = yes) from 'AboutUs' to 'about-us'

Compiled Destination: string(9) "about-us/"

Also notice the deepClean property of the Jumplink object: Instead of setting the old Enhanced Wildcard Cleaning in settings, this is now done on a per-jumplink basis (defaults to false).

Going to start working on aliasing (aka old smart wildcards) now. Aliases will convert, for example, {id} to {id:\d+}.

[Mike Rockett]

Aliasing is done now. As you can see from the "fromLog" (which logs changes to the "from" property), the original "from" contains a mix of a expression-based parameter and an aliased parameter, which then gets expanded to include the applicable parameter type, and then finally converted to the FastRoute-compatible regex.

Originally, I wanted to have aliases convert directly to the regex equivalents, but we convert from parameter types to their regex equivalents anyway, so no need to add an extra step.

I think I have everything sorted now - just need to start moving this into a freshly-baked module. Hopefully I can release a beta in the next week.

Edit: Completely forgot about destination selectors (even though I can only really implement these in the module itself). I'd thought about re-conceptualising these, but something tells me the current implementation is fine. Only thing worth considering for me is changing from double-parenthises to single.

Multi-language (feedback needed, please): I'd love some insight from those familiar with multi-lang setups on how I could possibly go about incorporating awareness into the module. The problem I see is that each multi-lang setup is different, and so it's impractical to implement a solution that only caters for one group of people, and I also think it's impractical to have too many solutions and bloat up the module. As such, feedback from anyone who has experience with the different kinds of multi-lang setups on how I could go about this would be most-appreciated.

(Sorry for all the test logs - just showing that it works in case there are any concerns/suggestions.)

Request URI: string(44) "blog/post.php?id=882991&title=This_is_a_test"

Matched Jumplink Object: object(stdClass)#2 (4) {
  ["from"]=>
  string(47) "blog/post.php?id={id:\d+}&title={title:[\w_-]+}"
  ["to"]=>
  string(26) "post/{title}/?ref=post.php"
  ["deepClean"]=>
  bool(false)
  ["fromLog"]=>
  array(3) {
    ["original"]=>
    string(39) "blog/post.php?id={id:\d+}&title={title}"
    ["alias_expansion"]=>
    string(47) "blog/post.php?id={id:\d+}&title={title:segment}"
    ["regex_conversion"]=>
    string(47) "blog/post.php?id={id:\d+}&title={title:[\w_-]+}"
  }
}

Captured Parameters: array(2) {
  ["id"]=>
  string(6) "882991"
  ["title"]=>
  string(14) "This_is_a_test"
}

Parameter 'title' cleaned (deep = no) from 'This_is_a_test' to 'this-is-a-test'

Compiled Destination: string(33) "post/this-is-a-test/?ref=post.php"

 

[Mike Rockett]

Right, so I've made a few more developments to my test-phase, and am now ready to begin porting this to a fresh module setup, which is going to be based on something I'd setup a while ago. I intend for it to run in namespaces (Jumplinks\Something\Etc) and use traits. It'll also make use of its own autoloader.

Now, I'm not sure if using my own autoloader is the correct approach. I see that both 2.8 and 3.0 have Composer support, but not sure on the Composer-based differences between the two - could someone enlighten me on that?

Also, I assume I can work on the module in 2.8 only and it will be fine in 3.0? The only difference is the fact that 2.8 doesn't use the ProcessWire namespace, right?

[LostKobrakai]

1 hour ago, Mike Rockett said:

Now, I'm not sure if using my own autoloader is the correct approach. I see that both 2.8 and 3.0 have Composer support, but not sure on the Composer-based differences between the two - could someone enlighten me on that?

Also, I assume I can work on the module in 2.8 only and it will be fine in 3.0? The only difference is the fact that 2.8 doesn't use the ProcessWire namespace, right?

I would not necessarily rely on composer being installed. But you can use the new psr-4 classloader of processwire, which is shipping with 2.8/3.0.

$classLoader->addNamespace('MyNamespace', $config->paths->templates . "includes/");

And if you want your module to work in both 2.8 and 3.0 simply do not use the ProcessWire namespace, which will be dynamically injected by the module/template compiler in 3.0.

[Mike Rockett]

@LostKobrakai - Thanks, that clears things up for me. So now, the new module will be making use of a Composer-package dependency. As you say I shouldn't necessarily rely on Composer being installed, should I go ahead and use my own Composer setup in the module directory itself?

[LostKobrakai]

If you have a composer dependency than go ahead and use composer. I'd just not use it just as the autoloader.

[Mike Rockett]

Hi All - I've merged the previous 1.5.3-dev to master. Please let me know if you encounter any problems, and I'll patch them up as soon as I can.

Development on JL2 is going quite well - busy organising a good OOP structure for the module.

[bernhard]

hi mike,

just wanted to say a big thank you! installed it today on a relaunched site and it works great!

awesome module, awesome docs!

[Mike Rockett]

@bernhard - You're most welcome

[Sergio]

Mike, I'll be doing some tests on my multi language install (that one we talk about in the earlier posts) but I'm afraid I can only start it in one week or so because of my other projects. But I'll let you know. 

[Mike Rockett]

@Sérgio - No problem. 1.5.3 will be the last of the 1.x range - hotfixes will increment the revision by one: 1.5.31, 1.5.32, etc. I'm going to put more focus on multi-lang in v2.

Edit: Seems I didn't make a note of this somewhere, and have proceed to bump to 1.5.4. Will continue on 1.5.41, etc.

[bernhard]

also a little feature request: what do you think of adding a "create copy" button so one could easily add new jumplinks based on existing ones?

[Mike Rockett]

1 hour ago, bernhard said:

also a little feature request: what do you think of adding a "create copy" button so one could easily add new jumplinks based on existing ones?

I think that might be heading towards feature overload... Could you perhaps give an example of what kinds of jumplinks would need to be copied? I can't really imagine a situation where you would need to do this.

[Mike Rockett]

Okay, so I've done a little thinking about multi-lang, and have realised that this could get quite complex, depending on the language setup of both the old and new sites. I'd like to find the simplest path that accomodates as many situations as possible.

As such, please would everyone interested in support for this feature provide me with their use-cases (other than what is mentioned below)? I'll need the following details:

1. Source URI Example (from old site)
2. Source Jumplink you would like to use
3. Destination URI Example (expected URI on new site)
4. Destination Jumplink you would like to use (not after conversion to page:n, but as you entered it into the entity editor)
5. If the Destination Jumplink does not contain parameters (wildcards), does the resulting Page exist in the Page Tree?

I can imagine that multi-lang awareness needs to only apply to jumplinks with destinations that do not have wildcards - for example: /de/seite/. In that situation, Jumplinks would convert it to page:123, for example, but would then be converted to /en/page/. We could implement a solution by passing a {lang:code} parameter to this so that when the module runs a $pages->get(...), it would also check to see if the page is available in the specified language using $page->viewable($lang) and $page->localUrl($lang).

• Example: Source: /{lang:de}/Seite.html Destination: /de/seite/ Saved Destination: page:123
• User requests /de/Seite.html and is redirected to /de/seite/ via $page->viewable('de') and $page->localUrl('de'), where 'de' is obtained from the special language parameter. If the page is not viewable in German, then the module would simply redirect to the default url.

We would also use this implementation for the use-case @Sérgio presented with regards to destination selectors. The {lang:code} would not be passed to the selector itself, but would rather be checked automatically due to the presence of that parameter.

• Example: Source: /{lang:pt}/books/book-details/{id} [Saved] Destination: [[template=books, wpid={id}]]
• User requests /pt/books/book-details/25 and is redirected to /pt/books/title-of-the-book/ via the same methods mentioned above after the page itself is selected using the provided selector.

In both examples, we could simplify the language parameter to include all languages known to the system by simply using {lang}, without the specific language. This should cover both /something and /en/something, for example.

Everything else could well be handled by existing features, I am sure.

(Guys, note that I still haven't played around with multi-lang yet, and so all of this is coming from information provided in previous posts. If you think I've missed the ball in any way, please do let me know.)

[Mike Rockett]

Todo list up: https://github.com/rockettpw/jumplinks/issues/14

[Mike Rockett]

Bumped to current master to 1.5.4, fixing a potential security issue.

[palacios000]

Hi, great module! I have a problem writing redirects, I am following documentation but still I can't make it work.

le_stampanti_a_noleggio/?m={all}

should go to

noleggio-stampanti/{all}

Is there something wrong with this settings?  Here attached the debug output.

PW 2.6.1 with Jumplinks 1.5.4

Thanks a lot!

[Mike Rockett]

@palacios000 - Thanks for bringing that to my attention. It appears to be a bug that seeped in from a previous change. In the early days, making trailing slashes optional involved setting them like this: [?]

However, I wanted to retain the regex format for this, and so enabled a workaround that allowed us to do this: /?

But, I didn't think about query strings after a trailing slash, and so I did not make it check for the regex optional format only at the end of the source string.

Will patch this shortly and bump to 1.5.41.

[Mike Rockett]

Bumped to 1.5.41 with a workaround that only allows the use of /? at the end of a source string. As JL2 is in development, trailing slashes will be dealt with differently (provided I can fix the FastRoute implementation this is now fixed, and I'm not sure how I fixed it).

Edited August 28, 2016 by Mike Rockett

[Mike Rockett]

Busy working on module configuration, and some questions have popped up regarding the way in which we should work with permanent and temporary redirects. I'd like to change the process to this:

1. When creating a new jumplink, we set the 'from' and 'to' fields as normal.
2. Then, a 'redirect type' field can be used to choose between permanent and temporary redirects.
   1. If permanent is selected, timed filtering will not be available for the jumplink, and it will redirect with HTTP status code 301.
      1. I also think that the jumplink should be completely locked if this option is selected - to the extent that the jumplink may only be deleted (which should only be done when the module has picked up that it is stale, having had no hits in the last 60 days). Not 100% sure about this, but I do like the idea. (Note: a warning would be displayed before saving if this option is selected.)
   2. If temporary is selected, then timed filtering will be made available, and it will redirect with HTTP status code 302, even if a start/end time is not specified. This will be the default option.

I'll also be implementing destination validation, which will be turned off by default. When enabled, this feature will first check to see that the resource we're redirecting to returns either of the following status codes: 200, 301, 302. We could then also turn on strict validation to ensure that the only return code allowed is 200 - this prevents the possibility of infinite redirects my simply not allowing them at all. I could go ahead and use curl to check for infinite loops, but I think that brings about some unnecessary overhead...

With the current 1.5.x branch, the module automatically uses 301 if timed activation (now known as timed filtering) is not enabled.

Thoughts, please.

[szabesz]

1 hour ago, Mike Rockett said:

permanent jumplink may only be deleted

I haven't yet used the module, but I'm sure sooner or later I will, so I thought I should I share what I think about this part of your question. Personally as the developer/superuser I need the possibility to edit anything that generally does not break the site. Since this is not such a feature, I think only non-superusers should be restricted, but even this restriction could be optionally disabled by the superuser, at least for a given user role specified by the dev/superuser.

Lots of small sites use at least three user role/group levels: Superuser-Editor-Guest where superuser is often the developer itself, and editor is the client. At least, this is the case with most of my sites. My clients do not want to touch things that might break the site, so they ask me to "hide" those settings.

[ceberlin]

Not sure a restriction has the intended effect.

There are 2 cases where I regularly delete links when they are still valid:

• when I detect a double entry (or they are part of a rule already)
• when I see that I can replace a bunch of manually set links with a rule

What about 307 redirects?

I like the idea of a destination validation. If an infinite loop (or a redirect to another redirect within the same module) is detected it would be great to have some tool to monitor and eventually fix the problem.

[Mike Rockett]

@szabesz - Hmm, interesting idea. So it would be a case of allowing certain roles to modify permanent redirects. The only real reason this has come up is due to the relevant standards, which are not often adhered to. However, considering browsers don't adhere to half of the status code standards (I'm sure there are good reasons for it), perhaps I should just leave the restrictions off altogether - at the end of the day, if you want a 301, you're doing it for a reason, and you more than likely won't make too many changes to it...

@ceberlin - The only real difference between 302 and 307, the way I see it, is how HTTP methods can change when redirecting. For example, with 307, and as I understand it, changing from GET to POST requires user intervention. For the purposes of this module and its general use, I think we can stick to 302 (unless I'm missing something). Regarding validation, my intention is to keep it simple and only check for either 200, 301, 302 or just 200 (strict mode). If the former is enabled and a 301/302 is returned, Jumplinks won't check to see if that redirects to another redirect, and so on.

[ceberlin]

I am fine with that, I just heard 307 mentioned in the context of Google and the new "Strict Transport Security" feature (without understanding every detail of it).

That's ok with the loop detection. There are other tools to dig further. It would be just convenience, a redirect problem had driven me nuts recently.

[Mike Rockett]

Carry-over from here:

@POWERFULHORSE - Sorry to see that error came up, as we have had problems with timestamp fields in the past.
What version of MySQL are you running? There is quite a difference between 5.6 and 5.7, but understood that this problem was fixed.

Also note that (as you'll see in the posts above), Jumplinks 2 is in development, and it uses Laravel's Eloquent for database interactions. Makes it somewhat more manageable in terms of table schemas (and a whole bunch of other goodies).