To main heading

Smallsite Design

Build a site, not just pages

2. Requirements

Smallsite Design is restricted to using technology that has proven itself stable for years, and is unlikely to radically change for many more.


Smallsite Design uses well-tested server technology that is the de-facto standard for running small to medium websites.

Smallsite Design runs on a server stack called LAMP, which is:

  1. 1.Linux operating system.
  2. 2.Apache web server.
  3. 3.MySQL database - not used.
  4. 4.PHP - the programmable pre-processor with which Smallsite Design is built.

This stack is offered by most budget site hosting services, and is always the lowest cost option. cPanel is the stack management package that Smallsite Design is designed to use, just because it is so common. Smallsite Design may work on other LAMP-based platforms, but is not designed with them as a target environment, so is unsupported on them. Many larger hosters offer their own management software instead of cPanel, so may not work for Smallsite Design.

The Apache web server is used because it has a .htaccess file that allows virtualising the content so that the site appears to have a file structure suitable for the content, rather than requiring the site owner to modify system-level rules and have advanced technical knowledge. The hosting provider must have allowed write access to this file from PHP to add rewriting rules, which is the default Apache setting.

MySQL server is not utilised by Smallsite Design because its own data requirements are very modest, and so can be provided by means that are not dependent upon separate login ids and passwords for the storage itself. Also, such databases require technical knowledge to migrate the site to another hoster. A design goal of Smallsite Design was that migration be as low-tech for the site owner as possible.

Smallsite Design does not use any third-party software, other than what most implementations of PHP provide. PHP 8.0 is the minimum version, just because any previous versions are no longer supported. PHP is not only a programming language, but a fairly complete selection of technologies that enable building sophisticated site tools without having to have lots of third-party plugins.

Smallsite Design forces use of the https protocol to ensure that any communications between a browser and the site is secure, but also prevents it being changed from then on. cPanel automatically installs SSL certificates as required, so there is no need to purchase any. There is no technical advantage in using any other certificates, including wildcard and Extended Validation (EV) certificates.

Avoid third-party cohabitators

Other software installed on the machine may be able to access files of a site.

When renting from a hosting provider that uses cPanel, they use a reseller version where the sites on one of their accounts cannot access those on another. However, sites on one cPanel account share the same home folder structure. Smallsite Design sites do not access any folders outside their own folder structure, nor even of another Smallsite Design site has had its its root folder inadvertently placed in its own. Furthermore, Smallsite Design does not have the facility to allow plugins at all, as they might be able to access any folders.

Third-party site software, such as for bulletin boards or mailing list managers, might be able to be used if they don't share the same root folder. However, often such programs allow customisations, which may include being able to include or modify PHP code, and that could be used to access the contents of Smallsite Design sites or other third-party application code. Some third-party applications may have a plugin facility that allows other third-parties to include their own code that might also access site content that they shouldn't.

To avoid introducing third-party access to Smallsite Design content:

  1. a.Install only Smallsite Design sites on the one cPanel account.
  2. b.Install any third-party applications on another cPanel account.
  3. c.If using another cPanel account is not feasible, only use applications that are known to not access content outside their own folder structure, and do not allow customisation of the PHP code, nor allow plugins whose code may do so.
  4. d.Do not install third-party applications in the the same root folder as a Smallsite Design site, nor place its root folder in any of the site's folders.

Engaging a hosting provider involves a lot of trust. Similarly, using a Smallsite Design site that is shared with others on the same cPanel account involves trust in the renter of that account, as they have access to all the content files of those sites, but not through their Smallsite Design interfaces unless they have user logins for them. If not wanting to share, which is certainly the case if that would be with strangers, rent a separate cPanel account through a hoster, but that will involve doing all the setup of email accounts and installing Smallsite Design.

The typical scenarios for sharing sites on the one cPanel account are:

  1. a.Having multiple interests that each require their own site.
  2. b.Each member of a family has their own site.

In a trusted family situation, for those who may need help from time to time with the processes, consider allowing manager access to one or more family members who can provide that help. However, avoid giving such access to outsiders who are not trusted, even if they may have some technical smarts.

Even with outsiders who can be trusted, preferably have them present and let them do what they need under supervision after being logged into the user account with the issues out of their sight. Have them explain along the way to help with the learning how to do the task. All tasks have procedures in the product documentation.


Smallsite Design only relies on that part of browser technology that has been shown to weather many version changes without fault.

Any faults that are serious enough to disrupt Smallsite Design will have created problems with far too many sites not to have the browser maker provide an urgent patch as soon as possible.

For visitors to a Smallsite Design site, the only browser requirement is that it was made in the last few years, as supplied with most devices bought within that time, just so they have all the inbuilt functionality to support secure and reliable performance. Javascript is not required, but is used in places where it adds usability, like expanding textareas as text is typed in.

All browsers have quirks, but Smallsite Design's fluid layout and conservative use of browser facilities makes it less susceptible to what a particular version of a browser may not do correctly in future.


While the produced pages can be viewed on any device, editing the pages is more demanding.

While editing could be done on a mobile phone, the small screen size may be limiting for complex layouts, especially since the onscreen keyboard can take up a lot of room. Android phones tend to be narrower and use larger text, making the viewing screen seem even narrower, so landscape mode will be of better use.

During editing, and on some other management pages, there is a lot to process, so devices with lower processing power may take longer to render. This is because the full page is refreshed with each change, mainly because most of the page will change.


Smallsite Design (SD) can work behind a firewall, but there are some considerations.

Many enterprises run their sites behind firewalls, usually for protecting their infrastructure. SD can work behind these but the connection between that infrastructure and the server the site is running on must use https, otherwise it will try to redirect to the https version of itself. Accessing the management pages from the web through load balancers may not work as it uses a cookie to provide session continuity.

Enterprises tend to only allow connections to specified servers to minimise the risk from malicious connections to their architecture. If SD is behind a firewall, as might be the case for internal use, there still needs to be firewall rules in both directions between the license server at and the publicly accessible domain name of the internal SD installation for updates. The incoming rule is only to allow the license server to provide a code that SD will use to validate itself to that server. The only ports needed are those assigned to the https protocol.

The outgoing communications from SD are to the license server to get the list of current versions or version files, to check passwords, or to check external links. If SD cannot contact the license server, it will continue to work as normal. If password checking is enabled and SD cannot contact that server, it assumes the password is ok and continues as normal. If external links are not accessible, they will be reported with error codes on the Check links page.

Only use the internal search facility (default), unless there is an in-house search engine appliance, as an external provider will not know about the site's contents if it does not have access.

All this means that the site can be kept private and only needs the license server connection open when wanting to check for and do updates. The default URL for password checking is, but can be left blank for none. If not checking for updates or passwords, and there are no external links, once installed, the site can be completely shut off from the outside world. Links to other sites behind the firewall will still have to be prefixed with https://

During installation of SD, the full domain or subdomain name at that time is saved internally, and must be used for all subsequent operations, including contact with the license server. For purely internal use, this may require the site being in a DMZ to use the public DNS system for its naming, but firewalled off from it for normal use, though still using the DNS names for accessing internally.

  • Design principles
  • When can I get it?
  • Who will want Smallsite Design?
  • Terms and conditions
  • Contact   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