peter schotman wrote
| ROBAX wrote
to work directly on the ASCX files live on the server, I do that, but using Expression Web. It makes skinning much easier.
|
Rob, can you tell us how you do this?
Thanks, Peter
Sure thing. I'm still planning to write up something more permanent about this, but I'll run over a few points here.
Why should one even use a web editor to work directly on the server? Because it's vastly more convenient than using an FTP app as a mediator between the server and your editor; and I wouldn't even begin to try working off-line and syncing to live - that's just a huge drama and a waste of time. EW is highly suited to customizing skins, module and portal ascx files, vb files, module templates, CSS files and also script files. It is not suitable for working on portal content.
One point above all others:
- Back up before doing anything and don't blame me for stuff-ups
Remember that Expression Web (EW) uses the same server extensions that are used by other MS programs including Sharepoint and Frontpage. The first thing you have to do is learn to ignore all the misleading and ignorant statements you'll hear about that. All you have to know is that the extensions perform the very valuable task of managing files and users. Every useful web app has a way of doing this, even DNN. What we're doing here with EW and DNN is have two (three if you count Windows itself) such systems overlapping each other on the same set of files.
The first thing to do in order to manage a DNN system with EW is turn it into a Web. This can be done with your Server Extensions management tool in IIS. There are two things to know about - Permissions and file-stubs. One can create a new blank web and build a DNN portal in that, or apply the extensions to an existing portal system. It is only done once and doesn't matter otherwise.
Each time one applies or reapplies the server extensions to a web, the file permissions will be reset to suit EW. Normally this only happens only once, the first time the web is created. The trick is, after creating the web, apply DNN permissions to the web folder via Windows Explorer or your host control panel - exactly as you normally would when creating a DNN site. Once this has been done, EW will respect the file permissions and any new files uploaded or created in EW will gain or retain the correct permissions. I simply create a new website in EW, then apply the DNN file permissions, then unzip the DNN install package and upload it via EW. Upgrades are done in the same manner.
So, after the initial application of DNN permissions to the EW web, nothing further has to be done to make the systems compatible. You can now work on all portal files using EW. You can even use EW to publish the web to another location. Like FrontPage, EW publishes only changed files and this can be a convenient way to mirror the file system to another server or your local computer. I used to use that as my local backup but now I'm using a system of zips and am exporting the db to go along with them.
The other thing to deal with is the file stubs. The server extensions keep a record of what's going on with the file system by creating a tiny record file for each file in the web. These are held in those _vti folders that are often seen on IIS webs. These can normally be ignored and left to do their business. However - there is one place where they do matter. - and this is the second significant point to learn here.
The first thing to note about the stub files is that they only get created when a folder is either created by EW or when a folder that wasn't created in EW is visited using EW. The first time EW looks in an unknown folder, it will create the _vti_cnf subfolder and put a stub in there for each file it finds. That is normally perfectly fine as it will then manage the changes to file in that folder. However, it is not fine in folders containing portal contents.
Two things happen as a result. First, after DNN syncs the file system, DNN users will see those files and folders in file-selector dropdowns and in the file manager. This can be confusing for users and I've put two or three tickets in Gemini over the years requesting that DNN hide those folders (ones beginning with an underscore - which is Microsoft's own means of hiding folders, and oddly, DNN uses it for the portals/_default folder) from view.
The other thing that happens I didn't discover until a little later, and this really makes the issue of hiding the folders a little moot. Many modules create their own folders when a user creates content. This is normally desirable behavior because it means the module is also planning to clean up after itself when the user deletes said content via the module interface. If one visits one of those folders with EW, then the stubs will be created. When the user deletes the content, the module attempts to delete the folder but can't do so because of the stub files it hasn't got a record for.
That second point was a problem for me early on, but the solution is clear and obvious. There is simply no need to browse portal content with EW. Just stay away from the portal folders and there'll never be an issue. The same goes for any other folder.. just don't browse folders you don't want stubs in.
There is a further solution to the whole stub file thing.It's a simple task for those with remote desktop to search the DNN system for "_vti" then select all and hit delete. EW doesn't care if it finds the stubs or not. If there are none, then it will create them, and if you're working on skins, then it's fine to have the stubs.
I spend most of my time in EW working on skins and in the desktopmodules folder, and occasionally I'm altering things in admin, controls, js and the FCK folders. I've been doing this since using FP2003 and i really wouldn't do it any other way. I keep backups of altered files simply but copying and pasting a file on the spot. One of the biggest conveniences with EW and even more in EW2 is the way it checks syntax for everything and suggests the right code in the right place. I've learned how to be a complete hack developer by simply hitting the spacebar to see what possible attributes and tags I can add or change. And nothing beats EW for CSS.
I think that's pretty much the article I always planned to write about it... and this is as good a place as any.
Just remember these three points:
- Create or convert Web first
- Apply DNN permissions second
- Don't put stubs in the portal content folders - or remove them afterwards if you have.
Rob