Mike Rockett

That did it, thanks Soma. I gave the isPermanent field an id.

(I hope I'm not missing something silly here - but I have checked around, and can't figure it out.) I have two checkbox Inputfields in a form. One is called isPermanent, and the other is called delete. When isPermanent is checked, delete needs to disappear. The following selector us being used: $deleteField->showIf = 'isPermanent=0' Now I think I'm having a bad time with checkboxes (I had an issue with them in ModuleConfig). I've noticed that, even if I pass value = 0 to isPermanent, the value stays at 1. The issue here is that the delete field is not hiding when I check isPermanent. Am I missing something?

For those interested in testing, please use the latest code from GitHub. (Still versioned 0.1.2, but with quite a few changes.) Please test in the latest PW dev, this is now intended for PW 2.6.

My bad, thanks Soma.

Greets So, I'm not clued up when it comes to localisation stuff, especially when it comes to modules. I've seen some modules using __(), and others using $this->_(). What's the difference? If none, is it just a matter of preference?

Indeed, it is working now.

Good site indeed - well done (Contact page still isn't working...)

It probably has something to do with the fact that admin themes were, once upon a time, not handled as modules. So, somewhere along the line, it loads up `templates-admin` instead of the module. Hope Ryan completely removes it when 2.6 comes out... /Nudge /Wink

Just pushed the module onto GitHub. Also keeping a Master Task List.

Very interesting thing just happened. The pre-2.4 admin theme just popped in to say hi, and then it disappeared again. I basically installed ModulesManager and then used that to install ProcessWireUpgrades. Then when I clicked on Setup: How on earth? And why does it still even exist?

Great! Yeah, I just had a look at their website. Can't say much about them, but they're certainly not a modern hosting company. And I see their usage over time has gone down (the past few months, in fact). If you ever feel unsure about your hosting provider, then I would recommend that you do a little research and find a new, better one. A quick search yielded 1and1 Italy, and Register.it.

I've been meaning to do that for a while - in a search for a good solution for a client. Would also be interested to know their experiences.

At this point, the module is quite feature-rich. As such, I'm pausing development. This gives time for those testing the module to do so without me introducing new things every three seconds, and it also gives me time to prepare for the whole 'back to work' thing - I return on Monday, and need to prepare for it. I'll still be here to discuss things, but there won't be any changes for about two weeks. Looking forward to the results/feedback of everyone's testing. Update: Lol, the stuff I had to do couldn't be done today - so there are a few changes up on the repo now.

Okay wait, something broke with collections. Looking into it... Update: Nevermind, I didn't test properly. Hehe! It works

<development post> New Alpha Release - 0.1.2 (Breaking Changes) This module introduces a new feature: Mapping Collections (this is the final name for it). The feature allows you to map key/value pairs to your redirects so that you need not repeat yourself. An example would be the following: Redirect /blog.php?id=2309 to /hello-world/, by using the following redirect: blog.php?id={id} => {id|pages} You're wondering, what's {id|blog}? Simply put, that's called a mapping reference, which refers to an entry in a Mapping Collection. A Mapping Collection, in this case, would look something like this: 1=a-post 2=another-post 3=third-post ... 2309=hello-world So, when it comes time to redirect, it will scan the provided id against the collection called blog and, if it finds a match, will redirect accordingly. If, however, there is no match, the segment that asked for the mapping will be left out, resulting in an invalid URL. I may get it to insert the original capture instead. Some Screenshots: -- -- -- Full Changelog for this release: [6 Jan] - Some refactoring; moving code blocks from main module to UtilityProcess - [New Feature] Mapping Collections - Changed module title to Advanced Redirects [ALPHA] Breaking Changes: The DB schemas have changed in this release. If you already have 0.1.0 or 0.1.1 installed, please uninstall it first.

Thanks for bringing that up, Steve. I did indeed think about this earlier, and made a comment on my to do list: "Find out if we should prevent the deletion of 301s". Granted, that isn't the right question to ask, but it reminds me to look at the various options regarding this. I think your idea is quite good. After such period, should we prevent the deletion of redirects? And what does everyone else think about this?

@Faisal - not sure if this will make a difference, but have you tried the Upgrades module?

Great (Also, I'm busy working on the Mappings feature.)

What was it anyway?

<development post> New Alpha Release - 0.1.1 The full changelog is below, but I want to highlight an important addition to the module. In its present state, this new feature is classified as an experiment, and so it may not make it into the final 1.0 release. The experiment is called Enhanced Path Cleaning which basically splits and hyphenates TitleCased wildcard-captures, as well as those containing abbreviations or acronyms in capital letters. This is quite handy for those who come from a DNN background, or some other ASP-based framework. As an example, EnvironmentStudy would become environment-study and NASALaunch would become nasa-launch. It also changes any numbers that are not broken out with hyphens. You'll need to turn the experiment on in the module's config page, as it is off by default. Example from scan log: Page not found; scanning for redirects... - Checked at: Tue, 06 Jan 2015 10:20:20 +0200 - Requested URL: http://processwire.local/NAGMagazine/home/tabid/1027/default.aspx - PW Version: 2.5.13 [ASPX Content] - Source Path (Unescaped): {path}/tabid/{id}/Default.aspx - Source Path (Stage 1): {path:segments}/tabid/{id:num}/Default.aspx - Source Path (Stage 2): ([\w/_-]+)/tabid/(\d+)/Default.aspx - Destination Path (Original): {path}/?otid={id} - Destination Path (Compiled): processwire.local/{path}/?otid={id} - Destination Path (Converted): processwire.local/nag-magazine/home/?otid=1027 Match found! We'll do the following redirect (301, permanent) when Debug Mode has been turned off: - From URL: processwire.local/NAGMagazine/home/tabid/1027/default.aspx - To URL: processwire.local/nag-magazine/home/?otid=1027 Changelog [5 Jan] - Modified Module Config page - Simplified wildcard and cleanPath() expressions - Added 'segments' check to 'segments' smart wildcard, where only 'path' existed before - Added 'num' check to 'num' - Changed ellipses style (added border) - Made Legacy Redirects temporary (302) - Fixed CSS #ModuleEditForm declaration so other modules are not impacted by the style change - Changed CSS p.notes to p.parNotes so we don't conflict with anything else - Other small semantic code modifications [6 Jan] - Added Experiments fieldset in Module Config - Added Enhanced Path Cleaning Experiment - Removed license file, refer to http://mikeanthony.mit-license.org/

Perhaps you have a browser extension that's messing up your JS? (And the chances are, if it is, that there won't be a console log of it...)

Depending on your browser, you can also try Ctrl+F5, or Ctrl+R (some browsers have both). If you're using Chrome/Opera/Safari, open up developer tools (the console), go to settings, and make sure cache is off. Then leave it open and refresh the page. If it's not that, then an alien has taken over your PC, and I wouldn't know what to do, I'm afraid.

I've made few changes, which I'll be uploading tomorrow morning as v0.1.1. Some of it is to do with bettering my code (specifically in the way of Regular Expressions), and the rest of it is to do with better path cleaning, and a few backend CSS fixes.

Have you tried with any other versions?

That may be because you switched these two rules around when you were encountering problems: # ----------------------------------------------------------------------------------------------- # Pass control to ProcessWire if all the above directives allow us to this point. # For regular VirtualHosts (most installs) # ----------------------------------------------------------------------------------------------- # RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] # ----------------------------------------------------------------------------------------------- # 500 NOTE: If using VirtualDocumentRoot: comment out the one above and use this one instead. # ----------------------------------------------------------------------------------------------- RewriteRule ^(.*)$ /index.php?it=$1 [L,QSA] As such, it's looking for index.php in the root of domain, not the root of the installation. If you swap them around again (comment the second one, uncomment the first one), it should work. Please let me know if it doesn't...