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 10: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.

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'

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 4: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.

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]

3 hours ago, Mike Rockett said:

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

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

[Mike Rockett]

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

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

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]

40 minutes ago, 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.

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.

35 minutes ago, Mike Rockett said:

Guessing this should do the trick…?

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]

8 hours ago, 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.

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.