lombiq / open-source-orchard-core-extensions

Looking for some useful Orchard Core extensions? Here's a bundle solution of all of Lombiq's open-source Orchard Core extensions (modules and themes). Clone and try them out!

Lombiq's Open-Source Orchard Core Extensions

About

Looking for some useful Orchard Core extensions? Here's a bundle solution of all of Lombiq's open-source Orchard Core extensions (modules and themes). Clone and try them out!

This is an Orchard Core Visual Studio solution that contains most of Lombiq's open-source Orchard modules and themes, as well as related utilities and libraries. Please keep in mind that only those extensions are included which use the latest released version of Orchard (i.e. the very cutting-edge ones depending on a nightly build are not yet here).

This also serves as an example of an ASP.NET Core web app using Orchard from NuGet.

Note that this solution also has an Orchard 1 counterpart, Lombiq's Open-Source Orchard Extensions.

Prerequisites and getting started

• You need Node.js for building client-side assets in multiple projects. Check out Lombiq Node.js Extensions Readme for details.
• To develop and test scripts written in PowerShell, install and use PowerShell 7 instead of Windows PowerShell (i.e., up to version 5.x). Static code analysis is only executed through PowerShell 7.
• Since the extensions are included as git submodules when cloning this repo be sure to initialize submodules: When using a GUI this will most possibly happen by default, and when using the command line use the --recurse-submodules switch. If you cloned without initializing submodules, then you can run git submodule update --init --recursive to initialize them later.

Included Projects

• Libraries

  • Lombiq.HelpfulLibraries: Various libraries that can be handy when developing for Orchard Core, to be used from your own Orchard modules.
  • Lombiq.HelpfulLibraries.Cli: Command Line Libraries. This project helps with executing command line calls.
  • Lombiq.HelpfulLibraries.LinqToDb: With the help of this project you can write LINQ expressions and run them with a YesSql ISession extension method to query from the DB instead of writing plain SQL queries. Uses the LINQ to DB project. You can watch a demo video of the project here.
  • Lombiq.HelpfulLibraries.RestEase: Adds a typed HTTP client to the service collection using RestEase.
  • Lombiq.HelpfulLibraries.Refit: Adds helpers for working with Refit.
  • Lombiq.HelpfulLibraries.Targets: Targets project which references all Helpful Libraries. Only necessary for NuGet publishing, just as Lombiq.HelpfulLibraries.sln.
  • Lombiq.OrchardCoreApiClient: A client library for communicating with the Orchard Core web APIs, it contains an implementation for the tenant management API and a console application for testing and demonstration.

• Modules

  • Lombiq.AuditTrailExtensions: A module with additional features for the Audit Trail module in Orchard Core.
  • Lombiq.ChartJs: An Orchard Core wrapper around the Chart.js library for displaying datasets as various charts.
  • Lombiq.ContentEditors: With the help of this module you can create custom multi-page editors with async loading and saving. Watch a demo video of it from the Orchard Community Meeting here.
  • Lombiq.ContentEditors.Samples: Example Orchard Core module that makes use of Lombiq Content Editors.
  • Lombiq.DataTables: An Orchard Core wrapper around the DataTables library for displaying tabular data from custom data sources.
  • Lombiq.DataTables.Samples: Example Orchard Core module that makes use of Lombiq Data Tables for Orchard Core.
  • Lombiq.HelpfulExtensions: Orchard Core module containing some handy extensions (e.g. useful content types and widgets). This module is also available on all sites of DotNest, the Orchard Core SaaS.
  • Lombiq.HelpfulLibraries.Samples: Example Orchard Core module that makes use of Lombiq Helpful Libraries.
  • Lombiq.Hosting.Azure.ApplicationInsights: This Orchard Core module enables easy integration of Azure Application Insights telemetry into Orchard. Just install the module, configure the instrumentation key from a configuration source (like the appsettings.json file) as normally for AI, and collected data will start appearing in the Azure Portal. As seen on the Orchard community meeting. Note that this module has an Orchard 1 version in the dev-orchard-1 branch. Note that the module depends on Helpful Libraries.
  • Lombiq.Hosting.BuildVersionDisplay: Module to display the build version (i.e. .NET assembly version or other) on the admin of the Default tenant. This is useful to see at a glance which version of the app you have to deployed currently to the given environment.
  • Lombiq.Hosting.Tenants.FeaturesGuard: A module that makes it possible to conditionally enable and conditionally keep enabled, or entirely prevent enabling, configurable sets of features on tenants.
  • Lombiq.Hosting.MediaTheme.Bridge: With the help of this module, you'll be able to host your theme assets and templates from Media Library. It can be used together with the Lombiq.Hosting.MediaTheme.
  • Lombiq.Hosting.Tenants.Admin.Login: With the help of this module, you can log in from the Default tenant's admin dashboard to any other tenants as an administrator user. This is useful if you manage a lot of customer tenants and don't want to create individual logins of yours for each of them.
  • Lombiq.Hosting.Tenants.Maintenance: With the help of this module, you can execute maintenance tasks on tenants.
  • Lombiq.Hosting.Tenants.Management: With the help of this module, you can set restrictions on tenant creation and set tenant level shell settings in the tenant editor.
  • Lombiq.Hosting.Tenants.IdleTenantManagement: With the help of this module, you can ensure that any tenant where the feature is enabled will shutdown after a preset time is elapsed. This can be used to free up resources.
  • Lombiq.Hosting.Tenants.EnvironmentRobots: With the help of this module, you can ensure that your sites will not be indexed by search bots. Check out a demo video of this module here.
  • Lombiq.JsonEditor: Orchard Core module for displaying a JSON Editor like on jsoneditoronline.org. Watch a demo video of it from the Orchard Community Meeting here.
  • Lombiq.LoginAsAnybody: With the help of this module, a user with the site owner permission can log in as anybody on the admin dashboard.
  • Lombiq.OSOCE.Samples: This is a placeholder module that will contain sample code for UI tests and demonstration content for our open-source Orchard Core extensions.
  • Lombiq.Privacy: Orchard module containing features related to data protection/privacy and the EU law on it, the General Data Protection Regulation (GDPR). Check out a demo video of this module here. Important! Using this module will not make your site GDPR-compliant alone. Do not forget to create a privacy policy page that you need to link to from the various consent-asking features.
  • Lombiq.TrainingDemo: Demo Orchard Core module for training purposes guiding you to become an Orchard developer. Note that this module also has an Orchard 1.x version in the dev-orchard-1 branch of the repository. If you prefer tutorial videos more then check out the Dojo Course 3, the complete Orchard Core tutorial series.
  • Lombiq.UIKit: This module contains reusable shapes like text editors, custom-style checkboxes, dropdown editors, and in the future potentially more complex editors. Here you can also see a demo of it.
  • Lombiq.VueJs: Orchard Core module that contains Vue.js and commonly used Vue.js components to be used in other Vue.js apps as dependencies. Provides extensibility to create Vue.js component templates as Orchard Core shapes making them able to override in themes or modules.
  • Lombiq.Walkthroughs: Do you want to learn about the most important Orchard Core features with a hands-on tutorial that guides you with interactive tooltips, right there in Orchard Core? This module is for you! Check out a demo video of it here.

• Themes

  • Lombiq.BaseTheme: This theme contains infrastructure for custom Bootstrap 5 themes with standardized zones and built-in front end menu display.
  • Lombiq.BaseTheme.Samples: A sample theme that demonstrates the features of the Lombiq.BaseTheme.
  • Lombiq.Hosting.MediaTheme: With the help of this theme and its dependency, the Lombiq.Hosting.MediaTheme.Bridge, you'll be able to host your theme assets and templates from Media Library.
  • Lombiq.Hosting.MediaTheme.Tests.Theme: A theme only used for testing that demonstrates the local development version of a Media Theme.

• Utilities

  • Lombiq.NodeJs.Extensions: Configurable and MSBuild-integrated frontend asset pipelines for SCSS, JS, MD, and external libraries implemented using npm scripts. Uses NPM Targets under the hood.
  • Lombiq.Npm.Targets: Provides automatic NPM package installation and a custom NPM command execution before building a .NET project. This way it is possible for example to manage assets (e.g. .scss files or images) in a folder that will be automatically compiled into the wwwroot folder on build, which then can be excluded from the version control system.
  • Lombiq.SetupExtensions: Extensions for setting up an Orchard Core application.
  • Lombiq.Hosting.MediaTheme.Targets: Provides automatic Media Theme package creation during build.

• Testing

  • Lombiq.Tests: General and unit testing extensions and helpers, mostly for ASP.NET Core and Orchard Core. Also see our UI Testing Toolbox.
  • Lombiq.Tests.UI: Web UI testing toolbox mostly for Orchard Core applications. Everything you need to do UI testing with Selenium for an Orchard app is here.
  • Lombiq.Tests.UI.AppExtensions: UI testing-related configuration extensions for the web app under test. Note that the module depends on Helpful Libraries.
  • Lombiq.Tests.UI.Samples: Example UI testing project. The whole project is heavily documented to teach you how to write UI tests with the UI Testing Toolbox. It guides you through this process just like the Lombiq Training Demo for Orchard Core teaches Orchard Core and Orchard 1 development.
  • Lombiq.Tests.UI.Shortcuts: Provides some useful shortcuts for common operations that UI tests might want to do or check, e.g. turning features on or off, or logging in users. This way, UI tests needn't use multi-step UI processes to do these operations (and thus implicitly be coupled with and tests those features). Note that the module depends on Helpful Libraries.

• Tools

  • Lombiq.Analyzers: .NET code analyzers and code convention settings for Lombiq projects, predominantly for Orchard Core apps but also any .NET apps. We use these to enforce common standards across all our .NET projects, including e.g. all of our open-source Orchard Core extensions.
  • Lombiq.Analyzers.PowerShell: PowerShell static code analysis via PSScriptAnalyzer and Lombiq's recommended configuration for it. Use it from the CLI, in GitHub Actions, or integrated into MSBuild builds.
  • Lombiq.GitHub.Actions: Some common workflows and actions for GitHub Actions shared between Lombiq projects, e.g. to build and test Orchard Core apps, publish packages to NuGet, verify that a Git submodule pull request has a corresponding superproject one. These can be invoked from any other repository's build.

Samples and Recipes

You can activate various sample content in the site:

• Lombiq.JsonEditor: Go to Recipes in the admin dashboard and select "Lombiq Open Source Orchard Core Extensions - JSON Editor Sample".
  • Content Items > JSON Example Page: Shows the sample item in action. Edit shows the JSON Editor where you can change the JSON value. View demonstrates simple JavaScript consuming the JSON content.
  • Content Definition > Content Types > JSON Example Page > JsonExampleField: You can edit the this field's JSON Editor's configuration object here. Check out the Templates property!
• Lombiq.UITestingToolbox: Web UI testing toolbox mostly for Orchard Core applications. Check out its samples in this solution.
• Lombiq.TrainingDemo: Select the Training Demo setup recipe when you first run the site.
• Lombiq.DataTables:
  • Go to Features in the admin dashboard and select "Lombiq Data Tables - Samples".
  • Go to Recipes in the admin dashboard and select "Lombiq Data Tables - Sample Content - Employee".
• Lombiq.BaseTheme:
  • The "TEST: Basic Orchard Features" setup recipe automatically sets it up. If not using it, run the "Lombiq Orchard Core Base Theme - Layers and Zones" recipe, and then enable the theme in Admin → Design → Themes.
  • In case of theme development you can use the "Lombiq Orchard Core Base Theme - Styling Demo" theme to test against some common HTML elements.
• Lombiq.ChartJs: Go to Recipes in the admin dashboard and select "Lombiq Chart.js - Sample Content - Income/Expense".
• Lombiq.Privacy: Go to Recipes in the admin dashboard and select "Lombiq Privacy - Sample Content - Privacy, Forms, Workflows".
• Lombiq.Hosting.MediaTheme: Go to Recipes in the admin dashboard and select "Lombiq Hosting - Media Theme - Samples".

Contributing and support

Bug reports, feature requests, comments, questions, code contributions and love letters are warmly welcome. You can send them to us via GitHub issues and pull requests. Please adhere to our open-source guidelines while doing so.

This project is developed by Lombiq Technologies. Commercial-grade support is available through Lombiq.

Adding a new extension or significant new features

When adding a new extension, or significant new features to existing extensions, do the following:

• For user-facing features add a recipe to it, demonstrating its usage with sample data. In that case, refer to it in the above section.
• If no data is needed or if the feature is more library-like, add a sample project (or in addition to the recipe). Put this project into the root of the submodule, so to have the main project's and sample project's folders side by side.
• Add lower-level unit/integration tests as necessary with the Lombiq Testing Toolbox for Orchard Core.
• If the sample project includes MVC actions, create a service that inherits from MainMenuNavigationProviderBase and adds front-end main menu items. The top level menu item should have the project's shortened name and the submenu items the individual actions. If you have several controllers, use separators and labels as you can see in the TrainingDemoNavigationProvider.cs.
• If the feature is user-facing, also add UI test extension method(s) with the Lombiq UI Testing Toolbox for Orchard Core that assert on some important aspects, and execute them from a new UI test in Lombiq.OSOCE.Tests.UI (for inspiration, see the examples there). These methods are also meant to be executed from UI tests in other projects when testing how it integrated with other features. If you've added a demo recipe or sample project to it then utilize that in the test too (see ExecuteRecipeDirectlyAsync()). For this, you'll also need to enable the feature in Lombiq.OSOCE.Tests.recipe.
• If the project is published on NuGet, reference it from the app in the Lombiq.OSOCE.NuGet solution as well, and enable its features in the Lombiq.OSOCE.NuGet.Tests.recipe. If it has UI testing methods, also run them from Lombiq.OSOCE.NuGet.Tests.UI.
• If an extension is added, removed or significantly updated in this project, then add, remove or update its description under the "Included Projects" section of this Readme.

Opening pull requests

• Open a pull request in this repository for every submodule pull request. That way, static code analysis and complex tests can run. If you forget to do so, a check in the submodule will fail. Once you've created the PR here, just click "Re-run jobs" in your submodule.
• If you see build errors under your pull request then check out its details: It will send you to the failed step in the Actions tab. You can also click on the "Summary" on the sidebar to download the artifacts (logs, screenshots, etc) and in case of failed UI tests you find the annotations linking to which test failed.
• Open a pull request for all but trivial changes (like typos) so we can nicely track them, including when generating release notes for the next release.

Dependencies between Lombiq projects

When making a Lombiq project depend on another one from this solution, apart from adding a project reference and dependency in the extension manifest for Orchard Core extensions, also add a conditional package reference. This way, when published to NuGet, dependencies will still work. See the project file of Lombiq.HelpfulExtensions for an example.

You can just have project references between projects in the same repo though if both projects are published on NuGet (like between projects of the UI Testing Toolbox) since those will be turned into package dependencies automatically.

You can use the NuGetBuild switch in the root Directory.Build.props file to make all projects use NuGet references so you can update Lombiq packages for the whole solution.

open-source-orchard-core-extensions's Issues

Release all projects (OSOE-388)

Once Lombiq/UI-Testing-Toolbox#101 is done, issue NuGet releases of all of the OSOCE projects.

Jira issue

Problem building Lombiq.OSCCE (OSOE-384)

Hi,

I have clone the repo and installed all the pre-req (I think) and I am getting the following error:

"Severity Code Description Project File Line Suppression State
Error MSB3073 The command "pwsh -File C:\Users\User\source\repos\Lombiq2\tools\Lombiq.Analyzers.PowerShell\Lombiq.Analyzers.PowerShell\Invoke-Analyzer.ps1 -ForMsBuild" exited with code 1. Lombiq.OSOCE.Web C:\Users\User\source\repos\Lombiq2\tools\Lombiq.Analyzers.PowerShell\Lombiq.Analyzers.PowerShell\Lombiq.Analyzers.PowerShell.targets 41
"

No sure were to go from here. Any pointers will be appreciated.

Thank you

Jira issue

Detect in submodules if there's no PR here (OSOE-131)

If you change a submodule of this project, then to do integration, code analysis, and run tests, you should also open a PR here (as also mentioned in the docs). We need something to enforce this.

Perhaps have a build for submodules that fails if it doesn't somehow detect a corresponding PR here?

This repo could automatically be updated with submodule changes too but that's after the fact, at that point the changes are already merged.

Test new GitHub-hosted runners (OSOE-773)

From the original announcement:

From now on, any Linux or Windows workflow triggered from a public repository, using GitHub’s default labels, will run on our faster, more powerful 4-vCPU runners.
...
This upgrade offers increased performance, memory, and storage with 4-vCPUs, 16 GiB of memory and 150GiB storage.

Jira issue

hCaptcha module (OSOE-577)

Originally by @0liver:

An Orchard Core module to be able to use hCaptcha everywhere you can use the built-in ReCaptcha feature. Include the option to use Invisible Captcha.

Jira issue

Upgrade to Orchard Core 1.5 (OSOE-392)

...once it's released.

• Lombiq/UI-Testing-Toolbox#133 will need this.
• Change services.AddScoped<IDataMigration, CustomMigrations>() calls to services.AddDataMigration<CustomMigrations>()
• You'll get a "System.MissingMethodException: 'Method not found: 'System.Collections.Generic.IDictionary`2<System.String,NLog.Layouts.SimpleLayout> NLog.Config.LoggingConfiguration.get_Variables()'.'" exception until the UI Testing Toolbox's NLog version is not the same as that of Orchard's.

Jira issue

Project not building for me

I cannot seem to get the project to build. I get an error "The command "gulp" exited with code 9009" for both the VueJs and TrainingDemo projects. Could you possibly steer me in the right direction to get this to build?

Update all NuGet packages to latest (OSOE-398)

Update all NuGet packages in the solution to the latest released (not prerelease) version.

• Since Atata.HtmlValidation now uses HtmlValidationOptions.HtmlValidatePackageVersion = "7.5.0", remove us setting that property in HtmlValidationConfiguration.
• Perhaps WebDriverManager won't be possible to update until Orchard Core 1.5 is released and we upgrade to that.

Jira issue

Rename Licence.md files to License.md (OSOE-80)

We used British English but since we use American English for everything else, let's rename them. Note that submodule repos with more than one project and published to NuGet have not just a file in the root but in each published project's folder too.

Apart from the file renames, the references for NuGet build in the csprojs need to be adjusted too.

Remove `build-create-binary-log` and `dotnet-test-process-timeout` configurations from OSOCE workflows (OSOE-834)

After Lombiq/UI-Testing-Toolbox#228, remove the build-create-binary-log and dotnet-test-process-timeout configurations from OSOCE workflows.

Jira issue

Upgrade to Orchard Core 1.6 (OSOE-548)

The new version is out, see https://docs.orchardcore.net/en/latest/docs/releases/1.6.0/ and https://github.com/OrchardCMS/OrchardCore/releases/tag/v1.6.0

• Utilize AddIndexProvider and AddScopedIndexProvider extensions, see here.

Jira issue

Optimize spell-checking dictionary files across projects (OSOE-523)

Currently https://github.com/Lombiq/GitHub-Actions is the owner spell-checking dictionary files, even for entries specific to OSOCE.

Here are a couple of ideas for improving how OSOCE and other repositories consume spell-checking configuration from LGHA, so there are no hidden dependencies. For example, Utility Scripts and Infrastructure Scripts relies completely on LGHA for its spell-checking dictionaries (most importantly allow.txt and expect.txt), but those are referenced by other repositories too. As a result, spell-checking reports in different repositories have a varying number of irrelevant entries, which makes it harder to maintain them.

With this, OSOCE will be a template for consuming LGHA as they were completely independent.

1. LGHA should continue to do its own spell-checking, but the allow.txt and expect.txt dictionary files should be specific to LGHA only.
2. Generic entries should be added to scope-specific files, such as lombiq.txt or orchard.txt and such. Entries that are specific to a submodule of OSOCE can also be considered generic if we can expect that they will be used as a submodule in other repositories too (let's just put them all in osoce.txt?).
3. OSOCE-specific entries should be added to allow.txt and expect.txt files in its root .github/actions/spelling folder. Unrecognized entries should be removed.
4. As a result of the previous points, OSOCE should skip LGHA from its own spell-checking.
5. Other consumer repositories (e.g., Utility Scripts and Infrastructure Scripts) need to be re-checked and some further entries added, so it will be a relatively complex endeavor.
6. Does LGHA actually need to be a submodule of OSOCE? If it's only used through actions/workflows, then decoupling would make LGHA contributions easier by not having to maintain PRs there too (and breaking changes can occur outside OSOCE, so testing with OSOCE should still happen, but it isn't always enough).

Jira issue

Upgrade to Orchard Core 1.9 (OSOE-818)

... once it's released. This needs to start from the task/system-text-json-migration branch, see #692.

Jira issue

Investigate adding NuGet and NPM caching for CI builds (OSOE-555)

...because actions/cache seems to be faster now. See e.g. this build with the default settings, and

Jira issue

Let's use Central Package Management to simplify NuGet package updates (OSOE-567)

With NuGet 6.2, Central Package Management can provide a much improved experience to manage NuGet packages over many project in a solution (folder).

The feature is available across all NuGet integrated tooling from the following versions:

[Visual Studio 2022 17.2 and later](https://visualstudio.microsoft.com/downloads/)
[.NET SDK 6.0.300 and later](https://dotnet.microsoft.com/download/dotnet/6.0)
[.NET SDK 7.0.0-preview.4 and later](https://dotnet.microsoft.com/download/dotnet/7.0)
[nuget.exe 6.2.0 and later](https://www.nuget.org/downloads)

Jira issue

Set up automated dependency updates (OSOE-815)

Set up some kind of automation to update NPM and NuGet dependencies in all OSOCE projects. If we really want to get fancy, then perhaps Docker dependencies (if we have any directly used ones, e.g. ZAP is not an easy case) as well as dotnet tools (see e.g. this) too.

• This needs to cover the projects directly in this repo, both in the OSOCE and NuGetTest solutions, as well as all referenced submodules. Once we have a working approach, we'll use it in all non-OSOCE and closed-source apps too.
• Dependabot can do this. However, we have dozens of repos where we don't want to duplicate configuration, and it seems Dependabots configs can't be DRY (though there are workarounds.
• Renovate looks like a good tool too, and it supports DRY config as well.
• We don't want to get too many such PRs, since ultimately, all of them need to be reviewed by a human, perhaps also tested, and in the case of submodules, integrated into OSOCE. So, e.g. make it check dependencies once a month?

Jira issue

Fix visual verification tests (OSOE-763)

They started to fail due to the year in the footer changing. Fix this with a higher tolerance.

Jira issue

Figure out how we can build and NuGet-publish projects that depend on Gulp Extensions (OSOE-84)

Currently, we commit the wwwroot folders instead of building them during publishing with Gulp Extensions, which is bad. Instead, we should build static resources as we do in the OSOCE build, but we can't really do exactly that.

• Most possibly this needs changes to the affected projects and https://github.com/Lombiq/NuGet-Publishing-GitHub-Actions as well.
• Remove the note about this issue in the root OSOCE Readme too.
• This is a continuation of: #23 An attempt was made and can be continued under Lombiq/Gulp-Extensions#31.
• Adapt all GE-using projects of ours.
• Perhaps we can use the Node.js Extensions project of ours that can make this easier.
• See @Skrypt's remarks here: OrchardCMS/OrchardCore#11294 (comment)
• Maybe we could Exec an NPM install or something? Perhaps the other NPM-related packages can be of some inspiration: https://www.nuget.org/packages?q=npm

Jira issue

NuGet publishing

Publish our OSS packages to NuGet. Individual issues for the same: Lombiq/Helpful-Extensions#34, Lombiq/Orchard-Azure-Application-Insights#15, Lombiq/UI-Testing-Toolbox#98

First steps:

• Set up the NuGet publishing with GitHub Actions of https://github.com/Lombiq/Helpful-Libraries and https://github.com/Lombiq/Helpful-Extensions. These will then at a later point serve as models for the rest.
• These two projects are special, and thus cover all important use cases, because Helpful Extensions depends on Helpful Libraries, and Helpful Libraries contains three csprojs that all need to be published (either as separate packages or one; perhaps the former because other projects may not depend on all of them).
• We're developing such OSS projects as part of this OSOCE solution. In other projects of ours we use them as submodules too, so consuming and improving them is easier. We'll keep this, thus we need some way for this to not clash with NuGet references.

Some criteria to keep in mind:

• We can handle the whole thing from a build in OSOCE too somehow, it needn't be for each project, if it makes things easier.
• Currently, we have about 30 projects that we'd like to publish to NuGet. This already necessitates the ability to manage NuGet publishing somehow centrally in a DRY manner (apart from credentials that can be stored in GitHub secrets) but we'll likely have many more. So, a solution where we need to maintain a pipeline in each of these repositories would be an issue

Disable Jira issue title suffixes for submodules (OSOE-386)

Go through the create-jira-issues-for-community-activities.yml workflows in all submodules, and set suffix-issue-titles: "false". We don't actually need to include the component in the Jira issue titles since it's also readily visible not just in the issue detail view but in the kanban board too.

Jira issue

Update all NuGet dependencies (OSOE-683)

Update all NuGet dependencies in all projects.

Jira issue

Test CodeRabbit for code reviews (OSOE-758)

CodeRabbit promises to offer code reviews for any language automatically. It's free for open-source so it seems that we can use it for OSOCE for free.

Jira issue

Normalize line endings to auto across all submodules (OSOE-91)

As discussed here we can get the best cross-platform behavior by using automatic line ending conversion (i.e. "Checkout Windows-style, commit Unix-style" on Windows) on push to have uniform LF endings on the repository and native line endings in the local work tree.

This can be done relatively quickly but it will cause a lot of neutral changes in the PRs with nothing to review so I'd prefer to dedicate an separate issue to it.

Run Windows CI builds only just before merging PRs (OSOE-635)

Windows CI builds are much slower than Ubuntu ones, which makes the feedback loop longer, they need twice the core count to achieve even this, and are twice as expensive per core. So, let's try a setup where CI builds for PRs only run Linux by default. Then, to catch possible incompatibilities, you have to run a Windows build just before merging a PR.

• We can achieve the Windows build enforcement with branch protection rules. Do make sure this does not break our DX in any other way.
• CI builds for dev and branches remain as they are.
• Check whether it makes sense to use a faster Ubuntu runner for a shorter feedback loop, where we can allocate some of the cost savings.

Jira issue

Test branch builds with GitRunners (OSOE-599)

GitRunners is a cheaper and perhaps faster option than using the larger runners GitHub provides. Let's test it for our larger runner builds.

• It's similar to BuildJet but that was only for Linux and we had issues with those runners being in parity with GitHub's.
• GitRunners' Linux runner is significantly cheaper: E.g. $0,0128 for a 4-core Linux instead of GitHub's $0,016. They don't offer Windows runners though.
• "Upcoming features Persistent storage for all ephemeral runners and flamegraph visualizations to analize workflows runtimes." Persistent storage may help us a lot with repeated builds for private repos (due to not having to do a full rebuild, and NuGet/NPM package cache being initialized, faster than with GitHub Actions Cache).

Jira issue

Only run the builds on the larger runner when on an other branch than dev (OSOE-411)

Larger runners help shorten the feedback cycle for PR builds. However, nobody waits for dev builds, so they can run on the slower standard runners.

Jira issue

Update all NuGet dependencies (OSOE-532)

• Update the NuGet dependencies of all OSOCE projects, unless it'd conflict with a version coming from Orchard (like YesSql, Json.NET).
• Do a release of all of our projects that didn't have a release recetly.

Jira issue

Orchard Core 1.0 upgrade

After upgrading to the Orchard version after RC:

• We need to change ApiController ChallengeOrForbid() to ChallengeOrForbid("Api"). See: OrchardCMS/OrchardCore#7039.
• Need to surround admin titles with <zone Name="Title">...</zone>.
• ResourceManifest migration:
  • Need to change ResourceManifests, see: https://orcharddojo.net/blog/code-generation-templates-for-net-5-fluid-2-breaking-changes-this-week-in-orchard-18-04-2021 (and use a ResourceManagementOptionsConfiguration class). See an example below.
  • The ocresourcemanagementoptionsconfiguration snippet of the Dojo Library can be used for this.
• Add https://github.com/Lombiq/Orchard-Azure-Application-Insights. Also merge the orchard-core-preview-16154 branch.
• Add https://github.com/Lombiq/Orchard-Chart.js
• Add https://github.com/Lombiq/Orchard-UIKit
• Add https://github.com/Lombiq/Audit-Trail-Extensions
• Add https://github.com/Lombiq/Orchard-JSON-Editor
• Merge after updating them to the then-current packages: Lombiq/Helpful-Extensions#25
• Merge Helpul Libraries' orchard-core-preview-16154 branch.
• Change ad-hoc shape creation and ILayoutAccessor usage, see below.

ResourceManifest migration

Sample:

using Microsoft.Extensions.Options;
using OrchardCore.ResourceManagement;

namespace OrchardCore.Facebook
{
    public class ResourceManagementOptionsConfiguration : IConfigureOptions<ResourceManagementOptions>
    {
        private static ResourceManifest _manifest;

        static ResourceManagementOptionsConfiguration()
        {
            _manifest = new ResourceManifest();

            _manifest
                .DefineScript("fb")
                .SetDependencies("fbsdk")
                .SetUrl("~/OrchardCore.Facebook/sdk/fb.js");

            _manifest
                .DefineScript("fbsdk")
                .SetUrl("~/OrchardCore.Facebook/sdk/fbsdk.js");
        }

        public void Configure(ResourceManagementOptions options)
        {
            options.ResourceManifests.Add(_manifest);
        }
    }
}

Registration:

services.AddTransient<IConfigureOptions<ResourceManagementOptions>, ResourceManagementOptionsConfiguration>();

ILayoutAccessor usage

E.g. ShapeInjectionFilter needs to be changed as follows:

            // The layout can be handled easily if this is dynamic.
            var layout = await _layoutAccessor.GetLayoutAsync();

            // The Layout object will contain a Zones dictionary that you can use to access a zone.
            var contentZone = layout.Zones["Content"];
            // Here you can add an ad-hoc generated shape to the content zone. This works in the same way as we've seen
            // previously when we talked about display management. You can find the template that'll render this shape
            // under Views/InjectedShape.cshtml.
            await contentZone.AddAsync(await _shapeFactory.CreateAsync("InjectedShape"));

Upgrade to Orchard Core 1.4

Orchard Core 1.4 is now out. Let's upgrade to it. See release notes.

Publish alpha packages to Cloudsmith (OSOE-649)

Currently, we publish all issue-specific alpha versions of our projects' NuGet packages to nuget.org. Not to pollute NuGet, let’s publish them to Cloudsmith instead.

• This can be done with a different NuGet publish GHA workflow for non-release (e.g. alpha) version tags. OCC does this with preview tags, see here.
• Add the necessary NuGet.config to OSOCE to configure the Cloudsmith feed. For projects with a dependency on another project of ours (like Helpful Extensions) this is needed too. We can just auto-add a centrally managed such file to every project, like we do with the Lombiq logo.
• Add a shield for the Cloudsmith package to the Readme of all projects too.
• Update our Open-source template too.

Jira issue

Add demos of all modules (OSOE-178)

This solution should also serve as a demo of all our modules. Probably the best would be to add a setup recipe that enables configures everything for a demo so you can better see what's in there. Maybe add some information about what you can access from a content item on the homepage.

Basically, do everything under https://github.com/Lombiq/Open-Source-Orchard-Core-Extensions#adding-a-new-extension-or-significant-new-features for those features that yet lack this.

System.InvalidOperationException : The docker.exe pull softwaresecurityproject/zap-stable:2.14.0 --quiet command failed (OSOE-821)

System.InvalidOperationException : The docker.exe pull softwaresecurityproject/zap-stable:2.14.0 --quiet command failed this error occures whenever I am trying to run any of the SecurityScanningTests on my local machine.
I asked @wAsnk and he confirmed the same thing is happening for him locally. Same error goes locally for the OrchardCore.Commerce solution and NuGet.Test solution.

It is very interesting because we do not experience this on CI neither on Ubuntu nor on Windows builds. At least every OSOCE dev build passed so far and I checked out dev to run tests.

Repro

1. Run BasicSecurityScanShouldPass on your local machine and the error should occur.

I tried:

1. Upgrading CliWrap nuget to 3.6.6 did not solve this issue that was my best bet.

I suspect something is off with CliWrap and HelpfulLibraries.Cli atleast the logs are suggesting that the docker daemon might not be running and the generated test log claims that : this error may indicate that the docker daemon is not running: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/images/create?fromImage=softwaresecurityproject%2Fzap-stable&tag=2.14.0": open //./pipe/docker_engine: A rendszer nem találja a megadott fájlt.

Here is the TestOutput.log:
TestOutput.log

Jira issue

Make NuGetTest updates better (OSOE-816)

This is not a fully planned out suggestion, more of a problem statement and opener to think together.

When you change an OSOCE project today, you don't have to publish an alpha NuGet package. This is OK, since not every change warrants an alpha due to it being used in another NuGet solution (or things like docs or sample changes don't need a NuGet release ever).

However, this results in versions used in the NuGetTest package gradually going out of date. That is, until an OC upgrade requires an update to every project, when all potential breaking changes will arrive at once, and you have to fix the NuGetTest solution. Or a project's NuGet publish may fail as well, e.g. due to incomplete project-package references, or something breaking due to the Node build.

A couple of ideas on how to tackle this:

• Require a NuGet release before approving every submodule PR, if the changes in that PR affect the NuGet package (excluding e.g. the mentioned samples or docs changes). However, this is a chore.
• Run a NuGet package creation, but without publishing to NuGet.org, for every submodule commit, kind of like a CI build. This would at least prevent introducing NuGet publishing errors.

Related issues that might help here: #703 and Lombiq/GitHub-Actions#70.

Jira issue

Split CI test execution into parallel jobs (OSOE-730)

This is something for the future, when we'll have a lot more (UI) tests, I just wanted to record the idea.

Currently, the Tests step in the CI build takes 8-10 minutes under Ubuntu. We have 71 UI tests that take up the bulk of this time. Once we'll have a lot more and, we've exhausted other speed-up options, and we want to make this step faster, we could split the Tests step into two or more parallel jobs. I'd only do this for the Ubuntu build-and-test-larger-runners job.

This requires us to have at least 3 jobs: One that does everything up to Build and Static Code Analysis. Then, it'd upload the build artifacts. Two other (parallel) jobs then would be triggered, download the artifacts, and execute the tests.

We need to employ Cancel Workflow on Failure for each of these jobs still.

This would allow us to have two separate VMs running the tests in parallel.

Jira issue

Update GitHub Actions workflows of all OSOCE projects from the OSS template (OSOE-485)

The GitHub Actions workflows of our open-source repository template now contain various smaller fixes, including but not necessarily limited to:

• The types parameter of GitHub Actions workflows should be arrays, even if they contain a single type, see the docs. E.g. it should be [created], not created, even though the latter works too. The create-jira-issues-for-community-activities workflow didn't comply with this.
• The job names were fixed to relate to what the job actually does (there were copy-paste errors).
• validate-submodule-pull-request is now validate-pull-request, and its content also changed, but it still only executes the validate-submodule-pull-request workflow.

So, let's go through all OSOCE projects, and update these workflows from the template. Note that all three workflows may contain project-specific configuration, and create-jira-issues-for-community-activities at least has a unique issue-component for each project. So, simply overwriting the files is not enough, these configurations need to be retained.

Jira issue

Upgrade to latest OC preview to test System.Text.Json (OSOE-795)

After OrchardCMS/OrchardCore#14572, OC now uses System.Text.Json instead of Json.NET. So, let's upgrade to this preview version and test if anything is broken.

• Open a task/system-text-json-migration branch from dev and start your issue branch from there. After this issue is done, we won't yet merge this to dev, waiting for that for OC v2.0.
• Upgrade OC as usual.
• Change all of our code that uses Json.NET to use STJ instead.
• The OrchardCMS/OrchardCore#13181 PR changed the registration order of the authentication middleware. This might break BlockMediaThemeTemplateDirectAccessMiddleware. Be sure it's not broken.
• Issues like OrchardCMS/OrchardCore#15628 can now be made apparent, even with SQLite, with the new EnableThreadSafetyChecks YesSql config. Please enable those for UI tests, see OrchardCMS/OrchardCore#15961.
• For every general OC issue we find, open an OC issue.
  • OrchardCMS/OrchardCore#15397
  • OrchardCMS/OrchardCore#15451
  • OrchardCMS/OrchardCore#15497
  • OrchardCMS/OrchardCore#15505
  • OrchardCMS/OrchardCore#15533
  • OrchardCMS/OrchardCore#15628
  • OrchardCMS/OrchardCore#15975

Jira issue

.NET 6 upgrade (OSOE-60)

Let's upgrade everything to .NET 6. Official docs: https://docs.microsoft.com/en-us/aspnet/core/migration/31-to-60

• The best is to wait for OC 1.3 with this since that's the version that'll drop .NET Core 3.1 support.
• NPM Targets and Gulp Extensions, due to being used in Orchard 1 and other .NET Framework projects, should target .NET Standard still.
• Search the whole code base not just for "netcoreapp3.1" but also "net5.0".

Related:

• Lombiq/.NET-Analyzers#29 is needed for this.
• Lombiq/UI-Testing-Toolbox#101 needs this.
• Lombiq/Orchard-Azure-Application-Insights#27

Upgrade to Orchard Core 1.8 (OSOE-751)

...once OrchardCMS/OrchardCore#14940 is done.

• Lombiq/Orchard-Core-API-Client#34 is part of this.
• Utilize OrchardCMS/OrchardCore#14759 and OrchardCMS/OrchardCore#14801 where we currently have sync-over-async.
• Perhaps we should do OrchardCMS/OrchardCore#14806 in our forms too?
• Add Lombiq/UI-Testing-Toolbox#324 (comment) to the release notes of UI testing Toolbox.
• Add a note about the changed and app-wide setup for AI to its release notes.

Jira issue

Add the Content Editors module (OSOE-588)

Include the Content Editors module of ours, upgraded to OC 1.5.

This was kind of started in the issue/OSOE-56 branch, so start from there. It only contains the very basics though. The point in this issue is not proper open-sourcing yet, just adding the module.

Jira issue

Upgrade to Orchard Core 1.7 (OSOE-682)

1.7 is now out, so let's upgrade OSOCE to it. See the release notes here.

Jira issue

Failed to start project.

Environment:
IDE: visual studio 2022
Node: 14.15.0
npm: 6.14.12

The operation of gulp keeps reporting errors

The screenshot of the error is as follows

Can you help me? thank you so much.

Update all packages to latest (OSOE-620)

...in all submodules too, once #378 is done.

• When a UI test fails, currently an HTML snapshot is saved into the FailureDumps folder. This should rather be an MHTML with compatible Chromium browsers. This worked before but now it appears to revert back to HTML, perhaps due to some Chrome change. If this happens with the latest Atata too, then report it here.
• Microsoft.AspNetCore.Http is now deprecated. Remove it and use a substitute if necessary.
• Don't forget about the NuGetTest solution.

Jira issue

Named FlowPart? (OSOE-824)

Is it possible to have more than one/a named FlowPart on a Content Item? I currently have a "page" which contains a flow part along with several other fields. I would like to do something like this when rendering.

Top FlowPart

Field 1
Field 2

Bottom FlowPart

Field3
Field4

Jira issue

Keep LF in pnpm-lock.yaml to prevent Git from reporting this file as changed (OSOE-418)

... after it is edited by pnpm.

Add these lines to all .gitattributes files in OSOCE and the template repository:

# Keep the LF in pnpm-lock.yaml files to prevent Git from reporting this file as changed after it is touched by pnpm.
pnpm-lock.yaml eol=lf

Jira issue

Use custom VM images for CI builds (OSOE-717)

Once github/roadmap#826 is available, let's use custom VM images for CI builds.

The image used for .NET builds should contain all build dependencies preinstalled, as well as an OSOCE source built that'll be updated on checkout (or if that's not possible, then re-cloned, but still, we'd have the NuGet and NPM caches warm). Perhaps saving OSOCE after also a test run would be useful, to let the UI Testing Toolbox install its dependencies (smtp4dev, Zap) too.

This should be regenerated when OSOCE dev changes; most possibly, after every dev commit it'd be wasteful, but perhaps once every day if there are new dev commits.

Once this works with package caches, package caching in the build workflow can be disabled.

If this works out well, we can introduce it in all other projects of ours too.

Related:

• Lombiq/GitHub-Actions#273
• Lombiq/GitHub-Actions#84

Jira issue

Test Visual Studio build acceleration (OSOE-584)

Test if we can use build acceleration for the full solution, and if it indeed helps with build times.

• Elaborate results.
• Enable it for the full solution if it indeed works.

Jira issue

Configure YAML linting (OSOE-759)

After Lombiq/NodeJs-Extensions#11, configure the YAML linting rules of yamllint as it's fitting for our projects.

• Check all the rules it has and enable/configure them, as well as fix the issues it uncovers. When in doubt, discuss it with the team.
• Add the workflow to https://github.com/Lombiq/Hosting-Media-Theme too.
• For quotes, we'll need to use the following:

quoted-strings: {
    quote-type: single,
    required: only-when-needed
}

Jira issue

Evaluate NDepend (OSOE-135)

NDepend is a .NET code quality tool. We've received 4 licenses due to the generosity of NDepend's founder, Patrick Smacchia. Let's try NDepend on OSOCE:

• Show what kind of issues it finds and evaluate whether there are features in NDepend we can benefit from using in the long-term.
• Create issues for the findings in each repo.
• Demonstrate running it in CI with GitHub Actions if it's possible.
• Summarize our experiences here in form of a comment in about 3-4 paragraphs.

List of projects in the root Readme (OSOE-73)

Let's add a list of all included projects to the root Readme.

• A hierarchical (similar to the solution structure, e.g. Modules, Test...) list of all included modules with their names, GitHub links, short description (from their Readmes).
• Add a note about extending this under "Adding a new extension or significant new features".

Related: #7

Fix test execution sometimes hanging (OSOE-129)

Sometimes, for seemingly no good reason, the Tests step hangs and times out if we let it run. Let's fix this.

• See e.g.:
  • This build, logs:
    logs_364.zip. Happened on Ubuntu.
  • This one happened on Windows. Logs:
    logs_334.zip
  • Another one, ironically happened when setting the workflow timeout as a stopgap to prevent them from running for 6 hours.
  • See others under canceled Actions (note that cancellation can be by the user's request too, a run is only interesting if it took one hour and was canceled by the system).
• It seems that the test run doesn't even start dotnet test. Maybe a command before that is hanging.