I've created a "branding" site with Sharepoint 2013. I'm not being able to configure the search engine so that it finds the content from the custom web parts. Most "static" content (institutional content) from the web site are displayed through custom web parts.
So my approach now is to try to configure the Content Search with "Web site" type, in order to have the crawl processing all pages as a regular website. But it's not working, it seems to keep crawling as a Sharepoint site, because the content from webparts are not being "searchable", even if I remove the "MicrosoftSharePointTeamServices" http header.
So, how could I configure the search in order to have the contents from web parts "searchable"?
Finally found the answer!
All webparts are rendered with class="noindex" by default, which causes crawl process to ignore it.
To solve the issue: go to "Site Settings" -> "Search and offline availability" and for "Indexing ASPX Page Content" configuration select "Always index all Web Parts on this site".
This will make sharepoint do not include "noindex" class anymore.
If there are any subsites, the configuration must be done at subsite leve as well.
Related
I'm working on remolding my companies current exsisting Sharepoint site. I installed the SP ZAP Slideshow webpart and went to the sharepoint site to insert it, and absolutely no webparts were listed. I went into the provided Sharepoint 2010 central administration and realized that everything seems to be listed as
//usmvwc0wtf1srv.ww005.work.net/sitepages/
When the website were hosting, and it should be listing is
//usmvwc0wtf1srv.ww005.work.net/sites/
I went to the /sitepages website and all the webparts exsisted and worked, however i need to get them working on the /sites page. Is there some way to switch it so it will not default all the webparts and content i'm uploading to the wrong page? I feel as though the wrong default page is listed? sorry new to all this!
Web Parts, which you see listed and are able to insert on a page when you edit it, come from the Web Part Gallery in the site collection. They are usually installed to the gallery when you activate their site collection-scope feature. Check what features you didn't activate in the new site collection - I suspect that one of them is responsible for the installation of Web Parts you are looking for. (The scope of the feature can be site collection or site - check both.)
I want to place the RSS Viewer web part into a page layout I've created.
In the Sharepoint Designer (Sharepoint 2010) using the "Advanced Edit Mode" I tried to add the RSS Viewer web part but I cannot find it in the list. Under "Insert>Web part" I find many other web parts but the one I need is missing, also under "More web parts..." it cannot be found.
The web part is installed (I activated the feature). The web part can manually be added to a page into a web part zone when I don't use the Designer but edit the page directly in the browser but of course this is not what I need as I have to put it in the page layout.
Anyone got an Idea why the web part is not selectable/visible in the list?
As I've learned not all web parts are available in this listing.
The workaround would be to manually add the desired web part to a webpart zone on the page (not in the designer) and then open the page in the designer so that you can copy/paste the web part relevant code to the page layout of your desire.
How would you go about having WSS search index content that's inside a webpart/pulled from an external source and presented in a SPGridView?
You probably already know this, but if you go to Site Settings -> Search Visibility you will see a section stating:
This site contains fine-grained permissions. Specify the sites ASPX page indexing behavior: ...
If you choose "Always index all ASPX pages on this site" it should index the content in your web part, but only as the crawler sees it, so security trimming would not apply. It is basically a web crawl and not a SharePoint content crawl.
I know you said WSS, but in MOSS you might be able to take this one step further if the above did not work out and use a web site search on your SharePoint site. I have done plenty of web site searches (it does not work perfectly), but have not tried to explicitly do a web site search on a SharePoint site so I'm not certain this will work.
Lars (who co-wrote "Inside the Index and Search Engines: MOSS 2007") is pretty active on StackOverflow so maybe he'll chime in.
Also in MOSS: Have the data you are displaying available as for instance a web service / page in a different site also. In Moss you can add Federated Search locations to be included in the Search results.
I've asked a similar sort of question here but what to be more specific.
I want to be able to deploy a solution and activate a feature that provisions various custom aspx pages to different site levels within my web site.
So my first custom aspx page would be at the root: http://example.org/custompage1.aspx
And then another custom aspx page would appear at a deeper level: http://example.org/subsite1/custompage2.aspx
I've got my solution scoped to the "web" level. If I activate the feature at the sub site level I can access the custom aspx page that should appear at this deeper level, but, I can also access the other page that should only appear at the root of the web site e.g. http://example.org/subsite1/custompage1.aspx
Which is wrong, wrong, wrong!
I tried to scope the feature to “site” but this only seemed to provision the root custom aspx page, not the page that should appear at the deeper level of the web site.
"Custom aspx" pages are known in SharePoint as "Application" pages, and they are deployed in the _layouts directory (usually C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS). All pages inside the Layouts directory are available from every site in the web application.
If you know in advance which page goes with which site then you could put code in each custom page that checks to see if it's being accessed from an "invalid" site, and if so, throw a custom 404 error (see here: Hidden Features of ASP.NET) or something similar.
Anything you do in the feature xml will only apply to the site on which the feature is activated. If you want to do something across multiple sites based on relative urls, you will need to set up a feature receiver and use custom code to deploy files/features to the other sites.
The easiest approach is probably to create a seperate web scoped feature within your solution and have the site scoped feature receiver activate it on subsites.
Clorphil nailed the answer. I would only add that you can use SPContext.Current.Web within your page to determine which web site you are in when called.
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).