Skip to main content

Optimizely Gets More (Case-)Sensitive

As Windows developers, we don't always have to pay attention to capitalization when dealing with paths and URIs. With CMS12, Optimizely has started deploying to a Linux container for hosting sites. This means that deployed sites (and developers!) will have to pay attention to capitals in references. Inconsistent capitalization can cause 404 errors in unexpected places. Thankfully there's a few ways to handle that! 

The worst part of this is that developers won't be able to find these issues until deployed to Azure, with Windows, being case in-sensitive and all. Once named, files and folders can be difficult to change in git. Below are some ways to help rename your files so that they'll play nicely in Linux.

Rename via Git mv Command 
One way to update capitalization is by the git mv command. In you git command shell: 

git mv <source> <target>

This command will rename a file or folder, however it still runs in the context of Windows. If you want to simply change change capitalization you'll have to use an intermediate name due to the previously mention case-insensitivity of Windows, otherwise you'll get an error message from git. For example using the Scripts folder, in order to get the name to simply lower-case the following command sequence has to be run:

git mv Scripts scripts-lowercase
git mv scripts-lowercase scripts

Changing name directly in repo
This is perhaps the most straight-forward way to fix capitalization. If available, you can simply rename the files that need to match capitalization. I work in Azure DevOps, where this changes is as simple as hitting the kebab menu and select "rename".
Updated file names will carry-through a pull request, giving you proper naming on your master branch when completed. 

Update your git configuration
Perhaps the best way to enforce case-sensitivity is to update your git configuration to be case-sensitive in the first place. To do this, run this command in your git shell:

git config core.ignorecase false

This command will force git to pay attention capitalization on commits. If you want to only enforce this restriction do your local dev environment, you can add the --local argumment to the command. Doing this will cause only your commits to enforce capitalization, so other devs are not impacted. 

Unfortunately, if trying to update an existing repo this method can leave artifacts behind in your repository that will need to be cleaned up. These artifacts will not show up in your local file system, and will have to be removed via git command with the rm function, or removing the folders directly from your git repo. 


And another thing!
If a PR already exists and you're trying to merge capitalization changes into it, this will not update the names on merge. If you cancel/abandon the PR and create a new one, the capitalization changes will then be merged in properly.

This is a prime time to examine your file names and if they aren't inline with your current standards, now is the time to reduce some tech debt rather than create more by carrying bad practice past this point. A future dev (possibly even a future you) will thank you. 

Comments

Post a Comment

Popular posts from this blog

The 1001st Piece in your 1000 Piece Puzzle: .NET Default Interface Functions

I was recently working with a client who wanted a reasonably large subsystem added to Optimizely that would add automated management to their content. While cutting the code for this, I found myself writing similar code across multiple classes. The reason why I had to write it that way was: 1) The client was currently on CMS11 and didn't have access to newer language features; 2) The hierarchy of the classes prevented me from inserting a common ancestor. Thankfully, .NET has expanded the functionality of interfaces, so we can take advantage of those within Optimizely. With .NET 5, Microsoft introduced default implementations on interfaces. Now interfaces can bring along a default implementation. Resulting in all classes that implement the interface can use the default implementation or override it with custom logic. Enough text! Let's code! Original Interface The following code is something that we'd create for an Optimizely experiment: using OptimizelySDK; using Optimizely

Config-Per-Site in Multi-Tenant Environments

Recently, a task was given to me at work where we needed a multisite configuration. We all know that multi-environment is as easy as appsettings.<environment_name>.config. What about in multi-tenant environments? You can't have appsettings.site1.config and appsettings.site2.config in your site! Well, not without a little extra work... Allow me to introduce  AddKeyPerFile ; this handy little function that you set up in your Program.cs will enumerate the files in a directory and add them to your Configuration.  "Alright!" you must be thinking "Show me how this miracle function works..." Well, let's get to it! First, you'll want to identify the config sections that will be unique to each site and put them in their own folder. I do this by site name because it makes the most sense by our conventions, if something else works for your practice, these names aren't set in stone.  Now, in order to suck those values into your config, there's one simp