3

I am working on sharepoint server 2013 (on-premise & office 365). and sometime i have to write some custom JavaScripts and custom style which hide/relocate certain HTML components. Example of these include the following 2 cases:-

1- Inside the built-in discussion board view there is a link named "What's Hot" and i did not find any way to hide this link, other than writing this custom style:-

<style>

a.ms-pivotControl-surfacedOpt[aria-label^='What']
{
    display:none !important;
}


</style>

2- Inside the built-in create/edit discussion board forms, there is a check box named "Question", and to hide it i wrote the following custom javascript :-

<script>
$( document ).ready(function() {

$('.ms-formtable nobr:contains("Question")').closest('tr').hide();  

});
</script>

keeping in mind that the question check box is disabled inside the Discussion content type (for a reason or another) so i can not hide it from the content type using the regular appraoch.

now if i am building my own .net application i would write these custom javascript and style without any worry, since i own the markup. but in sharepoint i do not own the markup and from my own experience that this markup might chnage if we apply a CU or a single update to sharepoint.

so i am not sure which appraoch can be considered valid in sharepoint:-

  1. I should avoid writing such a custom javascripts and custom style in sharepoint, since the classes i am depending on can change in the future?
  2. those customizations are valid and i am not doing any thing wrong,, but if these custom javascripts and/or cusotm style break after installing an update, then the normal process will be to update these custom javascripts and/or custom style to match the new classes names...

i am asking this question, because currently i am preparing a document on how we need to manage updating sharepoint servers (including installing sharepoint CU and/or SP security updates). and i need to mention what we need to do in-case a cusotm JavaScript and/or cusotm style breaks.. so will the normal process be to update these cusotm scripts and style to match the new classes? or it is our problem from the beginning that we have defined these cusotm JavaScript and custom style ?

Improve this question

3 Answers 3

Reset to default
1

It's not the greatest of practises - as you're aware you may come back to the project later and be unable to recall how you hid it - if at all not to mention if anyone else comes to the project or should you leave. You should be able to edit the itemstyle itself and create a custom layout for it so you can select it that way. Liekly the best solution.

I can understand you not wanting to put it in the core css of the SP as youre unlikely to know any far reaching implications of your actions - you never know if SP is re-using those class names elsewhere.

Improve this answer
3
  • thanks for your reply... but seems i did not get your answer very well...... so you are against these customization just because it will be hard for other developers to understand these customization,, but in our case we always document our work, not for others to understand but also for me to know what I havedone,, if i come back to the project later on... my question is more into the validity of these customization from a pure sharepoint technical overview,, and not from a PMO or CEO point of view !!! hope this makes my question clearer to u Commented Mar 9, 2017 at 0:34
  • for applying these customization using custom layouts then i am not sure what do you mean by custom layout? do u mean custom master pages... if yes then the components i am hiding using custom javascripts and cusotm styles are not part of the master pages... Commented Mar 9, 2017 at 0:36
  • I don't want to overwhelm you by jumping into share point backend stuff if it's not something you're familiar with. There isn't really a definitive answer to your question - ye / no - it's not that black and white. Commented Mar 9, 2017 at 9:28
1

  1. I should avoid writing such a custom javascripts and custom style in sharepoint, since the classes i am depending on can change in the future?

  2. Those customizations are valid and i am not doing any thing wrong,, but if these custom javascripts and/or cusotm style break after installing an update, then the normal process will be to update these custom javascripts and/or custom style to match the new classes names...

Even Microsoft does not have all the answers to your questions yet.

That is why all CSS or JavaScript branding in (SPOnline) Modern Experiences is currently disabled.

They are working on technologies which will let you, partially, do customizations.
But besides current terminology 'scenarios' and 'codeparts' we have no clue what will actually be possible, or how.

The problem you describe is not new, even with .Net applications you could have problems when the OS was updated.
Just try and run an 8 bit EXE, from 20 years ago, on a Windows 10 machine.. None of the Multimedia CD-ROMs I developed 2 decades ago, run on todays machines.

Problem with the Cloud is that the 'OS' can update daily, and yes your custom applications on top of them can break.

My personal opinion is that we have to learn to live with that. No one takes out a blowtorch on their Tesla, no one changes the UI color of Outlook, Word or Excel.
Then why have we been so eager to take out the blowtorch on SharePoint for the past 10,15 years?
I think that is why Microsoft is churning out applications like Teams, Planner, etc. ect. like crazy. (Office365) Users want simplicity.

You want custom stuff? You can do everything you want with SPFx (the SharePoint FrameWork)

And we have to learn to program for changes, the Cloud is conceptually the same as the OSes 20 years ago.. only difference is the Update Cycle is Continuous... Takes a different mind-set.. maybe even takes Programmers who never used .Net

In synchronicity with the Google Cloud Next '17 Keynote playing on my second screen..

Paul Gaffney (HomeDepot):

"To a modern view: Just assume that everything is going to fail"

Improve this answer
5
  • first of all i have applied similar customization inside office 365 ,,so not sure if these are really disabled,, and those customization i am doing are not part of SP branding... second point, so can i conclude from your remaining reply, that we can apply such a customization ,, but we have to live with the fact that these customization might break in the future for a reason or another ... Commented Mar 9, 2017 at 0:40
  • You will be an inter galactic hero if you blog about how to do customizations in SPOnline Modern Experiences. Commented Mar 9, 2017 at 9:42
  • Ok i got your point ,,, i never customize the modern look and feel in office 365.. but my question is about the validity of writing custom javascripts and custom styles ?? are these approaches considered valid ? and have you implemented such cases before ?? keeping in mind that most of the customization i did in SP 2013 using javascripts and style are still working except in some cases these customization were removed after we install some SP updates and when i investigate the issues i note that some classes have been added/removed. for example after a SP update the selected Commented Mar 9, 2017 at 11:59
  • ........ quick launch link will be bold .. which was not the case in previous versions before the update,, and seems SP have done this modification by applying new classes to the selected link .. while other cases is still working well... my question as i mentioned before that i am writing a process that we need to follow after installing SP updates (either single fixes or full CUs) and one point i mentioned is that we need to test any customization ,, but i do not want to be documenting something that it is not valid (not recommended) from the beginning... did you get my question.. thanks Commented Mar 9, 2017 at 11:59
  • You answered your own question. When you do updates it is possible Microsoft changed the software. If you made changes as well, they could break. It is your own choice how you want to deal with that. This is not different than any software updating processing from the past 50 years... Updates bring changes, changes can break software. Commented Mar 9, 2017 at 13:00
0

I'm going to have to disagree with Daniel's answer: not only is it okay, I wish more developers would use Microsoft's OOB classes and IDs. They should be done with caution, and it is good to understand all the other places the classes and IDs might be in use - but that's the power of it: you can implement customizations that can be leveraged across your entire portal (or other SharePoint environments). If everyone did this, we could all be building on top of one another's work, instead of everyone always reinventing the wheel with every new solution. (After all, you're probably not the first person to want to hide the "What's Hot" link. :))

I do think it is a good idea to log these changes though, so you have a list of things to test after service packs or other upgrades (not that I've seen much in the way of HTML Class/ID changes during service packs).

Improve this answer
9
  • thanks for your reply,, but to be honest i did not full understand your point,, as you mentioned not only is it okay, I wish more developers would use Microsoft's OOB classes and IDs then you said They should be done with caution .,, and not sure how we can build on top of other work in such scenarios ... Commented Mar 9, 2017 at 0:43
  • So, let's say you implemented your changes based on Microsoft's CSS classes/IDs, and later instated some solution or feature that provided a more robust discussion board, or addressed some other shortcoming: if their feature used the same classes/IDs, then your customizations would continue to work even on their updated version of the tool. But if they used all their own classes/IDs, then your tweaks would need to be rewritten to support their solution/feature as well. Commented Mar 9, 2017 at 2:50
  • The caution just comes into play with making sure that your CSS is precise enough to only cover the scenarios you intend, so they don't muck up other elements of the interface. Commented Mar 9, 2017 at 2:51
  • i always write these customization only on the intended page/s using code snippets, never added such a customization inside master pages, just to make sure that my customization will have its effect on the current page only .. Commented Mar 9, 2017 at 10:24
  • :) That's caution. Commented Mar 9, 2017 at 12:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.