I faced an interesting problem. I have a sharepoint 2007 website. I created a new masterpage and changed default design. So i dont use default.master.
I add site actions menu to masterpage. it renders on google chrome successfully. But there is a problem on IE. I cant see a div or text related with site actions menu on html source of IE.
So what could be reason of this problem?
I am almost sure that this is a probled related to unattended removal of some javascript from master page that handles IE compatibility.
Try to compare your master and the default one and to play with removed lines.
Related
Here i have a issue with SharePoint Designer 2013, an Modern site page was build on SharePoint Online. But i need to customize the modern page and adding url to quick links.
Though modern page doesn't support CEWP or SEWP it's hard to custom the page. But what i am looking is to edit the site pages from SPD 2013 and if i edit the planner.aspx will changes save, unfortune i have Url to navigate the user from the one page to other url(https://...Planner.aspx).
What i want is when user clicks on above link, it should open in new tab and i have to align the page with Css branding. i am adding something like this to open in new tab using SPD href="/abc/xyz/3/SitePages/Planner.aspx?web=1 target="_blank" but no luck at the end.
Looking for an solution, Thanks in advance !
As far as i understand, using SharePoint Designer is not supported for modying the SharePoint modern experience.
You should be using the SharePoint Framework to modify your pages, you can see the full list of supported modifications here:
https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/modern-experience-customizations
However, if you are used to using CEWP and SEWP, you can deploy an app which replicates the functionality in the modern pages
https://github.com/SharePoint/sp-dev-fx-webparts/tree/master/samples/react-script-editor
Atlthough this is probably not supported either, it should allow you to make the changes you want.
I am trying to set Global navigation for my publishing portal site in sharepoint 2013 using Managed Metadata. It works fine for Default.aspx but when I browse to Site Settings page it does not show some of navigations.
My navigation is shown bellow :
Now when I browse to default Page it shows navigation perfectly as shown bellow.
But when I browse to Site Settings page it only shows :
Problem: I have created Top Navigation using Managed Metada Service in Sharepoint 2013. It works fine for all pages such as Home.aspx, default.aspx etc... In other words it works great with WebPart Pages. But when I navigate to any of Application pages e.g. Site Settings or Site Columns( they are called application pages which by default referencing default.master page.), it is not showing my Top Nav bar with all its menu item as well as Sub menu items.
I have googled lot, finally I got solution for SharePoint 2010 from here,
First locate/find PlaceHolderTopNavBar
<asp:ContentPlaceHolder id="PlaceHolderTopNavBar"
and rename it to PlaceHolderTopNavBarOriginal,
I looked into my custom.html page for same div tag as suggested in link above but I could not. After that I find
<div class="ms-hide">
and put
<!--SPM:<asp:ContentPlaceHolder id="PlaceHolderTopNavBar" runat="server" Visible="false"/>-->
inside that div.
I have written blog here:
http://apppagetopnavigation.blogspot.in/
Hopefully this will help you all.
I'm not too sure. But I think that's caused by the fact that they're using different masterpages.
Meaning when the person that activated the cascading dropdowns forgot to make that master page the default for the site. He might have only selected set as custom master page instead of default.
Sean
I think this is a bug it happens in all SharePoint 2013 versions and also in the Office 365, in the settings pages it will always show just one level in the menu.
On my sharepoint site I am unable to add an existing basic webpart to a page where I've added webparts before. I am a site owner. I am using IE 8. I also work remotely using VPN.
The strange thing is IE won't even open up the EDIT MODE.
When I use Google Chrome, it is able to open up EDIT MODE, and it was also able to open up the Add Web Part popup, but when you actually select a web part and press ADD...nothing gets added to the main page.
The extra strange thing is from Google Chrome, I am able to delete and modify existing webparts.
I've upgraded to IE 9 and the same issue still happens.
i assume the similar issue you would be facing with firefox it seems your css is not compliant with IE8 try using ie8 in campatibility mode or use following querystring parameter at end of ur url
toolpaneview=2 and see what is the result
I had that problem and it appeared that a CSS file was messing up with the Ribbon controls.
Try to disable a CSS file at a time.
Regards,
Pedro
We had this issue (or at least a very similar one) where, in edit page mode, clicking on 'Add a Web Part' had no effect. I was assuming that it is a JavaScript issue. In, I beleive, the same day, it effected both my Production and DEV Site Collections, in IE8, Firefox and Chrome. We restarted all of our servers and ran the config wizard. No good.
We were able to create new pages which seem to be uneffected.
For an existing page, our workaround is to edit the properties of the page, then, down at the bottom, select 'Open Page in Maintenance View'. Select one of the Web Parts and Close it. Note: It seems as though if you unselected the 'Allow Close' checkbox, it wont be on this list. Then click on the 'Go Back to Web Part Page'. Click on the zone where the closed Web Part was. You may now be able to 'Add a Web Part'. If so, the last Web Part folder on the left will be 'Closed Web Parts' which I beleive you can put back (Open) the closed Web Part.
I have see this issue occur when someone else has the current page open in edit mode. Until that person either checks in or undoes there checkout you will not be able to edit the page.
I have a custom feature which adds a few controls into the AdditionalPageHead DelegateControl. This works fine on any sites which use our default.master. However the project requires the use of a publishing site which has a master page derived from BlackBand.master (which does not have the AdditionalPageHead DelegateControl included), so I made a copy of the master page from the master page gallery on the appropriate site collection and then modified it to include the following line:
<SharePoint:DelegateControl
ID="DelegateControl1"
runat="server"
ControlId="AdditionalPageHead"
AllowMultipleControls="true"/>
This should therefore include this DelegateControl within all pages using this master page. However when this is uploaded as a new version of BlackBand.master and approved as such, all the pages in the site that use it get a 404 error as if they no longer exist. If I restore the previous version of the master page then everything return to normal.
Help is appreciated as always.
The answer was that I was approaching the solution to my problem incorrectly.
To fix this I opened SharePoint designer at my site collection root and clicked on _catalogs/masterpage. Then I made a copy of BlackBand.master in the masterpage catalog. Opened it and added my line of code. Saved it and then set it as my default and custom master page (to ensure that it applied to any straight up web part pages as well as layout pages).
This worked without a problem.
In SharePoint (MOSS 2007), with an OWA web part on the page, either inbox or calendar parts, when a page loads it "jumps" down to have that part as the focus. No matter where it is on the page. Has anyone encountered this before or know how to solve this issue?
This happens on out of the box sharepoint sites, with the OWA components. No mofidications or 3rd party components or customizations are in play.
Thanks.
Its by default. The webparts are designed to get the focus when loaded.
Below might be solution/s using jQuery/JS:
Just create another webpart in the bottom (CE webpart just for adding JS) and add a JQUERY/JS code to scroll the page to top
Get to know the default JS function that's being called from the OWA webparts & override them in your custom JS
Nothing tested but normally this is how we prevent default behavior.