Confused about mappings

Hi, I’m trying Komodo again, after several years away from it. The language is PHP 5.4.37, Komodo 10.2.0, IIS 7.5.

Regarding this error message,

The URI ‘file://////99.999.999.999/C:/inetpub/myapp/index.php’ could not be opened. You can use a URI mapping to specify an alternative file location. Without a mapping, Komodo will display a read-only copy of the file contents. Would you like to setup a mapping now?

I have a few questions, relating to this message. My background is primarily in programming, and most of that time, somebody else manages the server, and moves the code from local development to Test; or from Dev to Test, and they then move it from Test to Prod.

Right now, I’m trying to work directly in the Dev environment, using the Dev server, rather than localhost on my PC. Since this is the first time I’ve tried to configure any tool to work directly on the Dev server, it’s a little confusing.

I’m able to single step through the code – although the debugging session often reloads the same module, instead of reusing the one that’s already open. But the main problem, is that I can’t edit the files within Komodo.

So, when the server connects with Komodo, from

, and asks me if I want to connect (I click Yes), it then displays the above message, always.

I’ve tried setting up mappings between the uri, but it keeps asking me again, and then I have to click ‘No’ to the Mapping prompt, in order to proceed. And so in my debugging sessions on the Dev server, it’s readonly, so I have to edit the documents in another IDE or text editor.



Maps to: \99.999.999.999\c$\inetpub\myapp

Side question – why does Komodo add all of those forward slashes – 6 of them – to the IP address, in the error message?

It’s obvious that I’m missing something about the format of the mapping. But, since I don’t usually deal with these directly, it’s hazy right now.

If anyone could make some suggestions and forward links with more details for understanding this, it would be much appreciated.


\99.999.999.999\c$\inetpub\myapp does not look like a valid location, the whole point of mapping is that you are mapping a remote location to a local location. Mapping a remote location to a remote location should not even be possible I believe. @careyh can probably confirm.

I think I understand. But that’s the location that I use when editing the files, either in a text editor, or an IDE. It’s the exact location (aside from the 9s and the ‘myapp’ reference) that appears in the Total Commander window.

Maybe what I’ll have to do, is remote over to the Dev server, and install Komodo there.

You could also try mounting the remote location. As far as Komodo is concerned the location would then be local.

Beware that performance won’t be as good as working with files locally though.

That’s an interesting idea. Just map it to a drive.

Ok, will try, thanks.

Ah sorry, you’re on Windows. I’m not confident if that’ll work on Windows, but it’s worth a shot.

No go. Even when I set up the mapping from the M: drive to the uri, it still pops up the same message, and refers to the PREVIOUS mapping. I already deleted that previous mapping, and saved the M: mapping.

Yeah mapping is not exactly the same as mounting, I don’t think you can do that in Windows.

Another thing you could do is have a local checkout of your code repository and use Publishing to push remotely. Ideally though you would use version control for this type of thing.

Meaning, just develop in locahost, which I’ve been doing (not in Komodo).

That’s fine, of course. Quick and convenient. But then sometimes errors occur on the server, that don’t occur in the local development environment. For example, the root folder $_SERVER[‘DOCUMENT_ROOT’] is different, between the two environments, and it leads to different results when checking paths.

Those problems occur, when using the built-in server, for the given IDE. Maybe what I should do, is set up my own IIS server locally, and use that for development. Does that sound right?

Yeah generally that’s a good approach; mimic your production environment locally. There can always be differences between environments. Generally in software development you have several environment “stages” to account for this; local/development, which has all the debugging tools. Then QA whish is for testing on a dedicated environment which may have some debuggint tools. Then staging which is essentially an exacy replica of production without actually being public facing. And finally production, which is your live environment.

Often you’ll see developers just use a development and production environment, sometimes they’ll have either QA and staging but rarely they’ll have all 4. I’m sure there’s also variations of the approach I explained, but that’s the one I’m most familiar with.

I would recommend at least having a separate development and production environment.

We actually have 4 environments - one is the local environment, which generally uses the built-in web server for the ID; and then the Dev, Test, and Prod. Most of the time, I’ve used the local environment, gone to Test from there, and then to Prod.

But anyway, we’ll try setting up an IIS server locally. They’re giving me time to explore this, so might as well take advantage, and learn something.

Ok, thanks nathanr.

That’s great :slight_smile: Good luck!