Kentico Support Roundup, Winter 2019

Posted: 1/3/2020 11:14:33 AM by Chris Bass | with 0 comments
Filed under: API, eCommerce, How-To, Macros, Performance, Support-Roundup

This season a lot of my focus has been on Azure Search, Online Marketing, and data cleanup, which I hadn't quite realized until I looked through my backlog and saw so many questions about Search and deleting things. Here's the big takeaways from Kentico Support questions - as always, let me know if you see any of these that you'd like me to dive deeper into! I'm always happy to take suggestions for topics.

  • In doing Contact Mapping, the Country and State fields have custom logic for saving their values - they can accept either the CountryName or the CountryID - it'll be stored in the Contact as an ID, but it'll translate if you point the mapping at a field containing a country / state codename.
    • No other fields have custom logic for saving the value, by default.
  • If you have EMS (Activities, etc) data that was stored, and your site's license is changed from EMS to Ultimate or lower, that data will stick around, but there won't be an interface in Kentico for clearing that up. Intead of writing a script to go manually delete it all from the database, reaching out to Kentico Support resulted in me getting a temporary EMS license that let me go in and clear out the data using the Kentico interface.
  • If the website is too slow to delete records, you can more quickly delete them in a custom scheduled task - This is how to do it for Activities, and this can be done even in lower license versions:
    • int batch = 5000;
      int max = Convert.ToInt32(ConnectionHelper.ExecuteScalar("SELECT MAX(ActivityID) FROM OM_Activity", null, QueryTypeEnum.SQLQuery));
      var prov = AbstractInfoProvider<ActivityInfo, ActivityInfoProvider>.ProviderObject;
      for(int i=1; i<=max; i+=batch)
      {
           prov.BulkDelete(new WhereCondition($"ActivityID >= {i} AND ActivityID <= {i+batch}"));
      }‚Äč
  • There are a number of issues with using Azure Search indexes in Kentico, when you're working with a Staging environment, because the index created in Azure is solely mapped to the Code Name of the Search index:
    • Any documents added to the index in one environment will be added to the index, where it can then be read from the other environment - so, you'll have Staging data as Production search results, and vice versa.
    • Any changes to the index definition in Kentico, while they *are* Staged, are *also* immediately applied to the Azure index (and thus used in Production), so there's -effectively- no content staging for Azure Search indexes.
  • Multilingual indexes, on the other hand, work fine - documentculture is one of the fields available to the index, so you can filter your search results based on DocumentCulture. Of course, that means there's no fallback - if the document hasn't been created in a culture, it's not in the search results (including the Default culture would result in duplicates)
  • Be careful of updating DLLs in general - you shouldn't just use NuGet to update every DLL to the latest version. For instance, a client had upgraded Azure Search to 5.0, which broke Azure Search, which (as of that task) used 3.0.x. 
    • If the DLL creator is doing their job right, minor versions should be fine - but I would be skeptical of, and thoroughly regression test, any updates to major versions of DLLs that Kentico uses.

Bonus round: Kentico Community Slack questions, answered by other developers:

  • When looking at a Product page's Form tab, remember that what you're seeing is a combination of the SKU object and the Page data, but both are stored in the cms_versionhistory table for that page. The takeaway *I* had for this, was that if you create a Staging task to move a SKU page, you need to move both the "SKU" record *and* the Page, not just go to the "Pages" tab in Staging and push the page. Otherwise, the two can get out of sync and leave you seeing data on the Live site different from the data you're seeing in the Form tab.
  • In Staging, it's worth knowing exactly what the "Synchronize All" and "Delete All" buttons do - specifically, it will delete/synchronize all of the *currently filtered* pages' worth of tasks - so, if you've filtered 20 pages of tasks down to 5 pages via the filters, those 5 pages are what will be synchronized/deleted. If you haven't set a filter, then of course all of them will go.
    • Relatedly, before doing a Staging task, if you have multiple sites *always* look at the top right hand corner, to see what Site you're looking at. Tasks can be pushed per-site, and it's important to know whether you're just pushing a change to one site, or globally.
  • Validation rules on Form fields (or custom table field, module fields, etc) only are run when there is 'data' being submitted. So, if you have a non-required field, that has minimum length set to 5, it will accept blank, or a string of length 5+. The main time this comes up is if you want a field to be *conditionally required*. The way I have found to do that is to create a new field, with no database representation, called 'FieldValidation' or something like that. Give it a simple default, hide the field, and have *that* field do the validation on the conditionally required field - because the field is filled, it will run the validation, verifying your actual conditionally-required field.
Comments
Blog post currently doesn't have any comments.
 Security code