Hi Blondie, discussion is exactly what forums are for, so let's go.
I'm a huge fan of multiple portals... the efficiency gains in my own processes are immense. I wouldn't use DNN if it weren't for that. The ability to split a portal off off a multiportal instance does come up quite often and from what I have read, it is just too hard given all additional modules that may be installed. This would probably have to have been built into the system from the start for it to have a hope of working. That said, I'm aware that evotiva has mentioned attempts at doing it as part of their backup system. There is also one method of doing it that is perfectly acceptable if there is a pressing need to remove a portal from an instance. Simply duplicate the entire instance and then delete all the other portals and un-needed modules.
There are ways using sql to show which modules are being used where, but I'm no good at it. In my notes I have a script that does the exact opposite.. perhaps you know how to make it show which are being used instead of which aren't?
SELECT ModuleDefinitions.ModuleDefID, ModuleDefinitions.FriendlyName, ModuleDefinitions.DesktopModuleID
FROM ModuleDefinitions LEFT OUTER JOIN
Modules ON ModuleDefinitions.ModuleDefID = Modules.ModuleDefID
WHERE (Modules.ModuleDefID IS NULL)
There are also some third party modules that can display module use, but I haven't got on off the top of my head.
I'm pretty sure that multi-language content is on the roadmap. Have a look for the Cambrian announcement.. I've just spent 5 minutes clicking around the DNN site menus and can't find a damned thing.. it's an information architect's nightmare.
oh... look I just found a page with polling for enhancements.. that's a new one to me - have a look for ML on it and vote: http://www.dotnetnuke.com/Products/Development/Roadmap/tabid/616/Default.aspx
Speed.... well.. we've already had the biggest improvement back with 4.4.something, so I don't see a lot happening there for a while. Assuming you already tune your system to the max, you can only do one thing with DNN to improve speed.. throw resources at it... lots of resources... or, if you can't afford the resources, go to the dark side and get into a php portal. There is also an interesting thread about pre-compiling DNN.. see if you can find it - it was just this past week. It seemed to open a can of worms.
As for the toolkit.. I feel this is another fundamental problem with the entire framework - not enough rules and requirements. Even the DNN Reviewed program completely fails to address workflow or usability standards and only touches on a handful of technical hurdles that even the worst module in the world could be made to pass (and a fair few of them already have!). I suggest going through the skinning guide and perhaps build a set of guidelines up from that. Also, perhaps get in touch with the guy who has made the skinning tool released just this week. It's mentioned in Michael Washington's blog here. Perhaps he could devise some sort of a skin check tool.... what exactly are the common issues with the skins.. I guess it could check a skin for certain items.
hmmm.. the more I think about it I think you could have a good suggestion about that. It would be good risk mitigation if DNN checked a skin file for certain items before it applied a skin permanently. As it is right now I imagine one can upload a completely blank skin without a protest from the system. All it would have to do is put up an
Sounds like a good point of discussion to me.
Rob