I have a custom DNN module that I'm working on that I need to create an Admin Page when the module is installed within a DNN instance. I have creating the page handled, but getting code to run when the module is installed/upgraded is something I haven't figured out.
How do you wire up code to be executed as part of the installation/upgrade of a DNN module?
I've been successful with using IUpgradeable as part of the install. You specify a method in a core module class (FeatureController.cs if using the Christoc.com template) in the dnn install manifest file.
This [class].UpgradModule is executed after the app restart (happens after a module install/config change for the module version(s) specified).
It's quite "elegant"...the DNN install schedules an "eventexecution" as specified in the manifest and you can run whatever code you desire.
My manifest (modulename.dnn) had an eventMessage attribute (placed after the desktopModule element). Ex:
<eventMessage>
<processorType>DotNetNuke.Entities.Modules.EventMessageProcessor,DotNetNuke</processorType>
<processorCommand>UpgradeModule</processorCommand>
<attributes>
<businessControllerClass>SSI.DNN.SSIReplicationModule.Controllers.FeatureController, SSIReplicationModule</businessControllerClass>
<desktopModuleID>[DESKTOPMODULEID]</desktopModuleID>
<upgradeVersionsList>00.00.01</upgradeVersionsList>
</attributes>
</eventMessage>
Whatever is in:
<businessControllerClass>SSI.DNN.SSIReplicationModule.Controllers.FeatureController, SSIReplicationModule</businessControllerClass>
With the method name:
<processorCommand>UpgradeModule</processorCommand>
will get executed at install.
Hope that helps...if you need code for the page creation and module add let me know.
My first SO post ever!!
Apparently, there's a new way to do it, but so far I haven't found documentation. It looks like this:
<desktopModule>
...
<page type="Admin" common="true">
<name>Configuration Manager</name>
<icon>~/Icons/Sigma/Configuration_16X16_Standard.png</icon>
<largeIcon>~/Icons/Sigma/Configuration_32X32_Standard.png</largeIcon>
<description>Modify configuration settings for your site</description>
</page>
....
</desktopModule>
Not sure when this was added, but I found it in source code of DNN 8.0.3.
Related
I'm trying to get started with module development using Abp framework, the potential of using the framework is huge with the community and the abp.commercial support if it's needed, but it's not always easy to up and running the application. Let me explain...
I have created a new module: abp new sample.module -t module. ABP CLI version 3.3.1
After that, I have added a new entity in Domain (member.cs) and using AbpHelper.GUI to auto-generate all the code.
🎉My module works correctly using Hosts/*.web.unified test project. Well done! :).🎉
NOTE: see here if you want to know how to solve a tricky issue for me at this point.
Next, I have added assemblies one by one to the Host App. I have mapped:
Module.Application --> Host.Application
Module.Application.Contracts --> Host.Application.Contracts
Module.Domain --> Host.Domain
Module.Domain.Shared --> Host.Domain.Shared
Module.EntityFrameworkCore --> Host.EntityFrameworkCore
Module.HttpApi --> Host.HttpApi
Module.HttpApi.Client --> Host.HttpApi.Client
Module.Web --> Host.Web
Finally, I added Module Dependencies and Configurations, following this post.
🎉 Restore, build, dotnet ef migrations, and *.HostApp.DbMigrator work like a charm and the database is updated based on the entities in the module. Cool! 🎉
But... when I run my Host App and click on the new module menu contributor the route doesn't work 😒 but it seems to be correct based on the page structure of the module and it worked fine using Hosts/*.web.unified test project inside the module.
I tried several times with no lucky 🤦♂️
Something is missing in the code that I cannot see.
Any help is really appreciated.
Because the Host application and Module are in different solutions. I was missing to include an assembly (Module.Web.Views.dll) into the Host web project.
After upgrading to DNN 9, I get the following error when I try to place modules on the page:
`Error occurred when request service 'AddModule'.
With most of my modules, if I refresh the page after getting the error, the module appears "hovering" and ready to be placed on the page. But with one custom module I created using Christoc's custom module templates, nothing happens when I refresh so it's impossible to place the module on a page.
What can I do to fix this error?
It's been a while. But I had a similar problem. In my case the problem was an extra entry in the <moduleDefinitions> node of the .dnn file. Like a reference to an ascx file that was part of the original template, but was deleted by me, but not from the .dnn file.
It seems DNN 9 is much more strict when it comes to modules and adding them.
How can I add information on the main section of a build page? Which class do I need to implement?
(I've already managed to get my plugin working as a post-build step, on the project level and the build page left menu)
A summary.jelly was missing from the PluginBuildAction resource:
<j:jelly xmlns:j="jelly:core" xmlns:d="jelly:define" xmlns:l="/lib/layout"
xmlns:t="/lib/hudson" xmlns:f="/lib/form" xmlns:i="jelly:fmt">
<t:summary icon="orange-square.png">
Surprise! <br/>
</t:summary>
</j:jelly>
Is there a way to get details about this error? I turned off custom errors:
It looks like I am missing a skin file. How do I get it back? I used the one from the default install of DNN 6.2.4.
You could look at your DotNetNuke log4net config settings and check where you are logging errors. The default location is {DotNetNuke_Root_Folder}/Portals/_default/Logs/.
The log level by default is set on error so you can change that to "Debug" if you want by changing the element in the following config file {DotNetNuke_Root_Folder}/DotNetNuke.log4net.config
You can copy the skin's folder in your DotNetNuke installation zip file to your installed DotNetNuke website. Path to skins (DotNetNuke_Community_07.00.05_Install.zip\Portals_default\Skins)
Hope this helps.
You can get all error detail from LogViewer module of DotNetNuke
Login as administrators then go to Admin-Event Viewer , here you can find the details about error.
I had this error also; on a local instance. After installing a DNN Template via the .visx file, IIS had set up a virtual directory for the desktopmodules folder. Removing the virtual directory cleared this right up in my case. Took a long time to troubleshoot, so hopefully this helps someone avoid the wild goose chase.
Using Cmd 3.0.0.141, I have successfully generated a workspace and an Ext app in that workspace. The application builds correctly until I attempt to integrate the Bryntum Scheduler, where I encounter an error when I try to build:
"Failed to resolve dependency Sch.panel.SchedulerTree for file ExtCalendar.view.Tree"
the app is very simple at this point, uses Ext.application and follows the MVC pattern where I have a view defined "ExtCalendar.view.Tree" that extends 'Sch.panel.SchedulerTree". I also have models and stores that extend Bryntum classes as well, so I assume the compiler will trip over those as well, since it can't see the Sch namespace.
I've added a 'js' path to my app.json that points to the bryntum js file where 'Sch.panel.SchedulerTree' comes from. I've tried to run the 'refresh' command with the same results (Failed to resolve...). I've regenerated the bootstrap.js file manually using 'compile', but nothing from the Sch namespace ever gets added to it, despite the Brytum lib file being in the classpath.
What do I need to do in order to successfully run the 'build' command with libs like this?
Or, do I need to take a more granular approach using the 'compile' command?
With the help of the nice folks on the Sencha forums, I was able to resolve my build issues. The solution, for me, involved a shim. I added an external shim.js file to my index with as many //#require and //#define directives as needed in order to resolve the dependency issues.
According to the nice folks at Bryntum, once I upgrade from the free-trial version of the Bryntum Scheduler, I will be able to get rid of the shim and simply rely on the sencha.cfg classpath pointing at the Bryntum src.
Also, as an aside, the app.json file is not used in ExtJS apps, its inclusion in the generated files was a bug in build 141 of Cmd v3.
See this thread for more detail.