Mike Rockett

Any time ? I've rolled out 1.5.57 with a fix, so you should be good to go without the {!all}, which is somewhat unsafe IMO.

@adrian Ok so this seems to be the wildcard cleaner. Because {all} is the equivalent of .*, it includes the query string in this case and therefore cleans it like a normal wildcard. The only option for the time being is to disable cleaning of {all}, by changing it to {!all} in the destination. I know it's not perfect, but JL doesn't actually handle query strings very well – they should actually be handled separately somehow. Edit: I'm actually going to see if I can update the cleaner to prevent query string character cleaning.

Ah of course - didn't click that it would be the same as the previous query ? ? Ok I'm able to reproduce, will investigate

Going to have to spin this up and see what's going on. Mind sharing your source/destination with me? Sorry, I edited that post as you were replying

@adrian I wonder if database->escape_string is playing a role here? I think I'm doing it differently in JL2, but that's nowhere near done in terms of a frontend. ? Scratch that, it's being used in the importer. Long day I tell you

Hey @adrian Super odd, that. Will take a look.

@adrian — Glad you're all sorted there ?

@adrian Page identifiers were never intended to be used as part of a destination. These identifiers use the full, absolute URL of the page being identified. Perhaps destination selectors could come in handy here? Haven't ever tried it this way before, but I imagine redirecting subscribe/{all} to [[1495]]{all} (or [[1495]]/{all}} if trailing slashes are turned off) would work. Anything inside the square braces is passed to pages->get and replaced with page->url, which is why I believe this will work.

Thanks @teppo – have reviewed and merged in with some minor UI/textual adjustments to the config. Tested it too, works great! ?

@teppo Quick follow-up on your merge request, unless you'd like me to take care of it? ?

@apeisa I think I'll take the trimming option here, for now. I have been doing incremental work on JL2 in my very short-lived spare-time, and will be using a text column for referrers in the hits table. I'm deciding whether or not the 404 monitor should still be a separate module like I'd originally intended - still makes more sense to me, but either way, the same column type will be used there.

@Ben Sayers This could indicate that something's wrong with your blog setup. To clarify, are you deleting posts or un-publishing them? Either way, whatever is going on here is preventing the 404 event from kicking in, which means Jumplinks has nothing to do. When it comes to common patterns like this (ie, "blog/*"), the only things that come to mind are urlSegments and custom htaccess directives, both of which I suspect are not the case for you. Worst case, I would try reproducing on a fresh install. On a side note: I don't know ProCache very well, but could it possibly be that?

Ah ok, thanks for the clarification there. Guess the optimist in me was hanging around ? Good to know - thanks!

@wbmnfktr - Hence why I'm needing some more info – not sure if any additional composer support has been added. Would be great if I could trigger an install during module install from the UI. ?

I'd also like to drop support for ProcessWire 2.8. Any objections?

@teppo - in regards to Jumplinks 2 and composer support: the module utilises several composer packages, which at present are kept in the vendor directory of the module, part of source control. Just to be 100% sure, if I were to drop this from source control, this would force users to install via composer? If so, I'd need to leave it in there, unless you know of another way ? @all - I'm putting some time aside today to continue working on Jumplinks 2 – specifically frontend stuff. I'm cool with sticking to the usage of jQuery for the time being, though I imagine at some point I would move over to something like Svelte. No point in doing it now though, as pretty much all of the functionality I need (excluding bulk actions) has already been implemented. On the topic of dependencies, I'm feeling inclined to push the minimum PHP version to the one that still has active security support, which at this point is PHP 7.1. In my experience, it's always been best to only support maintained versions of PHP. This also allows me to bump illuminate/database from 5.4 to 5.8 (I imagine there are a bunch of fixes). I don't know what the implications of this are in terms of the various hosting providers people use, but I'd be quite shocked if providers were only supporting unmaintained versions of PHP.

These columns are sorted in 1.5.56. However, instead of text, I've gone with varchar(512), which should be more than long enough. :)

Hey @teppo – no problem at all ?Probably a very good idea; happy for you to submit a merge request. Thanks!

1.5.55 is released :)

I've pushed up to the master branch but won't release until I have an opportunity to test later this afternoon (SAST). :)

Thanks @apeisa I'll need to add in a schema update to change the column to text. Really wish I could find the time to continue work on v2 – the minute I find a gap, something comes up. :|

@Tiffany - I think this is a caching issue. If I recall correctly, you can go into the module config for PageRender and clear it from there.

@entschleunigung That's correct - it doesn't give consideration to multi language. That said, /en/old/page should throw a 404, and so the redirect should still take place...

@entschleunigung To make sure that jumplinks is working, go into the module settings and turn on debug mode. When you hit the old URL, you should see a log from the module, showing what it's doing. Feel free to post that log here so we can take a look :)

@Lance O. Looks like it could well be a case sensitivity issue with the license field, where yours is using an upper case "L", it is actually expecting it in lowercase. Are you able to rename the field and try again? Whether or not that fixes it, I'll need to push an update that converts the casing appropriately.