From DNN 5.5, GetTabsBySortorder has got a new parameter: the cultureCode (and one for includeNeutral).

I have not yet figured out what the sort order refers to, but as opposed to GetTabsByName, I have some expectation of what it might mean. I will only find out for sure when I step through the process and examine the results.

Adding a cultureCode to the method's parameters is most likely a way to access the tab info for the translated pages in core CL. Other CL solutions don't have tabs per language, so using this parameter might produce unwanted results. Research on the subject leads nowhere. It's not that I would be at my wit's end yet, but a little information would save me a lot of time.

Would this be a method I should override in my code to produce the same results? [This is an issue I'll do some deep thinking about - after all, this is for me one big learning process.]

If I use the new function in my solution, wouldn't I be making my solution incompatible with DNN 5.04.04 and below? What would be the advice on this?

---

____________________________________
The one-eyed in the land of the blind.

I do not want compatibility with DNN 4. DNN 4 has a perfectly working solution. DNN 5 has not. One more issue remains. So I figured, changes in DNN 5 caused it to break.

The issue is this:
Module localizations allow you to specify a container per installed culture. Tab localizations allow you to specify a skin and a default container per culture. Portal localizations allow you to specify default skins and containers per culture.
Containers set in the module localization page and skins set in the tab localization page work as expected. But when default container or default skin are specified, DSL does not use the localized defaults but the defaults of the default culture.

Forget the issue for a moment. If it was created by (breaking ?) changes in DNN, my best chances are in first updating to the new DNN specifications. Most changes will make no difference to the result. The only difference they make is that they have forced me to think through the logic of the function and I understand the concept a little better. Some changes do make a difference.

There was an issue with breadcrumbs not being translated completely when a page in the path was disabled. That issue has gone.

There are changes regarding username, adminrole, isadminskin, isadmintab etc which I still want to understand, because some of these changes now produce different results. The warnings give some indications of where those changes might have taken place. After all, this is an application that has its roots in DNN 2. Clearing the other warnings kind of clears the playing field (I started out with the easiest ones).The warning about GetTabsByTaborder will not be cleared, which is okay, since I understand why and the outcome is the same. There are a few more warnings I decided not to clean up because I understand what they mean and I am sure they produce the same result anyway.

The last issue in DSL may be one of programming logic, but I think I'd be better equipped to analyse that when I'm sure there are no more other causes that may obscure my search. The fact that all supposedly functioned on DNN 4 kind of justifies my attention on the warnings.

I am maintaining this source because it has some vital functions for Khmer websites (and those of a dozen othes MS forgotten languages). I think this can benifit the community and I'd like to share my improvements.This is also part of a learning curve.

I am not sure how I will continue after I solved all open issues and I have a stable version of DSL for DNN 5. I will of course continue the necessary maintenance. But I am still considering whether or not I should make a DSL 4. The improvements I had in mind are only partly related to ML. So instead of creating a set of improvements to be included with DSL, I might create a set of controls that include controls for translators which can use DSL if present or core CL if installed or other solutions I can lay hands on.

I see the cleanup exercise also as a preparation for my new project by spying on others' solutions to solve specific problems or by having a template for parts of my project. Learning by example.

Thank you for pointing out I better leave this one as is for compatibility reasons, I was myself considering doing so. This does not change anything to the fact that I want to understand that function.

---

____________________________________
The one-eyed in the land of the blind.

The concept of an admin skin has been replaced by the the idea of an Edit skin.

Basically in the past the admin skin was used to display pages in the admin and host menus as well as any control pages such as edit settings and edit content pages for modules.  It was as skin with only one contentpane as such.

The idea being that you could have one skin for the site and another skin that displayed when you were doing admin work.

People used to then used the IsAdminSkin() function as a quick way of working out if they were currently displaying site content or editing that content in a settings/edit content module.

But having said this -  IsAdminSkin() is still a part of the core - it may work a little differently in the way it determines it status - but it still returns a valid result when you are in a edit options, edit content states for example - when the url has 'ctl' or 'mid' parameters in it.

RE:  AdministratorRoles

All permission should checking is now being handled thru the Permissions collection -  to get the same result you can call:

myAdminRoles = TabPermissions.ToString("EDIT")

Which is what the AdministratorRoles property has been deprecated to do anyway.

Westa