module Jumplinks

[POWERFULHORSE]

7 minutes ago, Mike Rockett said:

Carry-over from here:

@POWERFULHORSE - Sorry to see that error came up, as we have had problems with timestamp fields in the past.
What version of MySQL are you running? There is quite a difference between 5.6 and 5.7, but understood that this problem was fixed.

Also note that (as you'll see in the posts above), Jumplinks 2 is in development, and it uses Laravel's Eloquent for database interactions. Makes it somewhat more manageable in terms of table schemas (and a whole bunch of other goodies).

Hi Mike, thanks for carrying this over for me. Using 5.7.13 as far as I can see.

[Mike Rockett]

@POWERFULHORSE

Strange indeed. The issue had something to do with nullable/default timestamps. I think I may have missed a timestamp though. Please open ProcessJumplinks/Blueprints/schema-update-4.sql and change created_at TIMESTAMP to created_at TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00'. Then try installing again.

Or if it is the other way round (that the default is incorrect), rather remove the DEFAULT ... from each of the sql files in that directory.

Edited August 29, 2016 by Mike Rockett
Possible reverse

[POWERFULHORSE]

No luck with either of those unfortunately. Should I also try to update the created_at lines in schema-create-main.sql and schema-create-msc.sql with the replacement line you quoted?

[Mike Rockett]

@POWERFULHORSE

Are you running your own server? If so, you'd be a lot better off strict mode in your MySQL configuration. If I recall correctly, this will allow zero dates as defaults. There are individual overrides for allowing zero dates while keeping strict mode on, but these methods are to be removed from MySQL, and so I wouldn't recommend using them.

As mentioned, this has come up before. Looking at the source again, it 'feels' like a mess - it really does. And, to be honest, I'm ot exactly sure what the correct approach is 0 the Oracle team have really made things difficult. When this happened, I recall fixing the issue, and then switching over to MariaDB 10.

[Mike Rockett]

Hold on, I've just seen that Eloquent now handles these differences depending on the version of MySQL used. For a Laravel project I'm working on, it's using this for the timestamps:

`created_at` TIMESTAMP NULL DEFAULT NULL

As such, give the following a try:

1. Change the created_at and updated_at lines in schema-create-main.sql to match the above line (so just add NULL DEFAULT NULL on the end of each one)
2. In schema-update-v2 and schema-update-v3,  replace NOT NULL DEFAULT '0000-00-00 00:00:00' with the NULL DEFAULT NULL
3. If the above does not work, then simply use TIMESTAMP for all of these, without the NULL DEFAULT NULL

Hopefully this will fix it for you, keeping in mind that the module uses CURRENT_TIMESTAMP when inserting or updating records.

[Mike Rockett]

Have made progress with adding some features after a small refactor (too many traits! - gone now). Destination validation is done, and module config is done (for the most part).

Regarding debug mode, I think this will need some changing: Instead of showing a scan-log in the browser, I think debug mode should log this to file, preventing people from seeing the output during an 'emergency' troubleshooting session (rare, but they happen).

Thoughts?

[szabesz]

10 hours ago, Mike Rockett said:

I think debug mode should log this to file

I often see such features to be (superuser) configurable: no log, log to screen, log to file, log to both.

[Mike Rockett]

4 minutes ago, szabesz said:

I often see such features to be (superuser) configurable: no log, log to screen, log to file, log to both.

Awesome idea - I think I'll implement that then. Sensible default? Log to file?

[szabesz]

If we probably do not get too many log entries, then log to file will probably do, however, if we do get too much stuff, logging is normally recommended during testing sessions only.

Edited September 1, 2016 by szabesz
o

[Mike Rockett]

3 minutes ago, szabesz said:

If we probably do not get too many log entries, then log to file will probably do, however, if we do get too much stuff, logging is normally recommended during testing sessions only.

Correct - the intention of debug mode is for troubleshooting and should be turned off 99% of the time. The hit logger, for production use, is database driven, and disabled by default.

[Mike Rockett]

One more change I'm implementing that will be handled by the internal migrator: Parameter types (old base wildcards) that span multiple segments (separated by a slash) are no longer represented by their plural form. So, before, you could use segments, which simply added a forward slash to the segment expression: [\w_-]+

Now, these types are represented by an asterisk, and multple types are supported:

Examples:

num represents [\d+] and num* represents [\d/]+
any represents [\w.%\=\s-]+ and any* represents [\w.%\=\s-/]+

For 'any': Note that PW does not support spaces in URLs. If these are required for a migration, add them in .htaccess 16a or 16b character classes, which ever one is being used.

[POWERFULHORSE]

On 8/30/2016 at 6:27 AM, Mike Rockett said:

Hold on, I've just seen that Eloquent now handles these differences depending on the version of MySQL used. For a Laravel project I'm working on, it's using this for the timestamps:

`created_at` TIMESTAMP NULL DEFAULT NULL

As such, give the following a try:

1. Change the created_at and updated_at lines in schema-create-main.sql to match the above line (so just add NULL DEFAULT NULL on the end of each one)
2. In schema-update-v2 and schema-update-v3,  replace NOT NULL DEFAULT '0000-00-00 00:00:00' with the NULL DEFAULT NULL
3. If the above does not work, then simply use TIMESTAMP for all of these, without the NULL DEFAULT NULL

Hopefully this will fix it for you, keeping in mind that the module uses CURRENT_TIMESTAMP when inserting or updating records.

Thanks again for this, managed to get the module to install correctly. The changed lines below summarised for anyone else facing a similar problem. This was for PW 3.0.28, PHP 7.0.1 and MySQL 5.7.13.

schema-create-mc.sql

updated_at TIMESTAMP NULL DEFAULT NULL
created_at TIMESTAMP NULL DEFAULT NULL

schema-create-main.sql

created_at TIMESTAMP NULL DEFAULT NULL
updated_at TIMESTAMP NULL DEFAULT NULL

schema-update-v2.sql

ALTER TABLE <table-name> MODIFY date_start TIMESTAMP NULL DEFAULT NULL;
ALTER TABLE <table-name> MODIFY date_end TIMESTAMP NULL DEFAULT NULL;

schema-update-v3.sql

ALTER TABLE <table-name> ADD COLUMN last_hit TIMESTAMP NULL DEFAULT NULL;

 

[Mike Rockett]

State toggling is done in v2 - already shared in this issue.

[Mike Rockett]

Master branch bumped to 1.5.42 in response to #15: If you need to disable a jumplink, simply add !! to the front of the Source. As you can see in the previous post, there's a better way of handling this in v2.

[Mike Rockett]

For those needing to temporarily disable the module, I've added the ability to do so in 1.5.43.

[Mike Rockett]

Thoughts on the new manager page?

 

[szabesz]

Impressive  However, since you do not use checkboxes, there is no way to perform a batch operation (at least I cannot see it in the screengrab). Is this intentional?

[Mike Rockett]

@szabesz - It is intentional, as it was in JL1. However, I am open to bulk operations. My idea is to perhaps incorporate this into the ordering utility. The new manager page will paginate jumplinks to show a certain amount per page. As there will be times when certain jumplinks would conflict, order is important. As such, I'm thinking about putting together a utility to re-order jumplinks. Whilst there, bulk activities can also be performed. I'd like to maybe do it there so as to not clutter up the manager page - my objective is to keep things simple and neat, and not to clutter up the interface. It has been brought up before that the module remain easy to use with no feature overload, and so I'd like to keep it that way. As such, whenever something new is added, it is disabled by default. Ordering/bulk actions won't be disabled by default, but everything else that can be classified as an 'additional feature' will be.

I've also decided to turn off Collections and Page Selectors by default as these features are classified as 'additional' due to the fact that they are not required for the module to operate. The hit logger is also disabled by default, along with destination validation.

[Jason Huck]

I've just discovered that Jumplinks has stopped working on an older site. Same behavior on both dev and production -- the admin UI works fine, but none of the actual redirects happen on the front end; users are just bounced to the 404 page. When I enable (Jumplinks') debug mode, I see it skip right past the relevant entry for a given URL as if it couldn't find a match. The site is running PW 2.6.1 and Jumplinks 1.3. I tried upgrading Jumplinks to the latest version in dev, but it didn't help. Any suggestions on how to further diagnose the issue?

 

[Mike Rockett]

5 minutes ago, Jason Huck said:

I've just discovered that Jumplinks has stopped working on an older site. Same behavior on both dev and production -- the admin UI works fine, but none of the actual redirects happen on the front end; users are just bounced to the 404 page. When I enable (Jumplinks') debug mode, I see it skip right past the relevant entry for a given URL as if it couldn't find a match. The site is running PW 2.6.1 and Jumplinks 1.3. I tried upgrading Jumplinks to the latest version in dev, but it didn't help. Any suggestions on how to further diagnose the issue?

Hi jason - not sure what the issue could be there. Could you perhaps share the debug log (PM is also fine, if you'd prefer that)?

[Jason Huck]

There's not much to see. If I hit a URL like

about/locations

...which should redirect to:

locations

...I instead end up on:

http404

The debug log starts off like this:

404 Page Not Found
Checked Tue, 13 Sep 2016 13:40:14 -0400
Request: http://xxx.xxxxxxx.xxx/http404/
ProcessWire Version: 2.6.1

Scanning for jumplinks...

[Checking jumplink #1]
- Original Source Path:       about/community
- Compiled Source Path:       about/community

No match there...

...then iterates through all of the jumplinks, including the one it *should* match on:

[Checking jumplink #3]
- Original Source Path:       about/locations
- Compiled Source Path:       about/locations

No match there...

...and ends like this:

No matches, sorry. We'll let your 404 error page take over when Debug Mode is turned off.

 

[Mike Rockett]

36 minutes ago, Jason Huck said:

Request: http://xxx.xxxxxxx.xxx/http404/

That's the problem right there - the request should not be http404, which is the built in 404 page. That should show the original request. As it isn't doing that, it means that something is redirecting to the 404 page before Jumplinks can do its thing. Perhaps there's another module hooking to the 404 event in play? Template code, maybe?

[Jason Huck]

3 minutes ago, Mike Rockett said:

That's the problem right there - the request should not be http404, which is the built in 404 page. That should show the original request. As it isn't doing that, it means that something is redirecting to the 404 page before Jumplinks can do its thing. Perhaps there's another module hooking to the 404 event in play? Template code, maybe?

Okay, that makes perfect sense, and gives me something to go on. I can't think of anything off the top of my head that would be interfering, but I'll have a fresh look. Thanks!

[Peter Knight]

Hi Mike

Are the number of Jumplinks displayed in the Jumplinks manager capped at a certain point?

I noticed there was no pagination (good) and wondered if it only shows first 250 etc

 

[Mike Rockett]

@Peter Knight - Hi Peter. There's no limit on that front. Current module shows all of them on the single page. At the time, I thought to myself that if jumplinks are used effectively, then pagination won't even be needed. Doing the same thing for JL2.