Mike Rockett

Have just pushed an update to the dev branch, but the feature is not yet complete.

This is what the editor looks like now. Just trying to figure out the above regarding the assignment of the selectors before I push to the dev branch - if anyone could help me out with that, I'd appreciate it.

Above response was for your original post. Using the title is handy for smaller sites, but I do actually agree with you. Much of the module is really me testing things out. For consistency reasons, I'm going to make it dispay the path instead. Regarding font sizes, those were deemed best for the common 1366x768 resolution. Anything larger than that, and it just doesn't fit nicely for me. Sure, on a large screen (if I remember correctly, you're using a Mac), it would appear differently. For the time being, I'm going to leave that as it is. 404 Monitor is in dire need of an upgrade, which is one of the aspects that prompted me to do a rewrite. It's usable in its current form, but can easily get overcrowded. Also, it's limited to 100 404s (it stores all of them, though), which is something I'd like to deal with when it becomes a separate module. Glad you like it

Hi Peter - Jumplinks is my own successor to Redirects. It was originally developed for Bolt CMS, but has now been fully adapted for ProcessWire. At present, yes it's stable. All the issues that have been encountered are closed, and don't have any complaints so far. I think that Jumplinks is called earlier that Redirects in the event chain, so no clashing on that front. If the same redirect is defined in both, then Jumplinks will redirect first, and the Redirects module will not do anything. (I haven't actually tested this, but it should be the case.) I do have plans to upgrade Jumplinks - it's really more of a coding issue than a practical one. Essentially, the module will remain mostly the same, and the upgrade will be seamless. Unfortunately, I don't get much time to look at it - as such, I remind myself that the current version is stable, and ready for production use, and so it isn't really an issue when I start writing Jumplinks 2. However, the major part of Jumplinks 2 will be that the 404 monitor currently included with the module will be removed, and made available separately. Give it a spin - if you like it, you can switch over. When I'm done with v2 (which won't be any time soon), you can upgrade with no hassles. In the meantime, I do want to add the feature you suggested for Redirects, I think it's definitely quite useful for large sites.

Sure, that was your original. Now that I'm working on a new feature, it's better off in the Jumplinks thread. Edit: My apologies - I'm not keeping tack of the conversation properly (I can be quite a scatter-brain sometimes)... Nonetheless, I'm adding your suggestion to Jumplinks, and have asked for a little help on that thread. I do agree with what you need though. Thing is, I don't think Redirects is being updated anymore.

Now I need help with something... When selecting a page via the tree, its ID is added to the text field so that Jumplinks may process it easily. Now, how do I accomplish the same thing with AutoComplete? Checking pageSelected doesn't seem to do it. The event doesn't get called (tested with an alert). Additionally, how do I set the AutoComplete value when the tree is used? Lastly, how do I set the tree value when AutoComplete is used?

Continued from here... @PeterKnight: So I'm nearly done with this. One thing I need to know is this: how do I get AutoComplete to only allow one page selection? By default, it allows more than one, and there doesn't seem to be an option to prevent that... Edit: Nevermind, got it - maxSelectedItems

I'm moving the remainder of this conversation over to the Jumplinks thread.

Okay, so I'd use both fields (the auto-complete field would be off by default, and would be enabled in config), and the last one to have done an update - that is, the last one used - will fill the Destination field. Easy enough - will give that a shot now.

Yeah, it did cross my mind for Jumplinks 2, but I may just implement it sooner. Reason being: Quite a bit of non-dev work going on at the moment, which is taking up a lot of my time. I'll try and do something this afternoon - probably will make it an option. Though, you say you'd love to see it as an additional field - why have both?

Glad you like it! Your example can be made shorter, too: blog/{year}/{month}/{day}/{title}/ The bits between the curly braces are just identifiers for types. There are no actual length limitations. You could swap title out with name, page, post, user, model, or entry, which all assume the type segment - these are known as Smart Wildcards. If you wanted to give it another name, such as postname, you'd need to define the type in the Source as well: {postname:segment} As a recommendation, I'd also make the trailing slash optional, just to be sure. blog/{year}/{month}/{day}/{title}/?

Seems this has been put to one side... Have asked if there are any updates on their end.

Jumplinks uses 301 by default, but uses 302 if you specify that a redirect should only occur during a certain time.

Any time. Side note: That's quite a lot of redirects - perhaps you might want to give Jumplinks (links in signature) a try. It has wildcard support, which will, more than likely, reduce the amount of redirects needed...

Correct - I think that may be the case, @elabx. Simple fix: footer p:last-child { float: right; width: 180px; text-align: right; }

Yup. Module uses $session->redirect().

I have a feeling that current additions (2.6-dev) will bump PW up to 2.7. Perhaps then Ryan will start putting most of his focus onto 3.0. From the roadmap (which hasn't been updated recently):

Due to the fact that every server is different, the figure would be an average, which I don't know. Maybe someone else can shed some light on that. I would recommend only removing redirects when it is determined that they are no longer being hit. Jumplinks provides this functionality - each jumplink has a hit counter and, when you hover over it, you are told when last the jumplinks was hit. That said, I prefer to just keep redirects up permanently. Others may prefer to do it differently.

For those amounts, I'd defintely recommend one of the two modules. The speed difference is hardly noticable. If you had a lot more page views and very little memory on your server (the chances of which are very slim these days), then I would recommend .htaccess so that the ProcessWire system does not need to boot up for every redirect. Also remember that once you have the new links on your site, search engines start indexing them, and remembers that you have permanent redirects. So, over time, the redirects won't even occur.

The two rules should appear immediately after RewriteEngine On so that those redirects are the first things checked for, before any other rules are checked. I'd only recommend using .htaccess if you have a few redirects and a small site with not many daily visitors that would hit the old links. As an alternative use the Redirects module, or my own Jumplinks module, which might save you some time as it does support wildcards. Running these modules on a small site won't affect performance at all.

Better to use mod_rewrite: RewriteEngine On RewriteRule ^providers/provider1$ /region-provider/region1/providerName1 [R=301,L] RewriteRule ^providers/provider2$ /region-provider/region1/providerName2 [R=301,L] Does providers/provider1 actually exist in the ProcessWire page tree?

Specifically, I'm referring to sub-pages of story-of-the-month. By making a request to story-of-the-month?article=9, it's really a request to story-of-the-month, which exists. As such, the only alternative is to use mod_rewrite (the following two lines should be placed directly under RewriteEngine On): RewriteCond %{QUERY_STRING} ^article=(\d+)$ [NC] RewriteRule ^(story-of-the-month)/?$ /$1/%1 [R=301,END]

Because Jumplinks reacts to the 404 event, only requests to story-of-the-month and story-of-the-month/ would be excluded. However, a request to story-of-the-month/something-that-does-not-exist would be sent off to Jumplinks.

Please share what you used for the Source and Destination fields in your jumplink? To me, this is unrelated due to your use of $myStory, which looks like a PHP variable, and not a Jumplinks wildcard. Also, does story-of-the-month exist in the Page Tree? If so, Jumplinks won't do anything with it as only 404-hits are handled.

Redirects does not support wildcards, which is why Jumplinks was created. In your case (I assume your intention here is to drop the .html extension from all requests), you would create a jumplink like so: Source: {all}.html Destination: {all}/ Alternatively, you can ask Jumplinks to check common extensions (such as .php, .htm, .aspx, etc.) by using the {ext} wildcard: Source: {all}.{ext} Have a look at the Wildcards and Smart Wildcards documentation pages for more information. If you would prefer to use mod_rewrite, then you can use this as the very first rule, just after RewriteEngine On: RewriteRule ^(.*).html$ /$1/ [R=301,L]