Jump to content

Jumplinks


Mike Rockett

Recommended Posts

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.

  • Like 1
Link to comment
Share on other sites

@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 by Mike Rockett
Possible reverse
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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?

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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;

 

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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)?

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

36 minutes ago, Jason Huck 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?

Link to comment
Share on other sites

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!

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...