In DNN DotNetNuke 4.92, you can use [Host][Portals] to export a complete Portal as a template to the Portals/_default/ directory. You can then import the template elsewhere using [Admin][Site Wizard].
Summary: if you have pages that have a "Link Url" that refers to another page on the site, then these links do not survive the import/export process properly. Currently, you will need to fix these up by hand after the import, going through [Admin][Pages] to edit the selected page's settings.
Preamble: in DNN, each page is identified by an integer TabId. This nomenclature stems from DNN's initial versions that refered to each page as a "tab".
Details: When a "Link Url" is set up to another page on the site, the page's TabId is stored as an integer in the Tabs database table Url column. When the portal is exported, this Url TabId number is stored in the template (in a <url> XML element). On import, the Url TabId is simply stored directly in the new page row Url column. However, the TabId of the desired "Link Url" page will almost certainly have changed, so the page will redirect the user to the wrong page.
Background: The Site Wizard does not really describe what it does very well. An old book says that the import process is *additive*, ie the pages in the template are *added* to the existing pages on your site. However this isn't entirely correct: if you select "Replace" in the wizard, then the existing pages are soft-deleted, ie their TabName has "_old" appended and the page is marked as Deleted.
The import Site Wizard assigns a new TabId to each imported page (if a new page is created). This means that it is virtually certain that the TabId-s have changed. If your template etc has hard-coded links to particular TabId-s, then these are almost guaranteed to be wrong.
It would be useful if it were possible to import a template and keep the original TabId-s. Currently, the portal export does not contain the current TabId for each page. Superficially it is also not possible to keep existing TabId-s as the Tab table TabID column is an identity. However it is possible to use the SET IDENTITY_INSERT command to insert a row with a particular TabId.
Reported on DNN Gemini bug tracker
To do:
- See if there is a better way of putting links (eg in Text/HTML and in code) so that they survive the import/export process. Me: in code you can do this using the TabController GetTabByName function.
- Double-check what the Ignore and Merge site wizard options do
Bro John adds:
- These problems typically cause an infinite redirect loop and that IE does not notice this but FF and Chrome do. Me: The problem in one case is that the Login page was not visible to anonymous users, so it redirects to the Login page ad mausoleum. The import process does not reset the LoginTabId; it only sets it if a tab with tabtype logintab is found. Unless the old LoginTabId is Replaced, this should be safe.
- The logon menu item typically fails so you need to have added a hand made login page to be able to log in to the site once you have created it ...
Subscribe to:
Post Comments (Atom)
1 comment:
*if you're making child portals* One way around this is to use datasprings 'tailored text/html' module in place of text/html modules. Just make your links with friendly urls instead of tabid's, and with the tailored module you can add [portalname] tags to your links. so make your link "/$(PORTALNAME)/about.aspx" for example, and the links wont break when exporting the site to create a child portal :)
Post a Comment