|
Lee;
This month's issue of your magazine was very interesting. Like most DNN developers, I too will have to
maintain a local copy in a production copy of my website. I am always interested in better ways to
synchronize the two sites. I feel that
you missed a couple important issues
in your training video.
- The
first issue is that the text module requires “fix up", to correct the
pointer to the image location, which is different between the localhost
and production sites. You also
neglected to mention that any files such as images must be moved manually. You cleverly got around the issue in
your video by pointing to images distributed with DotNetNuke.
- It has
been my experience that several other modules also require some fix-up
after being moved. For example,
Ultra Media Gallery 3.0 requires rebuilding of the cache by editing one
entry per module.
It would be interesting to know if you have actually tried
this synchronization method on your production website with serious changes
having been made on the local site. I would be interested in how well this
methodology worked for other modules such as: Forum, Blog, Repository and UDT especially
if any images are involved.
My current strategy for synchronizing my websites is as
follows:
- I do
all page/content development on the production server on pages that are
only visible to developers. If the
page being developed is a major change to an existing page, I cut and
paste the content into the old page at the time that I want to make it
visible. This is done this way to
keep Google’s index happy. If the page being developed is a new page I
just changed its settings and make it visible when I wish to expose.
- I do
all skin development on my local site.
I zip them up and installed them on the production site and test
them on a test page there. When I wish to make them visible by merely have
to change the site admin settings.
- A new
module/application development on my local site. Since I use ListX for most of this
development I am able to extract the XML files and installed them on the
production site. I'd still have
issues here with image files such as buttons.
My current ISP provides a backup methodology that zips up
all of the files and a backup of the database in a single zip file. This makes it very easy to download and
install locally.
In my main portal on the production site I keep portal
aliases for each address that I use locally: localhost/asi3, dsnow2.dnsalias.com/asi3, and
192.168.5.12/asi3. This way I don't have to add them after I have downloaded
the site. Because the ISP has the SQL server on the same local host, I could
actually move the data and not have to edit web.config. However, I have elected to name the databases
differently just to make sure that I don't edit the wrong one.
I use your methodology from Issue 22 to do all of the image fix-up. Since my
site includes several parent portals I have adapted your process to fix them
all at once. I have a two-step process to do that. First I execute “Replace_DesktopHTML '/Portals/','/asi3/PortalX/'” then “Replace_DesktopHTML '/PortalX/','/Portals/'” This process will loop if you try to do it
in a single step.
I usually disable Snapsis PageBlaster on my local site just
to ensure that its caching isn't getting in my way.
When I get to a good point in my development I move skins
and modules to the production site. Then
I clone the production site back to my local host.
Keep up the good work. You always seem to be thinking of how
to help us develop,
/DaveS
|