One of my clients has migrated all its teamsites from SP 2007 to SP 2010. They kept most of the sites in 2007 compatibility view though. One of the sites that I customized 2 years ago is not working properly. The javascript code has error and they cannot edit most of the webparts content.
I tried to troubleshoot the site in my farm. However, I face more issues because the teamsite I created is not in 2007 compatibility view. (Ribbon, ajax, etc.)
Is there a way to create a site in 2007 compatibility view from scratch?
No, there isn't, unless you want to spend A LOT of time and effort, which is better spent debugging.
Is the new farm running in a different domain?
Related
I'm new to SharePoint development and design. Someone recommended using SharePoint Designer as a quicker way to have the site have a specific look that is different from the SharePoint Look Book. We want sections of our page to have borders with rounded edges, and specific color headers. I found several contradicting articles about using SharePoint Designer. Do you recommend using it on the latest version of SharePoint online in 2022? Have you had any success, or have you encountered any issues?
I enable scripting on my site. I tried connecting SharePoint Designer 2013 to my SharePoint online site successfully, but would like to know if it's a good idea to move forward with it.
As you can read from here SP Designer is supported on the latest On-Premises version of SharePoint(2019) on the bare minimum. But as you can see it is a product that is steadily heading to it's end-of-support/deprecation lifecycle.
Also, as you can understand, since it's development was halted since the 2013 version, a lot have changed since then, and many of the new features are not even supported by SP Designer.
If your are trying to make modifications to a SharePoint Online site, I would suggest using more modern tools(PowerApps, Power Automate, Modern UI, SPFx etc) and leaving SP Designer to it's way to deprecation.
You can also, update your question in terms of what you are trying to achieve and we could propose you some ideas :)
We have different business divisions and each division has its ecommerce site hosted as webpart in SharePoint 2007. We also have product/adv images/documents in SharePoint.
We want to migrate from SharePoint 2007 to SharePoint 2013 and as per our initial research we noted that we must first migrate to SharePoint 2010 and then to SharePoint 2013
Questions :
what is the best way to migrate from sharepoint 2007 to sharepoint 2013 considering above context. please provide pointers..
or should we re-write our webpart code in mvc and get rid of SharePoint. since we have soa arch i belive it would not be big pain to do so.. just ui webparts will be replace with mvc site
which third party migration tools can be used considering their reliability and cost.
please suggest best way to go ahead.
As you mentioned, there's not direct migration path from 2007 to 2013. It's hard to give a definitive answer without knowing more about your environment, it really comes down to trying to estimate the cost and time doing a manual migration (2007-->2010-->) versus purchasing a tool.
I have one customer that used Metalogix to go from 2007 to 2013 and it was fairly successful. They had a couple of branding issues and some code that had to be re-written to use updated API's but considering the scope of the migration, it was fairly smooth.
Ditching SharePoint and re-writing everything using MVC.... Not sure about that one. Even though you have a SOA architecture in place, it doesn't mean it will replace everything that SharePoint provides. It does a lot of things; security, service app scalability, branding, ECM, BCS, search, etc.
UI issue may be faced as below
Migration HTML content (in content webpart) from ntext data type to XML data.
SharePoint adds some extra tags for xml validation and it distorts to whole UI for all the pages. Means look and feel will not be as it is after migration.
Table based old structure in menus and drop-dwon is very hard to manage. It must be in and Box model for better UI management.
I had used Metalogix in my migration projects and it worked 70% fine, however be ready for the post deployment fixes as you might have to rewrite some scripts. But overall it works fairly good. I would also suggest you to run a report before migration using SPCAF tool.
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.
From my experience, this is adding minor features at increased implementation and maintenance cost in comparison with using just "pure" Microsoft.Net, ASP.NET and IIS application.
Sharepoint 2007 = ( no concept of deployment version control etc, narly css/skinning, weird cms features, sp webparts not recommended, very limited worfklow features)
Sharepoint 2010 = ( is everything fixed? )
The generic feeling I have is to stay away from Sharepoint, implement in pure asp.net using proven patterns and practices, architecture etc. And just consume Sharepoint services when suitable.
Is Sharepoint 2007 or 2010 ready for real line of business applications running extranet with thousands of users, or should we just go for asp.net?
Unfortunately there is no clear cut answer to your question, I guess the proverbial "It Depends" is the best answer.
SharePoint 2010 is a big improvement over SharePoint 2007. But, most of these improvements are in the plumbing for Shared Services. So the functionality that is provided with typical collaboration sites is more or less the same.
Not to say that MS did not make major investments in everyone of your concern areas (deployment versioning, skinning, content management, etc).
My guess is if you were not happy with SharePoint 2007, you will probably still be unhappy with SharePoint 2010.
Considering that I've built several externally-facing Internet applications on SharePoint 2007 with thousands of users, yes, I'd say that 2010 is ready.
In addition to what the guys have already said:
Just like anything, you get what you pay for. Unfortunately there are a lot of cowboy SharePoint developers out there who keep repeating their wrong approach which causes problems in the long term. This then forms a bad vibe about the the product.
I've been working with SharePoint 2007 since its betas. I did lots of cowboy development myself (not that I realised at the time). I had the same opinion you did at the start but now that I know what I know, I've changed my mind about it. SharePoint 2007 is an absolute monster. Once you understand what it does well and what it doesn't do well, you'll realise that is a great product. Its only let down by a documentation and understanding. My team and I have managed to roll out many SharePoint sites and the clients are very happy with them.
The question is, is SharePoint 2010 going to be well documented?!
The other major question for me is, will it have better Error reporting (some meaningful errors instead of the non-sense it currently displays)
I have a few colleagues looking into 2010 right now as well as some MVP's I've previously worked with, they're reporting 2010 is great. There are some tricky bits to it e.g. the Ribbon but nothing that a good developer won't overcome.
I have a series of reports served by SSRS. They are great and the users like them.
That being the case, upper management wants to throw a wrench in the works and serve the reports from the Sharepoint server.
Is there a realtively painless way to let users access the reports from sharepoint? How would somebody go about doing such a thing? Or do I just need to bite the bullet and try to stop the madness?
I'm not sure which version of SSRS or Sharepoint you're using, but there have traditionally been both a Report Viewer and a Report Explorer web part shipped with Sharepoint in the RSWebParts.CAB file (at least since SQL Server 2005 SP2 I think). You can start there, but if you wanted quick and low-tech you could put in an IFRAME web part and point it to the Reports folder on your SSRS Server. Since you're using Sharepoint, that's also making the assumption that you're using Windows Authentication, so that wouldn't be an issue there.
Here's a link that might be of some use:
Viewing Reports with SharePoint 2.0 Web Parts
The most painless is going to be to run SSRS in Native mode, which it sounds like you're doing already, then install the SSRS web parts on your WSS/MOSS server.
You will have to manage security and report source control using some other methods besides sharepoint, however you don't have to deal with installing WSS/MOSS on your SSRS box and adding it to your SharePoint farm.
The more painful option is to run SSRS in Integrated mode. This allows you to use all the SharePoint document management stuff for your reports and share the same security setup however, the server configuration can be lengthy and difficult to setup.
http://msdn.microsoft.com/en-us/library/bb677365.aspx
Hope this helps!
Ben