Calculated string field in Content Search Web Part

One of my customers had a need. They have an intranet site collection and another one for team sites. One of the team sites contains a list from which they wanted to show five newest entries on the intranet front page. Since both site collections are indexed in search, no problem, we simply used a Content Search Web Part for it. Re-indexed the list columns and created properties in the search schema for the columns they wanted to show in the CEWP.

One of these columns was a calculated field, that combined the name information into a neat display column of [Lastname, Firstname] string. It was quite a surprise when the CEWP showed this information with an additional string;# resulting in a list such as this:

• string;#Connor, June
• string;#Mickowich, Mark
• string;#Somebody, Else

You get the drift. I started to google, of course, landing several references to this behavior. The workarounds consisted mainly of two propositions: do not use a calculated field but rather a workflow, or, more specificly addressing this CSWP issue, make your own display template and fix the Javascript responsible for this starngeness. I wanted to do neither.

There is a very simple solution, done right there in the client side, on the page. What I did was insert a Script Editor Web part on the page underneath of the CSWP and in that editor, I added this simple piece of script: 

<script type="text/javascript">

$(function(){

$("h2.cbs-picture3LinesLine1").each(function(){$(this).text($(this).text().replace("string;#", ""))});

});

</script>

Element h2.cbs-picture3LinesLine1 was the one containing the name with extra string in front of it. This Javascript insert simply replaces that extra string with nothingness. Mind you, this uses jQuery, so be sure to have the jQuery available, referred to on the page one way or the other; this site already had it in the MasterPage.

[Edit Feb 27th, 2015
If SharePoint has MDS (Minimal Download Strategy) enabled, many JavaScript functions will not fire upon page refresh. To solve this issue, use the ExecuteOrDelayUntilBodyLoaded(function() in order to call your function after page refresh too, eg.

function cleanstring(){
$("h2.cbs-picture3LinesLine1").each(function(){$(this).text($(this).text().replace("string;#", " "))});
}
ExecuteOrDelayUntilBodyLoaded(function() {
   RegisterModuleInit('/mySite/SiteAssets/testModule.js', cleanstring);
   cleanstring();
});

If your script is located in a custom MasterPage or PageLayout, you can use the SharePoint ScriptBlock element which is run on the server, instead of the Script-element. This, however, does not work if your script is added to a page using the Script editor web part or editing page source code.

<SharePoint:ScriptBlock runat="server" >

$(function(){

$("h2.cbs-picture3LinesLine1").each(function(){$(this).text($(this).text().replace("string;#", ""))});

});

</SharePoint:ScriptBlock>

Also, on a publishing page, where MDS was not the issue, the problem was solved by using

$(window).load(function(){
...
}

whereas $(document)ready() did not do the trick.]

Content Query Web Part Breaks Page Layout in SP2013

Content Search Web Part replaces Content Query Web Parts in SharePoint 2013 on many occasions. This probably is the reason why it has taken this long for me to discover this rather annoying SharePoint bug: Content Query Web Part breaks a page layout built with div-elements, because the default web part (or the XSLTs?) seems to miss a </div> closing tag!

Everything is ok in edit mode, for what ever additional wrapper reasons:

but when I click my way out of edit mode, the page breaks:

In FireBug, I added a </div> tag to the page's source code (which is perfectly ok when no CQWP is added to the page) and this fixes the problem:

In real life, this obviously won't do. So as a workaround, I added a table element to the Page Layout code, inside the div-elements as a wrapper for the web part zones: 

<div id="rightcolumn">

  <table width="100%"><tr><td>

    <div class="ms-webpart-zone ms-fullWidth">

    ...

    </div>

  </td></tr></table>

</div>

Not an especially pretty insert, but the easiest fix I came up with for now.

Working With Boolean (Checkbox) List Fields

While it is rather straightforward to retreive a value from a text field in code, the checkbox is a little bit more tricky, being a boolean field. 

Using boolean (checkbox) field in a CAML query 

To retreive items from a list with a CAML query, you use the elements <Eq> or <Neq>, as in equals to (Eq) or is not equal to (Neq), value. In Checkbox fields there is no actual value string touse in the CAML equasion, but the Value element is needed to state that the value is boolean, and thus the equal to comparison is made against TRUE/FALSE, namely whether value is false or not:

• unchecked = false --> to retreive unchecked items, use <Eq>
• checked = true --> to retreive checked items, use <Neq>

So the following CAML would return all the items where the NotDisplayed field ("Do not display in webpart") is not checked.

<Where><Eq><FieldRef Name='NotDisplayed'/><Value Type='Boolean'></Value></Eq></Where>

Using boolean (checkbox) field in code, to retreive or set the value

In your code you might need to determine whether the checkbox of a list item (or any list item) is checked or not in order to do something, e.g.

bool YesOrNoValue= (bool)item["YesOrNoField"];

if (YesOrNoValue == true)

{

   ...do something

}

else

{

   ...do something

}

If you need to retrieve the value to use it as a string, you need a slightly different approach:

SPFieldBoolean YesOrNo = item.Fields["Item value is yes?"] as SPFieldBoolean;

bool YesOrNoValue= (bool)YesOrNo.GetFieldValue(item["YesOrNoField"].ToString());

To set the checkbox value, you can use a simple

item["YesOrNoField"] = true;

item.Update();

Adding Properties to a Web Part

When you create web parts for SharePoint, you can give the content managers the possibility to set some properties for the web part. These properties need to be set in the beginning of the webpart class, e.g.

private int_numTiles;

[WebBrowsable(true), //needed for visibility in web part properties in browser

WebDisplayName("Number of tiles per row"), //set the display name for the property field

WebDescription("Number of tiles per row"), //description for the property

Personalizable(PersonalizationScope.Shared), //enables setting the property for the shared view

Category("Tile Settings") //create your own property group (instead of the default Miscellaneous)

]

public int numTiles

    {

            get { return (_numTiles); }

            set { _numTiles = value; }

    }

The property above would be a simple text box field. You can use different types of properties to collect the settings data needed:

• string, int and DateTime are text fields
• enum is a dropbox
• bool is a checkbox

As for this particular case (that is, setting the number of tiles on a row in my Metro Tile Web Part) where the only possible number range that my web part would accept, the dropdown (enum) would be a better approach than a text box, or at least that way I can bypass the otherwise mandatory if-else (or property value check) by offering only the possible choices. The enum type in itself is a bit more work thatn the other properties, for you need to 

• declare the enum type first:
  public enum TileEnum{One=1,Two=2,Three=3,Four=4,Five=5};
•  then declare the property:
  private  TileEnum _numTiles;
  ...
  public  TileEnum  numTiles ...
• and in this case, convert the value to int for use in switch
  int TilesPerRow = (int) numTiles;
  switch (TilesPerRow){
  Case 1:
       tileclass = "onetile";
       break;
  ...

[The article about creating the tile web part: Creating a Metro Tile Web Part]

Creating a Metro Tile Web Part

Metro style is the hot topic right now, so it is only right to take a look at how to make your SharePoint site more Metro too. You can build Metro blocks in the Content Editor Web Part, of course, but wouldn't it be so much easier to manage the tile content if the data was in a SharePoint list instead of being static content in a CEWP?

What you need in your (Empty SharePoint project) is

• a List Definition and a List Instance for your source list - and I took it one step further by creating the Content Type for the list as well
• the WebPart
• your own CSS stylesheet in the mapped _Layouts folder

I am not going to go step by step through the process of creating these elements. For more info on creating SharePoint projects, webparts, content types, stylesheets etc. please check out some of my previous posts, e.g. in categories WebParts, Branding and Customization.

There's a whole lot of little things to do to put the thing together, and I will walk through the main points here.

For the Content Type (or the List Definition, if you are not creating a Content Type), you need to add the list fields and field references in its Elements.xml file. I used four fields in addtion to the Title field:

• tile icon url field
• tile content note field, setting the parameter HTMLEncode="true" to enable HTML tags in the content
• tile background color (text) field for the background color as HEX code
• tile url field (used to create a link wrapper around the icon and title)

In the ListDefinition Schema file you need to add the field references to the default view (BaseViewID 1) to show them in the AllItems view of the list. With the Fields and FieldRefs, remember that whether the tag has an endind tag or not really is of essence:

• in Content Type Elements.xml both the Field and FieldRef tags are one-piece, eg:
  <Field Name="TileLink" DisplayName="Tile Hyperlink" ID="{GUID here}" Type="URL" Required="true"/>
  and
  <FieldRef Name="TileLink"/>
• in List Definition Schema.xml the FieldRef inside the Content Type element is as above, but the FieldRefs in the View elements are two-piece:
  <FieldRef Name="TileLink">
  </FieldRef>

Also, remember to check the titles, descriptions and urls for the ContentType, ListDefinition and ListInstance, as well as the Web Part too, of course.

Once the list is done (and tested), add the Layout folder mapping to your project, and an empty CSS stylesheet in the project folder inside Layouts.

Then, add the WebPart to your project. In the WebPart .cs file, inside the CreateChildControls method, you need to

• add the CSS reference
  If you are not trying to override corev4.css, this simple line is fine:
  CssRegistration.Register("/_layouts/MetroTileWebPart/TileStyles.css");
  and as for this project, this goes fine, since only our own classes need to be used. But if you need to make sure that the CSS is read after the corev4.css, see this blog post for the instructions.
• retrieve the list items
  SPSite thisSite = SPContext.Current.Site;
  SPWeb rootsite = thisSite.RootWeb;
  SPList tilelist = rootsite.Lists["MetroTilesList"];
  SPListItemCollection items = tilelist.GetItems();
• loop through the items 
  A foreach loop is fine. 
• get field values for each item
  For any e.g. string type data (here the color and the content) you can use:
  string tilecontent = item["TileContent"].ToString();
  But if you try this with the hyperlink fields, due to the Description field embedded in it, you will get a double hyperlink value, separated by a comma, and that won't work. So you need to use the SPFieldUrlValue to get only the url value:
  SPFieldUrlValue TileUrlvalue = new SPFieldUrlValue(item["TileLink"].ToString());
  string tileurl = TileUrlvalue.Url;As for the title, you can simply refer to it with item.Title.
• and create the html for the webpart
  Using LiteralControls you can quite easily create the HTML for each tile, using the field values in the places needed:

And then you need to create the CSS for the classes. The key points in the CSS here being:

• the main element here is the tilecontainer, and for this 3 in a row, my CSS rules for it are:
  width:30%;
  padding: 10px;
  float:left;
  margin: 5px; /* to create a consistent 10px space between tiles */ 
• using the pseudo-element :nth-type-of(N), you can make the n:th (in this case the fourth) tile position itself neatly below the first tile instead of e.g. below the last tile of the row, if the tiles differ in height:
  div.tilecontainer:nth-of-type(3n+1) {clear: left;}
• the background of the content span is white opaque so that it sits nicely with which ever color tile, but the IE7 and IE8 don't understand the rgba-rule, so I set the background as #dedede for them:
  background: rgba(255, 255, 255, 0.4);
  *background: #dedede;

Otherwise, the CSS is all about the positionings and colors and margins etc. of the contents of the tiles.

For more info on Metro style UX desing, see: http://msdn.microsoft.com/en-us/windows/apps/.

[See also: Add Properties to Your Web Part]

Boost Up Your SharePoint

Even though I am very much pro-wsp, that is, building (UI)stuff in SharePoint the "right way", in VisualStudio, and packaging it into a wsp with features, I acknowledge that there are cases and situations where it really is not in the customer's - the SharePoint holder's - best interest to do it the long and expensive way, but instead make a lightweight solution directly in the site.

This - tweaking, enhancing, boosting the existing environment - is what I talked about at Techdays Finland last week. The slideset (in Finnish) can be downloaded from the Techdays site, video will be available later on, and here is a summary in English.

The basic thing to understand is that SharePoint pages are built with html and css, just like other web pages. The frame of the page is the html - xhtml more specifically, unless html5 has already been implemented - of the Masterpage. This you cannot alter - nor any other existing html on the pages - but you can manipulate it with css, and you can add your own html on pages too. 

On a wiki page, the additional css and html are inserted straight to the page by editing the html of the page (you might want to convert it to xhtml first); no Web Parts are needed for this. You could even create your very own Text Layout inside the wiki page by using the One Column Text Layout and then creating your own divs (or table, if you wish) in the html editor. You can hide elements on the page, e.g. the left side navigation (see my earlier post on this) - use IE Developer Toolbar or Firebug etc. to find the elements - but you cannot add JavaScript on the page for SharePoint will rip it out.

(I did not show this own layout as a demo at Techdays - an hour is sooo short!)

Save your layout html (Save and Close, then return to edit mode) before inserting Web Parts in your own divs - otherwise SharePoint just might erase the whole html.

On these wiki page based sites such as Team Sites, you need to create a Web Part Page and use a Content Editor Web Part in order to be able to insert JavaScript on the site. This Web Part Page can be set as the home page of the site in Site Settings > Welcome Page (in Look & Feel category). Another suggested work-around is to add the Javascript references and functions to the page as a linked text file and then call them from the page html. I haven't explored this further myself.

On publishing pages any custom html, css or JavaScript needs to be inserted in a Content Editor Web Part. Then the contents can be edited in a similar way as the contents of a wiki page - except that SharePoint does a little less ripping, so JavaScript can be quite easily inserted too. In my session I demoed a couple different jQuery functionalities:

• the simple picture gallery (from DynamicDrive)

(http://www.dynamicdrive.com/dynamicindex4/simplegallery.htm)

• the tabbed or accordion UI (from jQuery UI)

With the jQuery UI, remember the Download tool for getting all the right bits and pieces, and themes too, without needing to copy everything manually!

These are only a couple examples. Exploring the jQuery site and the web more widely, you can find a whole lot of ideas and things to put on your site, and if you learn SharePoint Client Object Model, you can even use the SharePoint libraries and lists in custom functions, e.g. in a picture gallery as above.

Just remember: jQuery shoud be referred to only once per page, otherwise the whole thing goes berserk. See more about JavaScript and SharePoint in my earlier post on the topic. And check out the mobile comaptibility tables to see what the mobile devices support and what not! If you want to really make it happen for the mobile devices too, you might want to consider jQuery Mobile.

JavaScript you can add to pages as demonstrated above, or use it in Web Parts or application pages etc. created in VisualStudio, or add it to a site in an empty module and then delivere it as wsp solutions with features. With the css, you have the possibility to insert it on the page, deliver it in a UI solution or create something in between: an alternate stylesheet. With the alternate stylesheet you get the same css tweaks on every page of your site, or even site collection if you select to inherit the stylesheet  - and you can even manipulate the Web Apps page ribbon to an extent.

The Office Web Apps and Office Web Parts, such as Visio and Excel Web Parts, are more or less untouchables otherwise. You can do some little tricks to the toolbars with css, even with wsp-issued JavaScript, but that's pretty much it. The contents and their styles run down deep in the code, there's no changing e.g. the colors of the Excel chart in the Web Part. Simply does not happen.

The thing to remember with all these customizations is that they are more or less one-time-only. You can copy-paste your html, css, JavaScript etc. and store it in a text file to reuse it (and actually this is highly recommendable even if you only use them in that one site - it's better to edit the text file and then copy-paste it to the page again as it is than try to edit the html that SharePoint has already messed up), but still, it is not an easily maintained reusable content part like a Web Part. So think carefully where the line goes between tweaking and making it for good!

Using JavaScript in SharePoint Content

With JavaScript, you can boost up your SharePoint page content, take it from being text and images to something interactive and awesome, right? With jQuery it becomes even easier - someone else has already figured out the code, all you need is to copy-paste it to your site, right? More or less, yes. The potential is great, but, how should I put it? There's some quirks involved. (Anyone else having a dêja vu right here?)

Let us start at the beginning. The way to use JavaScript on a SharePoint page is to insert it in the HTML content of a Content Editor Web Part on the page. It works fine on publishing pages and web part pages, but if you try to insert the JavaScript code to the html of a wiki-page, say the home page of a team site, it won't fly. SharePoint edits the page html after you, and while it allows scripts in the html of CEWPs, it doesn't allow them in the wiki content. And it doesn't help to insert a CEWP on the wiki-page, for SharePoint, it does not function there.

We have got as far as understanding that JavaScript is ok in CEWPs. Let's say that you want to be using some jQuery and implement e.g.  three accordions on a single page. With jQuery you need to remember, that you are using a JavaScript library, that normally is referenced only once on a webpage. If you simply copy-paste the jQuery code bits and leave the jQuery reference in situ in all of them, you will run into problems. The browser gets confused and starts reacting funnily to the keyboard, e.g. refreshing a page with F5 might take you to a whole different page.

The thing to do, of course, is to have only one jQuery reference on the page, in the CEWP that the browser reads first, the rest of the CEWPs are able to to use this one reference after the first one makes sure the file gets loaded. Other approaches could be to insert the reference on the page in its own hidden CEWP, thus it is not attached to any single web part using it (and won't get removed if that specific web part gets deleted from the page). Or, if you are building your own master pages and know that you will need the jQuery library, you could insert it to the master pages as well. This might be risky, though, if the content editors creating the jQuery thing-a-ma-jiggies on the pages are not aware of the already existing jQuery reference.

As you go about the inserting some script in a CEWP, I highly recommend you to create a base text file of the scripts + styles + css/js references + the basic html, so that if anything goes wrong, you don't have to start from the scratch all over again. Maybe even include the contents of, say the accordion divs, in the file. When you need to update the content, update the text file and then copy-paste it to the CEWP all over again, deleting all the old stuff first. SharePoint reads the JavaScript when you save the page and inserts all the classes and whatnot that the script feeds to the HTML and for some reason, if you fiddle with the HTML content of the CEWP after SharePoint has fiddled with it, it is bound to break very easily.

One last tip: don't store your JavaScript files in a library that requires publishing and/or approval for the documents. This will only give you problems.

Despite all, have fun with JavaScript and SharePoint! They do work together after you tackle these small details.

Building a Custom ContentQueryWebPart

Since I have just gone through building my first custom CQWP for a publishing site collection, step by step, thought I'd share some notes on it. It's basically really not too complicated, but it does have a few quirks to go with it.

ContentQueryWebPart uses two main xsl-files:

• the ItemStyles.xsl for item templates
• the contentquerymain.xsl for the outer templates

Most often what you would be interested in customizing, is the ItemStyles.xsl which is located in the Site Collection Style Library, in the XSL Style Sheets folder. This provides the templates for items in the query result, enabling you to e.g. add fields to show, alter the order of fields and add additional html and style classes to item templates. This, of course, requires knowledge of xsl, how deep depends on what you are trying to do.

The first thought might be "ok, I'll open the ItemStyles.xsl to SharePointDesigner and edit it". I say no, you don't. You open the ItemStyles.xsl to SharePoint Designer and copy all its content and paste it to an xsl file in VisualStudio. But wait! We're not that far along yet, so let's back up a bit.

Yes, the correct way to do this is to create a VisualStudio 2010 project and package it as a wsp solution package. So start by creating an Empty SharePoint (2010) Project (remember to check that your Framework is set to 3.5). 

Type a site to use as test site and select the solution type (either one is ok, sandbox or farm). Add a module (Add > New item) in the project:

Delete the Sample.txt file and add a new item to the module:

Note, the item added is xslt-file (from Data category), remember to change the file type to xsl, e.g. CustomItemStyles.xsl.

Open the Elements.xml file of the module and edit the module information by adding the Style Library as the Url for the module and XSL Style Sheets folder as the Url of the item:

Now it is time to locate the original ItemStyles.xsl and open it for editing in SharePointDesigner. There is no need to check it out since there is no need to edit it, simply copy the contents of the file and paste them to the xsl file just created in VisualStudio. VisualStudio will notify (as an error) that the named template OuterTemplate-etc. does not exist, but don't mind this. The OuterTemplates are defined in the contentquerymain.xsl, which will be available for the custom CQWP without needing to copy it to the project.

Now what we ought to do, is select one of the existing templates as the basis for the custom one - this saves a whole lot of work. So if you're not sure which is a good starting place, insert a CQWP on your site and try out the different OOB templates. Then locate the template you want to modify, copy the complete template tag and paste it on the xsl sheet as a new template tag. Modify it as you like - you can move the divs around and create your own (remember to assign a class for your div!), but be mindful to maintain the schema and general structure of the template!

Now, the item template being done, it is time to add the webpart in the project. The OOB CQWP does not know how to use the custom xsl and there is no way to implement it, so we need to create our custom CQWP as well. Add a SharePoint webpart item in the project:

You don't need the webpart's .cs-file, so you can delete that. Then open the browser again, add a new CQWP on a page and export the webpart without setting any properties. Once saved on your disc, open the webpart file and copy and paste its contents to the webpart file in VisualStudio, replacing the default content created by VS.

Change the title of your webpart:

Then locate the properties ItemXslLink and ItemStyle and set them to point to the custom xsl:

Yes, that's right: no slash between ~sitecollection and Style Library.

Furthermore, if you want to make things neat, you might want to change the category in which the webpart is found on the site. The deafult is Custom, but you can change it by opening the Elements.xml file of the webpart and typing your own group name:

Ok, now we're almost done. The last thing to deal with is the features. Adding the module created a feature and adding the webpart created another one. There is no need for two features, so you can delete the other one. The clue is to delete the right one. Double click on each feature to see its properties. The first one only contains the styles module, the second one shows both modules (although you need to add the styles module to the feature items). Delete the first one, and add the styles module to the other one. 

Also, you might want to rename the feature. One thing is to rename the feature in the feature properties and the other to rename the feature file in the solution explorer (right-click the feature > Rename). You might want to do both.

The final thing to do, is add a feature event receiver. Why? Because for some reason at least a publishing site collection otherwise refuses to let the custom CQWP use the custom xsl file, informing that it is not trusted. So this feature receiver corrects this problem by specifically assigning the sitecollection url for the webpart.

Right click your feature and add an Event Receiver to it. Open the event receiver for editing, uncomment the FeatureActivated method and add the following code to the method, changing the wp.File.Name value to your own webpart name.

(Thanks for the feature receiver goes to our coder, couldn't have come up with it myself!)

Note that you need to add the using statements for System.Linq and System.Text.

You're solution tree should now look like something this:

Now you are ready to package, deploy and test the webpart! 

Tip: If you need to do this more than once, which usually is the case, the easiest way to make it happen is to copy-paste the original xsl and webpart files to your disc drive (or such). Then you don't need to always do the same opening and copying all over again.

Invalid HTML in CEWP Causes Javascript Error on Page

One of my customers had a problem with the webpart menu on certain site pages in MOSS 2007 with a Content Editor Webpart on the page. The webpart menu on the content editor webpart and randomly, it seemed, on some other webparts on the page, wouldn't open at all and the page reported an error. Debugging this, the error I got was 'style.display' is null or not an object in the javascript file ie55up.js.

This error message, however, isn't really helpful for correcting the problem. There is nothing wrong with the javascript code, nor the webpart menu; the problem is the html in the content editor webpart contents. Apparently the editor of the page had copy-pasted the contents of the webpart from one to another and yet another, resulting in unwanted div-tags in the beginning of the webpart content, containing a false id attribute which seems to cause the javascript error.

So, to correct this error one should get the content editor webpart to editing mode, open the rich text editor and there swich to the html code view with the < > -button and delete these div-tags. Not an easy task though, when this very thing is causing an error opening the webpart menu! On one site, I managed to get the menu to work again by closing the webpart and then adding it to the page again from the closed webparts gallery. But on the other sites, trying to close the webpart only ended up in a SharePoint error page.

So what I did, was to open the page content list by adding ?contents=1 on the address bar after the page url and delete the whole webpart on that page. There it didn't cause an error. After that I could add a new content editor webpart on the page, without errors. And since I still wanted to restore the old contents, I had copy-pasted it form the page to notepad, from which I could then again copy-paste it to the new CEWP, clean.

Simplifying calendar booking

A customer of mine had this question about enhancing a booking calendar on a SharePoint 2007 website. They had a basic team site with a basic calendar on it, but they wanted to make it more simple for the users to make a new event or booking, than to force them to use the New button and the basic New Item Form with several unnecessary fields in it. Also they wished for the form to be on the same page with the calendar so free dates could be viewed simultaneously with filling in the form.

So I took to figuring out the easiest and most convenient way of doing this. After fiddling with dataviews and forms and coming to the conlusion that they, in fact, were not what I wanted and needed, I decided on inserting the calendar webpart to the aspx-page in calendar view and then inserting a custom list form beside it in SharePoint Designer.

I actually ended up doing this from a scratch, on an empty aspx-page. First, I created a table inside the PlaceHolderMain, then inserted the calendar web part in the left hand cell by dragging and dropping it from the web parts task pane.


Then I selected the table cell on the right hand side and inserted the List Form in it (Insert > SharePoint Controls > Custom List Form).



Select to use the Calendar on the site and the New Item Form. I didn't want the Attachment and Spelling buttons on the form, so I also deselected the Show standard toolbar checkbox.

Now, the form needed some editing for it had way too many fields in it. So I selected the rows containing data that was not needed and deleted the rows by right-mouse-clincking them and selecting Delete > Delete Rows. But beware not to delete the requiered fields (marked with the stars).



Once the form contained only the necessary fields, it was time to test it in the browser. It was nice and neat and worked as it should.