This is something I've learned and forgotten at least 4 times. Writing these types of things here helps me remember and seem to help quite a few other people as well. So...
Usually in DotNetNuke, if you want to associate a resource file with your control, you just create a resource file with the same name as the ascx file plus the .resx extension and place it in your App_LocalResources directory. DotNetNuke and/or ASP.NET auto-magically associates the file with your code and it just works.
However, every time that I create a control that dynamically loads other controls, I spend 30 minutes looking at names and file placement and... trying to figure out why the resource file doesn't seem to be loading. Eventually, it comes to me, for dynamically loaded files, you must explicitly set the LocalResource file.
To do this add the following line to your PageLoad function in your dynamically loaded control:
LocalResourceFile = DotNetNuke.Services.Localization.Localization.GetResourceFile(this, "controlfilename.ascx");
To learn more about DNN Module Localization, check out the DotNetNuke Module Localization Guide.
Comments (0)
DotNetNuke makes it easy to determine if the currently logged in user is an administrator (aka admin) or any other role for that matter. All you need to do is call the following: PortalSecurity.IsInRole("Administrators") or PortalSecurity.IsInRole("MyRoleName"). This function should return the boolean value very quickly as everything it needs is already in memory. You can call this from either the code behind or the ascx file (e.g. Visible='<%#PortalSecurity.IsInRole("Administrators")%>').
This can be very useful for determining whether or not to show a control or content meant only for the right groups eyes.
Comments (1)
A common performance issue in some versions of DotNetNuke
Is your DotNetNuke site running ridiculously slowly and consuming massive amounts of your processor? It might be stuck in a bit of a catch 22... The scheduler is trying to clear the ScheduleHistory table, but it can't because the ScheduleHistory table is too full.
Read More...
Comments (2)
When it comes to the toolbars for Rich Text Editors for clients to use to update there own sites, it is my firm belief that less is more. By default, the toolbars seem to be cluttered with endless options that rarely get used and in the end just make it harder to find the options users do need.
The FCKEditor Provider for DotNetNuke is great overall and exposes almost everything you need to set it up just they way you want it, including setting up different custom toolbars for different types of users (determined by role). But I haven't found much clear and concise documentation for adding your own custom toolbars. Here is how I do it...
Read More...
Comments (0)
*** Updated: Added method for DNN versions 3.3 and 4.3 and greater ***
DNN 3.0 - 3.2
In DNN 3.0-3.2 and 4.0-4.1, the membership / profile stuff made heavy use of Microsoft's Membership provider module which stores most of the information in a hash table. While this is fine for getting a single user, it's a complete nightmare if you want to show a grid or list of many users or to do something with the data in SQL.
There's a good write up on how to get at this info through SQL at DNN Stuff.
DNN 3.3+ and 4.3+
The core team did a complete and much needed overhaul of the User Profile system for DNN 3.3 and 4.3. The grid on the User Accounts page is now a lot more flexible but it still won't help you if you want non-admin users to view user data or if you want to utilize profile data in SQL... Click on the Read More link to learn how to get at DNN 3.3+ profile data in SQL. This data could then be displayed using the Advanced Data Grid
Read More...
Comments (2)