42 Running a public or community server
beardy-unixer edited this page 8 years ago

Who is this document for?

This document is about running Friendica servers for relatively large numbers of people, not about private servers for yourself and five to ten friends. If you are only setting up a server for yourself and your family or friends, you may find some interesting information in this how-to - but you can largely disregard warnings on issues like system overload.

In essence, people running servers for up to ten (or so) users will understand Friendica better after reading this document - but it’s only a must-read for those intending to set up much larger sites.

That’s because running a public or community Friendica server requires special consideration of every step. The effects of anything you decide are multiplied by the number of members you have - meaning that even minor issues for personal servers become big deals for public or community sites.

Differences between public and community sites

A community server caters for a specific group of people - your community centre, or church, perhaps - whereas a public server caters for the public at large. Both types of site have lots in common, but there are some important differences too.

For instance, registration policy is affected by these differences. If you run a public server and choose to accept or deny registrations arbitrarily, you make the whole Friendica project look unreliable. On the other hand, if you had a community server that allowed people from anywhere to sign up, you’d quickly run out of resources and your site would eventually grind to a halt. That’s because a community server probably knows how many users it will have and can purchase resources accordingly - a soccer club, for instance, has a defined membership base.

A public server will either have to upgrade frequently, or keep an eye on it’s resources carefully to know when to stop accepting sign ups. It is perfectly acceptable for a listed public server to be closed to new registrations if resources are running low. But it is very poor form to resort to cherry picking to combat the problem. As a public server admin, you may find that you have users you don’t really want on your server - but that’s the price you pay for serving the public. Rejecting or even expelling people arbitrarily contradicts the spirit of service. If you really wish to cherry-pick spontaneously, you should not ask to be listed as a public server.

Another difference is admin intention. A community server is generally set up to serve a particular community on a permanent basis, whereas many public admins view their sites as interim homes for users who feel unable to run personal/small group Friendica servers - see here for their sentiments (you may wish to link to that document on your own public site).

The technical environment - operating system

Choosing the right initial environment is a fundamental part of managing a public or community server. Obviously, you won’t normally try to host large numbers of users on a shared hosting scheme - you will almost always choose a Virtual Private Server (VPS) with an upgradable plan (or even a dedicated server if you expect extremely heavy use). But there are other considerations, too.

One pertains to the operating system. Our advice is to use Debian unless you are intimate with another Linux OS. The reason for this is simple: Debian is easily the most popular operating system among the people who usually offer support in the public Friendica groups. When you have problems later - and even the most experienced among us run into riddles from time to time - you’ll find it much harder to get help and will spend more time on search engines if you’re using a different distro. This isn’t evangelism: We’ve already had users on CentOS and Fedora who had to wait hours to find support because nobody else is familiar with the particular quirks of their systems. If you really know your way around, and you know where all your configuration and log files are without help, feel free to any Linux flavour you like - but unless you’re intimate with your OS of choice, stick with Debian (and not a derivative like Ubuntu - there are significant differences).

Web server

If you are comfortable with the idea, use Nginx - it offers superior performance to Apache and can handle around twice as many users on average. For bonus points, using Debian and Nginx lets you use the Debian install script to set up your server almost automatically in ten minutes flat (literally!). You can, of course, use Apache without any problems if your server is already set up and installed, but you won’t be able to host as many people on your site as an Nginx server.

On a public or community server, you’ll need to block the use of the prefix ‘www’. Some people still go to the effort of inserting www into web addresses. This breaks things. Use an Nginx rule or Apache redirect to send http://www.domain.com traffic to plain http://domain.com

Decide whether or not you’re going to use SSL now. If you are, you need to mandate it. You can’t have a public or community site that allows http and https for one reason - Internet Explorer. A considerable number of your members may be using this browser despite its questionable reputation. These people will be presented with mixed content warnings on practically every page (if there is a single non-SSL element on an SSL page, or vice-versa).

Don’t use a self-signed certificate. They’re very, very annoying for technical users, and a deal breaker for ordinary users (who are scared off by browser warnings). Get a free certificate from StartSSL instead. For more, see the SSL How-To. If you insist on using a self-signed SSL certificate, don’t run a public or community server.

Other tools

If you need a graphical control panel, use Webmin. Your webserver is going to crash, or start issuing 504s at some point, and it’s times like this that you really need to see what’s going on. If you need a web-based interface for this, you’re in trouble if you use something that relies on your webserver. Webmin runs on it’s own separate (and resource minimal) webserver, so you can access it even if your site is down.

Don’t install random additional software on your server. Your public/community site should share its VPS with a mail server to deliver notifications and registration emails (Postfix is our recommendation). There should be little to nothing else on that box. You might, in some cases, like an XMPP server too, but don’t push it (chat can be resource-intensive!). Installing wikis, blogs, and other apps willy-nilly is just asking for trouble.

Don’t use command line tools where they can be avoided. Yes, they’re quicker, and yes, they’re often easier. But it’s also much easier to mistype or use a wrong command - even if (often precisely because!) you’re copy-pasting from somebody else. Remember: You’re not just messing about with your own site - many other users are depending on you too.

Don’t use unorthodox solutions suggested by random geeks. Some of them know what they’re doing - but know far more than you do and are able to repair their errors quickly, too. Others are just guessing. Stick to the official documentation or to advice issued by the main developers.

Initial configuration

After choosing the right environment and installing Friendica, you need to do some configuration. You need to put more effort into this than somebody on a private server for the simple reason that other people are using your site. The options described in this section are available in your admin menu’s Site panel and are very easy to configure with the following information on their purposes.

  1. Site Name: Your front page will, by default, pronounce “Welcome To $SiteName” - where $SiteName is the value you put in this field. If you are a public server, this will also be your site name as listed in the public server directory. This is also starting to be used in various connectors. For example, if you cross post to the Libertree network, your post will contain “Posted from $SiteName”.

  2. Banner/Logo: This is actually a HTML box where you can put anything at all. You would normally want a logo and your site name in this box, but you can include any arbitrary HTML you want. Bear in mind that each theme will apply it’s own style sheet to this entry and it can appear very different in each. For instance, the Dispy themes have very large, left-aligned text here. By contrast Diabook has very small centre-aligned text. Instead of linking to friendica.com (default), you can link your logo to your home address. If you allow both SSL and non-SSL traffic, use “/” for the home link to avoid switching scheme.

  3. System Language: On a public server, the system language should normally be set to English, even if you’re not English. Friendica will attempt to auto-detect the language specified by your visitors’ browsers. If you have a translation installed for that language, the site will select the correct one automatically. Only if this fails, will the language fall back to the default specified here. English is the de-facto language of the internet and the usual choice here. But if you are targeting people from a particular country, go ahead and set their language as the default. If you’re a community server, you should set this to the language your particular community speaks.

  4. System Theme: This specifies the default theme for visitors to the website and members who are not logged in. Diabook is the most “newbie-friendly” theme, but it has a drawback - it doesn’t yet work in Internet Explorer. The Duepunto themes are the most basic, and should work in most browsers, but they’re also the least ‘shiney’. The Comix font is missing from some systems, though the theme still looks nice without it. Other than these considerations, your system theme is a matter of taste. Remember, for some reason, many users never seem to find the theme options. You should therefore select the theme you think most people will find easiest to use, not necessarily the one you personally use. For example, a lot of admins like Dispy for themselves, but that their users need less help if my system theme is Diabook. Users can later switch to any theme you have activated in the Themes menu.

  5. SSL policy: If you allow SSL and non-SSL connections despite the advice issued earlier in this document, you should set this to ‘No SSL policy’. If you do this, you may want to provide a way for users to switch between the two. You can, for instance, use two small padlock icons - one open, one closed - in the Banner/Logo area to achieve this. If you don’t have SSL at all, you should also use this option. If you mandate SSL, select the ‘Force all links to use SSL’ option. If you use a self-signed SSL certificate, don’t run a public or community server - so the self-signed policy isn’t relevant to this document.

  6. Register text: This is a plain text field that will be place prominently on the register page. If your site requires approval, you might like to point it out here. Likewise, if ban certain email domains (like gmail) or have problems with a particular email supplier receiving your emails, you could add that here. If you are a community server, you should use this field to remind people which community you accept members from. If you have a public server, consider something like this: “Before you sign up, remember the best way to protect your data is to host your own. Hosting your own Friendica account is both easy and rewarding. For more information, visit: http://friendica.com/download”. After all, Friendica is supposed to be decentralised, and public servers are supposed to be a last resort.

  7. Register policy: This is self-explanatory. ‘Open’ means people can register and sign up. ‘Closed’ means you do not accept sign ups at all. ‘Requires Approval’ means members can sign up, but their account will remain pending until you review and accept their registration (this is the option community servers should choose). On a public server, this option is to help you deal with bot sign ups and spam, not to cherry pick users. If you do have criteria for accepting or rejecting users on a public server, make your requirements clear on your website, and when you refuse an applicant make sure they know why, and that they get a link to find other public servers - no email is ever sent to a rejected member unless you do so manually.

  8. Block multiple registrations: This stops users creating a second account with the same email address to be used as a community forum/page, or a second personal account. If you’re trying to maximise resources, limit your users to one account each, and disallow the creation of forum pages. Pages are lower in resources than user accounts by a long way, but they soon add up if you’ve got a lot of them.

  9. _ OpenID support_: If this option is turned on, users will be able to create an account and log in using their OpenID. Warning: Depending on providers, this may not work with mixed SSL policies.

  10. Full Name Check: This will ensure users enter what looks like a full name - actually, any two words ‘look’ like a full name to the system. What this is really for is stopping bots creating spam accounts. Leave it turned off unless you have a problem with bots.

  11. Maximum Image Filesize: This is, as the name suggest, the maximum image size in bytes. The default size offers a good compromise between image quality and resource demands. If you’ve got a lot of disk space, you might like to turn it up, but remember, uploaded images can very quickly use lots of space. If you turn it up significantly, you might have to adjust the maximum file size in your server’s php.ini too.

  12. Allowed Friend Domains: Leaving this field empty will allow your sever to connect with any other sites (default Friendica behaviour). A reason for changing this would be special protection of your members - e.g. if you are running a site for children. If you want your members to only connect to people on the same site fill in your own domain name. Further sites entered into this box are whitelisted, enabling people on your site to connect to other people on your site, and on sites listed here, but nobody else. Use a comma to separate white listed domains: example.com,example1.com,example2.com

  13. Allowed email domains: If you leave this field blank (default) registrations from any email domain are allowed. You can restrict this to whitelist email domains, similar to option #12 - one reason may be to make double sure that no strangers register on a specially protected community site. Adding an email domain to this field allows only the whitelisted domains. To include more than one domain, provide a comma separated list: yourmail.com,othermail.info,moremail.net

  14. Block Public: This will block public access to your directory and member profiles, and make sure only your front page will be indexed by search engines. This is probably bad for public servers. Community servers - especially those whose users are minors - may find this a useful option.

  15. Force Publish: This forces all members to be listed in the sites local directory. This will probably be viewed negatively if used on a public server. However, on a community server it allows everybody to know who else is a member, and therefore, who can potentially see their posts. Force Publish also disables submissions to the Global Directory by default.

  16. Show Community Page: This will create a new tab that displays recent public posts by members of your website and comments to public posts on your website from remote users. This is good for giving new members instantly accessible content (though they themselves won’t be able to comment on anything until they have the respective thread initiators as contacts), but it costs in bandwidth and CPU as the page gets indexed by search engines.

  17. Enable OStatus support: This allows your members to connect to OStatus members using other systems (StatusNet, identi.ca etc.). All OStatus posts are public, and so this option can be a privacy hazard. If you have a public server, you probably need to leave this on - we do tend to get a lot of users with OStatus contacts. If you’re a community server, or are particularly privacy-conscious, you may wish to turn it off.

  18. Enable Diaspora support: This allows your users to connect to Diaspora members. This comes with privacy concerns - posts do not get deleted or edited on the Diaspora network. It can also prove a nightmare with support requests. Users often cannot connect to the larger Diaspora pods due to problems at Diaspora’s end... and then blame you. However, quite a number of new Friendica users come from the Diaspora network and want a way of keeping in touch with their Diaspora contacts. You should probably enable Diaspora support on a public server. On a community server, you may not need it.

  19. Only allow Friendica contacts: Exactly what it says on the tin - users can only add other Friendica contacts. No Diaspora, Ostatus, RSS, or email. Just Friendica. This is wonderful for resources, you’ll save a lot. Community servers should really consider this option. However, if you’re hosting a public server, the chances are you doing so to help the project - and that your members will still want their Diaspora and Facebook contacts. Not using this option is a sacrifice, but probably one worth paying in the long term.

  20. Global Directory Update URL: If members of your site opt to be listed in a global directory, this is the one that will be used. Actually, there is only one global directory at the moment. Either leave the field as it is, or leave it blank to disable profiles being submitted to the global directory. Searches that begin with @ will search the global directory for matches. If you do not specify a global directory here, this functionality will be unavailable on your site.

  21. Verify SSL: This turns on strict SSL checking, which will make your site check it’s communicating with sites using certificate-authority SSL certificates. This means sites using self-signed SSL certificates will not be able to connect to your site. This might arguably be a good thing. Self-signed SSL certificates will generate browser warnings that users just don’t understand and sometimes even make them leave immediately. On the other hand, you’ll miss out on some perfectly good contacts who refuse to bow to the SSL cartel - and chances are that the problem is alleviated anyway if these contacts use the respective self-signed SSL policy in Friendica. Unless you really know what you’re doing, or you have particular security concerns, leave this unselected.

  22. Network Timeout: This is the number of seconds before your server gives up trying to talk to a remote server. Initially, you should leave this value at the default. However, as you get bigger and things get a bit slower, increasing this can reduce timeout errors. Increase it slowly, until people stop complaining of errors.

  23. Delivery interval: This reduces system load by implementing a delay between background delivery processes. The recommend values as displayed should be used - however, increasing this number slightly can help if you start having problems. Increase in intervals of one second at a time until things come back under control.

  24. Poll interval: This is like the delivery interval, except that the delay is applied to background polling processes. Enter 0 to use the same interval as the delivery processes.

  25. Maximum Load Average: This sets the maximum load average before delivery and poll processes are deferred. If you set this value too low, posts will back up and never be delivered or polled. Too high and it doesn’t offer any relief for your server. This is a new feature, and has only really been tested by two public servers. Don’t play with it unless you really understand what you’re doing or feel you are in a position to be able to experiment.

  26. Accounts abandoned after x days: This is the most overlooked and most useful weapon in tackling server load. If you are a public server, a lot of your users will sign up, enable Facebook, then never return again. After x days, we’ll stop polling their Facebook contacts (and other external resources) to save system resources. In many cases, after x days, it’s as if they never joined. But as soon as they next log in, things will start working normally for them again. The smaller this number, the quicker you free up resources, but the more you annoy people who were just away for a few days. Finding the perfect balance between too soon and too late would be to know the users of your particular server perfectly. Since that is impossible, a rule of thumb might be this: 29 days are four weeks of vacation plus a day to sleep off jet lag. That could be a reasonable setting for a community server. If you’re running a public server and experience problems, you may wish to reduce this figure to 14.


Which plugins you enable depends on the functionality you wish to provide. The following list describes them from an administration point of view.


This plugin blacks out your friendica node during a given period. This was created as part of the SOPA protests and while it may seem generally pointless now, it isn’t. If you are a school or a youth group, you can use it to turn your website off after school, or at a certain time on a night. The system will continue to work normally under the hood, so any content from external sites will still be delivered, ready and waiting for your members to read when the lights come back on.

Server impact - none.

Impact to support requests - potentially high.


This allows you to collapse the posts and comments of specific members so you don’t have to read them. This is very similar to the “ignore” feature on most forum software - except that their contributions don’t disappear entirely (you can click to un-obscure them). Note that your users can also ignore, block or delete contacts in their contacts settings. But Blockem has the additional advantage of obscuring comments by people you would rather not read in your friends’ threads. That means you can use it on people that aren’t among your own contacts, but who annoy you in a forum or when they comment on your friends’ contributions.

Server impact - negligible/none.

Impact to support requests - low.

Blogger Post Connector

This allows you to cross post to blogger-based blogging services. It’s currently a generic plugin that needs to be amended for the specific service you wish to reach (copy, rename, adapt the code). So you will generally want to leave this one deactivated unless you are a developer with a use for it.

Server impact - low. Potentially high if you get a lot of users posting to blogger with lots of posts, but this rarely happens.

Impact to support requests - low.

Bug Link

This displays a ladybird in the bottom left hand corner of every page linking to the Friendica bug tracker so your members can report bugs. You may be better posting to Friendica Support and letting somebody else report bugs for you if you have a lot of non-technical users.

Server impact - negligible/none.

Impact to support requests - low, but likely to send support requests to developers instead of Friendica Support (where they should be).


This, well, adds a calculator to your apps menu.

Server impact - negligible.

Impact to support requests - nil.

Community Home

This replaces your home page with the community tab of your Friendica server, showing recent posts, recent likes, recent images, and recent members. While it’s fine in most cases, this is known not to work in certain configurations. While Community Home respects all privacy settings, there are possibly privacy implications to this. Some people may not expect their public posts to be quite so... well, public.

Server impact - medium.

Impact to support requests - minor. Some themes have issues with Community Home, and that may give you some bug reports.


This adds a unit convertor app to your apps menus, allowing users to change units from one form to another. This is surprisingly useful for an international site where people use weird measurements like yards/metres and pounds/kilogrammes.

Server impact - negligible.

Impact to support requests - nil.

Convert paths

This converts all links in your Friendica instance to the current http/https scheme. This is essential if you allow both http and https traffic, and have users who insist on using Internet Explorer.

Server impact - low.

Impact to support requests - beneficial. IE users will no longer get mixed content warnings.

Dreamwidth Post Connector

This allows your users to cross post to Dreamwidth blogs.

Server impact - low. Potentially high if you get a lot of users posting to Dreamwidth with lots of posts, but this rarely happens.

Impact to support requests - low.


Allows your users to use a plain text editor instead of the TinyMCE rich text editor. This is an essential plugin. Not only does TinyMCE break some things (code, iframe and embed tags) from time to time, but it’s also annoying for experienced users. Every time somebody turns it off, you also save system resources.

Server impact - negligible to negligibly beneficial, depending on its popularity among your users.

Impact to support requests - usually low... though somebody will turn it on without understanding it and get confused at some point.

External cron

This uses an external service to trigger a cronjob. It’s an inefficient alternative to a true cron. If you need an external cron, you shouldn’t run a community site for more than half a dozen members.

Facebook connector

This allows near seamless integration of Friendica with your Facebook account. Cross post to Facebook, and receive posts and comments from friends and pages in real time.

If you are a public server, you should think twice about allowing Facebook due to high resource use. If you decide to facilitate this plugin, you definitely shouldn’t use the option “synchronise comments”, but you should enable “Real-time updates” (which actually relieve the poller). You should also use the Facebook restrict plugin to block the linking of Facebook friends (see below). If you do not restrict Facebook use, your site will most probably eventually pass out. Even if you think you’re fine, you may be in for nasty surprises - the rapidly expanding item table will cause problems over time.

On the other hand, if you’re a community server, you can probably manage a few thousand Facebook contacts between your members. If you have a small number of users - or lots of spare resources - you may well be able to allow full Facebook connectivity. A community server may find itself in a considerably better position than public servers when it comes to Facebook. You are likely to be backed by your organisation, whereas most public servers are paid for by individuals. This means you might be able to handle a more fully featured Facebook connector. The safest bet for inexperienced community admins is to restrict Facebook initially, and allow each of its options one at a time, watching the resource demands closely until you find a level of integration you can sustain.

Server impact - rather high (but manageable) for a private server, very high indeed for a community server, often debilitating for a public server.

Impact to support requests - fairly high. The connector isn’t 100% perfect (mostly, because Facebook’s API isn’t terribly good). You’ll be asked to fix things that are often hard to fix.

Facebook Restrict

Install this addon and new users will not be able to link friends with the Facebook connector. Existing users that are linking friends will not be affected. New users will still be able to “throw things over the wall” (post to Facebook friends), and get comments on their posts. But they won’t see posts/threads initiated by their Facebook contacts.

Server impact - beneficial. This plugin exists solely to release server load. An essential plugin for all public websites using the Facebook connector, and helpful to community admins, too - at least initially while you judge the connector’s resource demands.

Impact to support requests - high, if you do it after the fact. Probably low if you do it from the outset.


Use Geonames service to resolve nearest populated location for given latitude, longitude. Geonames takes latitude and longitude of where you’re at (if you turn on “use browser location” in your settings) and tries to find the nearest population center.

Server impact - low.

Impact to support - probably nil. Potentially higher when you start getting people clicking the use browser location box.


This plugin allows notification emails from Friendica to be properly threaded for Gmail users. On the surface, it sounds harmless, but it corrupts threading for other mail clients. If you enable this plugin, half your life will be spent telling people to turn it off after they activated it for no reason.

Server impact - negligible.

Impact to support requests - surprisingly high.

Gravatar support

If there is no avatar image for a new user or contact this plugin will look for one at Gravatar.

Server impact - low.

Impact to support requests - moderate. Lots of people get very angry when they discover WordPress gave them a gravatar without telling them. They blame you for it, and it takes some time to make them calm down and understand whose fault it really is.

Insane Journal connector

Cross post to Insane Journal.

Server impact - low. Potentially high if you get a lot of users posting to Insane Journal with lots of posts, but this rarely happens.

Impact to support requests - low.


Adds an impressum/info page. This is required by law for German admins, but also useful for other people who want an “about” page.

Server impact - negligible.

Impact to support requests - potentially high, as it means users know who their admin is, but if you don’t make it easy for them to find that out anyway, you’ve probably got no business running a public or community server.

IRC chat room

Adds an IRC chatroom to your apps menu.

Server impact - negligible.

Impact to support requests - low, though you get a few people confused when they can’t log in with jappix (see below)


Add Facebook-like chat to your Friendica install, with the ability to automatically add your Friendica contacts, or connect to arbitrary Jabber (XMPP) servers, including Facebook.

Server impact - low/medium. Attaches to cronhooks when poller.php runs to grab the addresses of Friendica contacts. This has a low but noticeable effect. So if you’re already pushing resources a bit, this could be a problem.

Impact on support requests - low/high depending on your users. Mostly, it just works, but it’s a new plugin and still has a few bugs.

JS Uploader

This replaces the existing uploader with a javascript one. Don’t use it, it breaks in many browsers.

Server impact - negligible.

Impact to support requests - very high.

LDAP Authenticate

Authenticates a user against an LDAP directory.

Live Journal connector

Allows cross posting to Live Journal.

Server impact - low. Potentially high if you get a lot of users posting to Live Journal with lots of posts, but this rarely happens.

Impact to support requests - low.


This allows users to include mathjax in posts.

Server impact - negligible to high. The impact on your server is next to nothing, however, it connects to an external service to provide the service, and this can impact network performance negatively.

Impact to support requests - low. Anyone playing with it is expert enough to fix things themselves.


Displays the date on which a user joined in profile pages. There is potentially a privacy issue with this. Some people might not want other people to know what date they joined on.

Server impact - negligible.

Impact to support requests - negligible.


Adds a random name generator to your apps menu.

Server impact - negligible.

Impact to support requests - nil.


This adds a general purpose content filter, which collapses posts containing key words/phrases set by the user - this is rather like the ignore function on most forum software, but by scanning the content of posts, instead of by looking for usernames.

Server impact - negligible.

Impact to support requests - low, but the regex doesn’t always work for more complex terms, so it sparks a few questions at times.


This allow users to set the number of friends shown in their profile side bar. For some themes, this is essential as the default values make things look ugly.

Server impact - negligible.

Impact to support requests - no effect, except to make complaints about design easier to solve.


This links the post location used for a particular position to an external OpenStreetMap site, which attempts to display it on the map. An essential plugin for users who specify location. Without this, post locations will redirect to Google Maps. For privacy reasons, we really shouldn’t be sending any traffic to Google.

Server impact - negligible.

Impact to support requests - low.


This links all pages/groups/forums a user is a member of in their profile sidebar.

Server impact - low.

Impact to support requests - usually negligible.

Page Header

This allows you to set some text in the page header for important site announcements.

Server impact - low.

Impact to support requests - beneficial; allows you to answer them pre-emptively.

Piwik Analytics

Allows you to use Piwik across Friendica. Either install this on day one, or don’t install it at all. People don’t take kindly to having any kind of analytics added after they’re started using a service. You need a Piwik site to connect to if you wish to use this.

Public Server

As the name suggests, this is a plugin for public servers, and it’s a vital one in terms of resource management. There is no admin interface for this plugin. To use it, add any or all of these lines to your .htconfig.php file, depending on the options you want to use:

  1. When an account is created on the site, it is given a hard expiration date of

$a->config['public_server']['expiredays'] = 30;

... meaning accounts are deleted after this many days. Do not use this for a public/community server. It can be used to set up demo servers.

  1. To set the default number of days for post expiry use:

$a->config['public_server']['expireposts'] = 30;

This is essential. Once your item table gets up to half a million entries, even the best sites grind to a halt. Hardly any users expire their posts via their personal settings, despite both the massive privacy and performance this offers. Set a standard expiration time, or you’ll regret it. Users can override this value.

  1. Remove NEW users who have registered, but then never logged in after nologin days:

$a->config['public_server']['nologin'] = 30;

Before using this remember what happened when you joined Facebook. You signed up to look at a photograph, then never looked at your account again for years... until suddenly all your friends turned up, and you got a million friend requests in one day. It might be best to let never-used accounts live, if you can afford the space. But if you are short of resources, this option removes users who have not logged in for the number of days specified here.

  1. Remove users who last logged in over flagusers days ago.

$a->config['public_server']['flagusers'] = 146;

This is not useful for new public/community servers - it is intended for sites created before the public server plugin was enabled. It will flag users for deletion when they haven’t logged in for the number of days specified here. If you do use this, make sure you give it a large value. If somebody goes on holiday to find their account is gone when they come back, they’ll be very cross indeed.

  1. Set posts by users who last logged in a long time ago to expire (without expiring their accounts).

For users who last logged in over flagposts days ago set post expiry days to flagpostsexpire

$a->config['public_server']['flagposts'] = 90; $a->config['public_server']['flagpostsexpire'] = 146;

(Use the first option to mark an account as inactive if a user hasn’t logged in for that many days. In the example, an account will be marked inactive if the user hasn’t been logged in for 90 days. Once a user has been marked inactive, we will expire their posts after the number of days specified in flagpostsexpire. In the example, the posts belonging to the inactive account will be deleted after 146 days.)

Random Planet Imperial Edition

This is the same as random location, but using planets from StarWars or StarTrek.

Server impact - negligible.

Impact to support requests - low.

Poor Man Cron

Don’t ever run a community/public server if you need this. It’s an unefficient cron alternative for personal sites.

Posterus connector

Allows cross posting to Posterous.

This plugin is currently unstable at the moment, so don’t allow it.

Privacy image cache

When enabled, all external images will be cached on, and served from your own server. This acts as a barrier between your users and unethical networks like Facebook, which include tracking code in their images. Facebook will be able to see your server, but they won’t be able to see any of your individual members. Unfortunately, when using privacy image cache, there is no way to authenticate images with remote servers. This means your users will have to click through to their friends profiles to view private photographs.

Server Impact - there is a noticeable performance hit the first time you activate this as cache for old, but still viewable images is generated in one go. This only happens once, and lasts around an hour. From then on, new images are added “on the fly” rather than lots in one go, and the impact is negligible from this point on. Bandwidth demands are also increased. This is manageable in most cases, but can become a problem if you have lots of users linking lots of external animated gifs.

Impact to support requests - beneficial in most cases - nobody asks why Facebook social graph appears in their stream anymore. Possibly higher depending on your users - see the authentication issues above.

Quick Comments

Allows two click comments with user-defined text or smilies.

Server impact - negligible.

Impact to support requests - negligible.

Random place

Set a random location for each of your posts.

Server impact - low.

Impact to support requests - negligible.

Show more

Collapses long posts, and offers a “show more” option.

Server impact - negligible.

Impact to support requests - high. If you can believe it, people have edited themes instead of just turning this off! They’d likely do the same the other way around as well though.

Smiley pack

A pack of emoticons.

Server impact - low.

Impact to support requests - low, but you may spend some time telling people how to turn smilies of, if they are annoyed by them.

Adult smilies

A handful of adult smilies, not necessarily ‘politically correct’. Don’t turn this on if you’ve got kids or sensitive users.

Server impact - negligible.

Impact to support requests - negligible.


Inserts the Hot Shot Snipers game into your apps menu.

Server impact - low.

Impact to support requests - negligible.

StatusNet Connector

This allows users to “remote control” an existing StatusNet account, rather than use the built in StatusNet support which would behave like a separate account when viewed from identi.ca or other StatusNet instances.

Server impact - usually low.

Impact to support requests - users have to set this connector up for themselves when the plugin is enabled. This consists of more than merely entering a username and password, so you may be faced with questions. If you enable the plugin, be sure to try it out yourself in order to have the answers.


Expires accounts after n days. Don’t use this on a public or community server. It is for demo sites.


Adds 3D Noughts and Crosses to your apps menu.

Server impact - negligible.

Impact to support requests - negligible.

Tumblr connector

Allows users to cross post to Tumblr.

Server impact - low. Potentially high if you get a lot of users posting to Tumblr with lots of posts, but this rarely happens.

Impact to support requests - low.

Twitter connector

Allows users to post to Twitter.

Server impact - moderate; lots of people use it far too much.

Impact to support requests - low.

unhosted remote storage

Allows users to connect to remote storage using their Friendica identities. This is for use with so-called unhosted apps, of which few currently exist. It may be a very useful addon in future, allowing very easy integration of external functionality. But at the moment, don’t enable it on a public/community server.


Adds a “view source” link to public posts. This is so essential that it should really be in core.

Server impact - negligible.

Impact to support requests - nil.


Add friend/like widgets to other sites.

Server impact - depends how much they’re used.

Impact to support requests - low.

WordPress connector

Allow cross posting to WordPress.

Server impact - low. Potentially high if you get a lot of users posting to WordPress with lots of posts, but this rarely happens.

Impact to support requests - low to moderate. Some self-hosted WordPress installs have problems with this one if you are using old rewrite rules with an Nginx webserver, but it works fine in the vast majority of cases. (The Nginx rules here work: http://codex.wordpress.org/Nginx )


Specify a yourls shortener for use with StatusNet and Twitter. This is interesting if you want to use your own URL shortener for privacy reasons or to count clicks. But since only one yourls site can be specified, there is not much use for this plugin on a public or community server.

Advanced Options

There are a few options which do not yet have a section in the admin panel. Unfortunately, they’re also some of the more useful ones.

Managing Poller

Every time you see a spike in your RAM and CPU use, poller is running. The really big spikes are when the poller is polling Facebook.

If you followed the install instructions in install.txt, your cronjob will look something like this:

*/10 * * * * cd /var/www/mywebsite; /usr/bin/php include/poller.php

This makes poller.php run every ten minutes. This is about right for a private site but a community server can only dream of polling so quickly. Decreasing the regularity of your poller has obvious negative consequences - content that has to be polled (RSS feeds, Facebook, Email) arrives less often, but running it less often means you’re not using all your RAM all the time.

Exactly what number you should set this to varies by your users. You might initially set it up it to run ever 15 minutes initially. By the time you have about 50 users, you should be polling around once every thirty minutes, and once an hour by the time you have a hundred users.

To change the interval, simply change the value 10. For example, to make the poller run every half hour:

*/30 * * * * cd /var/www/mywebsite; /usr/bin/php include/poller.php

or every hour:

*/60 * * * * cd /var/www/mywebsite; /usr/bin/php include/poller.php

A feature related to this is the poller lockfile. It used to be that poller could take half an hour or even more to run on a large public server. This led to the possibility that you could have two instances running at the same time... which made it take even longer, so a third started running, then a fourth, and you could quickly run out of RAM. This has been mitigated very well recently, and doesn’t happen the way it used to. Nevertheless, it’s still a good idea to have a lockfile in place to stop multiple instances of poller running.

To use a lockfile, add a line like this to your .htconfig.php file

$a->config[‘system’][‘lockpath’] = “/path/to/lockfile”;

This is a directory, not a file, and must be writeable by the webserver. If you need a clearer example, the next line assumes the existence of a directory called “lockfile” in the Friendica root directory:

$a->config[‘system’][‘lockpath’] = “/var/www/mydomain/lockfile”;

Other .htconfig.php settings

Most of these settings in this final section of our how-to are self-explanatory, and have equivalents in the admin panel. It is very important that you don’t change settings here and in the admin panel, as this can have unpredictable results. For each setting, use one or the other.

The only really important setting not mentioned yet is for your maximum daily registrations. You can add a line that looks like this to restrict the number of users who can join in one day:

$a->config[‘system’][‘max_daily_registrations’] = 123;

where 123 is the number of users you’ll allow per day. This probably doesn’t matter for community servers, or servers that require approval, but it’s essential for open public servers. One admin once had one user sign up and then invite twenty friends. They all activated Facebook, and had over 500 friends each. Result: a crippled server for everyone else. Had max_daily_registrations been set to 5 or 10, that would never have happened. Use this setting or you will be hit like this eventually.

If you look through your .htconfig.php file, you may find another example setting with empty fields:

// If enabled, all items are cached in the given directory $a->config[‘stem’][‘itemyscache’] = “";

Do not be tempted to use this setting on a public server. It does the job intended by the author, making pages load faster, but at the cost of hitting the disk more often. This may be useful for a community site consisting of a couple of dozen members, but on a larger site actually increases server load due to the extra time spent writing to the disk.

If you are running a public server listed on friendica. com, the following setting may be attractive.

$a->config[‘info’] = “foo”;

Replace “foo” with the text of your choice. This will appear as the “additional info” text in the list of public servers. This is the only place anybody will ever see your info text, and it is not required. If you do fill it in, keep the text short - it shouldn’t extend the depth of the box on the directory page.