1

I have two orgs with a page that uses custom labels and one works as you would expect it: {!$Label.MyLabel}

And I think the old behavior is that on an org with a namespace it is changed to: {!$Label.MyPrefix_MyLabel}

A few releases ago this changed without warning (and without changing the API version!) to: {!$Label.myprefix_mylabel}

First. It is incredibly annoying that if you have a namespace registered all the labels are being prefixed. Why would you do that? Just look it up using the default namespace! And it also decreases readability due to unnecessary lengthy names.

Second. Why is everything suddenly in lowercase? This makes it so much harder to read! Is there any way I can prevent this? Anybody experiencing the same?

3

First. It is incredibly annoying that if you have a namespace registered all the labels are being prefixed. Why would you do that? Just look it up using the default namespace! And it also decreases readability due to unnecessary lengthy names.

The namespace is used to not conflict with subscriber labels. This also allows the subscriber to do things like:

 {!$Label.MyLabel} vs. {!$Label.otherns__MyLabel}

The API does this for you automatically. However, if you use source control, you'd never notice the difference, because it wouldn't be prefixed in your source control, only in the Developer Org. Consider migrating to DX for a better development experience.


Second. Why is everything suddenly in lowercase? This makes it so much harder to read! Is there any way I can prevent this? Anybody experiencing the same?

This is apparently a new (undocumented?) feature. It's also annoying, but easily solved; use DX and you can keep your source code under control in your source repo. You can develop your code in Visual Studio Code using files in your repo, and you don't have to worry about the changes that occur in your source.


I think it's unfortunate that these behaviors exist, since (a) the namespace for the label shouldn't matter in a Visualforce page in the package (because it's already running in a managed package context), and (b) it doesn't make sense to lowercase your code for you, since we developers do often use TitleCase or camelCase to make variables easier to read.


There's no mention of this behavior in Special Behavior of Components in Packages, so this might be an unintentional change. You might try logging a case with support and see if they can find out more about this. For now, seriously, consider using DX to manage your code. You should be using a code repository anyways, and using DX will probably make your experience more pleasant in the long run.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.