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.

The Wikipedia log shows that the page was previously deleted and restored, but there is no deletion log for this disappearance. So the only thing I can think of (and I don't know how Wikipedia works) is that the page was unpublished for editing, to be re-published at a later stage. To me, that doesn't make too much sense unless, perhaps, multiple members of the community are working on the page (however, there is no Talk page).

Indeed it will - but the plate has been filled once again, and haven't had a chance to do the refactoring mentioned on the roadmap before I continue with features. The composer issue kinda messed things up for me. Sorry for the delays...

Very nice site indeed. My only issue is with regards to the floating blocks - they float over the text, which means I have to scroll very specifically for the block to move past the text, but not so much that the text scrolls out of view. This would be less prominent on a 1080p screen, but more prominent on a common 1366x768 screen. Other that that, it's very well composed and designed.

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

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

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.

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

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

Yeah, we should just default to whatever ext uses.

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. Also true... Perhaps I should then default it to the ext parameter type then?

@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})...?

https://getuikit.com/docs/uikit3.html I like what I see.

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.

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

@Zeka - Great! Glad it worked. I just can't figure out why the schema tracker didn't update before. You don't remember any strange errors popping up (other than the ones you've already seen) at any point, do you? I'd assume this is an edge-case, meaning that it doesn't happen very often, but I would love to be able to find out why it happened.

@Zeka - I'm afraid I'm not getting any errors on this side; everything is running smoothly as expected. I assume that something went wrong during a schema upgrade (which happens when you install the module the first time, or when it is upgraded), and this prevented the schema version tracker from being updated. The safest bet would be to delete the last_hit column from the process_jumplinks table using whichever database admin tool you have on your server (phpMyAdmin, I'd assume). Then simply refresh the admin interface or request about-us.html again and the schema should update. Alternatively, I'd be happy to have a look at your database, if you'd prefer.

@Zeka - I see - let me quickly test this out on 3.0.35 and see what happens.

That's the one! Haha, totally didn't even know which one it was!

@Zeka - I can't remember if it was Admin On Steroids or Module Toolkit... But I doubt you are using either of those - otherwise you would have known if it was disabled or not. Please turn on debug mode in Jumplinks' config and request about-us.html again - you'll be shown a debug-log which you can then paste into this thread so I can review it. Thanks

Very nice indeed, and very quick. I admit, I have a very fast internet connection, but it even loads nice and quick from the US to here in SA and overall it feels quite snappy. Well done!

@Zeka - Thanks for reporting this. Unfortunately, I haven't allocated some time to see if Jumplinks is compatible with the new PW3 master - it was tested on earlier builds. That said, I still don't understand why this could be happening. The only thing that springs to mind is a possible conflict with another module. I'm not sure which module it is, but I think there is a module that allows you to disable (not uninstall) other modules. Are you perhaps using any of those? If not, mind sharing the source and destination of the jumplink to see what the problem could be? I'm busy with a client project at the moment, but will try test the module on the latest PW3 master in a few hours.

It's relative to the domain root, as far as I know. Have never actually tested in subdomain scenarios.

@Robin S - Thanks for the heads-up on that issue, wasn't aware of it. In my case, the layout is they way it is because of the clients wishes. That said, client uses Chrome, and has no problems. So I'll just switch over to Chrome (ungoogled-chromium, ahem) when working on this particular site.

No plugins. Using a default Firefox install. And no third-party PW modules are installed either. So that must be the problem then. Chrome seems to be fine.