Here you will find the right solution for different error cases.

• The directory fp-content/ is not writable
• The theme is displayed incorrectly
• Instead of the FlatPress blog, an error is displayed in the browser
• Incorrect date and/or time
• E-mail delivery failed

Grant the directory fp-content/ the access rights (File permissions 0666, Directory permissions 0777). By default, the owner is www-data.

Hint: FileZilla is a great free FTP tool for this task.

Here is the recommended procedure if the theme, the FlatPress design, is displayed incorrectly.

1. Clear the template cache from FlatPress.
2. Clear the browser cache.
3. Disable all browser extensions.
4. Make sure that the browser is allowed to execute JavaScript.
5. Check the security settings of the device used.
6. If the device is using a VPN tunnel, disable the VPN for testing.
7. If you are hosting yourself, check your network configuration. Disable public and local IPv4 for testing.
8. If you host yourself and use https for FlatPress, make sure that the certificate is issued for your domain.

If the theme continues to display incorrectly, check if the problem is reproducible with another device. If the problem is reproducible with another device, we would be happy if you let us know in the forum or on GitHub.

Here is the recommended course of action if some or all pages of the FlatPress blog are not displayed. You might see the following:

• Error 403
• Error 404 Page not found
• Error 500
• Error 502 Bad Gateway

Carry out the following actions one after the other and check after each action if the problem has been solved.

1. If you are not using the Leggero theme, make sure that your theme is Smarty4 compatible.
2. Make sure that the internet connection the device is using is not disrupted.
3. If the device is using a VPN service or tunnel, disable the VPN for testing.
4. Make sure that the Internet connection that the web server uses, DNS server is using, is not disrupted.
5. Make sure the web server has at least PHP 7.1 or higher installed.
6. Make sure that mod_rewrite, mod_headers, and GDlib are installed on the web server.
7. Check that all FlatPress files are in the correct directory on the web server – ideally in www-root.
8. Check that all ownership- and access rights are set correctly. By default, the owner is www-data. The FlatPress files 0666 and directories are on 0777.
9. Check if a .htaccess file is present on the webserver. If so, rename them test-wise.
10. Check for anomalies in the log files of the web server, e.g. syslog, error.log.
11. Check the server configuration, e.g. apache.conf, 000-default-le-ssl.conf e.t.c.
12. Check, depending on the application, whether requests from the Internet or from the home network are actually forwarded to the web server. By default, the web server must be accessible via TCP port 80 and 443.
13. Delete the file %%setup.lock in the /fp-content directory and run the FlatPress setup (setup.php) again.

If the problem persists and you were unable to perform some actions because you are not hosting yourself, other causes may be the hosting provider.

My self-created static page or entry has the wrong date/time.

Carry out the following actions one after the other and check after each action whether the problem has been resolved.

1. Check in the admin area in the Configuration menu → International settings whether the UTC is displayed correctly.
2. Check in the admin area in the Configuration menu → International settings whether the time offset is correct.
3. If you run your own web server, make sure that your web server has the correct UTC.
4. If you run your own web server, make sure that the correct time zone (e.g. date.timezone=“Europe/Berlin”) is entered in php.ini.

Note 1: FlatPress cannot distinguish between winter and summer time. Either the web server takes over this task or you have to correct the time offset in the admin area in the Configuration menu → International settings.

Note 2: If the entry was initially saved as a draft and is only published later, this entry will bear the date/time when the draft was saved. (#66)

If the problem persists and you were unable to perform some actions because you are not hosting yourself, other causes may be the hosting provider.

You will not receive an email if it was sent through the contact form, someone commented on a post, or a comment needs to be approved by you.

Perform the following steps one after the other and check after each action the problem has been resolved.

• First, check if it is generally possible to send e-mail with PHP.

Create a new php file with the following content:

<?php
ini_set('display_errors', 1);
error_reporting(E_ALL);
$recipient = "your-mail-server@domain.ltd";
$subject = "Subject with non-ASCII characters: ÖöÄäÜüó¿¡á";
$from = "From: Sender <your-mail-server@domain.ltd>";
$text = "The e-mail was sent successfully";
 
mail($recipient, '=?utf-8?B?' . base64_encode($subject) . '?=', $text, $from);
echo "Test email sent";
?>

Now upload the php-file to your web server. Adjust ownership and access rights if necessary. Now open the php-file in the browser. Ideally, you should see the text “Test email sent” – that’s all. Now check if the test e-mail has been delivered to your mail server.

• Check if there are any anomalies in the log files of your web server and mail server.
• Make sure your mail server uses authenticated mail delivery – with secured SMTP and SMTP authentication.

Reason:

Emails sent directly from the PHP mailer easily end up as unauthenticated emails in spam or are not forwarded by mail servers or are sorted out as suspected spam.

It can also happen that the web server (e.g. shared web hosting) is hosted on FlatPress and is blacklisted for email.

• If you are sending emails via a mail provider (mail-relay), make sure that “third-party programs” (your mail server) are allowed to access your mail account.

Reason:

By default, e-mail accounts with freemail providers are pre-configured so that only webmail is possible – no e-mail clients.

• If you are sending the e-mails via a freemail provider (mail relay), make sure that your own e-mail address as the sender is in the header of the e-mail.

Reason:

Many free mail providers (e.g. GMX, Yahoo) prevent forwarding if there is another e-mail address as the sender in the e-mail header.

• If FlatPress ≤ v1.2.1 is used, umlauts, special characters, etc. in the header of the e-mail may prevent it from being sent or received. Therefore, if possible, avoid umlauts, special characters, etc. in the blog title.

Reason:

The possible cause is the subject, which itself already represents a header and only accepts and interprets ASCII characters. All characters deviating from this (umlauts, special characters, etc.) are output as unreadable symbols and characters. An incorrectly formatted subject is also very often judged as spam by the receiving (or even the sending) mail server and is not accepted or not sent at all.

This article is currently being edited. It describes the measures in a simplified way and will be refined in the future .