Mike Rockett

Thanks, Adrian. Jumplinks is done (edit: 2.7).

Indeed a very good point. However, I feel that everything seems to be moving in that direction already. Wireless charging is starting to pick up the pace - could be a regular thing in just 5 to 10 years. That kind of technology could also, potentially, introduce similar concerns. The point I'm getting to: tech is becoming sophisticated and complex - so much so that 'simplicity' now only comes in the design. With such complexity, space for security issues widens. Let's not get started on IoT and IoE.

Glad it worked. It wouldn't have worked because of variable scope and attempting to assign multiple results to a single variable in one shot. In other words, the $warning = "" would have been reset each time the function executed. That's why the write access (reference) to $warning (outside the function) is needed. I'm surprised about the {title}, though... Not sure why that had to be changed. I think the {title} had to be changed because that seems to only be worked with after the function has returned a value. It can't just guess.

Just thinking out of the box here: $warning = ""; $divesites->each(function($item) use (&$warning) { if (!$item->marker->address) { $warning .= "<div class='alert alert-warning'>coordinates for {title} not set</div>"; } });

Definitely not able to reproduce this... I'm sure something else is interfering. Let me know if the problem doesn't persist after uninstalling Jumplinks.

Going to have to give this a spin later. I don't see why there should be a conflict though. Sure, Jumplinks may have a higher priority, but if there's no jumplink for the request, it should hand over to PagePathHistory, or anything else that grabs a lower priority. Unless I'm missing something... In the meantime, I think you should just export the 3 processjumplinks tables to sql files, and uninstall the module. Then check if it is indeed the case. You can then install Jumplinks again, and import the tables. Edit: In a quick test, I could not reproduce this. However, I did not install the PPH Manager - not sure if there could be conflict there. In a rush, however, so will look at this again later.

Hi Julio You can use $session->redirect($newPage->url).

Version Bump to 1.3.1 Hotfix: Drop 404 Monitor table on uninstall

Ah, also true...

Highly doubt that's built with PW. It's running on nginx - and there is no official support for that as yet. It doesn't respond to ?it= queries. It doesn't seem to use the built-in XSS protection PW has (lack of the X-XSS-Protection:1; mode=block response header). It has no wire cookie (or any other like it). Etc... If the site really is running ProcessWire, they've done a damn good job at hiding it. Perhaps they're using PW as a data-backend? If not, I really wish it was.

Perhaps this has got to do with the version of Twig being used? In your case, Twig 1.15 is being used, whereas the latest TemplateTwigReplace comes with 1.18, which is what I'm using.

Well, it works for me on the dev branch (2.5.28) with the latest TemplateTwigReplace... Perhaps a magic method was recently added. Update: This seems to be what's doing it (from core/Template.php) /** * The string value of a Template is always it's name * */ public function __toString() { return $this->name; } Not sure when it was added though... (Seems like it's there in 2.5.3 too...)

This works too: {{ page.template }}

Version Bump to 1.3.0 - Important Upgrade Release Notes: Debug Mode now logs each wildcard in a jumplink. Important fixes for zero/null timestamps. You can now make slashes optional with /? or [/] instead of just the latter. Classes are now only imported when needed. Each jumplink now remembers when it was last hit and notifies you if it has gone stale, as discussed above. 404 Monitor, as discussed above. Turned off by default. Schema version bumped to v4 to accommodate timestamp fixes and the new 404 monitor. If you come across any bugs with this release, please open an issue over at GitHub. Docs will be updated shortly.

So much for FluxBB 2 being built in Laravel? Edit: as a standalone app...

Have just submitted an update to the dev branch containing two new features: 404 Monitor: keep a log of '404 Not Found' hits (containing request URI, referrer, and user agent) so that you can later create jumplinks for them. You can clear the monitor at any time. This feature is turned off by default, and can be enabled in the module settings. Per @ceberlin's request, the date and time of the last hit on a jumplink is now recorded. The date can be seen by hovering over its hit counter, or by opening the jumplink editor. Furthermore, if a jumplink hasn't been hit in the last 30 days, that jumplink will be highlighted in the table, and a message saying that it is safe to delete will appear when editing it. Have tested on all systems available to me, and no issues have come up. That said, I'll bump to 1.3.0 tomorrow, after updating the documentation.

@guy - I have submitted a fix to the dev branch. Please let me know if it works for you now.

Hi guy, and thanks for bringing that up - will sort that out this afternoon. You're very welcome.

Ah, indeed. Those should be blank when not in use. I'm sure the latest fix will work for you - please let me know if it does.

Indeed, that could be quite useful, and is better than a full-on hit log, as I wanted to do at the beginning. This will also be helpful for an upcoming site migration, so will implement this soon.

I thought that might be the case (the JSON automation). Thanks for the clarification. Indeed I did search first (always do), but didn't find anything relating to this.

Hi All I'm more than likely missing something here, but it seems that one is unable to translate their module using language packs distributed with the module itself - say, in a lang directory. Is this possible? If not, how can I translate my module so that it's ready in the set language of the user?

Seemingly, PW compares dates in the database to the $lowestDate of 1974-10-10. I've updated the dev branch to do pretty much the same thing. Also, I have changed the schema of the date_start and date_end columns. The schema will update automatically. To me, this seems to be the better approach. Sure, I could use NULL dates, but recall that giving me problems before. I have tested on Windows, CloudLinux and CentOS. I'm sure the fix will work just fine on OS X and other nix variants, but please can those affected confirm for me? As soon as this is confirmed to be fixed, I'll push 1.2.1 to master. Thanks.

At first, I was using NULL dates, but that seemed to break on some systems. I then saw that PW uses zero dates, and so used them instead. As the column type is TIMESTAMP, can I even save empty strings? Edit: Although, I see where I am perhaps wrong. PW uses the following schema Type Not Null Default TIMESTAMP TRUE 0000-00-00 00:00:00 Whereas Jumplinks uses: Type Not Null Default TIMESTAMP FALSE NULL Whilst the default is NULL, Jumplinks sends a zero date to the database. Will work on this shortly.