module Jumplinks

[Mike Rockett]

@Peter Knight Hi Peter – the module won't clear out 404 history automatically, I'm afraid. You'll need to continue doing this manually every now and then.

[Peter Knight]

  On 9/4/2021 at 9:48 AM, Mike Rockett said:

@Peter Knight Hi Peter – the module won't clear out 404 history automatically, I'm afraid. You'll need to continue doing this manually every now and then.

Expand  

Hi Mike.

Thanks. Will do.

[Peter Knight]

@Mike Rockett

I'm getting an error on an install as follows:
 

  Quote

Failed to init module: ProcessJumplinks - SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'last_hit'

Expand  

It only affects the admin/back-end but wondered if there was a sensible way to fix?

The only change I made recently to the Module was to stop logging 404 errors and possibly an upgrade of the Module too.

Many thanks

 

 

[Mike Rockett]

@Peter Knight - That's odd, I was quite sure this bug was fixed. Internally, the module stores a schema version and then it does a comparison to see if an update is required. So if it is adding this column again, it means the stored schema version went out of sync. Could you check the database to see what the _schemaVersion is set to? Not sure which table it is, but it should be relatively simple to find.

[adrian]

Hi @Mike Rockett - I know you're not around much these days, but I just had this exception:

Obviously that's a weird request for mysite.com/? but it would still be nice if this was handled better. Not sure if you want to change the request_uri field to utf8mb4 so it can store these, or if you want to sanitize it somehow?

Let me know if you need more details.

Thanks.

[wbmnfktr]

Just a heads-up here...

Had to add {all}script{all} as there were issues with some recent requests containing those.
For now this works wonders. 

[Mike Rockett]

@adrian Thanks, I'm surprised I didn't cover this (thinking back, I thought I did). Will take a look-see as soon as I can. The idea is that it should support it - because it is valid.

@wbmnfktr Noted, I've replied to your DM.

[Peter Knight]

  On 10/15/2021 at 3:33 PM, Mike Rockett said:

@Peter Knight - That's odd, I was quite sure this bug was fixed. Internally, the module stores a schema version and then it does a comparison to see if an update is required. So if it is adding this column again, it means the stored schema version went out of sync. Could you check the database to see what the _schemaVersion is set to? Not sure which table it is, but it should be relatively simple to find.

Expand  

Hi @Mike Rockett

My SchemaVersion is set to 4

{"schemaVersion":4,"wildcardCleaning":"fullClean","enhancedWildcardCleaning":"","legacyDomain":"","statusCodes":"200 301 302","enable404Monitor":"","moduleDebug":"","redirectsImported":true,"moduleDisable":"","_schemaVersion":2}

 

[DV-JF]

PHP 8.2 Deprecated Warnings

Hey when using with PHP 8.2.6 I get some warnings:

25× 	
PHP Deprecated: htmlentities(): Passing null to parameter #1 ($string) of type string is deprecated in .../modules/ProcessJumplinks/ProcessJumplinks.module.php:1131

13× 	
PHP Deprecated: htmlentities(): Passing null to parameter #1 ($string) of type string is deprecated in .../modules/ProcessJumplinks/ProcessJumplinks.module.php:1130

1× 	
PHP Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in .../modules/ProcessJumplinks/Classes/ParseUserAgent.php:169

Any chance that you could @Mike Rockett update the module?

Cheers Jens alias DV-JF

[Mike Rockett]

@DV-JF Thanks for reporting. 1.5.62 released with fixes. Please test and let me know if all's good.

[ceberlin]

  On 11/24/2023 at 5:11 AM, Mike Rockett said:

@DV-JF Thanks for reporting. 1.5.62 released with fixes. Please test and let me know if all's good.

Expand  

shows still as "version": "1.5.61" after the update?

[Mike Rockett]

  On 11/24/2023 at 9:11 AM, ceberlin said:

shows still as "version": "1.5.61" after the update?

Expand  

Thanks – completely forgot about the info.json file. Bumping to 1.5.63 to remedy it.

[adrian]

Hi @Mike Rockett - brand new issue with the latest version: 

PHP Deprecated: ltrim(): Passing null to parameter #1 ($string) of type string is deprecated in ProcessJumplinks.module.php:206

EDIT: I see that line hasn't changed recently, but I've never seen the error before on the same server with no recent PHP upgrades. Regardless, it still needs a fix please and thanks.

[Mike Rockett]

Hi @adrian – very odd as $_SERVER['REQUEST_URI'] should never be null. Perhaps something is unsetting it? Imo, Jumplinks should actually be throwing a hard exception in this case.

[adrian]

@Mike Rockett - sorry, I should have come with more details - looks like it's happening from a cron executed PHP script that bootstraps PW. That would explain why it's null.

I'm not sure why it's a new error though - on a quick scan I can't see anything from your most recent commit that would cause this change.

[Mike Rockett]

@adrian The only thing I can think of is an upgrade to PHP 8.1, as that's the only thing that can cause it. I guess I'd need to find a way to have the module not do anything when being executed via the CLI...

[Mike Rockett]

Guessing this should do the trick…?

[adrian]

  On 11/30/2023 at 10:05 AM, Mike Rockett said:

The only thing I can think of is an upgrade to PHP 8.1, as that's the only thing that can cause it.

Expand  

That would make sense, except I have been running 8.2 on that server for many months and the error started appearing immediately after updating Jumplinks from 1.5.61 to 1.5.63.

  On 11/30/2023 at 10:09 AM, Mike Rockett said:

Guessing this should do the trick…?

Expand  

Yep, that should work just fine.

Just a little FYI about something I have noticed in the past - sometimes $_SERVER['REQUEST_URI'] returns false rather than the URL or NULL (https://github.com/nette/tracy/issues/351) which means checks need to consider that. Obviously not relevant given your CLI check.

PS - thanks so much for continuing to support your modules even though you're no longer using PW - very generous indeed.

[Mike Rockett]

@adrian – I've released 1.5.64 which adds the safety net around CLI usage (as a general rule) and request_uri. Please let me know if that solves it.

[adrian]

  On 11/30/2023 at 11:12 AM, Mike Rockett said:

@adrian – I've released 1.5.64 which adds the safety net around CLI usage (as a general rule) and request_uri. Please let me know if that solves it.

Expand  

Thanks - that has taken care of things. I actually think there are lots of modules that get loaded via CLI scripts even though they aren't needed. I kinda think PW should have a module autoload option for this to make it easier / more obvious to the developer to disable via CLI unless needed.

[sebibu]

Hi @Mike Rockett!
I Just noticed, that you are unfortunately no longer really active here.

3 weeks ago I created an issue after using your valuable module and having issues with encoded special characters:
https://gitlab.com/rockettpw/seo/jumplinks-one/-/issues/5

Is there perhaps a chance that you could take a look at it?

Thanks in advance! 🙏👋

[wbmnfktr]

Not 100% sure but isn't this the default behaviour of browsers or maybe even the web server to encode umlauts/special characters?

I know we can enable them in ProcessWire itself and use them in page names but not sure this would change the behaviour in Jumplinks as well.

For the time being you could at these to the redirects. How often do you experience these kind of URLs?

[sebibu]

Hey @wbmnfktr, thx for taking the time!

  On 3/1/2025 at 9:46 PM, wbmnfktr said:

Not 100% sure but isn't this the default behaviour of browsers or maybe even the web server to encode umlauts/special characters?
I know we can enable them in ProcessWire itself and use them in page names but not sure this would change the behaviour in Jumplinks as well.

Expand  

I think that's the default behaviour of browsers, too.
Non ascii characters (like special characters) that are not substituted in ProcessWire are URL encoded by the browser and used for requests.
So in Jumplinks broken links should be recognized and redirected as URL encoded Links (under the hood).
But unfortunately this does not work:

In 404-Monitor links are recognized with URL-Encoded special characters:

news/2020-06-26-ich-war-schon-angekommen-bevor-ich-%c3%bcberhaupt-da-war

(Better for reading would be the unencoded version, if possible.)

When adopting the 404 by click on the corresponding „Request URI“, the URI is shown and saved unencoded in the next step under „Register New Jumplink“.

news/2020-06-26-ich-war-schon-angekommen-bevor-ich-überhaupt-da-war

These unencoded redirects (created via 404-Monitor) are not working.
If manually changed to encoded version it works.

  On 3/1/2025 at 9:46 PM, wbmnfktr said:

How often do you experience these kind of URLs?

Expand  

On one website a lot. Lot's of news pages with pagetitles (= pagenames) having special characters. Coming from a CMS that allows nearly all special characters that are allowed in the web nowadays.

  On 3/1/2025 at 9:46 PM, wbmnfktr said:

For the time being you could at these to the redirects.

Expand  

Adding this manually would be really time consuming and error-prone.

I assume fixing this should not take that long for a Pro.
The most important thing is to preserve the right URL when adopting it from the 404-Monitor.

[Mike Rockett]

Thanks for raising this, however I'm not maintaining Jumplinks anymore. It has been up for grabs for a while now, and nobody has expressed an interest in taking it over. I would consider the module archived at this point. I am open to a merge request to resolve any lingering issues, but am not prepared to spend development time on the module.