module Jumplinks

[Mike Rockett]

Yes I confirm, I uninstalled the module and reinstalled again and the error gone, sorry for that.

Must have been a left over schema? That would be the only thing that explains it...

[Mike Rockett]

Bumped to 1.5.2 - Fixes an issue pertaining to URL sanitization. If you used a period in a destination (tested only with "robots.txt"), the URL was sanitized, and "http://" was added. This issue is now fixed.

Using Git Gui now, instead of Desktop - it seems to prefer the fast-forward merge. Am using an older version, but it doesn't matter, really.

[ceberlin]

Not sure how this works...

If the source link has a language in it (en) then I want to redirect always to that language:

en/label/carl/ --> en/label/management/

Jumplinks does some autocorrection after save, and because I as a user have my profile language set as de (German), I see this:

en/label/carl/ --> de/label/management/

Did I set it up wrongly or is this something that goes wrong? (Google does not like cross-language linkings)

[ceberlin]

Small ideas: 

• I would love a lot if there was an "external-link" button before the Source string and the Target string. Clicking on it would send me to a new window with the page loaded (or not). So I can quickly test the Target (valid) and the Source (if the redirect applied is working).
• I would like a dupe check - So the same string is not entered twice.
• If I use the 404 monitor to fix a link the link should be removed from the 404 monitor so I do not fix it twice

[Mike Rockett]

Hi ceberlin,
 

Not sure how this works...
 
If the source link has a language in it (en) then I want to redirect always to that language:
 
en/label/carl/ --> en/label/management/
Jumplinks does some autocorrection after save, and because I as a user have my profile language set as de (German), I see this:
 
en/label/carl/ --> de/label/management/
Did I set it up wrongly or is this something that goes wrong? (Google does not like cross-language linkings)

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?

Small ideas: 

• I would love a lot if there was an "external-link" button before the Source string and the Target string. Clicking on it would send me to a new window with the page loaded (or not). So I can quickly test the Target (valid) and the Source (if the redirect applied is working).
• I would like a dupe check - So the same string is not entered twice.
• If I use the 404 monitor to fix a link the link should be removed from the 404 monitor so I do not fix it twice

1. 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?
2. Dupe-checking is on my to-do list
3. 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.

[ceberlin]

Yes en is replaced with de on save (or maybe without any language path information and PW adds this later)

That the module does not handle languages is a surprise because I thought it did - South Africa alone has so many languages )

 

OK, what I see: it keeps the paths at the source. If there is an /en/ in it stays there.

The target is "treated" somehow. It appears that it shows the path always in the language I use as a user.

If I change my user language, the target paths change. Not sure how the effects are if a bot comes. Probably always en or what I set as hreflang='x-default.

 

Test buttons: The idea was to have a quick possibility to check if the redirect is still needed and still valid.

I am used to this from a very good Wordpress plugin.

(That plugin is a very clever beast, by the way: http://codecanyon.net/item/seo-redirection-pro/7596396 it even has a history for any redirects made - which is usefull to track errors, if you have many redirects - on of our sites has 500 redirects)

 

I would not have a problem with wildcards are left out and the source button is inactive in that case.

[Mike Rockett]

(1) Yes en is replaced with de on save (or maybe without any language path information and PW adds this later)

That the module does not handle languages is a surprise because I thought it did - South Africa alone has so many languages )

 

(2) OK, what I see: it keeps the paths at the source. If there is an /en/ in it stays there.

The target is "treated" somehow. It appears that it shows the path always in the language I use as a user.

If I change my user language, the target paths change. Not sure how the effects are if a bot comes. Probably always en or what I set as hreflang='x-default.

 

(3) Test buttons: The idea was to have a quick possibility to check if the redirect is still needed and still valid.

I am used to this from a very good Wordpress plugin.

(That plugin is a very clever beast, by the way: http://codecanyon.net/item/seo-redirection-pro/7596396 it even has a history for any redirects made - which is usefull to track errors, if you have many redirects - on of our sites has 500 redirects)

 

I would not have a problem with wildcards are left out and the source button is inactive in that case.

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

[Mike Rockett]

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.

[ceberlin]

(3)The buttons are there:

Do you want to have access to a website where you can see the plugin in action? It's pretty advanced. Maybe it is inspiring for your new project?

I installed the beta from today:

I set this

and still got this after save:

The string that I had set manually "en/helium-vola/" had been replaced again by the page-id and ignoring the language.

If you touched that in the beta, the behavior is still unchanged...

[Mike Rockett]

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.

[ceberlin]

Avoiding cross language linking are a big SEO topic. An option like the one you mentioned would be great. (And maybe that all is only needed if Languages are active (module installed, more than 1 language counted?) Or leaving it as it is and adding a language selector for the installed languages placed before the target link and shown for multilingual setups? - Just thinking loud.

 

What the module has and what I like is a very good search for links substrings on the source and target side (think of cases of 500+ redirections). And a debug option where every redirect is logged and shown the same way as 404 errors, with listing source and target for each incident. In case of redirect problems (first of all: loops) those information can be extremely valuable. And it has an optional cache.

[Mike Rockett]

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.

[ceberlin]

One more idea

For testing and debugging malfunctioning redirects (redirects can come from so many sources, htaccess, PW core, modules) it would be great to being able to either deactivating the module temporarily (preferred) or to temporarily uninstall the module without loosing all the stored data.

[Mike Rockett]

One more idea

For testing and debugging malfunctioning redirects (redirects can come from so many sources, htaccess, PW core, modules) it would be great to being able to either deactivating the module temporarily (preferred) or to temporarily uninstall the module without loosing all the stored data.

Added to the list of things to do.

[Sergio]

Still on the topic about multilanguage URLs, I have the following use case:

It's a Wordpress site with the qTranslate plugin

Old url: example.com/books/book-details/25/

New url: example.com/books/title-of-the-book/ (it has a field called wpid that stores the old wordpress id)

The jumplink: 

Source: books/book-details/{id}[/] / Destination: [[template=book, wpid={id}]]

works for the default language, the problem is when I try to redirect to the non-default language, Portuguese:

Old url: example.com/pt/books/book-details/25/

New url: example.com/pt/books/title-of-the-book/

I got a 404 so I changed the rule to: 

<|pt/>books/book-details/{id}[/]

and it almost works, BUT only redirects to the default language.

Is there a way to keep the matched string ('pt/') in the redirect? Or something like:

Source: <|pt/>books/book-details/{id}[/] / Destination: [[template=book, wpid={id}, language=$user->language]]

Or is there other workaround?

[Mike Rockett]

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.

[Sergio]

Mike, thanks a lot for taking the time to reply.

Your solution worked! I thought something similar before posting, but decided to give it a shot. For these book pages, your approach is good indeed, as there are few books. But for my next challenge, mapping hundreds of download items to their new pages, my proposed solution would be handy. But for now I'll just create a script to generate the collection list for me. 

Cheers!

[Mike Rockett]

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.

[Sergio]

I think this will work pretty good, Mike. And it will work for pages that are only published in one language as well. 

[Mike Rockett]

I think this will work pretty good, Mike. And it will work for pages that are only published in one language as well. 

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

[Peter Knight]

Hi Mike

I was just updating PW from 2.7.2 to 2.7.3 and have following error

Fatal error: Exception: Blueprint not found: /var/www/vhosts/mysite.com/httpdocs/site/modules/ProcessJumplinks/Classes/../Blueprints/schema-update-v1 (in /var/www/vhosts/mysite.com/httpdocs/site/modules/ProcessJumplinks/Classes/Blueprint.php line 61) #0 /var/www/vhosts/mysite.com/httpdocs/site/modules/ProcessJumplinks/Classes/Blueprint.php(40): Blueprint->findBlueprint('/../Blueprints/...') #1 /var/www/vhosts/mysite.com/httpdocs/site/modules/ProcessJumplinks/ProcessJumplinks.module.php(276): Blueprint->__construct('schema-update-v...') #2 /var/www/vhosts/mysite.com/httpdocs/site/modules/ProcessJumplinks/ProcessJumplinks.module.php(223): ProcessJumplinks->blueprint('schema-update-v...') #3 /var/www/vhosts/mysite.com/httpdocs/site/modules/ProcessJumplinks/ProcessJumplinks.module.php(192): ProcessJumplinks->updateDatabaseSchema() #4 /var/www/vhosts/mysite.com/httpdocs/wire/core/Modules.php(462): ProcessJumplinks->init() #5 /var/www/vhosts/mysite in /var/www/vhosts/mysite.com/httpdocs/index.php on line 252

Any advice? In the meantime I'm going to rewind a little back down to 2.7

[Mike Rockett]

Hi Mike

I was just updating PW from 2.7.2 to 2.7.3 and have following error

Any advice? In the meantime I'm going to rewind a little back down to 2.7

Hi Peter,

I'm not sure why that is happening...

What version of Jumplinks do you have?

[adrianmak]

How to deal with multi-language website ?

A client with a old website build with joomla

A multi-language url may look like for a same piece of content

content/blogcategory/19/34/lang,en/

content/blogcategory/19/34/lang,zh/

content/blogcategory/19/34/lang,gb/

How to redirect to different language of a pw site ?

[Mike Rockett]

How to deal with multi-language website ?

A client with a old website build with joomla

A multi-language url may look like for a same piece of content

content/blogcategory/19/34/lang,en/

content/blogcategory/19/34/lang,zh/

content/blogcategory/19/34/lang,gb/

How to redirect to different language of a pw site ?

Hi adrianmak,

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

[adrianmak]

Does your Source contain anything relating to the language of the Destination?

I'm not sure how to set it up.

When specify a destination, it could only select a page from page tree or something like page:1017

1017 is the page id

but how to specify page id 1017 of other language ?