POWERFULHORSE Posted August 29, 2016 Share Posted August 29, 2016 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. 1 Link to comment Share on other sites More sharing options...
Mike Rockett Posted August 29, 2016 Author Share Posted August 29, 2016 (edited) @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 Link to comment Share on other sites More sharing options...
POWERFULHORSE Posted August 29, 2016 Share Posted August 29, 2016 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? Link to comment Share on other sites More sharing options...
Mike Rockett Posted August 30, 2016 Author Share Posted August 30, 2016 @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 More sharing options...
Mike Rockett Posted August 30, 2016 Author Share Posted August 30, 2016 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: 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) In schema-update-v2 and schema-update-v3, replace NOT NULL DEFAULT '0000-00-00 00:00:00' with the NULL DEFAULT NULL 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. 1 Link to comment Share on other sites More sharing options...
Mike Rockett Posted August 31, 2016 Author Share Posted August 31, 2016 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? 1 Link to comment Share on other sites More sharing options...
szabesz Posted September 1, 2016 Share Posted September 1, 2016 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. 1 Link to comment Share on other sites More sharing options...
Mike Rockett Posted September 1, 2016 Author Share Posted September 1, 2016 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? Link to comment Share on other sites More sharing options...
szabesz Posted September 1, 2016 Share Posted September 1, 2016 (edited) 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 Link to comment Share on other sites More sharing options...
Mike Rockett Posted September 1, 2016 Author Share Posted September 1, 2016 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. 1 Link to comment Share on other sites More sharing options...
Mike Rockett Posted September 1, 2016 Author Share Posted September 1, 2016 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 More sharing options...
POWERFULHORSE Posted September 1, 2016 Share Posted September 1, 2016 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: 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) In schema-update-v2 and schema-update-v3, replace NOT NULL DEFAULT '0000-00-00 00:00:00' with the NULL DEFAULT NULL 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; 1 Link to comment Share on other sites More sharing options...
Mike Rockett Posted September 4, 2016 Author Share Posted September 4, 2016 State toggling is done in v2 - already shared in this issue. 1 Link to comment Share on other sites More sharing options...
Mike Rockett Posted September 4, 2016 Author Share Posted September 4, 2016 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. Link to comment Share on other sites More sharing options...
Mike Rockett Posted September 5, 2016 Author Share Posted September 5, 2016 For those needing to temporarily disable the module, I've added the ability to do so in 1.5.43. 2 Link to comment Share on other sites More sharing options...
Mike Rockett Posted September 5, 2016 Author Share Posted September 5, 2016 Thoughts on the new manager page? 6 Link to comment Share on other sites More sharing options...
szabesz Posted September 6, 2016 Share Posted September 6, 2016 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? Link to comment Share on other sites More sharing options...
Mike Rockett Posted September 6, 2016 Author Share Posted September 6, 2016 @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. 1 Link to comment Share on other sites More sharing options...
Jason Huck Posted September 13, 2016 Share Posted September 13, 2016 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 More sharing options...
Mike Rockett Posted September 13, 2016 Author Share Posted September 13, 2016 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 More sharing options...
Jason Huck Posted September 13, 2016 Share Posted September 13, 2016 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 More sharing options...
Mike Rockett Posted September 13, 2016 Author Share Posted September 13, 2016 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? Link to comment Share on other sites More sharing options...
Jason Huck Posted September 13, 2016 Share Posted September 13, 2016 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! 1 Link to comment Share on other sites More sharing options...
Peter Knight Posted September 21, 2016 Share Posted September 21, 2016 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 Link to comment Share on other sites More sharing options...
Mike Rockett Posted September 21, 2016 Author Share Posted September 21, 2016 @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. 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now