Recently we moved our server from testing to production.
We had an issue with caching some referenced scripts so we needed to edit site.master and put some artificial query parameters on our referenced scripts.
From what I thought you wouldn't need to restart IIS simply modifying a .master page, but the other day I tried uploading a handful .master pages because we eliminated some code on them, and the site went down until we restarted IIS.
Any insight to the way IIS and MASTER pages work would be stellar.
Thank You for your help.
Generally speaking you wouldn't necessarily need to restart your website for a change in your master page. However, if you modify the code-behind you need to compile the site, because Sitefinity is a Web Application Project, not a Web Site Project. This means the full site is compiled to a DLL, so any changes in the code require a new compile to be run and pushed to your site.
In addition, Sitefinity makes use of caching to improve performance, so you might need to restart the site to clear the cache for any changes to things like master pages or user control (ascx) files as well.
I hope this is helpful!
Related
I can't found nothing recent on the web about if deleting Default Web Site in IIS is a good practice, i'm using IIS v10 and as in wwwroot i have each website inside it's own folder in IIS i've just created a website for each of them..
So i'm just not using the Default Web Site and i was wondering if will it cause any problem if i will delete it (for now i've just disabled it but seeing it in the list is a bit triggering), about deleting or keeping the Default Web Site i just found an article from 2001 so i would know something more recent about it.
Yes, you can safely delete the Default Web Site in IIS Manager, even though delete the files under the wwwroot. And it should be a good practice to do that to avoid some unexpected web accesses or attack.
And the Default Web Site in IIS Manager, even though the files under the wwwroot, is used for the first validation of IIS installation.
More, the Default Web Site will take the default port 80 if not disabled/deleted.
So, please go ahead to delete it.
On a fresh install of Windows Server 2008 R2 with IIS 7, it creates a default website in C:\inetpub\wwwroot. I'm sure there's lots of subjective opinion on where good places to store website files are, but I'm wondering if I were to create a second website, in addition to the default website, where would the IIS developers have intended I put it?
I'm thinking C:\inetpub\mysecondsite, but I can't say for sure.
You can really put your new web site's files wherever you want on the server. Most people tend to make subfolders for each individual site under the wwwroot. I usually delete the Default Web Site and start from scratch.
For example:
C:\inetpub\wwwroot\myfirstsite
C:\inetpub\wwwroot\mysecondsite
I am using WSS 3.0 in a hosted/shared (read: can make no server-side changes) environment. Unfortunately, between SP and IIS, almost nothing is getting cached, so page loads can be terribly slow.
We have a bunch of custom image, JS, CSS, etc files that are currently just in a /img, /js, and /css directories, all of which are grabbed each and every time the page loads (server is returning "Cache-Control private,max-age=0").
Since I can't do anything with IIS, and can't enable any caching server-side on SP, do I have any other options? I've read in a few places that if your files are located in the layouts directory that they will be cached, but using SP Designer I don't seem to have access to the /___layouts directory, unless I'm missing something....
Thoughts?? Thank you!
Since you are running in a hosted/shared environment I would work directly with the ISP on this one. There are many ways to cache things and the ISP could very well prevent you from doing most of them.
Ask them the following questions...
Have you set output caching on the Page Layouts directory for anon and or authenticated profiles, or at the Site level or at the Site Collection level (overview on how to here)? If not, can you?
Do you have IIS set to compress static files (its not caching, but, will help)?
How much RAM is available to me in this shared environment?
If you have enough RAM, look into caching your custom web parts.
You could also host your custom images, css, javascript etc on a 3rd party CDN (Akami, Amazon Web Services), that doesn't help with your theme and core js/css files.
_layouts is the "repository" for application pages, i.e. pages deployed by sharepoint for performing maintenance etc. through the web UI. It is very well possilbe you don't have access to that folder, it will also not show up in SharePoint designer. You have a couple of options:
If you have a Publishing site, you can enable caching through the site settings.
What you could also do is add the #OutputCache directive to a page you create through SharePoint Designer (Outputcache on MSDN
deploy your site through a solution, which does allow deploying in the _layouts folder
I'm making some changes to a legacy classic ASP application. I've made the changes locally, and now I want to copy the changed files to the server. At the same time, I need to download the Access database, add some fields to some tables, and upload it again. For this reason, I need to be able to stop visitors from modifying the database while this is happening.
My main question is, what is the best way to setup a quick "Down for Maintenance" page that will be shown immediately and no matter which page the visitor requests. The application is already established, so I'd rather an answer that didn't require me to rework the application's architecture.
My second question (maybe this should be a separate question):
Is there a better way to add fields to a db table than to copy it down, modify, and stick it up again? Please forgive if that's a dumb question - I'm new to ASP - new to Windows too.
I only have FTP access to the remote server.
Thanks.
two ways:
1
if you do a server-side include in every asp page you can do a response.redirect in that include to /upgrading.html
2
in global.asa you can do a response.redirect in the session on start event. THis is probably the best way. Will only work for .asp pages, not if the client comes to a .html page.
Do you have any control panel access to the site at all?
When I used to run a number of ASP Classic sites I often turned them off for the five minutes required to do what I needed.
Rude to do to your visitors I know.
As others have said you could redirect to a page, but that won't stop people visiting static content in html pages, but then that probably won't matter, at least it stops them making changes to the mdb whilst you download it.
It's a pity that ASP.net's app_offline.htm doesn't work for ASP classic.
Another option I used to use was to create a default.htm file that had the offline message, and the way IIS was setup default.htm overrode default.asp, so simply uploading default.htm changed the homepage. This of course doesn't stop anyone using any of the other .asp pages.
So no real answer! Sorry.
If you have just FTP access to the server (and no control over the IIS) just insert a response.redirect to the "down for maintenace" page in top of all the asp pages, and remove it when the update is completed.
The changes to the database can be performed with the ALTER TABLE statement.
With regards to the "Down Maintanance" page issue you can and taking mapache's idea a step further if there is an included file (for a header) in each of the pages you can put the Response.Redirect in that one file and upload that in place. This will avoid making changes to all pages.
Another option is to upload a temp html file which will be found first by IIS. In IIS you can set which page name.ext are looked for in a domain/folder. For example when you browse to www.example.com you don't specify the page you are looking for so it could load index.html or index.htm for example depending on setup. It will depend on your hosts configuration setup, but a bit of trial and error I'm sure you can find out which one they use. Common ones for IIS are default.htm, default.html, index.html and index.htm. You can then put it in each of the folders in the website (not ideal I know) and then carry out your maintenance.
When updating databases you can run a migration script, written in sql, to update the schema and data of the db. As you only have FTP access this will require some sort of page you can paste the sql into and run. This however opens security issues so downloading the db, making the changes and then uploading again is probably easier. In addition to doing it this way you can also save the file and you'll have a backup :-)
Hope this helps.
Better than an include file, just use the Global.asa.
In the Global.asa's Application_onStart, add
Application("Offline")= True
at the top of all of your ASP files, add
If VarType(Application("Offline")) = vbBoolean Then If Application("Offline") Then Response.Redirect "App_Offline.htm"
(The double-if gets around the lack of VBScript's short-circuit operators, and therefore any data type errors.)
You could even set the Global.asa code to
Set fso= Server.CreateObject("Scripting.FileSystemObject")
Application("Offline")= fso.FileExists(Server.MapPath("App_Offline.htm"))
Set fso= Nothing
Which would enable the offline page if it exists, like ASP.NET. However, the application start code is only reparsed when the server is reset (using iisreset), or when the Global.asa file is modified, merely adding the App_Offline.htm will not be enough.
Add below code in web.config
<?xml version="1.0"?>
<configuration>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
</configuration>
And place app_offline under root folder. This will work.
I am developing publishing site. I have some layouts that are pre-populated with web parts and have a problem when I need to make some change on the layout.
Deployment succeeds but I still see old version. If make I change in SP Designer it is reflected OK but not if the change is done by the feature that is being deployed.
It looks like after I deploy particular layout any site collection in that web application will have the first version.
I have tried deleting complete site, all the pages, layouts and nothing happens, after deployment I still see old layout.
Current solution for this problem was that I take new virtual image and start with clean machine.
Real problem is how to solve this on clients installation without reverting to clean machine. There will be some bug fixes and I will have to send new WSP file with some changes in layout.
Is there any way to force SharePoint to use newly deployed layout and not some old Unghosted version?
If the layouts are without web parts I don't have this problem.
Update
I am using default "Publishing Portal" and deploying layouts using features. For development I am using VSeWSS 1.3.
tried in SharePoint designer to detach page from layout and attach it again but still no results.
Since you are using VSeWSS, you can execute your own code upon feature activation. So try writing an SPFeatureReceiver that will call SPWeb.RevertAllDocumentContentStreams() to reghost directly after feature activation on the web(s) in question.
If this doesn't work, then the problem isn't about ghosting, maybe it's about Orphans then. But try this first.
If it's a feature that you are deploying you have do deactivate the feature and activate it after deployment again. And don't forget to do an IISRESET or an AppPool recycle.
If your new site collection has the first version of the layout make sure that it is really your new feature version that you are activating.
Try to reject your solution first and add the new one after that.
Are you using Site Definitons or Site Templates? If you are using either of these it may not update after initial provisioning.
Try completely retracting and deleting the solution from central admin, resetting AppPools and then redeploying the solution.
Make sure your element manifest for your feature specifies that existing files should be overwritten.
Looks like some folks have had problems with layouts too...
See http://msdn.microsoft.com/en-us/library/ms459213.aspx
If you are developing new sitedefinition, you can attach your new layout in the onet.xml file by using the property, i hope it will help you
-->