When I deactivate a feature, or even just after removing a Solution package, I can still choose to select the Master Page which belonged to the feature I removed. This is a problem for me.
The only way to get rid of the hanging reference is to open SharePoint Designer and to browse to the sites _catalog directory then remove the .master files from the masterpages directory.
Is there a way to cause different uninstall behavior which would remove the hanging reference? If so how?
Thank you,
Yes deactivating the Master Page feature will not remove the master page from the Site you need to do it manually or using some feature receiver code that hooks the deactivating event.
My MOSS is a bit rusty, but can't you write some code in the
feature_deactivated event?
Do a manual remove of the master page there?
Related
I'm working on a SharePoint 2010 project. We have a usercontrol to include all of our custom javascript. I popped an alert in there whilst debugging something else, and lo and behold the alert was called twice. I checked and the file in question is included by only one Elements.xml file in one feature. So how can this be? I've tried searching the whole solution, and I only get one hit, so I must be missing something.
EDIT:
This is the code calling the User Control:
<Control Id="AdditionalPageHead" Sequence="10" ControlSrc="/_controltemplates/company/UCLoadJS.ascx" />
This code is found in the Elements.xml of the MasterPages folder, which deploys our custom master page.
Having searched the whole project for UCLoadJS, I cannot find another instance.
I think you have hidden WPs loading these Controls.
Try creating a new page and add the Visual WP once and try again
I know that this question is 9 years old but I just had the same problem, so in case someone stumble across this thread, maybe this will help you:
try to list all your delegate controls. you can slightly modify the script provided by Waldek Mastykarz : Checking which Delegate Controls are activated on your site
if you find duplicated controls (and that was the situation in my case) then its probably because you deployed your control using one feature scope (Site for example) and then redeployed with another one (Web). Follow the steps below to solve the problem:
1). switch to another feature scope (the one you no longer want to use)
2). deploy the feature
3). deactivate it
4). switch feature scope to the required one and redeploy it
Source: SharePoint delegate control is rendered twice
First off, I am not a programmer and so I am simply trying to update an old Sharepoint site using Sharepoint tools. The difficulty I have been having is that the site has a lot of archives and pages that I don't want to recreate if possible. Therefore, I have been renaming and adding pages to an old site (originally creating via an earlier version of Sharepoint) and as I create these new pages/site within the share they look and navigate very differently from the old. How can I either update the old navigation to the new or vise versa so that the site all looks and navigates the same?
Any tips on this would be greatly appreciated
Your old pages were probably edited using SharePoint Designer and that's why they do not get the new look&feel. You could reset this changes using Site Setting Reset to Site Definition option, but it could make changes to the site you don't want (it was probably edited for a reason). I would suggest making the change on a test copy and then you will see what is changed and how it can be fixed.
This solution will allow programmers and non-programmers to work on navigation. You will be able to update the navigation using the site settings>navigation and allow the programmers to customize the styling however they wish. You can also put as many levels of sub-entres as you want.
http://sharepoint2010customnavigation.blogspot.com/
I am working on an intranet in Sharepoint online. I have added a custom css file and included it in the masterpage, after the default stylesheets. In the sourcecode I can see it clearly and I can follow the path to its intended file.
Earlier I had no problems to check it out, edit in Sharepoint designer, save it, then checking it in and changes would apply to the site.
But now the changes I make don't seem to catch. I have cleared cache on several browsers but still no change.
The masterpage and the custom startpage are both published. No files are left checked out.
I may be a sharepoint noob, I have searched any number of forums but not found anything pertinent to my problem.
Can anyone give me a pointer in the right direction please?
:)
Do you save the CSS file in a document library that uses versioning? Perhaps you forgot to publish the latest version of your changes, so browsers only see your previous version.
I made an account specifically to respond to this post because I was having the same issue and found your update about creating a new CSS file helpful in determining the real issue. So I wanted to share my solution!
In the end I discovered it was our BLOB cache being enabled that was causing the issue. We had enabled it to use image renditions. As per the following technet article regarding configuring the BLOB cache, I removed CSS from the file types and our issue was resolved!
http://technet.microsoft.com/en-US/library/cc770229(v=office.15).aspx#BLOB
I hope this helps :)
You are logged in as the Site Collection administrator?
CTRL+F5 to get the latest .css from server?
When you View Source you are able to see the link to your .css file?
When you follow the link to the .css file and open the .css file, it has the recent changes you made?
I think you might have done this.. but make sure after publishing the .css file it is approved.
Press F12 to load IE Dev Toolbar to see what styles are being used in the elements in question. May be you have a small syntax error in the recent classes you added.
Thanks, Karthik.
In the end I made a copy of the css file, gave it a new name and referred to that instead, worked like a charm.
Thanks for your answers and comments all
Under Site Collection Administration settings, go to SharePoint Designer settings and make sure all the checkboxes are marked including "Enable Customizing Master Pages and Page Layouts "
Also, make sure your tag that cites your custom CSS is just below the last meta tag in the head of your master page.
Lastly, remove quotes... there are additional quotes added with javascript so you don't need quotes AND have the full URL to the stylesheet or it will not work!
I need to change the name of a Sharepoint designer workflow.
There is a simple direct way I can edit it via SPD right clicking the workflow name. However often the simple, apparently straight forward things that cause unforeseen
issues.
Will this affect the functionality of the workflow or application?
Thanks!
In addition to breaking all or most existing hyperlinks to that workflow (such as initiation forms, etc.) and the weirdnesses already pointed out, renaming the workflow can negatively affect the running instances of the workflow.
(Sorry, I can't be more specific; I just know that it's not recommended unless necessary. :-/)
You can also rename the workflow by:
Open the site with the workflow in SPD
Open the workflow in SPD
Click the "< Back" button
Change the name of the workflow
Click Finish to save
AFAIK, renaming the workflow (the way I specified above) will not cause issues.
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
-->