Kentico Support is one of my favorite resources when the documentation fails to properly go over some detail of Kentico implementation. I wanted to take a few minutes to review some of the most useful advice I've gotten recently from them.
- Implementing a custom module page on the Pages interface? If you're saving changes, you can make use of Kentico's "You've got unsaved changes, are you sure you want to leave?" dialog. In the Security.ascx.cs file, there's a check between previous and new versions of your object, which then triggers the javascript in ~/CMSScripts/savechanges.js to pop up that dialog. So if you ever see that dialog or need to control when/how it appears, that's where that is. (If you make changes to those pages, be warned they probably will be overwritten in Kentico upgrades)
- When using ECommerce, the Order ID is hashed using the current session, creating an obfuscated string to actually represent the order ID in querystring. This means that if your session resets during a user's order (because of a build, or restart, or just coming back to the site later), their order can be abandoned accidentally, because that hash won't be usable anymore. That said, there's nothing stopping you from editing the Payment Form web part to have some other, restart-safe method of obfuscating the order ID - maybe save a random GUID for each order, that you can recall later. Doesn't really matter.
- When using a K# macro inside another K# macro, you should separate the "}" and the "%" at the end of the macro, to prevent Kentico from processing the inner one as closing the outer one. This looks something like:
{% "{" + " % InnerMacro %" + "}" %}.
- Want to use an object as the data source in an email template? If you use an object that is: "either a DataRow, DataRowView, or utilize an Interface such as IVirtualHierarchicalObject, IHierarchicalObject, IDataContainer, ISimpleDataContainer", then Kentico can understand macros like
{% Object.ObjectProperty %} based on that Object. It can save you from having to define Named source data for each property, and also lets you do things like implement Kentico-side transformations ({% Object.ApplyTransformation() %}) on those objects!
- Given an InfoProvider, you can generally get the SQL table associated with it by using the API call DataClassInfoProvider.GetDataClassInfo() on the object, which then has a property ClassTableName.
- In Kentico ECommerce, the Customer Detail web part wasn't designed to accomodate multiple instances of the web part in the same page of the shopping cart process. If you're implementing a one-page checkout, you'll need to create a single alternative form that shows all the data you want to gather, and then use client-side JS to rearrange the form to fit the interface you want to use (or to populate the real, hidden Customer Detail form somewhere else on the page on submit).
- If you're using it one per page on multiple pages, it should be able to find the prior-entered values and maintain them, even if you don't display those fields in your alternative-form.
- In Kentico's Shopping Cart logic, any fields you add to the ShoppingCartInfo class that are the same name as fields on the OrderInfo class, or fields on the ShoppingCartItemInfo that are the same name as fields on the OrderItemInfo, will automatically be transferred over when the order is completed, in addition to any come over by default. This is an easy way to make customizations to the Shopping cart (or item) data and have them maintained after the order is completed.
- When setting the event log size, you're setting the event log size *for that site* (or global events, for the global setting). That means if you just set the global size to 5000, you should expect to see the most recent 5000 global events, and the most recent 5000 events for each site on your installation. That means when you reach the 5000 global events point, you'll stop seeing global events but may still have more site-specific events, or vice-versa. (Plus a 10% margin on each that Kentico allows them to expand before automatically deleting them) This is especially noteworthy if you have a lot of non-error events, like content updates and such, that may push global or site events to be deleted, and then you look through your error log and see 'oh, there's still events here but the event I was reviewing before has been deleted'.
- If you have multiple sites that all use the same page type, be aware that if you set a default page-template on the page-type, that applies to *all* sites. Not so great if you have different layouts per site - either implement a Global Event that sets the page type as needed on Insert, or have your content editors manually set the page type on each page.
- In Kentico 11, there's a third Shopping Cart Address type, "Company", in addition to the billing and shipping address. It's not currently exposed in the Kentico interface anywhere, but you can manually set it in your custom code - it's represented in the Shopping Cart as ShoppingCartCompanyAddress.
- Relatedly, the billing address in Kentico is a required field. If your Ecommerce implementation doesn't need it (maybe everything in your shopping system is free?) then just hide that web part and set the billing address to a dummy value.
- If you've got a custom page type set up, and build a smart search index, you won't by default be able to do the smart search sorted by your customized document name field - they are not standalone fields in the index, they're part of the 'Content' field. If you want to do this, you need to customize the CMS.Document module class, setting the field as 'Searchable', which will break it out into its own field, and thus be sortable.
- Lastly, Kentico Support is actually where I was pointed towards the SiteObjects and GlobalObjects macro classes I covered back in May.