To main heading

Smallsite Design

Online management help

5Import

The contents of a Smallsite Design site can be archived, and from an archive, overwrite all the current content or import some elements.

Warning

Overwriting a site from an archive, or importing elements from it,
can lead to loss of some content.

Make sure you understand the consequences of such actions, perhaps getting help to discuss what changes need to be made to make the process easier. An as-is archive is always created when instigating an Overwrite or Import operation, so it can be used to overwrite the site to restore it to its original structure.

For simple elements, like paragraphs with plain text, recreating them and copying their text to them may be conceptually simpler to achieve, whereas more complex elements, like subsites and tables, will be much more straightforward to just import. Horses for courses.

Archives

Archives of the site are created periodically and during some operations, but are automatically deleted according to a calendar-based schedule.

Archives are a complete .zip file of all the content (not program) files in a site. They can be downloaded, uploaded, used to completely replace the content of a site (overwrite) or selectively import elements from.

Archives are created:

  1. a.When the master manager logs in, if it has been more than 12 hours since the last login archive (automatic).
  2. b.Before overwriting the current site from an archive file (manual).
  3. c.Before importing elements from an archive (manual).
  4. d.Explicitly invoking an archive (manual).

There is no difference between automatic and manual archives internally, but it is for reference when determining if an archive was generated during an operation on the Import page (manual) or routine logins (automatic).

Automatic archives are deleted to leave only the last in each of the:

  1. a.Current day.
  2. b.Previous day.
  3. c.Current month.
  4. d.Previous month.
  5. e.Current year.
  6. f.Previous year.

Each time period excludes that time already covered by later time periods, so Current month does not use archives from Current day or Previous day to determine its last archive. For example, if the current day is the 16th of the month, then Current month does not consider any archives after the end of the 14th.

Archive files have a name format of dt.sid.t.algo.hash.zip, where:
#PartDescription
adtDate and time saved as yyyy-mm-dd-hh-mm-ss using UTC as a time reference
bsidSite ID, as specified in the Values section of the Settings page
ctType of archive, where a is automatic and m is manual
dalgoAlgorithm used to generate the hash
ehashHash of the file contents in hex characters. The length is dependent upon the Algo used
fzipExtension for archive files

Manual archive must be explicitly managed and deleted if not needed. Archives don't include anything that is regenerated automatically or of non-critical use, such as search or statistics files.

Archive list

The archive list shows the available archives and the operations that can be done on each.

The columns for the archive list are:
#NameDescription
1IDArchive identifier as its date-time of creation. Currently for the site itself
2SiteSite identifier as specified in the Site ID field of the Values section of the Settings page
3ModeLoaded for the current site
Automatic if created at master manager login
Manual if actioned on this page
4FilesList of the numbers of all elements in the site or an archive, including any changes required to locales for import. Use to identify possible import issues
5ActionsActions available for the current site or an archive, followed by any errors that prevent importing
The available actions for the current site or an archive are:
#ActionDescription
aArchiveCreate an archive of the current site
bUploadUpload an archive file to the site
cDeleteDelete the archive
dOverwriteImport the whole archive to replace the current site
eImportImport part of the archive. Only shown if no errors that would prevent importation are found
fDownloadDownload the archive from the site

When an archive has been selected for import, a list of any changes to locales required during import are shown. Clicking the Deselect button in the navigation bar re-presents the Select import element drill-down list.

Importing

While overwriting a site from an archive is straightforward, importing elements is dependent upon locales and ID conflicts.

The master locale of a site can only have its region changed, so unless the master locale in the archive to be imported from has the same master locale or only differs in region, it cannot be imported. If still eligible, for any other locale in the archive that cannot be renamed to match one in the site, any elements with text for that locale will have that text removed before importing. When expanded, the Files column of the archive's row in the ʘ?ʘ will show what will happen to each locale.

The results for several import scenarios are:
#ArchiveSiteResultImport
aen-001*
ar-001 ✘
en-001*
de-de
Masters match. ar-001 stripped. No de-de in importsYes
ben-us*
en-ca
en-001*
en-gg
Master renamed to en-001. en-ca renamed to en-gg. No en conflicts as the masters evaluated first, then excluded from following comparisonsYes
cen-ca*
en-001 ✘
en-001*en-ca renamed to en-001. en-001 stripped because masters already handled, so nothing to rename toYes
den-001*
en-ca ✘
en-us
en-001*
en-us
Masters match. en-us match. en-ca stripped. No conflict as exact matches evaluated next after masters, then excluded from following comparisonsYes
een-001*
en-us ?
en-ca ?
en-001*
en-au ?
Masters match. Conflict because two source locales could be renamed to match the non-master site localeNo
fen-001*
en-us ?
en-001*
en-ca ?
en-au ?
Masters match. Conflict because the non-master source locale could be renamed to either of the site onesNo

The last two situations can be made alright for importing by making a source locale match a destination locale, but that would have to be done on the live site from which the archive was obtained. However, that locale on the source site could be renamed back to its original after getting the archive, so that the site is restored.

In today's internet, people have been getting used to sites using the same language having different spellings and expressions, especially given the dominance of US English content over the early times of the internet. Typically now people will write how they are used to, and let readers accept the spelling and other differences.

Having two or more locales with the same language (and script) but different regions is usually to cater for audiences who really want to retain the different idioms and expressions they are used to, and that is why renaming regions is not really a solution. Yes, it may get around the technical issues of importing, but anything imported with renamed regions would have to be carefully checked that all content is consistent with the new locales.

Some elements in the archive might have IDs or internal references that are the same as elements in the site. The ID and Created columns of the Import list will show what their new values will be. Any elements to be imported that reference other imported elements with such changes will have those references updated as well.

Any elements that cannot be imported will need to be recreated in the site and the text individually copied from the source elements. For simple elements, this may be the most efficient way compared to importing, Some content of elements may be removed if it is not critical or possibly irrelevant to the current site, such as spike contents in user files.

Workflow

Not all elements undergo the same processing.

Only one element is selected for import, and any descendant elements will be imported along with it unless excluded. Elements like files or users are self-contained, so they will be imported by themselves. Most of the other elements can use files, so any that are duplicates of those already in the current site can be excluded, though there are advantages to temporarily keeping them. Similar with elements owned by subsites or categories which might also be excluded. After any exclusions, categories and articles must have their new owner in the current site selected.

The work flows for each element as each stage of the process is actioned are:

ElementSubsite----Category-----Article-----File---User---PhaseSelect
import
element
Modify
selection
ImportSelect
owner
Done

Select import element

An element in the archive has to be selected.

Drill down to select the one element to be imported. 𝝙 indicates an element that will be renamed to prevent duplicates.

As a result of selection, the result or next action required, by element type, is:

  1. a.Subsite – modify which descendants are included.
  2. b.Category – modify which descendants are included.
  3. c.Article – modify which files are included.
  4. d.File – can be imported immediately.
  5. e.User – can be imported immediately.

Modify selection

Some descendants of the selected element can be excluded from the import.

Click on each element to exclude. Click again to re-include. Files listed under subsites, categories or articles are a link to their entry under Files, which can be clicked on to exclude them. If JavaScript is enabled (default) in the browser, the file list will be expanded to show the file. For each file, there is a list of which elements use it, so check that to make sure that the file will not be needed.

Categories and articles are only ever owned by one element, but files may be pointed to by several, which means that care must be taken to not exclude files that might be used by multiple imported elements, even if they result in duplicates. The duplicates can always be deleted after all the new elements that point to them are repointed to the existing file versions. Doing it this way, rather than risking dead pointers by aggressive exclusioning will allow the site to maintain its operational and visual integrity without having to rush to fix up anomalies.

As a result of clicking the Import button at the bottom of the Import list, the result or next action required, by element type, is:

  1. a.Subsite – imported immediately.
  2. b.Category – select the new owner.
  3. c.Article – select the new owner.

Select owner

For a selected article or category, the new owner element must be selected.

For a selected article or category, there is no way to automatically know where they will need to be imported to, so the new host in the current site must be clicked on. Drill down to find it. After selection, another element can be selected from the archive for import.

Import list

All the elements to be imported are listed, including any changes to prevent duplicate identifiers.

After selection or modification, the list always includes all elements to be included in the import, along with any changes to identifiers that will be made. There is an Import button at the bottom to proceed if all seems alright.

The columns for the list of imported elements are:
#NameDescription
1TypeThe type of element being imported
2IDElement identifier, if applicable. If to be renamed, the new ID is underneath
3CreatedUnique internal element identifier as its creation date. If to be changed, the new identifier is underneath, usually differing by one second from its source
4CommentsText for files, else blank

Cleanup

The relationships between the elements of site can be complex, so importing other elements into a site may tread on a few existing element's toes.

Imported elements might have the same names as existing elements, and they will be suffixed with numerals. These will be documented in the list of elements to be imported, and will need to be renamed to something ending less cryptically .

The relationships between elements are maintained by unique date-based identifiers which are normally invisible, but may need to be automatically changed to prevent inadvertent conflicts when elements are imported. These are itemised in the import list. While some elements, like subsites or files are automatically added to the existing site's host elements, others, like an individual category, will need to be pointed to their new owning element, even though internally they are added to their type's host element, otherwise they would be hidden from discovery.

Descendent elements of the element to import will still point to it, even if their internal identifiers have to be changed to prevent duplicates. If some of those descendants were excluded because there were already versions of them in the existing site, some links in the elements that were imported may have to re-pointed to those existing elements. It is files that are usually pointed down to in a uses type of relationship, whereas articles and categories point up to an element in a belongs-to type of relationship.

So, while every imported element will have a home in the existing site that allows them to be drilled down to, exclusions will usually require a review of the resulting structure to make sure there are no gaps or dead links. Importing missing elements later will not restore any relationships they had to other elements in the archive they were imported from, so those relationships will have to be recreated from scratch. Thus it is better to err on the side of having duplicates so that relationships are maintained than try remembering what they were.

  • Work list
  • Files
  • Find
  • Contact   Glossary   Policies
  • Categories   Feed   Site map

  • This site doesn't store cookies or other files on your device when visiting public pages.
    External sites: Open in a new tab or window, and might store cookies or other files on your device. Visit them at your own risk.
    Powered by: Smallsite Design©Patanjali Sokaris