Mike Rockett

Busy working on module configuration, and some questions have popped up regarding the way in which we should work with permanent and temporary redirects. I'd like to change the process to this: When creating a new jumplink, we set the 'from' and 'to' fields as normal. Then, a 'redirect type' field can be used to choose between permanent and temporary redirects. If permanent is selected, timed filtering will not be available for the jumplink, and it will redirect with HTTP status code 301. I also think that the jumplink should be completely locked if this option is selected - to the extent that the jumplink may only be deleted (which should only be done when the module has picked up that it is stale, having had no hits in the last 60 days). Not 100% sure about this, but I do like the idea. (Note: a warning would be displayed before saving if this option is selected.) If temporary is selected, then timed filtering will be made available, and it will redirect with HTTP status code 302, even if a start/end time is not specified. This will be the default option. I'll also be implementing destination validation, which will be turned off by default. When enabled, this feature will first check to see that the resource we're redirecting to returns either of the following status codes: 200, 301, 302. We could then also turn on strict validation to ensure that the only return code allowed is 200 - this prevents the possibility of infinite redirects my simply not allowing them at all. I could go ahead and use curl to check for infinite loops, but I think that brings about some unnecessary overhead... With the current 1.5.x branch, the module automatically uses 301 if timed activation (now known as timed filtering) is not enabled. Thoughts, please.

Hey Adrian, Just started using this for Jumplinks, but not able to dump anything using any of the available methods (classes and shortcut methods not found). However, I'm using PW 2.8 for this, and I see that your module doesn't declare compatability. Should I switch over to 3.0 for this, or is there another way? Class 'TD' not found in /var/www/jumplinks-two/public_html/site/modules/ProcessJumplinks/src/Jumplinks/Traits/HandleTrait.php when using \TD::barDump(...).

Hi Ryan, I definitely agree on the GitHub change - in fact, it's something I'd been meaning to bring up a few days ago, but figured I'd wait a little while in case you thought of it first (some excellent foresight, this is). My recommendation would be to convert the ProcessWire account to a GitHub organisation (already hinted above). It would be nice if there were two repos in the new organisation: one for 3.x (processwire/processwire) and one for 2.8 (processwire/processwire2x), but I'm not sure if there is a way to define some sort of upgrade process that redirects to the new repo for <2.8 users. Perhaps this could be incorprated into the upgrade module. As I understand it, running git pull on the old repo under ryancramerdesign will automatically redirect to the new repo, so maybe that solves the entire problem. You could then keep the PW repos in the new organisation, and have your third party modules over at your private account.

Anyways, gave this a shot on v3, and it appears it's unable to get the source sans font...

Battling to install devns: [RuntimeException] Error loading sha `devns`, curl request failed (status code: 0, url: https://raw.githubusercontent.com/ryancramerdesign/Proces sWire/devns/wire/core/ProcessWire.php). cURL error: SSL certificate problem: unable to get local issuer certificate Any ideas? (Going to do manual method for now.)

Bumped to 1.5.41 with a workaround that only allows the use of /? at the end of a source string. As JL2 is in development, trailing slashes will be dealt with differently (provided I can fix the FastRoute implementation this is now fixed, and I'm not sure how I fixed it).

@palacios000 - Thanks for bringing that to my attention. It appears to be a bug that seeped in from a previous change. In the early days, making trailing slashes optional involved setting them like this: [?] However, I wanted to retain the regex format for this, and so enabled a workaround that allowed us to do this: /? But, I didn't think about query strings after a trailing slash, and so I did not make it check for the regex optional format only at the end of the source string. Will patch this shortly and bump to 1.5.41.

Awesome!

Perhaps the most amazing one? http://photoswipe.com/

Bumped to current master to 1.5.4, fixing a potential security issue.

Ok, tested - a few things I noticed using 2.8.28: When using system notifications, the notification bell icon along with its number badge overlap the site URL in the header. The Modules section in the sidebar appears to be broken - doesn't want to expand? The main sections in the sidebar should go back to being click to open, I would think... Can't seem to close Pages and Settings... I think the selected item in the sidebar shouldn't have that arrow as if Tree is selected, the arrow doesn't server it purpose as it collides with the page header. #sidebar #main-nav li ul li ul should have a black-based drop shadow as grey never looks good. Change that to: box-shadow: 2px 3px 7px 2px rgba(0,0,0,0.19); However, I'm very happy with the fixed sidebar and header - that's always something I prefer. However, you should probably implement scrolling in the sidebar as well because some installations have many things that can easily clutter it up. Well done Love the overall effect.

I like this, will test it out shortly.

@berechar - You'll need to refer to your site's assets relative to the root of your site, or absolutely where you include the domain explicitly.

@biber - If you read my post again, you'll see that I mentioned that you need to place that line underneath the existing RewriteEngine on directive, not as the last rule. Nonetheless, what you have done is correct enough. Glad it works.

@Webrocker - RedirectMatch does not support flags, so [L] will not work. @biber - Please add the following under the existing RewriteEngine on directive: RewriteRule ^(.+).html$ /$1/ [L] Note that the QSA flag is not required here. Also note that I have added a trailing slash as that is the PW default. If you have removed trailing slashes on all your templates, then you can remove it here too, saving an additional redirect.

Naturally, I would assume that a check is done to see if an entry exists that matches the one that's being submitted, but confirmation is needed on that... Not sure who handles it, actually.

Interesting - I wonder what could cause it to throw an error as the only realy difference between 2.8 and 3.0 is namespace support...

Thanks, will test as soon as I can.

I've just tried this on 2.8, but it appears the module doesn't work. I get the following error: Configurable module check failed for AdminThemeSubtle, retrying...

Interesting module indeed. Can't say I'm one for too much tweaking, but some of the features here are quite helpful. Specifically, I like hotkeys and textarea autosizing. In terms of Reno theming, it's quite interesting, but I can't say I like the sidebar tweaks, specifically the non-linear items (and the flash menus don't work). I have, however, taken a liking to the sticky white compact header. +1 for that. Just a note: I have tested this in 2.8 (not extensively) and it seems to work fine, as it should. The only differenc between 2.8 and 3.0 is that 2.8 does not have namespaces, but both versions share the same code. As such, and if I were the module author, I would drop the dependency to 2.8. Oh, and flyout panels (like debug mode tools) needs a higher z-index (testing with sticky header and sidebar on - Reno theme).

Todo list up: https://github.com/rockettpw/jumplinks/issues/14

Okay, so I've done a little thinking about multi-lang, and have realised that this could get quite complex, depending on the language setup of both the old and new sites. I'd like to find the simplest path that accomodates as many situations as possible. As such, please would everyone interested in support for this feature provide me with their use-cases (other than what is mentioned below)? I'll need the following details: Source URI Example (from old site) Source Jumplink you would like to use Destination URI Example (expected URI on new site) Destination Jumplink you would like to use (not after conversion to page:n, but as you entered it into the entity editor) If the Destination Jumplink does not contain parameters (wildcards), does the resulting Page exist in the Page Tree? I can imagine that multi-lang awareness needs to only apply to jumplinks with destinations that do not have wildcards - for example: /de/seite/. In that situation, Jumplinks would convert it to page:123, for example, but would then be converted to /en/page/. We could implement a solution by passing a {lang:code} parameter to this so that when the module runs a $pages->get(...), it would also check to see if the page is available in the specified language using $page->viewable($lang) and $page->localUrl($lang). Example: Source: /{lang:de}/Seite.html Destination: /de/seite/ Saved Destination: page:123 User requests /de/Seite.html and is redirected to /de/seite/ via $page->viewable('de') and $page->localUrl('de'), where 'de' is obtained from the special language parameter. If the page is not viewable in German, then the module would simply redirect to the default url. We would also use this implementation for the use-case @Sérgio presented with regards to destination selectors. The {lang:code} would not be passed to the selector itself, but would rather be checked automatically due to the presence of that parameter. Example: Source: /{lang:pt}/books/book-details/{id} [Saved] Destination: [[template=books, wpid={id}]] User requests /pt/books/book-details/25 and is redirected to /pt/books/title-of-the-book/ via the same methods mentioned above after the page itself is selected using the provided selector. In both examples, we could simplify the language parameter to include all languages known to the system by simply using {lang}, without the specific language. This should cover both /something and /en/something, for example. Everything else could well be handled by existing features, I am sure. (Guys, note that I still haven't played around with multi-lang yet, and so all of this is coming from information provided in previous posts. If you think I've missed the ball in any way, please do let me know.)

I think that might be heading towards feature overload... Could you perhaps give an example of what kinds of jumplinks would need to be copied? I can't really imagine a situation where you would need to do this.

@Sérgio - No problem. 1.5.3 will be the last of the 1.x range - hotfixes will increment the revision by one: 1.5.31, 1.5.32, etc. I'm going to put more focus on multi-lang in v2. Edit: Seems I didn't make a note of this somewhere, and have proceed to bump to 1.5.4. Will continue on 1.5.41, etc.

@bernhard - You're most welcome