we are setting up multiple sites e.g A, B, we need to sync content of Site A on Site B, but, there probably is some problem with the site A due to which a difference of the version occurs, though the content does get synchronized with the site B.I want to make my sync component independent that can deal with the version mismatch.is there any possibility in liferay through which we can give manual version number/name?
Many Thanks
I'm still not 100% sure I understand what you are trying to achieve. However, I'd store every document only once and reference it from A and B. You can site it in global scope, which is automatically shared, create a site hierarchy and share or just create a site C and refer to it.
Don't duplicate data if it literally just doubles the size of backups
We have a production SharePoint site that uses a custom database quite a bit. We have a dev site on a separate box where we develop all of our things then move them over to a live site when they are ready for our customers.
We have many pages that use data views to show information from the database. Most of the actual programmability is done with stored procedures and UDF's in the database itself. One of the problems we are having is that when we try to move these custom pages over from one site to another (even if within the same SharePoint installation), the data views become broken. As far as I can tell, the data views are associated with data connections via a GUID. We can go in and set up all of these connections by hand on the new site, however there is no option in the data view webpart to change the data view's associated connection.
At present, this pretty much prevents us from developing on a separate site at all. Doing a command-line SharePoint export/import is an all-inclusive way of accomplishing this. However, ignoring the limited options for this operation, it is at best unreliable. Our first attempts left out some of the content (like custom aspx pages). As we began to create more complex customizations on the SharePoint site, the export function stopped working altogether only to return cryptic errors.
Has anyone else found a good way to do this?
You can do the following:
Create a new page on the destination sharepoint and include an empty data view
copy/paste the old code into the new page
Replace the webpart id of the old dataview with the new one
It worked for me, although I'm still struggling with some complex forms that use drop-down lists that lookup their values in the database depending on other fields. For that I use custom datasources and on the original site they work... but haven't had success in copying it to the new one.
My customer wants to provide 2 themes for a SharePoint application. Is there a strategy to accomplish this in MOSS 2007?
We want to apply user profile-based theme selection, and maybe even a drop-down to switch modes.
I don't know how extensive you want your re-theming to be. However if it could be CSS-only you could use this approach:
Store the CSS files for the different themes in the Style Library.
Create a list that stores the user and their chosen theme.
Write a feature and custom application page to allow the user to change their theme.
Write a control that does a lookup on the list against the current user and obtains the a reference to the corresponding CSS file in the Style Library. The control would then output the CssRegistration and CssLink controls to the page for this file.
Add this control to the master page so it executes on every page (caching should be added).
I can't see why this wouldn't be supportable by Microsoft as you're only changing CSS.
If you need to do more than that then another option is to write an HTTP module that changes the HTML output. Or of course JavaScript. With these two options you may have supportability issues (it depends on how extensive your changes are).
There is also SPThemes now available on Codeplex from Bjørn Furuknap. Users can choose their own themes and they can be applied at different scopes.
Here are the options that I’ve come up with from research and feedback. Both of which seem mostly infeasible.
Implement major UI layout changes in JavaScript. This would lead to client slowdowns, would be difficult to code, and would be completely unsupported by Microsoft due to the need to reference SharePoint objects that may change with subsequent SharePoint patches.
Provide two parallel themed sites based on the same data, and provide a way to switch between them. This would require that we deploy each site to multiple locations, and would require retooling of any site creation mechanisms in code (since they'd need to target two sites instead of one).
One another thing you can try is to use the Theme Changer and ThemeChangerStaple from codeplex , That is implemented as feature you can use the same code logic to archive what you want with bit of modification, give it as an option for the user using CustomAction.
I am new to SharePoint development. We have created a base site template and have used that template to start new sites in other locations on the same server. This works fine but the newly created site seems to "flatten" the custom content types created in the original site. I would think there would be a way to keep the original content type inheritance intact to help support any necessary modifications on the new site. They can still make the modifications but they take longer because you have to visit each list individually. Does anyone know how to fix this or know a better way to approach this?
The problem you are having is the move from your original site collection to another. The site template does not store the complete definition of a site - only the differences from the underlying site definition. Move from one site collection to another and you lose the underlying site definition and run into problems such as the loss of your content types.
Site templates and site definitions are two separate customizations you can undertake. You need to make a decision based on your requirements as to which is best.
Site templates
Pro's:
Easy to create and reuse through the SharePoint interface
Ideal for end users
A site template is a customization of the underlying default site definition
Con's:
Dependency on underlying site definition means SharePoint updates could break your site templates
Poor performance since the modifications are held in the database and are read from the DB and compiled on each request
Limited customization options
Site definitions
Pro's:
Harder to create: involves coding XML
Made by developers and site administrators
Independent of SharePoint default site definitions so not affected by SharePoint updates
Limitless customization options
Con's:
Difficult to modify when deployed
Can be cached on the file system so is fast to load
Check out Google for info on creating custom site definitions.
Hope this helps!
Jonny
The best way to do this is to create a site definition where the content types are within features whose scope is to the farm.
Tim
So, maybe I'm a bit old-school, but when we created websites in the past, we'd develop the site on a development server, then publish or promote the pages and files to the production server. This has always seemed to be a good way to go so that users didn't see messed up pages or (God forbid) a downed server because one of us screwed up.
But it doesn't seem that Microsoft had this idea in mind when they created SharePoint...at least, I haven't been able to find a way to do this in the infrastructure as it's defined.
Does anyone know if there's a management strategy for SharePoint development? I've read online that we can make a backup of the development environment and restore to the production server. That might work the first time, but any updates to the production server can't do that without risking data loss on the production server. I've seen some tools out there for migrating list contents, pages and documents from one server to another--although, admittedly, I've not yet investigated them.
But, another concern of mine is custom content types. It seems that once a list is using a content type, you can't update it without deleting the items from the list, disassociating the content type, and reassociating the content type. Shouldn't there be some way to UPGRADE a content type?
Anyway, if you have any suggestions for any of these current dilemas, I would LOVE to hear from you.
Thanks in advance,
Dan
Thank you for your quick reply.
We already have several features created for our site and a solution package bundling features directed at the fundamentals (content types, columns, etc), and another solution for features having to do with branding (page layouts, master pages, etc.)
But it seems like this is a one-time-shot...basically, it gets our server set up, right? Once people have started using the production environment, we're going to have documents, pages, list items all existing in our content database, and it'll be impossible to update things like content types, columns.
Features you have to deactivate and uninstall before you can install and activate the new feature, right? I've seen a Version property on the feature definition, but as near as I can tell, this doesn't do anything. Solutions seem like they can be upgrade by incrementing the version number, but it doesn't seem to modify things like content types and columns--especially if they're in use. Plus, I'm not sure how extensive the upgrade with solutions is.
There's precious-little documentation out there for this sort of thing. It seems like everything I'm reading is how to get your SharePoint server set up initially...not managing it long term.
Do you have any advice or suggestions?
Thank you all for your suggestions.
But we've been working on this site for over a year now. I'm pretty confident that we're already setup according to what most of you are recommending. We already have several features that install things like content types, columns, master pages, page layouts, and workflows. Most of these features are contained within solution packages. We have all of our development environments set up as VPC servers.
So, I have the initial deployment pretty much set. What I'm REALLY hoping to find out is how I can upgrade things like content types and columns and stuff down the road. Is it possible to change content types once they're in use? Because it doesn't seem, based on my initial testing, that this is possible. I'm not to worried about the assemblies because it looks like they swap out just fine, but the only way I've gotten a content type updated is by deleting any items referencing them (i.e. all the pages in my pages library), removing the content type, then re-adding it.
Do any of you know if there's a way to update a content type AFTER the initial deployment? ...when users have already created items based on the content types we've already deployed?
(The other part of my question was actually moving existing pages from the development server to production, but I can live without that. My major worry is the content types.)
The best way to go is developing with features. Once the features are done, you ca deploy them with Solution package (called WSP).
The only thing left to do is to reactivate those features. That way, you can progressively roll-out new features without having to do everything in production.
WSPBuilder is an application that helps you build WSP.
For automating all of this... good luck. There is a lot of work involved.
UPDATE:
Deploying Content Types and Columns are tricky. Once the website has been created, you can't update them anymore through features. You need to go through the code and recursively go through all the sites and modify the specific content type that match the name.
We've tried and it's not possible to do that normally with features. This need to go through something I call "deploying with code".
You really really need to define your content types using a feature because that way each content type will have a set GUID and will be stored in the database using the same name. This becomes important when running CAML queries over the site and there are a few other little gotchas when content types are created "will nilly" if you will.
I prefer STSDev for rolling out solutions using custom content types.
There are two ways to edit pages on the server. You can define the page library to have major and minor versions. This allows editors to edit the page and a defined publisher to publish them. This is good on an internal site, but is not recommended for a public facing site.
For a public facing site you will need to use Content Deployment
I cannot stress enough that before going ahead with a production release you make sure you have features for the content types.
As mentioned here, Chris O'Brian has a post saying that you should not use features unless necessary. One of his reasons is that it slows developement.
I disagree with this. Developement is slower if you are unfamiliar with features, but once a level of knowledge is reached, it is not a major factor.
Do listen to him about the backup and restore method of moving the content.
If you do that, all mess in the content types and fields and webs you may have created during developement (for me that is always quite a bit) will be moved to your production site.
Instead of having a nice clean site where everything is consistent, you will end up with little bugs and some areas of the site behaving differently to others simply because of old development cruft.
I recommend taking a look at Chris O'Briens most recent post, and his great Content Deployment Wizard: it's not all about Features!
Maxim is right in that most items should be deployed via features that are wrapped in solutions (WSP files). Your strategy should be to make sure your solutions and assemblies are broken into related bits of functionality. This is also beneficial in that features can be isolated at certain levels like sites and webs. Feature activation code, deactivation code and feature stapling should be used when updating any content updates. Content deployment can also make sense.
Once thing to remember is that if the updates are only in code then the assemblies can be updated without requiring the feature to be reactivated or the solution retracted and redeployed. All that is required is the Application Pool to be reset.
Microsoft has a couple articles on Dev environments and you can Google many others who recommend environments. We do development on virtual machines and deploy most items to an virtual integration server. Once we smoke test it we then deploy our solutions to QA so on and so forth. The benefit i sthat features and solutions are easy to retract. Once it goes out to production it should be thouroughly tested.
Developing in SharePoint has it's issues, that goes without saying, but so far I have found that the benefits outweight the problems.
Team-Based Development in Microsoft Office SharePoint Server 2007
We developed a custom solution which would update content types and fields for a Site Collection. Underneath the covers, through code, SharePoint allows us to modify the Fields as well as values in the Fields and Site/List Content types.
For moving the actual content from QA to Prod we use Echo