Mike Rockett

Due to the way the tree module works, I am not able to show the pages in all languages within Jumplinks. You may need to switch languages in the admin panel to see the pages in that language. You can also manually specify the destination without using the page tree or auto complete fields.

Hi adrianmak, Well it depends where you are redirecting from. Does your Source contain anything relating to the language of the Destination?

Hi Peter, I'm not sure why that is happening... What version of Jumplinks do you have?

I think that looking at the amount of issues present is like judging a book by its cover. So long as the issues are being managed properly by means of the correct labels and follow-ups, then the count of issues should not be seen as an issue itself. Regarding issues that cannot be reproduced, I think there should be a time-delay in terms of leaving it open. It should be labelled first, and then closed, say, after 30 days if there is no reply. If the author of the issue can prove production of the problem on their end, then it shouldn't be closed, because the issue does exist.

Have been using it for a while now - really dig it!

Nice update, Ryan! My only suggestion would be to change "Publish + Exit" to "Publish + Close" as "Exit" seems a little much, if you know what I mean...

I'm sure I read somehwere that Blade could easily be used outside of the Laravel scope. Never really tried it, though, because I'm a Twig fan.

Phew, the flexibility is overwhelming. But yeah, that would be checked for.

Perfect, Sergio. I think that I need to spend some time getting to fully understand how multi-lang sites work so I can attempt to incorporate support for them. A quick thought that ran through my mind was this: Source: /{lang}/books/book-details/{id}/? Destination: [[template=book, wpid={id}], {lang}] In the background, this would change the user language if it exists, get the URI, and then quickly change it back. ({lang} would be a specific parameter, which would be allowed to be empty.) That said, the syntax may change for JL 2... Not sure as yet.

Hi Sergio, I see your dillema indeed. The problem is that the destination selector is language-agnostic, or, doesn't give specific consideration to the language being requested by the end user. Adding language to the selector doesn't seem to be the way to go - though I haven't tried it at all (not very familiar with multi-lang at this point). The only suggestion I could make is to deviate from using destination selectors (I know they're wicked and what not, but sometimes they're just not the beasts they want to be), and use mapping collections instead. In fact, I think it is more suited to the task. However, it should be noted that I haven't given Jumplinks the ability to have optional params ({segment?}, for example) as yet. So it would be a case of having a jumplink for the URIs without the lang code, and another with the lang code. Source (without lang code): books/book-details/{id}/? Destination: books/{id|wpbooks}/ Source (with lang code): {segment}/books/book-details/{id}/? Destination: {segment}/books/{id|wpbooks}/ Mapping Collection named wpbooks: 1=foo 2=bar n=baz Sure, this is a tad tedious (two jumplinks where there could be one), but I think it's the safest and most reliable bet at this point. I hope this works out for you. Of course, I'll be looking at all of this as I continue with JL 2. Optional parameters is something that has been on my mind once or twice.

Generally, I use inline SVG for easy manipulation. My stance is that if a browser doesn't have enough support SVG, then I don't support the browser. That said, I don't use much SVG... Just my 2c.

Very interesting concept indeed. And definitely loving this new colour-scheme, too. Nice work, Tom. Quick note about the editor: a expander button at the top left of the editor [<] to expand it to the width of the page would come in handy, especially useful when working with multi-column editor layouts.

Added to the list of things to do.

If you have Jumplinks installed (pre 1.5.1), please upgrade (we're on 1.5.2 now), as previous versions trim out the index.php from URIs. 1.5.1+ only trims it if it is suffixed with a trailing slash and an optional path, matched by index.php(/.*).

Have started with v2, which will incorporate a considerable change in architecture and features. It was advised early on to not bloat the module with too many things, but I'm going to go ahead and add a redirect logger, the testing buttons, and a few other things. Note, however, that much of this will be turned off by default so as to keep the module clean and simple.

Welcome to the forums, Bipeen. Where did you put that redirect directive? It should really be right at the top of the file.

I think I see what's happening, though. When you manually specify the destination of an existing page without using the page tree or auto complete fields, Jumplinks actually converts it to a page selector (page:id). Because your currently language is German, the admin area will display the link to the page in that language. If you were to change your user language back to English, it would display that one instead. The only way around this, I would think (though it is too early in the morning for me to be doing any thinking), is to allow you to instruct Jumplinks to not convert destinations that match existing pages to page identifiers. So, in the DB, it would remain as /de/something, instead of being converted to page:id. For reference, the responsible process is this (in ProcessJumplinks.module.php): // If the Destination Path's URI matches that of a page, use a page ID instead if ($noWildcards && $isRelative) { if (($page = $this->pages->get('/' . trim($input->destinationUriUrl, '/'))) && $page->id) { $input->destinationUriUrl = "page:{$page->id}"; } } So I simply need to change the behaviour so that the destination is only converted if the check box is selected. This does mean that I'd need to do a schema change, though. Regarding that SEO plugin, I'd prefer it if I developed Jumplinks without looking at what other tools use and how they do so. If there is a specific feature (like the testing links) that is needed, I'm keen to implement my own version. But thanks for the offer.

I have pushed 1.5.3 to the dev branch, which does change that line to use the site root instead. Also finished converting over to PDO (no idea why this wasn't done sooner). Work on Jumplinks 2 begins this weekend. Had a 'prototype' before, but it wasn't working out the way I'd intended (coding blues?), so starting again this weekend.

From my side, I'd develop applications in phpstorm. But building sites and modules that are part of applications can be done in ST without fuss. My only issue with ST is that there are quite a few gaps in development. Before today, the previous dev build was from July last year. Two new builds were released today, though - so maybe 3 will come out sooner, rather than later... Let's wait and see.

(1) I think the original intent was for it to be language-agnostic - that said, specific wildcard/language features haven't been implemented. Haven't even though about how that would work - might be something to add to the todo list for v2. Yeah, 11 spoken language - there are sites in our native languages, but I've never had an African client ask for their website to be in their language in addition to English. Now that you bring it up, I'm actually quite surprised. (2) I think the following line may be the culprit. It comes from the compileDestinationUrl function (at line 309), which was recently changed. $prefix = ($hasScheme) ? '' : "http{$https}://{$this->config->httpHost}{$this->pages->get(1)->url}"; So the pages->get(1)->url is the part that could be causing the issue... Not entirely sure (I don't use multi-language at all, so not sure on the behaviour). (3) I'm not seeing the test buttons on that plugin - unless I'm just not looking properly... What would determine if a redirect is still needed? Currently, Jumplinks informs you of old redirects, those that haven't been hit in a while, and notifies you accordingly. And what would determine if it is still valid? I assumed that the intention was to have the test buttons make sure the jumplinks actually work as intended... No? (Forgive me if I've misunderstood...)

Yeah, same here. Wanted to switch over to phpstorm for better code insight, but: There are packages for that, and If an IDE takes longer to start up that Windows does on an i7, then I'm not interested.

Hi ceberlin, Jumplinks wasn't actually built with multi-language in mind. That said, I wouldn't have expected it to do this. Just to confirm, are you saying it changes en to de when you save the jumplink? I'm sure I can add a test button for the Source and Destination fields in the editor. The problem is that it would only be able to test Sources that do not contain wildcards. I could very well make it ask for input for each wildcard, but would that not be kinda tedious? Dupe-checking is on my to-do list The 404 monitor is being broken out into a separate module. Due to this, the plan is actually to have a little tick appear next to each 404 that has a jumplink assigned. There are often cases where one needs to keep the entries in order to obtain certain information about them. However, the module will have functionality similar to that of ProcessLogger, whereby the log can be pruned. The difference, however, will be that you can prune by different factors, including the removal of all 404 hits that have jumplinks assigned to them.

Great interview! This is pretty darn important, and is probably one of the most important things that sets PW apart.

(on mobile, so not checking out the links already provided) I use Sublime 3, and believe there's a snippets package for PW. For me, Sublime is still the winner.