We recently upgraded Liferay from 6.1 to 6.2 including data migration. So far I've noticed something strange, when I create a new site or organization and enable propagation of changes from site template, the action of site creation seems like entering in an infinite loop and never finishes.
Can this Reset and Propagate feature be somehow corrupted after migration?
Any help is really appreciated.
Related
I've recently installed the "CRM List Component" on a "Online SharePoint", but there are some problems when documents are added.
I'm getting "The document records could not be loaded from SharePoint. Try refreshing the grid. If the problem persists, contact your system administrator" error when adding any kind of document.
When I restart the page, the "CRM List Component" view isn't shown anymore and I see the complete SharePoint instead of the normal "View".
I've downloaded the latest "CRM List Component" on the Microsoft Site and even tried to add a new "site Library" (contact2) and it doesn't work on other "Site Libraries" too.
Has anyone encountered this problem?
If so, is there a way to resolve this?
The weird thing is, that I've done this for other customers and there it seemed to work correctly.
But I can't delete an "Online SharePoint" environment and start from scratch as it is a new environment created by the customer.
Apparently I’ve solved the Issue Myself after some research. The language of the User who created the SharePoint was different from my “SharePoint”-user. When I changed the language of my User, the problem seems to be disappeared. I guess this issue won’t be solved in the next releases of the “CRM List Component”? I’m hoping that this answer will help out other Users!
It is not always feasible to keep user's language same as site collection language. There can be a requirement to have alternative languages enabled on the site collection, where integration component is deployed. Instead of enforcing site collection language you can set the integration component language to be always same, regardless of the user language settings. This can be done by adding for example UICulture="en" Culture="en-US" attribute to the Page directive of the affected page CrmGridPage.aspx.
You can access CrmGridPage.aspx by unpacking the component's .wsp file as CAB archive. Then edit the page, archive back into CAB, rename into wsp and deploy.
Right now I have an HTML file and I'm trying to convert it to a master page. I'm using a VM on CloudShare.
So I create a new site collection and go into the site settings. Under “Look and Feel”, Design Manager isn’t there so I’ve found that if I go to “Site Collection Features” under “Site Collection Administration”, and activate “SharePoint Server Publishing Infrastructure” Design Manager will show up. So I go into design manager, but under Edit Master Pages none of the file or folder names will show up, and when I convert the html file the status column doesn’t show up either, so I can’t go to preview it or to the snippets gallery.
The only thing I can find online is to create a new site collection, which I’ve tried a few times. This happened on my old CloudShare VM, and creating a new site collection fixed it, but it’s not working for this. Can anyone help?
Personally when working with new master pages I have found that the best application to use is SharePoint Designer. You should be able to download it for free. Here are the instructions to configure SharePoint designer using it with CloudShare.
http://blog.cloudshare.com/tag/sharepoint-designer/
Figured it out - I made a new site collection and set it to a Publishing site template and it fixed the issue.
I use VS2010 on Server 2008 R2 with Sharepoint 2010 Foundation.
I have created a custom master page following instructions from here: http://msdn.microsoft.com/en-us/library/gg447066.aspx (activating my custom page as feature), and was delighted with the results. But as soon as I changed the images and attempted to deploy them through VS2010, I noticed that my changes were not showing in the page (which was still showing the old images).
Useful observations:
It's a Sandboxed solution.
I checked that wsp is built with the new images, and so it was.
When I retract my solution, I also go to Master Page Gallery, and
delete my custom master page from there to make sure I start from
scratch. No difference.
My SP Designer does not give me an option to "revert to site
definition".
My "Look and Feel" section in central admin does not offer a
"reset to site definition" option.
Checking "CustomizedPageStatus" property of the SPFile for my master page shows that it's set to "none", and indeed, calling RevertContentStream throws an exception. This indicates it may not necessarily be the unghosting issue.
Does anybody know where my images get deployed to, and what the cause of this problem may be? The "Deployment Location" property does not lead to the correct location (in fact, I can't even see my Feature's folder). Could it be something to do with the way variables in the path - {SharePointRoot}\Template\Features{FeatureName}\StyleLibrary\Branding101\Images\ - are parsed?
I am new to Sharepoint, so all and any help would be much appreciated.
Since this is a Sandboxed solution, everything gets stored in the content database, accessible through SharePoint Designer 2010. In SP Designer, open the site you are working on, then look under "All Files" in Site Objects: that's where I found my masterpages, images, etc.
Deployment paths (displayed in module properties in VS2010) are just red herring, as no deployment to the file system itself takes place. Hope this helps somebody else!
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.
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
-->