| Author | Messages | |
John Mitchell
Posts:3084
| | 02/05/2007 11:17 AM |
| Yes, this will change the behavior for all portals.
There is not really a parent / child relationship of portals in DNN even though that terminology is used a lot.
The default portal is Portal 0, so if you copy the skins from the portals/_default folder to the portals/0 folder they will show up in the Site DDL for the default portal (the first portal created).
The _default folder is where the Host files are.
| | | |
| SplatMan_DK
Posts:81
| | 02/06/2007 2:27 PM |
| You could probably change this for child portals only, but it will require somewhat more work, as you will need a case-structure in the code.
Consider this: How often do you change the skin of your Host portal? Is this actually a real problem for you, or more of a hypothetical one?
- Jesper | |
brgds
- Jesper | |
| SplatMan_DK
Posts:81
| | 02/06/2007 2:31 PM |
| John, what is the best approach to save and keep track of all the little modifications made to a DNN installation?
The CRM system I work with has a modular approach where code in a module can actually override code in the software core. And when the system is upgraded, the software engineer making the upgrade can decide if he wants to continue useing the altered version of a method, switch it to the new core version, or make an entirely new 3rd version where he merges the alterations from the two. All alterations are saved in "metadata packages" which are ease to handle and separated from the core (its loaded at application start time).
Is this possible with DNN? Can I buy a module that will keep track of code-changes for me, or am I forever-doomed in a maze of minor alterations to files that are constantly overwritten by new versions of the core software?
Brgds
- Jesper | |
brgds
- Jesper | |
| sharindenver
Posts:54
| | 02/07/2007 10:52 AM |
| | Hi Jesper, Users technically should never change the parent portal skin. However, the default skin gets "kicked off" sometimes and users need to go in and "hard set" the skin. Since they aren't accustomed to selecting a skin (the default skin is set when they create a new page), they often select the wrong one etc. I am trying to minimize the confusion by only having the appropriate skins visible to them so they don't need to week through all the child portal skins etc. Does that make sense? Figuring out why the default skin gets kicked off would be preferable, but I'm at a loss on that one. | | | |
|
|