Jump to content

Mike Rockett

Members
  • Content Count

    1,378
  • Joined

  • Last visited

  • Days Won

    9

Posts posted by Mike Rockett


  1. 3 minutes ago, adrian said:

    You're a legend - thank you - works perfectly!

    You're welcome. JL2 (when I get there 🙈) will give some more control here. This case would be covered by subscribe/{path} --> @[1495]/{path}, and then there'd either be a {query} wildcard or an option on the jumplink itself to automatically carry it over.

    • Like 1

  2. 3 minutes ago, adrian said:

    Thanks @Mike Rockett - the {!all} does the trick, but thanks for looking into updating the cleaner!

    Thanks for the superfast response!

    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.

    • Like 1

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

    • Like 1

  4. 4 minutes ago, adrian said:

    Source: subscribe/{all}
    Destination: [[1495]]{all}

    Ah of course - didn't click that it would be the same as the previous query 🙈 😆

    Ok I'm able to reproduce, will investigate

    • Like 1

  5. 3 minutes ago, adrian said:

    Thanks very much - let me know if you have any trouble reproducing.

    Going to have to spin this up and see what's going on. Mind sharing your source/destination with me?

    Just now, adrian said:

    I just removed all those calls and it doesn't seem to be coming from them as it didn't help.

    Sorry, I edited that post as you were replying

    • Like 1

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


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

    • Like 1

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


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


  10. 5 minutes ago, teppo said:

    Sorry, I've got nothing for this. At this point my suggestion would be to keep those packages in the repository. It's the only way that works seamlessly with the module installer in Admin, and I believe it makes more sense for your module than any of the alternatives I can think of. Anything else would reduce your potential user base significantly.

    Ah ok, thanks for the clarification there. Guess the optimist in me was hanging around 🙂

    6 minutes ago, teppo said:

    Go for it! I've been putting out PHP 7.1+ content for a while now, and so far no complaints.

    Good to know - thanks!


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


  12. @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 :)

×
×
  • Create New...