Deployment automation of factory default themes that were created trough developer mode

Eugene Shulga (SE) said:

plan C: was to copy-paste changes from themefiles/d and themefiles/fd directory from git repository directly into on-prem Verint instance filestorage, and this also seems risky for us because it was never officially approved to be safe way by Verint team

Currently, this is the approach I would recommend for continuous updating. The fd/ and d/ folders are documented ( https://community.telligent.com/community/11/w/developer-training/65591/editing-themes-in-developer-mode ) and supported, however, note that the file system is not monitored so updates will require manual UI Cache expiration (Adminitration > About > More > Expire UI Cache).

Eugene Shulga (SE) said:

there undocumented behavior when non-devmode Verint instance could store some of theme files in themefiles/f, and this /f directory is not properly documented, and just copying /fd and /d directories is not always working, so we currently dropped this plan

Storage in the f/ folder occurs when a factory default theme is edited, which is a valid behavior on a non-developer-mode site (like production). There are two versions of a theme implementation: the factory default version (only editable in developer mode) and the current version (site-specific, in non-developer-mode sites, preventing editing to the factory default so it is always available as a reference).

Eugene Shulga (SE) said:

Do you have code examples for these API or maybe you have something similar to Widget-Source-Management-Sample that could be applied for themes?

There is not currently a versioning API for themes as there is for widgets. The files can be written directly as mentioned above either via the file system or through the centralized file system API.

An alternative is to export and publish the theme to the production environment when changes should be promoted. This is fully supported, automatically expires the cache, and would overwrite all customizations made to the theme on the production environment (so it'll match the development version completely).

Currently, this is the approach I would recommend for continuous updating. The fd/ and d/ folders are documented ( https://community.telligent.com/community/11/w/developer-training/65591/editing-themes-in-developer-mode ) and supported, however, note that the file system is not monitored so updates will require manual UI Cache expiration (Adminitration > About > More > Expire UI Cache).

 Ben Tiedt , is this the main driver for the "Don't run production community in developer mode" note on the Developer Mode page?

Hi Ben Tiedt, thanks for detailed answer

Ben Tiedt said:

Currently, this is the approach I would recommend for continuous updating

Ben Tiedt said:

Storage in the f/ folder occurs when a factory default theme is edited,

I've performed few additional tests for filestorage2filestorage copy approach, seems there could be problems in edge situations e.g.

1. On devmode instance I created the theme with script file test1.js
2. I copy-pasted these files and directories from devmode instance filestorage to the prod instance filestorage
   1. \filestorage\themefiles\d\{themeTypeId}\{myThemeId}.xml
   2. \filestorage\themefiles\fd\{themeTypeKey}\{myThemeId}
3. After UI cache reset, theme have appeared on prod instance
4. I have altered test1.js file in my theme on prod instance, so my theme became "customized" and f\ folder have appeared
5. On devmode instance I deleted theme script test1.js, and created theme script test2.js
6. I have repeated step #2
7. After UI cache reset on prod instance, there was no changes in my theme scripts
   1. test1.js still exists
   2. test2.js is not exists
   3. theme is still marked as customized
8. On prod instance I have delete folder and reset UI cache
   1. \filestorage\themefiles\f\{themeTypeKey}\{myThemeId}
9. On prod instance my theme is still marked as customized and script section became totally empty (seems broken)
10. Only after I pressed in admin UI on prod instance to revert changes to default - test2.js file have appear

If we choose filestorage2filestorate copy method - how do we revert "customized" changes for our theme trough deployment script?

Primarily that warning is to provide production environments with an easy way to revert to a working version of the theme (or widgets/automations). 

Eugene Shulga (SE) said:

how do we revert "customized" changes for our theme trough deployment script?

There is not an API for this currently. Similar to widget upgrades, this would require interacting with the Community UI (select the customized theme and select "Revert to Default")

A theme is considered a single unit of editing--any edit to a theme implementation made within the production environment will cause the theme (as a whole) to be "customized" and no longer read from the factory default implementation. It is at that point a branch of the factory default theme, stored separately to allow diffing and reversion.

Thanks Ben!

Also it seems like even in Developer mode - page changes are not saved into file storage, thus copying fd/ & /d dirs between 2 Verint instances file storages will not include pages updates, right? Is there any workaround?

I'd rather prefer to choose filestorage copy method, but this seems as blocker for us

Also, this technically means - it's not possible to source control pages just by using Verint developer mode

Just quickly searching for solution - if we (somehow) extract page changes from devmode instance and put them into \filestorage\factorydefaultpages\{myThemeId} will it work?

Ben Tiedt