I created a new Composite C1 v4.3 site using the Venus starter kit. Now that I've added content to it, is it possible to switch to the Mercury theme instead? I'm fine with losing any CSS or layout customizations.
I see that there are 3 "Venus" packages installed on the site. I thought I could just uninstall those and install the "Mercury" packages, but I can't find the "Mercury" packages to install.
If I can't switch packages, then the 2 options I see are...
Manually move over the CSS, Less, script, and image files. Then update the "Layout" files to use the Razor templates from the Mercury site.
Create a new Mercury site from scratch and move over the content and data.
Are there any faster options?
Since I didn't find any better solutions, I created a new site that had the design I wanted, then I manually moved over the CSS, LESS, script, & image files. Then I updated the "Layout" files used by the Razor template through the admin site.
This worked but it was not pleasant.
Related
I have 100+ sites I need to create in a CMS. I'm researching different CMSs and have spent some time looking into DNN. It looks pretty promising, however I see two issues:
DNN doesnt seem to support MVC (this is more of annoyance than anything else but I can work around this issue)
DNN development looks like it is expecting 1 skin/layout per VS project
My goal is to have 1 single instance (for now) of DNN running all 100 sites. I know DNN supports multitenancy so that shouldnt be an issue. Each site should be customizable based on layout and css. What I'm not seeing how to do is be able to select different layouts and skins per site. So for example, Site A would have Skin A and Layout A. Site B -> Skin B / Layout B, etc.
How would I go about doing this? Also, is it possible to create all skins/layouts in a single VS project - it seems like I should be able to do this.
I think DNN is a perfect choice :-)
DNN supports MVC. Even if it runs under web forms, there is a control called MVC Panel that allows modules that use this pattern. The routing is a bit different, but it works. See MVC Module Development for more information.
A skin/theme can be applied to any page (even if that does not make too much sense in my eyes). There are three layers: Host (System), Portal (site) and Page (aka Tab), if a skin is not applied to the page, the portal skin is used, if this is not applied, the host skin is used.
To apply a skin to a portal, just set the skin at the portal level (Manage :: Themes). On the page level, you may change that in the page settings (Advanced :: Appearance). The host skin is always the default skin delivered with DNN (called "Xcillion" atm).
You don't need a VS project to create a skin, a good editor is all you need, most people I know who do skinning use Notepad++ or VS Code. For further information read Creating Themes.
Same for Containers (which are the "skin" for the modules placed on a page). Here you have one more layer, you can define the container in the module settings. If not, the one from the page settings is used etc.
I would recommend to have a look at the source code of the Xcillion skin to understand the mechanisms. And maybe download one of the more advanced free stuff and have a look at this code (eg DNN Bootster V2). A first step is always to copy a skin you like and changing the code as you need it.
I'm working with jsps in my workplace. Pages were built using bootstrap2. Though new versions of bootstrap and other frameworks came out, I'm stuck with bootstrap2 as we have hundreds of pages using it.
How do I make the style configurable, in the sense, the configuration should give me the freedom to choose the framework, etc. So going forward I can choose what to be used for new pages
I can relate to your problem as this is the case with many "old" products in the market. They could be built with jQuery, plain js or other tools that considered "old" in today's market.
I assume you could not refactor your whole app as you are saying there hundreds of pages. Some options to consider and to set pros and cons for each with management and product teams.
First, you need to decide your technology you want to use and how.
You can use small bits of react/vue.js/other to inject into your existing pages
you can create full pages from newer technologies and slowly replace older pages in the app one by one
start a full rewrite of the app (hard to sell to management)
I did all three options in my projects but you need to decide with your own team.
Now I'll elaborate on what you can do for each of the options:
I use react so can't recommend other libraries, but this is what I used:
https://github.com/rstacruz/remount
You build react components and then you can use them as HTML snippets in your existing code.
You create another app in whatever new language you want and start building out exiting pages one by one. With each new page, you build you link the old app to them.
This is the easiest one to start but the longest one to achieve. But straightforward of what you need to do.
To make the styles configurable, you can add another stlye.css file underneath the bootstrap2 css file. In that style.css file(name it anything you want, can be bootstrap2_override.css) you can add any styles as well as override bootstrap2's framework styles.
The downside to this is that you are now adding another css file with more CSS just to override bootstrap2 styles.
Ext JS 6 contains 37,903 items that total 504 MB.
Here is the content of the package:
I need to learn which files (white entries) & folders (blue entries) are required in order to use Ext JS 6 without using Sencha Cmd.
p.s. I am not using dynamic loading. I always import ext-all.js and theme-X-all.css files which are located under the build folder.
you really should try to use Sencha Cmd, it reduces your app size and the number of files significantly.
However, If for some reason you don't want to use it, then it is safe to delete the build folder and the build.xml file.
If you are using ExtJS classic then you should keep the classic folder, otherwise delete it. The same goes for the modern folder.
You can also delete the cmd and examples folder.
You won't need the LICENSE file and the licenses folder, however, you should keep it for legal reasons.
Also, delete the Readme, release-notes, templates, sass and welcome files and folders.
You won't need those if you are not using Sencha Cmd, but then again, I advise you to use it, it does a lot better job at creating a nice and clean build of your app.
Sencha has a great getting started guide located here:
https://docs.sencha.com/extjs/6.0.2/guides/getting_started/getting_started.html
This assumes you have sencha CMD which is only available if you purchase a license (not GPL version). With sencha CMD, it automatically extracts the files you need when you run "Sencha App Watch".
If you don't have a commercial license it's best to link to the full sencha library that has everything include in one file. If you are starting out I recommend you use the debug and commented version so you will see your errors better. You can find a link to directions to do that here:
https://docs.sencha.com/extjs/6.2.1/guides/other_resources/extjs_faq.html
(and scroll to "How can I build an application without Sencha Cmd?")
I understand your concern seeing tens of thousands of files. Sencha ExtJS has a pretty steep learning curve but once you learn it there are big pay backs in productivity. All those files really help in debugging. Other libraries just cram them all together and when things don't work you are left without a clue.
HTH's
I started a trial of Sencha Architect, and the more I use it more questions come to my mind for its actual feasibility usage in a development environment, one of the bigger questions I have is
In an environment that you can't edit the individual files in different editors, how can multiple people collaborate in developing different parts of a site, for example
app/models|components|views/Model1.js <- In charge of developer one
app/models|components|views/Model2.js <- In charge of developer two.
In a regular environment you could use git, for example, to distribute each file but in architect, you are not expected to edit files manually (which sucks because features like profiles are not exposed in architect). If you do edit them manually, it will cause problems or it may overwrite your code back to whatever data is on the project file so I am wondering what is the proper, or expected collaboration workflow with Sencha.
Having read the above posts, I still can't believe that keeping Sencha
metadata files in code repository and generating ALL JavaScript from metadata is suitable for big projects.
The idea of Sencha Architect is to keep the code not in javascript files, but in JSON metadata, and whenever you need to edit a JavaScript code, you have to use IDE and edit metadata. Phil Strong said "We ask that you continue to use Architect as your editor and doing so with 20 engineers is perfectly safe using Git or SVN.". Of course this workflow is very profitable for Sencha, it forces 20 people to use a licensed Sencha Architect, because to change a single line of JavaScript code the developer must use Sencha Architect.
When two people edit the same file, IDE updates metadata. Then they check-in the file into a code repository, and one of them has to resolve conflicts, so the developer has to merge two metadata files, not JavaScript files.
The whole idea of not letting developers to edit JavaScript unless they use Sencha Architect is counter-productive, because the same person can be using his favorite IDE for both Java and JavaScript development, or Python and JavaScript. Doing both client and server programming in the same IDE is faster than switch between two IDE's. The reality of a big project is that you have multiple teams around the globe who work with different IDE's, you also may have a short-term project implemented by a contractor who also has his favorite IDE.
ExtJS is a well designed framework, you don't need SenchaArchitect to modify a single line of JavaScript code.
When coding in JavaScript, I save my JavaScript file and refresh browser, and see the changes immediately. Sencha Archtect adds and additional step, it requires you to publish
javascript (generate JavaScript from metadata), and the bigger the project is, the longer is delay. Often I have to modify JavaScript files in production, sometimes changing a single line fixes the problem, again, I have to use Sencha Architect to re-generate this single line from metadata.
I use Sencha Architect for quick prototyping only, then check-in generated files into code repository and continue to edit JavaScript manually. With this approach I can use a version control system to see the history of JavaScript. If I checked in JSON metadata into
a VCS, then I would not have the history of JavaScript, I would have the history of JSON metadata which is counterintuitive.
I think that having metadata for GUI form is OK, but the limitation that MVC controller level has also to be generated from metadata is not OK.
While I appreciate very much Sencha's effort in creating useful and full-featured dev environment I don't think Sencha Architect is quite ready for relatively big projects and teams of developers.
I original Architect software very useful for quick prototyping and designing complex UI structures, but then again - after you figure out the way your UI elements will lay down in JS file - often it's easier and faster to copy-paste existing JS code.
I don't think this is the answer you were looking for, I just wanted to share my thoughts.
When I had searched for this same topic, I had found that it is the metadata/ directory that is the important meat of the project, and that all of the components are separated out into their own metadata files. This, along with the root level project files, is probably the important part for version control. The app/ is regenerated on save and probably can be excluded from version control.
The main xds project file containers more general references and will probably change less often than the metadata components. But it would change when new components are created or project/app level settings are modified.
Ideally, if you just check in the root files and the metadata folder, it should just work.
Working in a team with source/version control is quite easy with Sencha Architect. An Architect project is all enclosed in a project directory. Inside it's made up of n parts
project file - consists of a small amount of data used by Architect to open and maintain your project. It's the single file you can double click to open it
metadata directory - consists of the files that describe all the pieces of your project. Each class (controller, view, model, store, resource) has it's information stored in it's own file.
app directory - consists of the src of the project you've created. A javascript file for each class.
other root files - an app.html and app.js which is the launchpad for your application and what get's run when you preview your application. This is also where your packager.json, app.json would go.
The point of me describing all of this is to show you that the files generated by Architect are pretty much identical to what you would have created in your favorite editor by hand. The only additional information is the metadata and the project file. The metadata is all JSON.
FOR NOW!!
We ask that you continue to use Architect as your editor and doing so with 20 engineers is perfectly safe using Git or SVN. When a dev makes a change it changes both the metadata and the app for those files.
I asked the same question to Aaron from Sencha in a private message. He suggested to check in the entire project structure including app and metadata.
It works, we did one flow in our team.
I am working on DNN 4.09.03. I want to modify the look and feel of a links module. I know how to change the outer looks with containers, but I want achieve a mouseover effect for the links itself.
Looking closely it appears that the links are placed into a table datacell. I want to set the background of that cell to and image, and on mouseover swap it for another image. Can this be done with skinning?
If not, I need some assistance in extending/customising the links module source. I need to know how to set up the development environment to do this first. I have the DotNetNuke solution (with source code) working in VS2008. How do I integrate the source of the links module, so i can customise it (and rename - maybe mylinks)?
I don't think you can do this by containers. If you can do it by any chance, I bet doing it by modifying the code is easier. You have to remember that you might have problems upgrading the links module in future if you modify it.
Just add the Links module to DNN VS2008 solution as a web application. You can do whatever change you won't to do in it. And then use a nant script to just package it and copy to DNN/Install/Modules folder. And then hit the DNN installation URL:
http://<dnn_url>/Install/Install.aspx?mode=installresources
Alternatively you can write some post-build commands in VS2008 it self to copy stuff. Have a look at the existing modules and where each different part files of a module (.ascx, .dnn, .sqldataprovider) is stored in DNN after installation.
This is possible with some creative CSS and maybe even a little jQuery - i did a lot of this sort of thing for the Blog module without having to touch the core module -