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.

@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?

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?

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"

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+}.

Small update from my side: I'm busy testing all of this out in a simple PHP script that imports FastRoute - so far, so good! For the purposes of better understanding and correct approach, I'd like to also change the mapping collection syntax from: {variable_name|collection_name} to: {collection_name(variable_name)} I did want to use square parenthises, but I'd like to try and not conflict with FastRoute's optional params. (Edit: Sorry, my mistake - FastRoute has nothing to do with destinations. I might switch back to pipes anyway... Not sure I like this format.) Thoughts? Update: Here's some testing output at the current stage: Request URI: string(25) "/page.php?id=2&category=1" Matched Jumplink Object: object(stdClass)#2 (2) { ["from"]=> string(47) "/page.php?id={page:\d+}&category={category:\d+}" ["to"]=> string(41) "/{categories(category)}/{page_ids(page)}/" } Captured Parameters: array(2) { ["page"]=> string(1) "2" ["category"]=> string(1) "1" } Identified Collection Item from page_ids: array(1) { [2]=> string(8) "about-us" } Identified Collection Item from categories: array(1) { [1]=> string(7) "company" } Compiled Destination: string(18) "/company/about-us/"

Hi everyone, very sorry for the delays - as you may know, I've been too busy of late to attend to Jumplinks 2. I'm making time as a go along, and would like to briefly discuss the current work taking place. I may or may not have mentioned that I'd like the new Jumplinks to be powered by FastRoute. This improves processing time by quite a bit (haven't measured, but there is far less preg_* going on) and makes development somewhat easier. By using it, however, the syntax for each jumplink would change; but I believe this to be a good thing. As you well know, Jumplinks currently uses the {name:type} base syntax, where type is optional (this invokes smart wildcards). By moving to FastRoute, the base syntax would change to {name} only, which catches [^/]+ by default. That regex is typically used in an MVC framework context, and so may not be completely suitable for the purposes of this module - as such, I am sure this can be changed by overriding the RouteParser (we can default to what is currently used for the segment any type: [\w_-]+[\w.-_%\=\]+). Then, the concept of smart wildcards would disappear, and you would be able to specify your own expressions instead - this is done in the format {name:<exp>}, where <exp> is the expression you would normally use inside of a regex capture group, such as [a-z0-9]+. However, we could add support for aliasing expressions so that the module behaves the same way as it currently does, by silently converting the aliases to their respective expressions, but also allowing more complex expressions to be used. (Note that I chose FastRoute as its syntax closely matches the current Jumplinks syntax, and allows for greater flexibility.) Before Jumplinks 2 is launched, the current dev branch (which will then be moved to master) will be updated to include a JSON/CSV exporter to the Jumplinks 2 format. As an example, the exporter will automatically convert {page:segment} to {page:[\w_-]+}. However, if we choose to use the wildcard type aliasing (discussed above), then this exporter need only export the data on an as-is basis. Note: Due to Jumplinks 2 development, all new features requested by the community will not be added to v1, but will be implemented in v2 instead. It will, however, be easy to migrate from v1 to v2 in order to use those features. I also plan on making v2 compatible with only ProcessWire 2.8 and 3.0, and Mapping Collections will still be supported. I'm writing about this now so that we can discuss it - I'd appreciate your thoughts on the change, which I think is beneficial to the module going forward. (I hope everyone is doing well - haven't been around often enough to see new modules and some of the new progress on PW3; but getting there slowly.) Update: I forgot to mention that FastRoute also allows for optional segments which allows us to jump from, say, /page.php?parent={parent}[&child={child}] to either, say, /{parent}/{child}/ or /{parent}/, depending on the input. Sure, I don't see a wide variety of use-cases for this feature, but I'm sure it'll come in handy to some.

Very nice work, @bcartier! Nice to see an admin theme come out of those concepts, and awesome to see the new logo in action. Great work!

@David Karich - Thanks. I've committed your fix to the dev branch and commented. @OllieMackJames - This could very well be the fix you need. Please would you test it as well?

@tpr - Thanks, glad you like it. I have started building Jumplinks 2 from the ground up, but haven't had the time to continue work on it of late. With regards to the state-toggle: I can implement this feature, but it would be turned off by default. That said, if the feature gets enabled, the jumplinks would all be created to redirect with status code 302/307 (actuallly not 100% sure which one is better). That said, is isn't necessary to do so, but not doing so would mean going against the intention of the different HTTP codes. As for previews: these can be somewhat difficult, giving consideration to parameters - I think I may have brought this up before here. It would be easy to preview jumplinks that don't have parameters, but those that do have them would need user input in order to test. This is all on my to-do list for the new module, which will be compatible with both PW 2.8 and 3.0.

@OllieMackJames - Very odd. Let me look at this over the weekend. I won't have time today. Will let you know what I find.

@OllieMackJames - Sorry, I had a typo there. Meant to ask what happens when you manually go to the URL with id=19, the same URL that appears when you hover over a link. Nonetheless, I think there is a problem, as going to id=1 should edit the first jumplink you created. if id=0, then the module should create a new jupmlink. To be clear, if you navigate to /pwire/setup/jumplinks/entity/?id=19, do you get to the Register New Jumplink page, and does the URL change? And lastly, what version of PHP are you running? Is anyone else experiencing this problem?

With the re-brand, this will be more important when the new site is launched.

@adrian - I must say, I like the fact that we finally have a mentions system. No need to quote all the time and bloat up threads.

@pwired - That isn't happening on my side; also using Firefox...

Hi Ollie, I'm not able to test right now due to a server upgrade. That said, please can you check what link shows up in the status bar when you hover over a source? Also, what happens when you navigate to <admin>/setup/jumplinks/entity/?id=1 manually?

Weird indeed. Perhaps you could remove the QSD and add a question mark to the rule: RewriteRule ^$ /_redirect/%1/? [R=302,L] Both do the same thing (so far as I know), but not sure if one is deprecated...

Could you perhaps check your apache logs? That syntax is valid, and works on my system. Also, where exactly did you place the rule? It should be directly below RewriteEngine On. That condition and rule does remove the question mark, but it also adds _redirect to the beginning. You could also just strip out that part, and use this: RewriteRule ^$ /%1/ [QSD,R=302,L]

Right, of course! Silly me... When requesting /?something, it's actually a request to the home page, which exists. Because it exists, Jumplinks can't touch it. So you'll need to use htaccess for these. Place the code block below directy underneath RewriteEngine On. RewriteCond %{QUERY_STRING} ^lhre_Ansprechpartner/?$ [NC] RewriteRule ^$ /ihre-ansprechpartner/ [QSD,R=302,L] You'll need to do this for each redirect you want. Alternative using Jumplinks: If you want to do this in one fowl sweep using Jumplinks, then you only need to do the following: Instead of the above condition and rule for each URI, use this only: RewriteCond %{QUERY_STRING} ^(\w+)/?$ RewriteRule ^$ /_redirect/%1/ [QSD,R=302,L] Then create a jumplink with the following: Source: _redirect/{path}/? Destination: {path}/ Now, requesting domain.com/?lhre_Ansprechpartner/ will first redirect to domain.com/_redirect/lhre_Ansprechpartner/ and then Jumplinks will convert that to domain.com/lhre-ansprechpartner/. Please let me know if that works. Edit: I see that your destination URLs differ. So instead of using the {path} wildcard, just create the jumplinks using the format shown above. So for the first one, the source would be _redirect/lhre_Ansprechpartner/? and the destination would be lhre-ansprechpartner/.

Hi Makari, Being the developer of Jumplinks, I haven't used ProcessRedirects in a long time, so not sure if it supports query strings, but Jumplinks does. Once installed, the redirects above should work just fine for you. Jumplinks is, in fact, quite simple, but may come across a little more complicated because it has more features and more options to choose from. That said, you can use Jumplinks the same way you would use ProcessRedirects. Just create a new Jumplink, and specify the Source URI and Destination URI/URL/Page. Please give it a try and let me know if it works for you. Note that this could also be done with htaccess and mod_rewrite, but you don't want to get caught in the position where the htaccess file gets updated by ProcessWire and your redirects disappear.

Even feels somewhat faster here in SA. Awesome! That said, it'll more than likely load faster once our Fibre is enabled next week - currently using wireless broadband, which is a tad slow where I live.

I see - though, I admit: I'm pretty new to debug/profiling tools myself. It's quite simple, and I quite like XDebug, which is essentially a PHP extension that can profile your code as and when it is executed. It simply output the data to a file, which can then be opened using a client app. I'll continue work on Jumplinks 2 as soon as I can. There are already performance boosts in terms of PW3 and the new module structure. Also, I think I'd like for the module to make use of SQL statements that limit what is returned - that way, it doesn't have to loop through large sets of data. Lots of work ahead of me...

Hi laban, Thanks for the insight on this - this is the first I'm hearing of Jumplinks running on a large site. Jumplinks wasn't built for large sites - in fact, it wasn't something that crossed my mind when building it. That said, it does seem a little strange that this is happening. The only thing I think could slow it down is the multiple regex routines that the module makes use of - there are quite a lot, if you have a look at the code. Without saying much more, I would be very interested to see a Blackfire/XDebug dump of this - perhaps I may be able to look into the details and speed up the new module. If you could do that for me, I'd be most grateful. Unfortunately, I haven't been pyaing attention to the module of late - many other things on the plate at the moment. That said, I'm sure I'll be getting back into it soon with some new sites in the pipeline. Thanks, Mike

Right, I see. Haven't worked on/with the module for a while, so forgot that it stores the Page ID when the hard-coded URI exists as a Page. The issue here is that I'm not experienced with regards to multi-lang sites. Do multi-lang pages share the same ID? So 1234 would represent both the English and German pages... No?

Hi kixe - are you saying that if the module isn't storing the paths ID (page:id) in the database, but rather redirecting to its hardcoded URI, then it automatically redirects again to that same page in the correct language? (Forgive me if I've misunderstood... Also, not able to test right now - can only do so later today.) I see - muct be an oversight on my side. Will try sort out a fix this afternoon (SAST)