This sounds like it might be a situation where you can use Client Side Rendering.
If you are unfamiliar with CSR, I highly recommend reading this article to get an understanding of what you can do with it. Conditional formatting is one thing it's really good at, and I'm sure you'll be able to find many resources (probably a lot on this site) that have examples of using CSR to do conditional formatting based on a date.
To address some of the other obstacles you are facing, you should know that there is a whole sort of development pattern with SharePoint where you write JS/CSS/HTML, put those files in a document library on a site somewhere, and pull them to where you need them using various OOB webparts.
Typically the document libraries people tend to use are the built in Site Assets or Style Library libraries. Using the Style Library will give you version control (it's turned on for the Style Library by default), which gives you a couple advantages:
- Version control
- Any updates you make to your files there will be treated as a minor version, which means you will be able to see the effects of your updates, while everyone else will not, until you publish a major version. This will let you tweak things and fix bugs before "releasing" your updates to the rest of the site users by publishing a major version.
That being said, I personally tend to use the Site Assets library, because I have a different system for version control, and to me "style library" sounds like it should be limited to CSS files, and HTML and JS code files fall under the umbrella of "assets".
But anyway - you can upload the files you need there, and then link to them via various OOB methods. In the case of CSR, you can use JSLink. JSLink is a property that is exposed on many SharePoint objects that lets you "attach" JS files to them such that whenever that object gets loaded, the JS files you defined in the JSLink property also get loaded. This is perfect for CSR, because that's exactly what you want to happen for CSR.
Say you had a custom field that you wanted to apply conditional formatting to. In your field definition, you just set the JSLink property to include the path to your CSR file, and whenever that field shows up (in list views, in forms, etc.) your CSR file will get loaded. Now, you say you can't deploy WSPs, so no custom field definitions for you. You also say you can't use Powershell, so you can't use that to set the JSLink property of the field directly in the site. (If you can use Powershell, it is definitely an option you could use to set JSLink properties.)
Not to worry - there is a JSLink property exposed as a text box in the List View Web Part editor pane, so you can get to it through the UI. Just go to the list where you want to apply the CSR, Edit the LVWP, scroll down in the editor pane to the Miscellaneous section, and set the JSLink property to point to your CSR script (wherever it happens to be on your site).
Keep in mind - and I'm not 100% sure of this, but I think it's the case - when you set the JSLink property that way, it's not setting it for the entire list (as you would think), it's only setting it for the currently selected View. So if someone changes views or creates a new view, your CSR conditional formatting will disappear (until you go in and re-link it through the JSLink for the new view).
So that's how I would do it - make a CSR script to do the conditional formatting, upload it to the Site Assets library, go the the list I want it applied to and set the JSLink property in the List View Web Part.
JSLink can also be used to pull in non-CSR scripts, so if you had to get some other JS pulled in, you could use JSLink, but there is another very common pattern people use: the Content Editor Web Part.
When you add a Content Editor Web Part (CEWP) to a page and edit it, right at the top of the editor pane is a "Content Link" textbox. If you put the path to a file in there, when the page loads, the CEWP will inject the contents of that file directly into the HTML of the page, at the position where the CEWP is on the page. If you link to a pure JS file, it will dump your code as text into the page, so you will probably want to wrap your code in <script>
tags so that it's treated as inline code.
However, it's also really useful to be able to inject a little HTML into a page, and in fact you can use HTML <link>
s to stylesheets and <script src="">
script links to pull in other files.
Just today I used that method to jQuery-accordion-ize a long Edit form. I uploaded an HTML file, a CSS file, and a JS file to the Site Assets library. I went to the Edit form in question, added a CEWP at the top of the page, and added the path to the HTML file in the CEWP Content Link.
My HTML file looked something like this:
<link rel="stylesheet" href="/sites/MySite/SiteAssets/CSS/jquery-ui.min.css">
<link rel="stylesheet" href="/sites/MySite/SiteAssets/CSS/MyCustom.css">
<script type="text/javascript" src="/sites/MySite/SiteAssets/Scripts/jquery-2.2.3.min.js"></script>
<script type="text/javascript" src="/sites/MySite/SiteAssets/Scripts/jquery-ui.min.js"></script>
<script type="text/javascript" src="/sites/MySite/SiteAssets/Scripts/MyCustomForm.js"></script>
<div id="accordion">
<h3>Section 1</h3>
<div id="Section1"></div>
<h3>Section 2</h3>
<div id="Section2"></div>
<h3>Section 3</h3>
<div id="Section3"></div>
</div>
and in the MyCustomForm.js
file I had all the code necessary to pull the different form controls out of the regular form, put them in the new sections in my custom HTML, and then accordion-ize the while thing.
If I need to update the script or anything, I can just update the JS file and upload it to the Site Assets, and everything should update right away because the linkage through the CEWP to the HTML file is still there, and the linkage from the HTML file to the script file is still there.
Another OOB web part you can use is the Script Editor Web Part, which gives you a little editor window where you write JS or link to other files (CSS or JS). I'm not a fan of the Script Editor because I am used to all the benefits of using a real code writing tool (VS Code or VS), and the editor window is tiny and things get jumbled up pretty quick. But, it is a viable OOB solution to get code onto a page.
Site
, but what you are telling it to render (instead of doing the default rendering for the value of theSite
field) is the value of a different field with the internal name ofMoreText
. Is that really what you want to do? Also, have you uncommented the alert to make sure the override is getting called?.MoreText
to.Site
?.Site
, or you could also tryctx.CurrentItem[ctx.CurrentFieldSchema.Name]
. Also, I have never really done it using that<#= #>
replacement token notation. I usually register a function, build the HTML string in the function and return the string. That also gives you the ability to set a breakpoint in your function to see if the override got registered correctly. Where that alert is in your code only tells us that the script did get loaded.