To main heading

Smallsite Design

Online management help

1. Management structure

Smallsite Design uses a very simple data model, and protecting that defines which users have access to which resources.

Data model

Most data is stored in XML files, though some incidental information is stored in the names of file entries.

The principal XML data files are:
amasterSmall file containing information about locales, users and some settingsYes
bsiteAbove-the-line text and metadata for subsites, categories, articles and filesYes
carticleBelow-the-line content of an article for each work-in-progress, draft or release, and includes text for all locales. This enables life-cycle management of the article's contentYes
duserPer-user file for spike content and other status informationYes
esearchContents of all articles broken down by locale and text blocksNo
fstatisticsPeriodically updated with the latest articles read numbersNo

Only the files needed for a request from the internet are loaded. For files, only the master is required, as it contains information about whether the request is valid and if the file can be embedded. For other pages, site is required, and the latest release file for showing articles to the public. All the files required for a request are assembled into one XML structure which is transformed into the HTML of the page to display. Any extra information that may be required for particular pages is added to the XML structure prior to rendering.

While the master file will never grow large, the site file can increase in size significantly if there are lots of inline links or a large number of locales, as each of these adds the text for all locales to it. A large article file with multiple locale text can also get quite large. These are not likely to affect everyday operation of the site unless it gets extremely busy. They are parsed for each request, and the time to do that may affect site loading time unless the server hosting it has the processing power to handle for all the requests.

However, only the HTML actually needed for each request will be transmitted to the browsers, thereby saving bandwidth.

Some data, such as which pages have been read for tabulating statistics, are stored as content-less file names, as that bypasses any need for access management, but are periodically aggregated into the statistics file. There is only a search file if the internal search facility is used. Such files are not stored in archives as they are not critical for site operation. If used, the search file is regenerated daily at master manager login.

Access model

The access model is very simple, with the master manager having almost universal access.

Only the master manager can perform any operations that can change the content of any of the XML files, except those for articles and users. This ensures only one person at a time can have write access to them. Even though a user can change their own details, they are not updated until the next master manager action.

Other managers can view almost anything, but cannot make changes. A guest user has similar access, but they are allowed on guest-mode sites only, which are meant for demonstration or learning purposes, and so should not have production site data.

A writer only has access to the pages they need to be able to edit the articles they are assigned to work on, or from which to source content. Managers assigned to do such work are treated as writers as to what they can do with information on those pages. Whomever is assigned to an article is the only one who can modify its content, though a master manager can take back control if required.

In normal operation, the master manager will maintain the site, assign tasks, and decide when to release articles. Other managers are only required for backup purposes or for maintaining the site in shifts. Everyone else should be a writer who is assigned tasks and is only given access to what they need for that task.

Managers have perpetual access, while writers are given finite access. Within a month of that access expiring, the user file and details will be deleted, minimising the storage of personal information that is no longer required.

  • Preparing images for procedures
  • Security and passwords
  • Management page elements
  • 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