Mike Rockett

Just figured I'd use it if it's installed... In this case, it's the jumplink state toggler (enable/disable), so the notification is a nice-to-have, but won't show if Notifications is not installed.

Update: This doesn't change if I open the pull-down...

I'd like to use this for Jumplinks 2 (instead of an annoying popup), but every time Notification.message is called, the ghost popups keep incrementing. Eventually, sending one notification shows all the notifications that haven't been read from the pull-down yet. Any way around this?

I think that PW modules should remain in whatever namespace PW is using. In the case of 2.8, that is the root namespace. In the case of 3.0, that is \ProcessWire. Then, include a directory namespace (such as src), and use your namespaces there only. This seems most logical to me...

Very sorry, but this module was placed on the mantleshelf, but I'll be able to get back into it soon. It does need a complete refactor as well. However, Jumplinks 2 is the priority at the moment. That said, the basic fundamentals of the module do work, so it is possible to use it. However, I don't recommend using an incomplete module, even if it is functional enough. Will update the thread when I get back to this.

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.

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.

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

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?

@cmscritic - Ah, that explains it. Glad to see the site back on PW.

I'm sure you can do something with the ready() method to manually return a response. Perhaps you could even implement a router to handle this? I'm using nikic/FastRoute for the new iteration of Jumplinks. It can also be used for this kind of thing, I am sure. Or perhaps there's another way I don't know about - someone else will chime in if there is.

@cmscritic - That's excellent news indeed. I've noticed that requests are taking a really long time to process, however. For example, requesting an old URL (cmscritic.com/grav/) just loads forever. As does search... Any ideas what could be causing that?

This looks awesome Tom! Finding a decent helpdesk package these days is qiute tedious. There are some good options, but no free ones for the smaller folks. Really nice to see this kind of thing wrapped up in PW.

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.

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

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

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

Jumplinks 2 (in development) makes use of namespaces. I simply require a bootstrap file (say, bootstrap.php) at the top of the module's main file, and this file uses the PW classloader to add the namespace, like so: $this->classLoader->addNamespace('Jumplinks', __DIR__ . '/src/Jumplinks'); As such, you do not need to use the composer.json file for this.

@tpr - Thanks for this module. Have switched over from Twig for a project to test it out, and I dig it. Latte is quite awesome indeed.

I think that actually isn't a problem though, as the system doesn't mention anything about incompatiability - I mean, if it works with v3, then there's nothing I'm aware of that'll prevent it from work on v2.8. That said, it something that people would have to 'know', instead of it being specifically stated.

Thanks Adrian - all is working now. I'm just wondering if you shouldn't indicate PW 2.8 compatability in the mods directory?

I haven't tried it with JL1, but I assume it won't work. I'll send you a private copy of JL2 tomorrow some time

As with JL1, I'm hooking a handle() method from the init() method. However, with JL2, the handle() method is in a trait. Not sure what the difference between ready() and init() is... Oh, and I only tried the TD way as bd() wasn't working, nor was \bd().

@szabesz - Hmm, interesting idea. So it would be a case of allowing certain roles to modify permanent redirects. The only real reason this has come up is due to the relevant standards, which are not often adhered to. However, considering browsers don't adhere to half of the status code standards (I'm sure there are good reasons for it), perhaps I should just leave the restrictions off altogether - at the end of the day, if you want a 301, you're doing it for a reason, and you more than likely won't make too many changes to it... @ceberlin - The only real difference between 302 and 307, the way I see it, is how HTTP methods can change when redirecting. For example, with 307, and as I understand it, changing from GET to POST requires user intervention. For the purposes of this module and its general use, I think we can stick to 302 (unless I'm missing something). Regarding validation, my intention is to keep it simple and only check for either 200, 301, 302 or just 200 (strict mode). If the former is enabled and a 301/302 is returned, Jumplinks won't check to see if that redirects to another redirect, and so on.

@bernhard - Shortcuts are on (by default anyway). I use the backslash as I'm using a namespaced environment with Jumplinks. As I need to call TD's methods inside a trait, I need to refer to the root namespace.