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
Related
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!
There are two types of pages in sharepoint. Application and site pages. In site pages if we want to customize them, are we not able to use the server side code? If so why? I saw an article related to this in MSDN.
Generally what is meant by customized here. Adding a webpart through the code is customization? Please explain me any one.
Without a web.config modification (not recommended), Site Pages do not support server side code (either inline or in a code behind file). This is primarily for security and performance reasons. Unlike Application Pages, Site Pages can be added or modified in SharePoint Designer and, in a limited fashion, through the browser.
Normally, there are many more users with these privileges than those users that have access to the web server. I'll leave it to your imagination to consider some of the insecure or inefficient server side code some of these users could create.
In addition to custom web parts, see Where's the code-behind for sharepoint aspx pages? for server side code options within Site Pages.
When you're doing application page, you're storing the aspx with the 12 / 14 hive (SharePoint installation directory) and you're free to use any code behind class / component that you want to use. The original aspx file will stay in the physical folder of the Web Frond End
On the other side, when you're creating site pages, you're adding a new entry within the content database and not on the file system. Even if you have a site page template, you need to add safe entries to your web.config to trust the assemblies.
For the site pages, it is suggested to work with WebParts. They will allow you do do any business / core logic with the actual page, list, web, site.
When they talk about customization, they talk about modification done to the site pages that will alter the original definition. A site page provisioned through a web definition will stay "uncustomized" (ghosted) in the file system until it is being edited.
I'm creating a custom master page for my SharePoint 2010 publishing site. There are images, css files and js files associated with this custom master page. Where should they be stored?
I'm using the SiteAssets library for now - is this a good choice?
Thanks.
Yeah that is a good choice, also make sure you Provision all these files using Feature, this way upate of Files becomes easier.
In my opinion, you should store everything under the site collection libraries, this way you get:
Easy recovery in the cases you need to re-install the server[s]
Versioning and permissions on resources
Separation of resources between site collection
Simple deployment between environments, as you do not need to copy the files manually or design and deploy a feature to do it for you
The preferred place is of course Style Library, this is what it is intended for.
If you are creating and deploying your files through code, you can also use the _layouts directory to store your files. This makes it simpler to share files between site collections. Visual Studio 2010 makes it really simple to add a reference to the Images folder and any files will then be deployed to the _layouts/Images URL.
The only advantage of this is that a site collection administrator cannot make changes to these files, only someone with access to the physical server. (Although this can also be a disadvantage if your logos or images are changing regularly).
I usually store them in _catalogs/masterpage/ORGNAME/...
You can refer this blog for actual implementation
http://markviky.blogspot.com/2010/11/sharepoint-2010-web-content-management.html
-Vighnesh Bendre
I realise that Sharepoint in asp .net based but I have a PHP application that a user wants me to include in a Sharepoint site.
So is it possible to use PHP code inside sharepoint?
danit, when you say 'include' in the site, would it mean to be part of the site chrome (like inside the same menus etc) or just live connected with links would suffice?
I ask that because you can run php code under an IIS site but that would only keep the pages separated inside the same virtual host. if you need to actually join the functionalities you can:
Fake it with an iFrame (Page Viewer Web Part pointing to the php site for example).
you'll have to use some interop like webservices. It really comes down to what you want to do and not to if it is possible.
This is also possible by creating a web part page and adding a page viewer web part. You can link to the page, making it visible within the Sharepoint site, but it won't offer any interaction with Sharepoint itself.
Sharepoint treats the page as a shared document, however, so you can restrict access to it. I have done this in order to offer access to 'view only' content such as reports, but you can also use it for custom php apps that rely on a database other than the one(s) Sharepoint is using.
I need to provision a custom aspx page which does some work and then redirects to another page. Using a _layouts page, AKA an application page won't work since I only want this page accessible to one site collection.
I looked at using pattern #4 from blog post Application Development on MOSS 2007 and WSS V3. It feels pretty hacky, and it asks you to drop the DLL. Drop it into the bin of the site collection, and upload the file through SP Designer.
I'd rather have this page be a feature that gets included in my site definition or stapled to an existing site definition. I imagine I could use a feature receiver to deploy the files to the pages SP list. One of the comments on the blog post says as much:
Pardon my ignorance on this maybe I am
missing the point completely but
wouldnt it be easier to deploy your
custom pages by programmatically
adding them to the pages splist?
I basically, had a simple .aspx page
with a user control. I deployed it via
this method.
How can a custom page be provisioned without using a _layouts page?
I guess another option is to keep using a _layouts page, but make sure the referrer is correct.
Besides application pages, you also have the possibility to create site pages.
Site pages are in nature related to application pages, but they reside in a site not in _LAYOUTS.
The welcome page (default.aspx) is an example of such a page.
In the same way as with application pages, it is possible to do codebehind in these pages (check out AC's article on this subject, Using ASP.NET 2.0 Code Behind Files in SharePoint v3 Sites)
You can read this article regarding the subtle differences between application pages and site pages: SharePoint Application and Site Pages - Part 1 of 2
You deploy this custom page using a feature, where you specify the file as ghostable (look at the example in ACs article).