Is there a way to (semi) automatically convert a sharepoint 2007 site template to a site definition? This seems like it could be quicker than building a site definition from scratch, yet provide the benefits of the site definition.
I think with VSeWSS 1.2 you can convert a site to an site definition.
Extract from the VSeWSS 1.2 announcement on the SharePoint Team blog:
SharePoint Solution Generator
This
stand-alone program generates a Site
Definition project from an existing
SharePoint site. The program enables
developers to use the browser and
Microsoft Office SharePoint Designer
to customize the content of their
sites before creating code by using
Visual Studio.
So crating a site from a site template an then running VSeWSS 1.2 should do the trick.
One way you can do it to rename the Site Template (.stp) file to .cab and extract the content and get the onet.xml schema and customize it as you wanted it.
Which defintion was used for the site template do you want to convert? I've found the SharePoint Solution Generator to be hit and miss. For example I can't get it to process blog sites. Worth a shot though.
Related
We are migrating old SharePoint 2010 On Premise code to SharePoint Online.
Part of the SharePoint 2010 on premise code has custom list forms developed with visual Studio.
Thought of using JSLink for custom forms while migrating the code to SharePoint Online but it seems that JSLink is only supported in classic experience and not in modern new experience.
Is there any way we can develop custom list forms on SharePoint Online with modern new experience? Is it possible with SharePoint Framework?
Note:
Tried by adding forms to list instances on SharePoint Hosted Add In but it targets the AppWeb lists and not the lists on HostWeb.
Well you can use react in modern web part to build any custom form. We can reuse components.
Another option is to use Power Apps similar to info path to design and add validation on list form.
https://abdulazizfarooqi.wordpress.com/
Another option is to use Content Editor webpart and add bootstrap html forms.
I hope it may help u.
Coding in Classic View is the only solution to your query. Once you are done coding in classic, you can switch/migrate to Modern View Experience.
In this way, your form will be visible and lists will also be consumed.
Nope!.. Modern sites are totally different development model So JSLink is not possible but you can use SharePoint framework extension to achieve the customization for the list.
Please follow the link below
JSLink to SPFX extensions
Please mark if accepted as answer
Will we be able to add .NET code blocks to a page in SharePoint 365 - the cloud version of SharePoint? If so, how do we allow code blocks in the web.config?
Will we be able to use SharePoint designer to customize forms and create dataviews with external datasources?
Can we have asp.net codebehind files and class references? (I suspect not)
.NET code blocks (server-side scripts) are not supported in Office 365. You should build your ASPX page purely from controls and web parts, which would contain the code. Solutions for the SharePoint Online share their restrictions with sandboxed solutions for SharePoint 2010. The solution scope is a site collection; not a web application and thus you cannot access the web.config. However, you may not need to; you're bound only to a single site collection and the most usual task - adding SafeControls - is supported, although the SharePoint engine does not use web.config to maintain them. You can see an example of deploying a web part.
You can use the Designer to customize pages, forms and views. External data sources (entity types) - BCS - were added to SharePoint Online by the end of the last year. I haven't checked what connector types are supported; I presume SQL and WS sources, at least.
You cannot have the code-behind in ASPX pages. There is no ASP.NET compilation of pages and user controls available; that's why you have to compose your pages of coded controls and web parts only. However, there is a trick to circumvent this - the Visual Web Part. The original visual web part could not be used in a sandboxed solution because it relied on the ASP.NET compilation. There is a template available in Visual Studio 2010 SharePoint Power Tools that packages pre-compiled code to the solution and is friendly to the sandbox.
You can develop and test your sandboxed solutions on your local SharePoint 2010 prior deploying them to the SharePoint Online. Although I was surprised that deployng a solution to the SharePoint Online was kind of faster than to my local farm :-) MSVS makes the development really comfortable.
--- Ferda
Not being a .NET developer, here is my limited knowledge. Office 365 is a multi-tenant implementation of SharePoint and you you should have the following capabilities:
upload code blocks as sandboxed solutions
ability to customize forms and data views with SharePoint Designer
Note that Office 365 offers 30 day trials that would allow you to test drive it. Let me know if you need more details as there are a couple caveats to be aware of when you start a trial.
This question relates to how to implement what Mr Prantl suggested.
Where to write C# code for office365 sharepoint site
Hope this helps.
We have started our effort to migrate to 2010 from 2007 SharePoint.
In 2007 we used a site definition. After the migration, it is obvious we have work to do on our 2007 site definition.
1.) What is the best path for us?
2.) Can we create a new Site Definition in 2010 and change the site definition that existing sites used to the new one?
thx
After you do the migration, you can export the site definition of a migrated site as a template and use it as your site template for new sites.
To change the definition of existing sites, you need to write code that loops through the sites and updates them. If you have very few you could do it manually.
i m new to sharepoint and bit confuse,
i don't understand where coding take place in sharepoint as other asp.net application.
how it work if i have to create a page for adding record to database.
It's all about SharePoint features.
You may be interested in WSPBuilder so you don't have to write those XML manifest and feature files.
During site creation using SharePoint, SharePoint offers some templates. If we need to create a site other than a template offered, how should we proceed?
You have 2 options:
Site Templates
Site Definitions
Many people use those terms interchangeably, but there are big differences between the two.
Site Templates
Site templates are easy to create. Basically, you create a site using a ite definition (e.g. the blank site) and start customizing it. You can add lists and libraries and setup the site however you want it. Then, go to Site Actions > Site Settings > Save site as template. You can save your site as a .STP file. The .STP file basically records everything that you added or changed on your site after site creation.
Once saved, your site template will show up in your site template gallery. You can go to the site template gallery and save the .STP file offline. Your new site template will be available in the subsite creation page in the "custom" tab. The template will only be availalbe in this site collection, unless you add the .STP file to the site template gallery of another site.
You can deploy site templates globally. So, if you want everyone to see a STP in their subsite creation page, you can run the following stsadm command:
stsadm -o addtemplate -filename BoardDirectors.stp -title "Board of Directors"
You can retract site templates whenever you want without affecting the sites that used them for creation. This makes them easy to version, as long as you don't want to push updates to existing sites.
One big problem with site templates is that you cannot staple features to them.
Site Definitions
Site definitions are collections of XML files deployed to the 12 hive. They are harder to develop; you basically have to use Visual Studio. The XML files have to be packaged into a SharePoint WSP and deployed using STSADM.
Creating a site definition gives you the most control over your site. Another benefit is that sites using the site definition will always reference the site definition's files, so updates will be recognized by sites using that site definition. For example, if you find a bug, you can fix it in one spot and all sites using that site definition will be fixed.
Note that withdrawing a site definition will break sites that use it.
Recently, many SharePoint experts have recommended staying away from creation new site definitions because of the overhead. Instead, if custom functionality is needed, they recommend coding custom features and just activating those features on sites.
Think about which option you need. In our organization, we chose not to create any new site definitions, and use site templates sparingly. Custom functionality is driven primarily by the use of features.
You are talking about custom "site definitions" and custom "site templates". Google those terms and you'll find tons of information.
You can design your own custom templates. Install VSeWSS extension for Visual Studio and it has a project type called "Blank Site" template. You can use it as a base starting point and customize the solution generated to your needs. All the information required to do so is available in the help document that comes with VSeWSS.