This project has moved and is read-only. For the latest updates, please go here.

GetSPField broken since newest Update?

May 25, 2016 at 8:28 AM
Edited May 25, 2016 at 8:54 AM
Hi everyone.

Since we updated our SharePoint 2013 with the newest CU, GetSPField is returning errors for all Fields.

We investiagted this and found out, that there are no HTML Comments at the Field Elements anymore, which you used to get the internal Name and stuff, so i guess this affects all users of SPUtility.

Any info about a new version coming up?

Thank you very much in advance!
May 25, 2016 at 12:48 PM
Yikes that is definitely not good. I've actually already thought about removing dependency on the HTML comments but it would take a pretty high effort to implement.

Was it the May CU which was installed?
May 25, 2016 at 2:57 PM
Heyho,

it happened when we installed the April CU.
We used the Library in an important environment, so we needed to do a quick and dirty fix to get some of the Forms running again. (Hiding, Showing, ReadOnly)

What i did was i "reimplemented" the Framework by using another way of getting the Field Infos, so that the Code we had on the Forms was working again. It works for text, number, choice, yes/no, and hyperlink columns.

Maybe this could help other users to get their solutions running again until a new Version of SPUtility is released. Again, i do not advise to use this in a production environment as it is a quick and dirty fix and may fail in some circumstances.

At KitMenke: I called Microsoft Premier regarding the Comments today. They said it may happened due to refactoring, but they are investigating it further. I can provide more Info on Friday, but i doubt that the Comments will come back :(
function SPField(element){

   this.element = element;
}

SPField.prototype.Hide = function(){
    if(SPUtility_init == true) {
        $( "nobr:contains('"+ this.element +"')" ).parentsUntil( $( "tr" )).parent().hide();
    }
};

SPField.prototype.Show = function(){
    if(SPUtility_init == true) {
        $( "nobr:contains('"+ this.element +"')" ).parentsUntil( $( "tr" )).parent().show();
    }
};

SPField.prototype.GetValue = function(){
    return "";
};

SPField.prototype.MakeReadOnly = function(){
    if(SPUtility_init == true) {
        $( "nobr:contains('"+ this.element +"')" ).parent().parent().next().children(":first").children(":first").attr("disabled", "disabled");
        $( "nobr:contains('"+ this.element +"')" ).parent().parent().next().children(":first").children(":first").next().attr("disabled", "disabled");
        $( "nobr:contains('"+ this.element +"')" ).parent().parent().next().children(":first").children(":first").next().next().next().next().attr("disabled", "disabled");
    }
};



function SPUtility_c() {
    
}

SPUtility_c.prototype.GetSPField = function(displayname) {
    return new SPField(displayname);
};

SPUtility = new SPUtility_c();
SPUtility_init = false;

_spBodyOnLoadFunctionNames.push("initSPUtility");

    function initSPUtility(){
        SPUtility_init = true;
    }
May 26, 2016 at 3:58 AM
Edited May 26, 2016 at 4:00 AM
Ok thanks for the info about the CU and for double checking with Microsoft about the HTML comments. I find it strange they removed it in SharePoint 2013 but it still exists in SharePoint online.

Bad news first:
  • I probably have to add new logic to auto-detect the field's type based on the HTML elements.
    • The only other alternative I can think of is to force the user to pass GetSPField the type of each field along with the name like SPUtility.GetSPField('Title', 'SPFieldText').
  • GetSPFieldByInternalName will probably never work if the comment is missing
  • No way to distinguish Number and Current fields
  • I don't have a real environment to test this in
Good news:
  • I was able to reproduce the issue in my unit tests so I can start working
  • I was able to fix text and number fields pretty easily... now onto the rest!
You mentioned text, number, choice, yes/no, and hyperlink columns. Can you tell me what type of choice fields? Dropdown, checkbox, radio? With fill-in? I'll try to fix the fields you're using first.
May 27, 2016 at 9:08 AM
Hi KitMenke,

we are using all Kinds of the Choice Fields.

I talked to Microsoft again and they said that the Comments were NOT removed from their templates!
I started investigating on our site and we found out that our Loadbalancer somehow started removing HTML Comments from all Pages due to HTML Compression. So i do not think other users are affected by my Problem.

Sorry for making you worry about that.

It may be a good idea to remove the dependency on the Comments anyway, as other loadbalanced SharePoint Environments with Compression will not work with SPUtility until now and the End Users trying to use the Library may not know that and just think "well, the Library does not work".

I saw that you are loading all the Fields before doing anything, so i thought about a new way how to do it (i guess you had this idea as well, just wanted to know if that could be a useful solution).

All <input> Tags have an ID-Attribute, containing the internal Name of the Field, plus the Field Type like this:
<input title="abcdefg" class="ms-input" id="abcdefg_eb7c2503-3184-41d0-beb0-e6a9f3d244db_$NumberField" style="-ms-ime-mode: inactive;" type="text" size="11" value="2">
I guess its always [Internal Name][GUID][_$Field Type]
Additionally, if you traverse up the DOM Tree, there will be the Display Name of the Field in <nobr> Tags, right under the nearest h3 Element.

So this way it could be possible to get all the Fields by searching the DOM for ID Attributes containing _$NumberField, _$TextField, and so on to get internal name, type and even GUID, and then traverse up the DOM to get the Display name and load everything into the tables you are currently using as an internal container for all fields.

Again, i apologize for making you worry about your code.
May 30, 2016 at 11:24 PM
Phew.. well that is good news. At least it isn't broken for everyone. I do think that removing the dependency on comments is a good idea but like I said above it'll take quite a bit of work. :)

I took a look at the input elements and that does look like a good option for 2013+. In previous versions the ID wasn't so nice:

For example, single line of text, currency, and number fields were all TextField.
<input name="ctl00$ctl33$g_fb04b311_f2ea_4feb_b99a_31e89b601d71$ctl00$ctl02$ctl00$ctl00$ctl00$ctl04$ctl00$ctl00$TextField" type="text" maxlength="255" id="ctl00_ctl33_g_fb04b311_f2ea_4feb_b99a_31e89b601d71_ctl00_ctl02_ctl00_ctl00_ctl00_ctl04_ctl00_ctl00_TextField" title="Title Required Field" class="ms-long ms-spellcheck-true" />
<input name="ctl00$ctl33$g_fb04b311_f2ea_4feb_b99a_31e89b601d71$ctl00$ctl02$ctl10$ctl00$ctl00$ctl04$ctl00$ctl00$TextField" type="text" id="ctl00_ctl33_g_fb04b311_f2ea_4feb_b99a_31e89b601d71_ctl00_ctl02_ctl10_ctl00_ctl00_ctl04_ctl00_ctl00_TextField" title="Currency" class="ms-input" size="11" style="ime-mode:inactive;" />
<input name="ctl00$ctl33$g_fb04b311_f2ea_4feb_b99a_31e89b601d71$ctl00$ctl02$ctl09$ctl00$ctl00$ctl04$ctl00$ctl00$TextField" type="text" id="ctl00_ctl33_g_fb04b311_f2ea_4feb_b99a_31e89b601d71_ctl00_ctl02_ctl09_ctl00_ctl00_ctl04_ctl00_ctl00_TextField" title="Number" class="ms-input" size="11" style="ime-mode:inactive;" />
But maybe dropping support for the older versions isn't so much of a big deal anymore. Either way, I logged a bunch of issues on GitHub to tackle this. Thanks for all of your hard work doing the investigation to track this down.