Shared hosting

A site made with Ehundu is HTML, CSS and images: the server runs nothing. That is why it works on any shared hosting, even the most basic one, even if it only offers FTP and has no PHP 8.4. The only thing that needs PHP 8.4 is building, and you do that wherever you like.

Where to build¶

The usual way is on your computer. You build, you deploy over FTP or SFTP (the guide Deploying the site explains it) and the server only receives the result. You need PHP 8.4 with mbstring and, to deploy over FTP, the ftp and openssl extensions. You check it like this:

php -v
php -m

If you have SSH, you can also build on the server itself: you upload ehundu.phar and run it there with the carpeta destination (“folder”), which copies the site to the web root. Careful, though: the PHP version on the command line is not necessarily the one the web uses. Many hostings have several, and the console one is the old one. Check php -v first of all.

And there is a third way, for whoever builds a panel: building from a web process, when a button is pressed. There the time limit is real, and the library spreads the work over several calls. It is in the library (in Spanish) and in incremental builds (in Spanish).

How much memory¶

A shared hosting usually limits PHP's memory (memory_limit). On the biggest site we have tried, with 1,204 pages, the peak is 170 MB on the first build; one with a few hundred pages needs a lot less. These are measurements from a single machine, not a promise. If PHP runs out of memory, raise the limit just for that command:

php -d memory_limit=512M ehundu.phar compilar

The .htaccess¶

With Apache, an .htaccess file in the folder of the site configures the server without touching anything else. You put yours in publico/ and Ehundu copies it as it is to the root, like the rest of what is there. Three things you will almost always want.

The error page. Write the page with url: /404.html in its front matter and tell Apache to use it:

ErrorDocument 404 /404.html

The addresses that change. If a page moves, the old one redirects to the new one with a 301, and neither search engines nor whoever has it bookmarked are lost:

Redirect 301 /old-services/ /services/

And the cache. If you use css_fichero() or js_fichero(), the name of the file is the fingerprint of its content and it changes when the content changes, so the browser can keep it for a year:

<FilesMatch "^[0-9a-f]{10}\.(css|js)$">
  Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

Some hostings put a proxy in front of Apache, and then %{HTTPS} never arrives as on: a rule of the kind “if it is not HTTPS, redirect” goes into a loop. It is better to do the redirect from http to https in the hosting's control panel. And if your server is not Apache, the .htaccess means nothing to it: the equivalent configuration goes wherever its documentation says.

What a static site does not have¶

It has no PHP on the server, so a form is not processed there. You need a service that receives the submission and emails it to you; Ehundu does not include one. The same goes for a search box or anything that has to run when the page is visited: it is solved with an external service, not with the site.

The first time you deploy over a hosting that already had a website, the files of the previous one stay where they were until you remove them by hand. Ehundu only deletes what it uploaded itself.