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
-->
Related
I’m experiencing an issue with customization projects in Acumatica 2017 R2 Build 17.203.0029.
Specifically, custom screens, while in my project XML, are not visible within the customization project browser nor can they be navigated to once published (which occurs without error). This only occurs on my staging server. Everything works fine in my local dev environment and even on a different instance of Acumatica. My local dev environment matches the staging server in every possible way (Acumatica version, other packages, etc.)
Older versions of the same customization project have been published before and did not exhibit this behavior. It’s only after I replaced the project with newer version of the same project that I encounter the missing custom screen issue.
As shown in the screenshot below, remnants of the custom screens are present in the Customized Screens window. And the ASPX files are present and shown in the Custom Files window.
Screenshot of missing custom screen data
When I compare the “Edit Project Items” objects between the staging the server and my local dev version, they appear the same.
It it possible that the internal customization or sitemap tables on the staging server have inconsistent data? Is there anyway to rebuild them?
The solution appears related to the users roles config. I had not assigned access rights to the custom forms. Doing so solved the issue. The custom screens are now accessible by direct URL and are shown in the customization project browser. Maybe this will help someone else.
I had this same issue when trying to Deploy the customization to another instance.
To fix it I had to go to the site manager and change the URL of the new page
from: "/Pages/SO/CustomName"
to: "~/Pages/SO/CustomName"
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 have been adding lists and sites to sites when they have been created with feature stapling. Now I want to add a web part when a site is created but it seems like it is to early to do that in FeatureActivated() when I am using feature stapling.
It is working when I activate a feature for an already created site but when I try to do it with feature stapling a get an exception that the object is not created.
Do you know any why to accomplish this when the site is created?
Make sure you use the SPLimitedWebPartManager to perform this work, or you will have trouble.
I've been looking at Microsoft's own early example of how to build solutions - the GroupBoard Workspace solution (http://technet.microsoft.com/en-us/windowsserver/sharepoint/bb848080.aspx)
In this case they actually have two solutions - one which creates the site and another which "updates" the site afterwards. The webparts are added by the second one.
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?
How do you handle improvements and added functionality to your existing SharePoint code?
Did you deploy your original code as a feature?
Do you create a new feature_V2 and deactivate the original?
What processes have you found that led to problems in the future?
I am specifically interested about WebParts, EventHandlers, and WorkFlows.
From what I can find, MS did not leave a "Best Practices" around updating existing code. (Actually, I'm not sure they left a "Practice" much less a "Best Practices")
You can see other questions around this topic:
how-to-upgrade-a-long-running-sharepoint-workflow-already-in-production
how-to-update-spitemeventreceiver-assembly-version-for-a-list-in-sharepoint
should-i-keep-solutions-and-features-in-a-1-1-ratio
What is your method?
I understand this question may be subjective, but I feel there is a large information gap surrounding this area of SharePoint development.
Thank you,
Keith
We always deploy custom code as features and solutions. When it is time to upgrade the existing code, all you have to do is stsadm -upgradesolution and everything works very nicely. I do not like the idea of having feature_v2 type features around...it makes it extremely difficult to keep track of the current version. I think you should only have one version of each feature in your production environment.
Leave the version control to your source control system.
I'm working at a shop that does a lot of SharePoint development. You want to deploy by feature with a solution package. You can easily upgrade your features as you go along and you will need to upgrade the solution package. This solution package can be created from a TFS Build server with WSPBuilder. As you along, the only thing left is to upgrade the solution and "Force" reactivate your feature to have the new feature of the feature.
Don't forget to do an IIS reset for any new code deployment that is done through the GAC. If you put anything inside like sitemaps and resources inside your 12, you will want to do a stsadm -o copyappbincontent.
If you deploy features that contain application files, you want to unload your application on ALL servers of the farm. It can easily be done by putting an App_Offline.htm at the root of every application on every machine.
When completed, remove App_Offline.htm (or rename it) and you are done. Your site is back online.