I am looking at the default master page in SharePoint 2013 (v15.master) and there is a server control there <SharePoint:SuiteBarBrandingElement runat="server"/> which on the page renders as 'SharePoint'. I can't figure out where to change it to something else (without writing code behind).
Information is thin, but there does not appear to be any UI-based way to get at this setting. But a setting it is (actually, a property on SPWebApplication).
Refer to this (unhelpful) documentation: SPWebApplication.SuiteBarBrandingElementHtml
Like you point out, you could write a solution to modify this property, but we can also use some PowerShell to get at it.
Executing this in the SharePoint 2013 Management Shell:
$app = Get-SPWebApplication http://my.sp2013.site/
$app.SuiteBarBrandingElementHtml
Yields this output:
<div class="ms-core-brandingText">SharePoint</div>
This means that we can just assign a new value here:
$app.SuiteBarBrandingElementHtml = '<div class="ms-core-brandingText">Hello World!</div>'
$app.Update()
That aside, it would be pretty handy to build a solution that exposed the property via the Admin UI to update it. I don't know why Microsoft didn't provide this out of the box; it seems like that was the intention (at some point).
Related
I have a page template that has this line of code below:
<div id="<%= CurrentDocument.NodeAlias %>" class="lvl3">
Things work - the id value shows correctly. However, when using the Page Templates module Design tab, there's an error. In Event log, I saw the error message "Object reference not set to an instance of an object". Taking the id snippet out, the error is gone. I'm not sure what the error means and how to fix it. Could you help?
I do need some page-specific unique identifier in there (NodeAlias in this case) for other purposes.
The answer is pretty simple - if you open your page template in Kentico Page Templates application - your CurrentDocument is always null (because you are editing Template itself without specific document).
You could do absolutely the same thing in Pages application with the Design tab. It's also possible to edit all the template properties from there, including the Layout:
Using code blocks on page template layout is not supported. I assume you are using ASCX layout. Moreover your code looks more like a macro - so, maybe you are using HTML layout type? If yes, then the syntax should be {%CurrentDocument.NodeAlias%}
If you are using ASCX layout you may face also this issue: https://devnet.kentico.com/articles/the-controls-collection-cannot-be-modified-because-the-control-contains-code-blocks
Note that in portal engine the life cycle is bit modified, so we cannot ensure the code blocks will work every time - it may work sometimes. It mainly depends on what other web parts/controls and in what order are placed in the page template. I would rather recommend using the workaround from the article.
Or, you can give it a try, with no guarantee, this may work in certain cases, you need to specify the full namespace:
<%= CMS.MacroEngine.MacroResolver.Resolve("{%CurrentDocument.NodeAlias#%}") %>
I really hope I'm making sense with this one.
I'm trying to create a widget from a custom webpart that I created. It's nothing special at all as you can see:
<h3>Header</h3>
<p>Intro Copy</p>
<ul>
<li>List item one</li>
<li>List item two</li>
<li>List item three</li>
</ul>
I now want to be able to create a widget from this and create new fields that will be used to populate the above DOM. What do I need to do in order or do this.
In an example I saw for the demo site, they populated the bg image with:
style="background-image: url('{% ResolveUrl(PathToImage) %}');"
That was however done on the front facing part of the CMS and I'm trying to do it within the solution.
Any thoughts?
It's all in your layout or code behind. Your layout can have that code (but in ASCX format) and it will work just fine. OR you can add literal controls to the page based on the fields and what the user has entered.
Doing it in your layout is more restrictive and specific to that one application but allows you to use multiple new webpart layouts. Using the code approach allows you to be more dynamic but doesn't allow you to use the built-in layouts of the webpart/widget.
I would just use the Transformable Web Part in the Marketplace...it does exactly what you want it to do. Create a custom web part, and you use a Transformation to style the Web Part Properties into the DOM elements.
https://devnet.kentico.com/marketplace/web-parts/transformable-web-part
Reason why i built it!
I've done something similar in the past, using what I call generic web parts. I wrote a blog on it last year - it might help out with what I think you're trying to achieve:
http://www.mattnield.co.uk/Posts/Show/generic_web_parts_for_rapid_development
Why are you choosing to go with Widgets? If you want to access any field inside the transformation within the web part it's feasible by the same way as you define in inbuilt web parts.
If you want to perform any function like onload etc. then you need to use kentico API to access any data.
If you provide more insight on what is required, I can help further
I'm trying to send an automatic email receipt for items that have been created on a sharepoint list.
Conditions
I cannot use workflows - they are disabled
I cannot use webparts - they are disabled
I cannot use sharepoint designer etc etc etc - they are all disabled
The function needs to be OOTB
The only option I have is using javascript in calculated columns. I am aware of the use of the HTML:mailto tag - but this opens Microsoft outlook, and is not automatic.
Came across this link:
http://geekswithblogs.net/ThorvaldBoe/archive/2014/07/03/sending-email-with-sharepoint-and-jquery.aspx
So, here is the calculated column attempt:
="<button onclick=""{function SendEMail(from, to, body, subject){"
&"var siteurl = _spPageContextInfo.webServerRelativeUrl;"
&"var urlTemplate = siteurl + '/_api/SP.Utilities.Utility.SendEmail';"
&"$.ajax({"
&"contentType: 'application/json',"
&"url: urlTemplate,"
&" type: 'POST',"
&"data: JSON.stringify({"
&"'properties': {"
&"'__metadata': { 'type': 'SP.Utilities.EmailProperties' },"
&"'From': from,"
&"'To': { 'results': [to] },"
&"'Body': body,"
&"'Subject': subject"
&"}}),"
&"headers: {"
&"'Accept': 'application/json;odata=verbose',"
&"'content-type': 'application/json;odata=verbose',"
&"'X-RequestDigest': $('#__REQUESTDIGEST').val()"
&"},success: function (data) {"
&"alert('Eposten ble sendt');"
&"},error: function (err) {"
&" alert(err.responseText);"
&" debugger;}});}"
&"SendEMail('user#whatever.com','user#whatever.com','Test1','Test2');}"">"&"Send</button>"
When running the code, the Console shows the following error: '$' is undefined
Any suggestions on how to overcome this?
Thanks
You keep raising the bar, Steve!
You're really making it difficult for yourself this way
I suggest the next learning steps first:
Learn all about Chrome Snippets
this will help you develop/execute code directly on the View page without the need for stuffing it in a Calculated Column or any script in SharePoint
Learn jQuery (by using Snippets)
check out jQuerify it will inject jQuery where it is not available
[optional] Learn Tampermonkey
this will help in immediatly executing your scripts on a SharePoint page (without the need for including the script in SharePoint
Learn JSOM Ajax calls and REST Ajax calls (REST is halfbaked implemented in 2010)
again; do them in Snippets first
When that all works you're halfway done and you can wrap it all in the Calculated Column (again, this is all undocumented hacking away at Microsoft technology, if they decide to make changes in an Update you're cooked... e.g they disabled the use of the SCRIPT tag in summer 2013; that's why you now have to use the blank IMG onload trick
Note: I have updated my CalcMaster BookMarklet on GitHub. Once you have your Snippet working you can paste it in an existing Calculated Column Formula and wrap it in IMG onload and &".." notation with one click
If you get that sending email working let us know; I have never done it... I stay away from projects where SharePoint Designer can not be used.
Once you have mastered all the above you will have learned so much Front-End development I suggest you go look for another job.
I think I'm missing something with the ManagedPropertyMapping tag on display Templates. Indeed I have this code originally:
<!--[if gte mso 9]><xml>
<mso:CustomDocumentProperties>
<mso:TemplateHidden msdt:dt="string">0</mso:TemplateHidden>
<mso:MasterPageDescription msdt:dt="string">Displays a result tailored for a web page.</mso:MasterPageDescription>
<mso:ContentTypeId msdt:dt="string">0x0101002039C03B61C64EC4A04F5361F385106603</mso:ContentTypeId>
<mso:TargetControlType msdt:dt="string">;#SearchResults;#</mso:TargetControlType>
<mso:HtmlDesignAssociated msdt:dt="string">1</mso:HtmlDesignAssociated>
<mso:ManagedPropertyMapping msdt:dt="string">'Title':'Title','Path':'Path','Description':'Description','EditorOWSUSER':'EditorOWSUSER','LastModifiedTime':'LastModifiedTime','CollapsingStatus':'CollapsingStatus','DocId':'DocId','HitHighlightedSummary':'HitHighlightedSummary','HitHighlightedProperties':'HitHighlightedProperties','FileExtension':'FileExtension','ViewsLifeTime':'ViewsLifeTime','ParentLink':'ParentLink','FileType':'FileType','IsContainer':'IsContainer','SecondaryFileExtension':'SecondaryFileExtension','DisplayAuthor':'DisplayAuthor'</mso:ManagedPropertyMapping>
<mso:HtmlDesignStatusAndPreview msdt:dt="string">http://win2012spstd/sites/publishing/_catalogs/masterpage/Display Templates/Search/Item_WebPage.html, Conversion successful.</mso:HtmlDesignStatusAndPreview>
<mso:HtmlDesignConversionSucceeded msdt:dt="string">True</mso:HtmlDesignConversionSucceeded>
</mso:CustomDocumentProperties>
</xml><![endif]-->
And whatever I do Inside that tag, it doesn't change the way how my result looks. In other words, in can remove every properties:
<mso:ManagedPropertyMapping msdt:dt="string"></mso:ManagedPropertyMapping>
Or add more properties, it doesn't matter.
Could you please tell me what I'm missing?
P.S.: I'm using SharePoint Standard
Ok, I've finally solved that problem. I didn't understand that I needed to create a new display Template instead of editing the default one.
Brief description of the default behavior i want to override:
Creating a SharePoint list and using the "Title (linked to Item)" in a view provides a link to the DispForm for that list. By default, this link appends a Source parameter to the URL query string.
I would like to disable this behavior in some way while still retaining the default list view web part that is created by SharePoint when the view is defined.
To be clear, I know how to convert the list-view webpart to XSLT and then control this behavior. If at all possible, I'd like to keep from doing that so that the list view can still be easily supported by Help Desk and also keep the benefits of the standard list view (such as exporting to excel and so forth).
Any ideas?
Thanks in advance for your help.
Troy
SharePoint (2007) dynamically appends the source parameter in a javascript method named GoToLink. That method is defined in SharePoint's core.js file, and it can be easily customized without editing the original file. In fact, you never want to edit that file directly; it will put SharePoint into an "unsupported" state.
We'll create a solution for our customization, so it can easily be deployed or retracted in a consistent manner. Create a new Empty SharePoint solution in Visual Studio, targeted for GAC deployment. Within your project, create the following folder structure:
Templates
Layouts
1033
("1033" is for the English localization; if you're using a different language, your id will be different).
Within "1033", create a new Javascript file (we call our ours "CustomCore.js"). This will contain JUST the code we want to override from Core.js. Since GoToLink is the only thing we're interested in, let's focus on that. Here's the original from Core.js:
function GoToLink(elm) {
if (elm.href==null)
return;
var ch=elm.href.indexOf("?") >=0 ? "&" : "?";
var srcUrl=GetSource();
if (srcUrl !=null && srcUrl !="")
srcUrl=ch+"Source="+srcUrl;
var targetUrl=elm.href+srcUrl;
if (isPortalTemplatePage(targetUrl))
window.top.location=STSPageUrlValidation(targetUrl);
else
window.location=STSPageUrlValidation(targetUrl);
}
Not much to it. For our override, we just need to omit the bits that add the source parameter. From my reckoning, the modified method looks like this:
function GoToLink(elm) {
if (elm.href==null)
return;
if (isPortalTemplatePage(elm.href))
window.top.location=STSPageUrlValidation(elm.href);
else
window.location=STSPageUrlValidation(elm.href);
}
That should be it. Package up the solution and Visual Studio should interpret the "Templates" folder structure correctly when it builds the WSP (look in the generated manifest file for the TemplateFile element and that it's deploying to "Layouts\1033\CustomCore.js").
Once your WSP solution is deployed to SharePoint, we have the final step of referencing it in your Master page. In the HEAD section of your master page, you should see Core.js being referenced like this:
<SharePoint:ScriptLink Language="javascript" runat="server" Defer="True" Name="core.js"/>
We simply add a reference to the new JS file directly beneath this line:
<SharePoint:ScriptLink Language="javascript" runat="server" Defer="True" Name="core.js"/>
<SharePoint:ScriptLink Language="javascript" runat="server" Defer="True" Name="customcore.js"/>
Test it out and make sure it works. Note that this will affect ALL lists on the server to which you've deployed "CustomCore.js" and which use the master page.