DNN 9.13.10 with fixes from DNN 10.x

Author: bdukes

.github/APPROVERS.md

@@ -1,38 +1,38 @@
-# The Approvers Group
-
-A vital role in our project is reserved for the people who decide what code is accepted into our framework, and what 
-is not. This is the task of the (Git) Approvers Group. To explain let's look at how the code of DNN gets changed.
-
-As you are probably aware the way the source code of DNN (which is hosted on Github)
-is currently managed, is through accepting so-called Pull Requests (or PRs). These PRs are submitted by
-enthusiasts like you and me where we aim to change the Repository ("base code") of the platform. The current list
-of PRs can be found here: [https://github.com/dnnsoftware/Dnn.Platform/pulls](https://github.com/dnnsoftware/Dnn.Platform/pulls)
-
-Before any PR gets accepted it has to be reviewed by 2 people before it can be "merged" into the main repository. 
-This reviewing and merging is done by a handful of people. 
-Due to the sensitive nature of this task and the skills required to do it, this is a highly restricted group.
-In the interest of transparency and to avoid any confusion here is a list of criteria that guide our decision as to who is part of this group:
-
-- Actively take part in the project (like attending Tech meetings, contributing code, etc)
-- Having in-depth knowledge of the overall organization and architecture of the project (this favors people who have been with the project for some time)
-- Having a track record of good code contributions
-- Knowledge of Git and Github
-- Having enough time to devote to this task
-
-This group is dynamic. Meaning: we expect people to float into and out of this group. 
-It is not an award that you put on a shelf like an MVP-ship.
-It is an ongoing task and if someone drifts away to focus on something else that person will be removed from this group.
-
-This group is practical. Meaning: there are no stacks of procedures. 
-We try to keep things simple and focus on a smooth development process for DNN.
-Members stay in touch through a Slack channel and meet
-bi-weekly to discuss progress.
-
-The current members are:
-- Brian Dukes
-- Peter Donker
-- Mitch Sellers
-- David Poindexter
-- Daniel Valadas
-- Matt Rutledge
-
+# The Approvers Group
+
+A vital role in our project is reserved for the people who decide what code is accepted into our framework, and what
+is not. This is the task of the (Git) Approvers Group. To explain let's look at how the code of DNN gets changed.
+
+As you are probably aware the way the source code of DNN (which is hosted on Github)
+is currently managed, is through accepting so-called Pull Requests (or PRs). These PRs are submitted by
+enthusiasts like you and me where we aim to change the Repository ("base code") of the platform. The current list
+of PRs can be found here: [https://github.com/dnnsoftware/Dnn.Platform/pulls](https://github.com/dnnsoftware/Dnn.Platform/pulls)
+
+Before any PR gets accepted it has to be reviewed by 2 people before it can be "merged" into the main repository.
+This reviewing and merging is done by a handful of people.
+Due to the sensitive nature of this task and the skills required to do it, this is a highly restricted group.
+In the interest of transparency and to avoid any confusion here is a list of criteria that guide our decision as to who is part of this group:
+
+- Actively take part in the project (like attending Tech meetings, contributing code, etc)
+- Having in-depth knowledge of the overall organization and architecture of the project (this favors people who have been with the project for some time)
+- Having a track record of good code contributions
+- Knowledge of Git and Github
+- Having enough time to devote to this task
+
+This group is dynamic. Meaning: we expect people to float into and out of this group.
+It is not an award that you put on a shelf like an MVP-ship.
+It is an ongoing task and if someone drifts away to focus on something else that person will be removed from this group.
+
+This group is practical. Meaning: there are no stacks of procedures.
+We try to keep things simple and focus on a smooth development process for DNN.
+Members stay in touch through a Slack channel and meet
+bi-weekly to discuss progress.
+
+The current members are:
+
+- Brian Dukes
+- Peter Donker
+- Mitch Sellers
+- David Poindexter
+- Daniel Valadas
+- Matt Rutledge

.github/BUILD.md

@@ -3,13 +3,13 @@
 Important: **Dnn.Platform does not support "Hit F5 and see your website come up".** I.e. you can't run DNN by hitting F5 on the source code in Visual Studio.
 
 There are three supported build scenarios:
+
 1. **Build to create a platform distribution package**. You'd only use this to test a complete package (how it installs, works, etc). This build process is used by our Continuous Integration system and creates the release packages everyone uses to install the platform.
 2. **Build to create a local DNN development website**. You'd typically not do this all the time, but only when you wish to set up a new development site or revert your development website to the current DNN repository state.
 3. **Debug build**. You'd use this when changing code and testing your changes on your (previously created) development site. Note you can also "rebuild" just a part of the platform and not the entire solution for this which will speed things up for you.
 
 When contributing to DNN, you'd typically go through steps 2 and 3 at least and maybe 1 if you wish to run more encompassing tests. But before you delve into code, please familiarize yourself with [How to Contribute](/CONTRIBUTING.md) first.
 
-
 ## Build/Develop Prerequisites
 
 - Visual Studio 2022 (or .NET SDK 6.x) or later
@@ -19,13 +19,15 @@ When contributing to DNN, you'd typically go through steps 2 and 3 at least and
 ## External sources
 
 There is one project not included in this repository that are distributed with DNN:
-* [CDF](https://github.com/dnnsoftware/ClientDependency) - The Dnn Client Dependency Framework
+
+- [CDF](https://github.com/dnnsoftware/ClientDependency) - The Dnn Client Dependency Framework
 
 If you wish to make changes to that project, please keep this in mind.
 
 ## Used Build Technologies
 
 DNN uses the following technologies to create a working build:
+
 1. MSBuild. This is Microsoft Visual Studio's built in mechanism to compile C#. It can also run auxiliary tasks (like packaging the included modules). These tasks are specified in `.build` and `.targets` files and can leverage .net assemblies to do its magic. Almost all central MSBuild code is in the `Build/BuildScripts` folder. Main folder location settings can be found in the `DNN_Platform.build` file in the root of the repository which can be overridden using a `DNN_Platform.local.build` file at the same location.
 2. Webpack. The "Admin Experience" (which is the project that contains the UI for managing DNN) contains a number of client-side Javascript projects (mostly React projects). These are built using Webpack. Webpack is triggered in the main build process in the `Build/BuildScripts/AEModule.build` script. But it can be run on individual projects if you need to.
 3. [Cake Build](https://cakebuild.net/). This uses C# code to run build tasks. We use Cake for orchestrating the entire build process (e.g. packaging of the platform) and for auxiliary tasks like creating a dev site. All Cake scripts are found in the `Build/Cake` folder. After Cake first runs it bootstraps itself and creates the `tools` folder where the various assemblies can be found. Note the scripts use the [DNN Cake Utils](https://github.com/DNNCommunity/Dnn.CakeUtils) assembly to do the heavy lifting.
@@ -38,7 +40,7 @@ This process uses Cake. Open Powershell at the root of the repository folder and
 .\build.ps1
 ```
 
-This will trigger the build and packaging logic. The packages are created in the `artifacts` folder. 
+This will trigger the build and packaging logic. The packages are created in the `artifacts` folder.
 
 Note that (unless a build version has been specified, see below) this process will retrieve the latest version from Github and use that to version dlls and manifests. This creates a bunch of changed `.dnn` files and you'll need to make sure you don't include those in any Pull Requests when contributing.
 
@@ -60,7 +62,7 @@ The build process uses a local settings file which is excluded from source contr
 
 This will create a file called `settings.local.json` at the root with the following content:
 
-``` json
+```json
 {
   "WebsitePath": "",
   "WebsiteUrl": "",
@@ -77,18 +79,18 @@ This will create a file called `settings.local.json` at the root with the follow
 
 The settings are as follows:
 
-|Name|Description|
-|---|---|
-|WebsitePath|Full physical path to the folder of your (dev) website|
-|WebsiteUrl|Url for that website (unused for now)|
-|SaConnectionString|SQL connection string with admin privileges. This allows the scripts to drop and recreate your database.|
-|DnnConnectionString|Connection string used in the web.config of your dev site to connect to the SQL database|
-|DbOwner|If you wish other than the default "dbo", please specify here.|
-|ObjectQualifier|The DNN database Object Qualifier. This is optional.|
-|DnnDatabaseName|Name to use for your DNN database. This is used in the drop and create scripts.|
-|DnnSqlUsername|User name for the account that has ownership of the database. This setting is used in the create scripts to ensure the account has the proper access rights.|
-|DatabasePath|Physical path to where you wish to create the database. Note this is just the folder, not the filename of the database.|
-|Version|You can force the build process to build for a specific version. E.g. 9.4.4.5. That will be used to build the correct versioned dlls and modules.|
+| Name                | Description                                                                                                                                                  |
+| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| WebsitePath         | Full physical path to the folder of your (dev) website                                                                                                       |
+| WebsiteUrl          | Url for that website (unused for now)                                                                                                                        |
+| SaConnectionString  | SQL connection string with admin privileges. This allows the scripts to drop and recreate your database.                                                     |
+| DnnConnectionString | Connection string used in the web.config of your dev site to connect to the SQL database                                                                     |
+| DbOwner             | If you wish other than the default "dbo", please specify here.                                                                                               |
+| ObjectQualifier     | The DNN database Object Qualifier. This is optional.                                                                                                         |
+| DnnDatabaseName     | Name to use for your DNN database. This is used in the drop and create scripts.                                                                              |
+| DnnSqlUsername      | User name for the account that has ownership of the database. This setting is used in the create scripts to ensure the account has the proper access rights. |
+| DatabasePath        | Physical path to where you wish to create the database. Note this is just the folder, not the filename of the database.                                      |
+| Version             | You can force the build process to build for a specific version. E.g. 9.4.4.5. That will be used to build the correct versioned dlls and modules.            |
 
 Once you've set up the above, run the following in Powershell:
 
@@ -104,7 +106,7 @@ Note: **you need to have gone through the steps for setting up a dev site (see a
 
 To build the .net projects to the right location, you'll need to create your override of the core build variables in the `DNN_Platform.local.build` file:
 
-``` xml
+```xml
 <Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
   <PropertyGroup>
     <WebsitePath Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">C:\Path\to\my\DNN\DevSite</WebsitePath>
@@ -119,12 +121,12 @@ For the Webpack projects it is set up to read from the `settings.local.json` fil
 
 ## Build React Projects
 
-The solution includes a number of React projects. Notably for the PersonaBar (`Dnn.AdminExperience/ClientSide/*`). To build these to your development site you 
+The solution includes a number of React projects. Notably for the PersonaBar (`Dnn.AdminExperience/ClientSide/*`). To build these to your development site you
 need to use Yarn and scope to the project you're working on. Go to the `package.json` file for the project and find the identifier (name) and use that. So if you're
 working on the Site Settings PersonaBar project, you'll find that file here: `Dnn.AdminExperience/ClientSide/SiteSettings.Web/package.json`. Open it up
 and you'll see something like this:
 
-``` json
+```json
 {
   "name": "site_settings",
   "version": "9.8.1",

.github/FUNDING.yml

@@ -1,15 +1,15 @@
-# These are supported funding model platforms
-
-github: [valadas, david-poindexter, mitchelsellers, donker] # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
-patreon: # Replace with a single Patreon username
-open_collective: # Replace with a single Open Collective username
-ko_fi: # Replace with a single Ko-fi username
-tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
-community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
-liberapay: # Replace with a single Liberapay username
-issuehunt: # Replace with a single IssueHunt username
-lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
-polar: # Replace with a single Polar username
-buy_me_a_coffee: # Replace with a single Buy Me a Coffee username
-thanks_dev: # Replace with a single thanks.dev username
-custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']
+# These are supported funding model platforms
+
+github: [valadas, david-poindexter, mitchelsellers, donker] # Replace with up to 4 GitHub Sponsors-enabled usernames e.g., [user1, user2]
+patreon: # Replace with a single Patreon username
+open_collective: # Replace with a single Open Collective username
+ko_fi: # Replace with a single Ko-fi username
+tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
+community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
+liberapay: # Replace with a single Liberapay username
+issuehunt: # Replace with a single IssueHunt username
+lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
+polar: # Replace with a single Polar username
+buy_me_a_coffee: # Replace with a single Buy Me a Coffee username
+thanks_dev: # Replace with a single thanks.dev username
+custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']