I am working on our intranet that utilizes a custom .master page. One content placeholder that refers to the search functionality of SharePoint is being utilized in the footer ().
In our site mockup, we envisioned two search boxes, one in the top of the site, above the nav and one in the footer. I thought, easy, I just duplicate that content placeholder which brought up a duplication error from Sharepoint.
My question is this: Is there a way to duplicate content placeholders without needing to create a custom placeholder? And if not, is creating a custom placeholder the best way to go about this?
Thank you in advance!
There are many ways to customize this.
Direct master page change
Add (custom) place holder to master page
Use delegate controls (no master page change required)
Delegate controls allow you to create a regular user control (.ascx) and assign it a sequence number so that it becomes attached to an existing master page control. Using delegates could potentially allow you to attach the same user control to two different controls (delegates).
With all the recent "don't change the master page" buzz, it is becoming ever more relevant, although for on-premise scenarios, you can be a bit more eccentric.
Not only you can't duplicate place holders, but you should also be very careful while removing or even adding existing place holders, no matter how irrelevant they may appear to be. Even their original order matters (e.g. PlaceHolderPageTitleInTitleArea, PlaceHolderLeftNavBar).
refs,
http://blog.sharepointexperience.com/2013/08/missing-apps-you-can-add-with-custom-master-page-in-sharepoint-2013/
http://www.eliostruyf.com/missing-apps-can-add-zone-adding-new-app/
http://www.eliostruyf.com/document-set-view-not-visible-in-sharepoint-2013/
examples,
https://zimmergren.net/sp-2013-some-new-delegatecontrol-additions-to-the-sharepoint-2013-master-pages/
http://www.fivenumber.com/understanding-sharepoint-delegate-control/
Related
I have a custom list tracking idea submissions (think virtual suggestion box) where I am attempting to customize the DispForm.aspx so that users will not see fields that are not directly relevant to viewing the submission.
I am making a copy of the original DispForm.aspx and renaming to i_DispForm_mod.aspx and then changing the settings of the list to use this as the display form.
Problem is, once I modify the display form settings, it takes over the whole ball of wax. I can no longer access EditForm.aspx. Clicking on "Edit" gets you the display form.
Creating the URL to the edit page manually takes you to the display page. Creating a new item works as normal.
For some reason, SP is deciding to redirect all requests for EditForm.aspx to the display form. Properties for the list supporting files are set to all the appropriate pages - but SP is ignoring that in favor of serving up the display form. WTF?
I have no idea how to fix this. This is my second go-round with this after abandoning the first list created when I first got this behaviour.
Oh and just to add additional fun, the behaviour persists after restoring to original DispForm.aspx and resetting list supporting file properties appropriately.
Absent solutions I may have to mark DispForm.aspx as radioactive, do not touch and abandon my design as unattainable.
I cannot find anything similar being documented anywhere on the web.
I've got a form that gets filled out in stages so I wanted to direct users to a secondary edit form part way through the process. Is this possible?
Hide and reveal using JQuery on the editform.aspx would be my initial choice. I've done this type of work for a very well known bank and it worked very well. Single form with different sections of the form to fill in dependant on the answers provided (and the user group membership)
If you actually want to maintain two lists and hence two forms and redirect between the two - I would look into changing the "source" querystring parameter in the editform so that on completion of the form, you get directed to an alternate location. Not tried it but it would be a sensible place to start looking.
I am working on a specialized instance of MOSS for a client where What I am wanting to do is hide elements on the master page. In particular, I want to hide the main top navigation bar, the search functionality and the label that shows up in the upper-left-hand corner that tells you the name of the site you are on. So I made a copy of the default.master, and then in SP Designer I set the visible attributes for the placeholders for these blocks to “false” in the new master file.
I can then assign the master to my normal site collection no problems and it seems to been working like I want it to. But when I go to look at the system pages (i.e. any of the forms or backend stuff), it is still using the old default master. And when I tried to set the System Master Page to my customized master file, my MOSS instance threw a File Not Found error. Then certain parts of the admin area just started failing in that same way (i.e. I would try to go into Site Settings -> Content and Structure and it also would throw a File Not Found error) Then at one point, the whole Site Collection would throw “Unknown Error” and there didn't seem to be a way to recover, short of reverting the state of the VM I am running MOSS in for development purposes.
So I am curious, what is the best way to create a custom master page and then hide elements on that page? I realized that my web cluster didn’t have the proper flag set up to actually show me real ASP error messages, so I am going to change that tonight when I get home and see what SP is really telling me about all of this. I have also read that changing the application.master file is not recommended, but I figured I could get away with making a custom page for the Site and System master pages and not worry about application.master. I have been reading a bunch of Heather Solomon articles as well as various other things. They all basically say that it’s ok to hide elements on a master page, but not delete them outright as SP will break if you do that. Would it be advisable to use a JS/CSS hack to manually hide elements that way, rather than actually making a new master page?
You create an asp:placeholder with the visible attribute set to false and place the contentplaceholders that are to be hidden in that container, weird I know but it works... as for the system.master you probably would want to make a copy of the system.master that SharePoint uses and then alter that one in the same manner.
Thank you so much for posting this. Works like a charm. I was so afraid because everyone says not to mess with the Application.Master. All I did was open it with Notepad and add Visible="false" (I wanted to hide the topnavigation bar because I have custom tabs that display depending on a user's permissions which are controlled by code in default.master. But then if a user had to upload a file, upload.aspx uses application.master and all the tabs would be displayed.)
I edited this line only:
wssuc:TopNavBar id="IdTopNavBar" runat="server" ShouldUseExtra="true" Visible="false"
Works like a charm!
Note that the following pages will also be affected:
Site Settings
View all site content
Workflow settings of a document library
Recycle Bin
Search results
in a List i have one 'Status' field that should be accessible to only Owners and to the Viewers/Readers it should not be accessible. Do anybody can guide me how to do this.
Well, you can, your view still is visible if the users know how to reach the default views of your list, if its not a security issue, you can use this:
Open your All Items View (/Lists/MyList/AllItems.aspx)
Edit the Page
Add the same List as a WebPart, twice
Delete the original webpart (the one with the Change View drop down)
Edit your WebParts and configure your views
In the Toolpart, on the Advanced [+] set Audience Targetting to your desired Groups
Done!
Either that or you can create a workflow that copies the item to a new list with its metadata, but without that specific column and only give the viewers rights to see that list.
If the question is one of security (it usually is, else just use a view), you can't lock down specific columns. You can find techniques to hide them, but then you're just plugging holes.
The workflow approach recommended by KoenVosters is probably the only secured way I can think of delivering this without coding.
This is not possible out of the box, but I came across this tool that will help to archive this with ease
I have a custom SharePoint application page deployed to the _layouts folder. It's a custom "new form" for a custom content type. During my interactions with this page, I will need to add an item to my list. When the page first loads, I can use SPContext.Current.List to see the current list I'm working with. But after I fill in my form and the form posts back onto itself and IsPostBack is true, then SPContext.Current.List is null so I can't find the list that I need to add my stuff into.
Is this expected?
How should I retain some info about my context list across the postback? Should I just populate some asp:hidden control with my list's guid and then just pull it back from that on the postback? That seems safe, I guess.
FWIW, this is the MOSS 2007 Standard version.
Generally speaking I try and copy whatever approach the product group has taken when looking to add functionality of my own. In this case they add their own edit/view/add pages via the list definition itself.
I built a solution that also needed its own custom "New" form, not open source unfortunately, though if you are interested you can download it, its called "Tagged Links" (Social Bookmarking for SharePoint) and you can find some links on my blog.
To give you a few hints and tips, the following should set you off in the right direction:
Created a new list definition.
Created a new Content Type In the content type you can define your own "FormTemplates" that references a Rendering Template which determine what gets displayed in the "Middle" bit of those forms.
Copied the standard Rendering Template, but then made the changes to it that I
needed.
Wrapped it all up in a solution, and deployed.
My Rendering Template actually included an overridden "Save" Button where I did a lot of the extra work I needed to do during the save.
Anyway, it is a little too much work in my opinion but, I think, it most closely matches the standard approach taken by the product developers. Let me know if you need more detail and I will see if I can put together a step-by-step blog post, but hopefully this gets you off on the right direction.
I would be surprised if you could do something in a _Layouts file that you can't do in a forms template. You have pretty much the same technologies at your disposal.
Looking at the way SharePoint works with ListItems and Layouts pages (for example "Manage Permissions" on a list item), I can see that they pass some variables in via querystrings:
?obj={76113B3A-FABA-4389-BC85-4BB2CC5AB423},6,LISTITEM&List={76113B3A-FABA-4389-BC85-4BB2CC5AB423}
Perhaps they grab the context back each time programmatically using these values.
I'm not using a custom "new form", so this might not apply. I added an event receiver to my custom content type and then do my custom code in the ItemAdded or ItemAdding events. This code fires when the event is added to a list. You can use the event receiver properties to get to the parent List, Web, and Site.
I'd like to think my issue is "special" here, since I am using a custom form. I chose to use a custom form rather than a custom FormTemplate simply because I'm doing a lot of stuff that's not very SharePoint list-like (making ajax calls to get info from a third-party app then generating some dynamic form elements based on that ajax result, then subsequent processing of that data on postback). I thought it'd be a nightmare to try this within the usual custom rendering template mechanism.
I also don't think I can supply the custom form declarations in the list definition itself, because I have multiple content types associated with this list, and each content type has its own custom form (the other type is thankfully much simpler).
Actually, my simple way of keeping the list guid in my hidden field was a very low impact way to address this specific problem. My main concern is that I'm not sure why the SPContext just loses all its usefulness when I postback here, which makes me think I'm doing something wrong.