Mike Rockett

I find it interesting that it is specifically making the table name lower case on my side. I'm going to need to look at this properly as well. I think I'll land up just doing a test at runtime to see which one it is...

When you turn on debug mode and request the URI in your browser, the log will appear there instead of redirecting. Interesting - I haven't seen that before. I'll have a look at it now now. Edit: Ah, I see. I'm using the db object. Changing it will mean a little bit of refactoring and more testing, so I'll have a look at that tomorrow - have had quite a long day.

Unfortunately, I am not able to reproduce that on my side. Is anyone else able to? Edit: My Apologies - I didn't notice the version you're running. I can confirm this on 2.5.3. Quite weird, because I don't recall this happening before. Will look into it shortly. Fixed: I have submitted a fix in the dev branch. The error is due to the fact that the field is an InputfieldURL, and the validation for that type of field has changed since 2.5.3. So, I have changed it to InputfieldText for now. A few months after PW 2.6 is released, I'm going to make this module compatible only with that version. However, I will leave a legacy version for those who, for whatever reason, need to stay on 2.5.3.

@All: I have just submitted a fix to the dev branch relating to this issue. It will be merged in soon with the other commits. @Macrura: Something must have broken with the import feature -- I will look into that this evening. Regarding the selector, there must be something shown in the debug log - it can never be empty. The following should happen: if a selector is found, it will check to see if a page by that selector exists. If one doesn't it will skip the jumplink. If debug mode is turned on in the module's config, then it will tell you that it found a selector, but it doesn't map to a page. Please could you double-check the log, and paste its content here? Update: Confirmed, I can reproduce the import problem. Will fix that shortly. Fixed: Okay, I've fixed the import issue (dev branch). Was an oversight when moving to prepared statements. So that's working now.

Indeed, though I am surprised it was not trimmed automatically. The following line of ProcessJumplinks.module is supposed to automatically trim it: $destination = ltrim($this->db->escape_string($this->sanitizer->url($input->destinationUriUrl)), '/'); If removing the leading slash does not work, please let me know.

Just synced an update to the dev branch that skips a jumplink if it contains a selector that doesn't return a valid page.

Great! You could either do as I suggested before and set the redirectsImported setting to false or, if that fails, re-install the module and repeat. Edit: It seems that MySQL table names are case-sensitive on most Unix-varieties. That said, I don't understand why the table is being created as processredirects and not ProcessRedirects on my system, when it is clearly instructed to use the latter... Can anyone point me in the right direction with this? I don't think it would be wise to change it unless there's a better way.

Fascinating - I never thought such an issue would come up. (Not a brightspark when it comes to things like that. And case-sensitive stuff never impacts me as I use Windows. In fact, that could even be the issue - though, I doubt it because only Unix filesystems are sensitive; I wouldn't think that would expand to MySQL.) Anyways, I've just attempted the selector idea, currently on the dev branch. Basically, you can to define your destination path like so: [[template=product-legacy, legacy_item_id={id}]] So that means that anything in double-square-brackets is to be treated as a selector. I've used the following to check - hopefully it is enough... $convertedWildcards = preg_replace_callback("~\[\[([\w-_\/\s=\",.']+)\]\]~i", function ($mapCaptures) { $page = $this->pages->get($mapCaptures[1]); if ($page->id) { return ltrim($page->url, '/'); } }, $convertedWildcards); My test yielded the following log: Page not found; scanning for jumplinks... - Checked at: Thu, 16 Apr 2015 17:30:56 +0200 - Requested URL: http://processwire.dev.local/legacy?id=43 - PW Version: 2.5.26 == START == [Checking jumplink #177] - Original Source Path: legacy?id={id} - Escaped Source Path: legacy\?id={id} - After Smart Wildcards: legacy\?id={id:num} - Compiled Source Path: legacy\?id=(\d+) - Original Destination Path: [[template=basic-page,legacy_item_id={id}]] - Compiled Destination Path: http://processwire.dev.local/testing-this-page/ Match found! We'll do the following redirect (301, permanent) when Debug Mode has been turned off: - From URL: http://processwire.dev.local/legacy?id=43 - To URL: http://processwire.dev.local/testing-this-page/ Which means it works. Nonetheless, please give it a test-run and let me know if you run into any issues, or if anything needs to be enhanced. Once we're all happy, I'll pull to master and update the docs.

I used the raw table name (processredirects) as that what was in my database when I wrote the module. In fact, I've just installed a fresh copy of it, and the table is called "processredirects". Perhaps this could be different versions of MySQL changing the case at runtime?

That's even weirder - they're completely independent of each other... Are you saying that the jumplinks don't show after the import? Oh, that's a nice whoops right there. Happened to me too at some point during testing. To solve it: Make sure that the table is named processredirects. Go into the modules table and check for "redirectsImported":true in the data column for the ProcessJumplinks row. Change it to false. Then you should be able to do the import again. I'll be changing this behaviour soon to help this along automatically. There'll probably be a new button (or link) to say "No, wait! It didn't work."

That's more than likely it - changing it shouldn't be a problem, especially if you're migrating. I quite like that idea, albeit being a little out of the ordinary (who likes ordinary anyway?). I'd probably have to set it up so that get: prefaces the selector. That way, we can tell if you're using one. So, in your case, it would be get: template=product-legacy, legacy_item_id={id}. Lemme give that a bash quickly.

Hmm, weird. Have you confirmed that the table actually exists using phpMyAdmin or similar?

What version of ProcessWire are you running? I have re-checked on 2.5.3 and 2.5.26, and everything is working normally What error was displayed, and where did it display? Could you post a screenshot?

Hi If you don't mind, please would you let us know why Jumplinks doesn't work for you? Redirects isn't able to handle index.php?something requests, but Jumplinks is. In your case, setting it up would be as simple as this: Step 1: Create a new Jumplink. Source: index.php?id={id} Destination: {id|pages}/ Step 2: Create a Mapping Collection called pages, containing the following Collection Data: 33=products 36=contact 37=imprint I'm also sure you'd have more of those to add. Jumplinks will then check the incoming request, find a match, map the page ID to the respective page in the collection, and redirect with a 301 status code accordingly. Really easy

Just had a look at that commit, and I see that the 1.3.1 wasn't enclosed in quotes, which is why it never worked. With Jumplinks, PW seems not to have had any issues with me using strings instead of numbers/floats. Sorry - misread your post. Just woke up from a little nap. From my viewpoint, it's just a semantics thing - though I could very well be wrong.

This is actually quite interesting. I've been wanting to know why we can use numbers instead of strings. Is there any benefit to this?

So, basically, Arvixe has broken everyone's sites? Since when can they just alter everyone's files? Phew, I'm so glad my hosting provider knows what they're doing... Sorry, just had to get it out there...

Essentially, that field is checked every time a a 404 is hit and you haven't defined a jumplink for it - it checks to see if https://domain.de/foo exists at http://domain.de/drupal/foo. As such, one should only specify a Legacy Domain when they're performing a slow migration to ProcessWire. That way, visitors and users can still access content if it hasn't been moved yet. Then, when everything has moved, you can strip away the Legacy Domain. I collapsed the field by default as it isn't often used, and don't want it to get in the way. If I try to make it so the group expands if one of its fields contains data, it will always expand as status code field contains data by default. That said, I'll probably land up keeping it expanded anyway. With all of that to one side, I'd still like to know how those particular errors came about... I assuming some kind of infinite loop took place, but don't know exactly what that entails. Perhaps someone with extensive knowledge of how PageFinder works could enlighten me?

On the topic of performance, I'm now wondering if I should set up a cache system for Jumplinks. It was mentioned by Antti a while back that Jumplinks is already feature-rich, but I think that caching redirects will actually be a life-saver for some users with large sites. At the end of the day, running the regex engine for every incoming request is sure to be a big performance hit on any server (the way I see it). I'm sure everyone agrees this should be added? There are also a few other fixes and enhancements in the pipeline, the most important one involves optional query-strings (much like the QSA flag for mod_rewrite). At the moment, if you want to match something.php and something.php?foo is requested, the redirect will not occur. In order to get it to work, you'd need to add {all} on the end of the source URI, which is, quite frankly, not the best way of doing it.

Thanks for your post. Looks like another module is doing that. Jumplinks only creates two tables (one for jumplinks, and another for mapping collections). In terms of performance, I'm unable to test that sort of thing. Are you saying that those errors go away when you uninstall Jumplinks? Do you have the same issue if you use ProcessRedirects? If you (or anyone else) could provide me with more information, that would be great. Otherwise, I can't determine what's going on.

Any time Yeah, I had a hard time figuring out how to install them in the beginning...

I quite like ModuleToolkit, without the s. Yes? Great module, by the way

@Macrura: This works for me every time: Install the skin into site/modules/InputfieldCKEditor/skins/lightwire In config.js, use the following: CKEDITOR.editorConfig = function( config ) { config.skin = "lightwire,/site/modules/InputfieldCKEditor/skins/lightwire/"; }; By doing this, we need not put anything into wire/modules.

Thanks Pete Just as an idea, would it not be better to use the tag prefix drop-down instead of using the first tag? So, for forums where anyone can set any tag, you would limit the tag prefixes to 'Request', 'Support', etc. But for forums that have predefined tags, like the modules forum, you use the first tag.

@Peter - LightWire has been out for a while now: NicoKnoll/LightWire-Skin Also don't think it's alpha any more. Pretty stable on my sites. Edit: Whilst it's stable, it still has features to be added... Is that what you're following up on?