Skip to main content

Deleting a site 'does not' remove sites folder/sub-folders - is this by design?

Permanently deleted user

@Latitude - intrigued why deleting a site via manager does not completely remove the site contents (site folder & subsequent sub-folders/viewer.xml etc).  Deleting a site appears to simply remove the site.xml from the sites folder.  

(OR is this a permissions issue as a result of me running under NetworkService User (i think not since i have enabled it to have full control).)

If this is by design, i don't understand why. If i delete a site, i want the site to be completely removed.  While it doesn't cause any immediate issues when recreating sites, it makes back-end administration somewhat confusion.  If it is by design, i will raise a enhancement request for considering amendment to this functionality.

Brad

0

Comments

7 comments

Date Votes
  • Permanently deleted user

    Hi Brad,

    This is a holdover from the original configuration of Essentials that stored the Sites in the "App_Data" folder of the web application itself.

    App_Data is a data folder that is monitored by the ASP.NET application.  When you delete a folder from a managed ASP.NET folder, ASP.NET will recycle the app pool.  This leads to the unfortunate problems where "deleting a site" would cause "sudden termination of REST Manager session".

    We no longer store Site files in the App_Data folder but this behaviour remains.  I'll file an improvement request in our bug tracker to update it.

    Regards,

    -Malcolm

    0
  • Ryan Cooney

    In the next Essentials release when you delete a Site it will additionally delete the Site's "Viewers" folder. This should take care of most of the extraneous files. However, we won't simply delete the entire folder that contains the Site because this folder may contain shared content like workflows and reports.

    --Ryan

    0
  • Permanently deleted user

    Malcom / Ryan, thanks for the feedback & clarification.

    My only comment (Ryan) is its poor design if you go & share resources @ the site level & my take on it is that deleting a site should delete the site.  If the administrator is not considering these factors in their design then their poor design on their die.  If you were to implement a solution whereby the site was deleted completely they would learn quite quickly to not share resources at site level.  I can see both sides of the story but i'd prefer clean functionality rather than have built in functionality to cover poor site design. 

    Regards

    Brad

    0
  • Permanently deleted user

    Thanks! Encouraged by this thread, I have gone and deleted a number of already-deleted sites, and now I can better understand what's left in the Sites directory.

    And I agree (I think) with Brad. There are already quite a few places where site (and site viewer) resources can be stored:

        \inetpub\wwwroot\SilverlightViewer_1_4\ClientBin\Resources

        \Program Files (x86)\Latitude Geographics\Geocortex Essentials\Silverlight\REST Elements\Sites\Resources

        \Program Files (x86)\Latitude Geographics\Geocortex Essentials\Silverlight\REST Elements\Sites\<site name>\Resources

        \Program Files (x86)\Latitude Geographics\Geocortex Essentials\Silverlight\REST Elements\Sites\<site name>\Viewers\<viewer name>\VirtualDirectory\Resources

    Is there a good reason to allow a site to use another site's resources? It seems to me that sites should only use resources that they own or that are directly in line above them in the folder hierarchy.

    0
  • Permanently deleted user

    As with deleted sites, (Silverlight) viewers deleted by REST Manager appear to persist in {SitePath}\Viewers even after deletion.

    0
  • Permanently deleted user

    Brad and others,

    Your comments about 'poor site design' has prompted me to ask whether you could share any good design principles that we should consider when setting up Geocortex Essentials and Optimizer? e.g. Location of shared resources, permissions, file management etc. i.e. anything that goes beyond the published administrator guide?

    Thoughts and any lessons learned would be much appreciated

    Rob.

    0
  • Permanently deleted user

    HI Rob, 

     

     

    I think the current documentation lacks details when it comes to recommended site (including viewer) architecture, namely from a deployment perspective.

    The type of things i mean are:

    • Sites:  
    • I tend to keep a site self-contained (e.g. i tend to avoid sharing resources such as templates etc since it makes it that little bit harder when migrating between environments (such as dev, test & prod).  The geocortex install & samples doesn't necessarily follow this rule & i can understand your trying to demonstrate the added value of sharing resources.
    • Migrating a site from one environment to another:  so its literally a matter of a copy  & past of your url strings relating to your enviro but this isn't documented anywhere.  Its fine if you know how to do it but its not spelt out anywhere how one does this).
    • Security:  Bit of a varied topic since we all have different enviro's & hence different configs but i think unfortunately the current details lack the 10% of lower level config (particularly when it comes to permissions (when for example using a custom provider under the network service user)) which can be time-consuming to resolve.  This topic however sounds like its easier when you got to a server 2008 enviro (which I'm not just yet!).
    • Viewer deployment:

     

    One could see this type of info being available as knowledge base articles to be as useful as documented material but i think given the importance of the topics they should be clearly documented for new starters to get it right from the start.

    Hope this helps & gives you an idea of the types of things i think good benefit geocortex administrators.

    Brad

    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post