Using bip, Part 1: How the Pieces Fit

Using bip starts with knowing its parts. bip (Batch Image Processing and Gallery) began as a batch image processor and grew into a complete gallery. It’s a small PHP application with a SQLite database, no framework and no database server to install.

This three-part series explains how the pieces work, without being a step-by-step manual. For that, use the INSTALL and README files bundled with the product, and the bip project page for downloads.

Using bip: the four pages

bip has four entry points, and each has one job:

• bipa.php is the processing admin. It turns raw uploads into web-ready images.
• bipga.php is the gallery admin. It organises the processed images and holds the metadata.
• index.php is the public gallery. It is read-only.
• process_log.php is the log viewer for processing runs.

This separation is the central idea. The public page can never change anything, because it contains no code to do so. The two admin pages share a login.

The flow of a photo

1. You upload originals to the uploads folder by FTP. There is deliberately no browser upload form, which removes a whole class of risk. Any FTP client will do, and you can upload a few files or a few hundred.
2. In bipa.php you start a processing run. Each image is decoded once, resized to a web-friendly size, given a thumbnail, written out as WebP, and recorded in the database.
3. In bipga.php you assign images to albums, add captions, and set the text shown on the public page.
4. Visitors see only index.php.

bip reads from the uploads folder and writes its results elsewhere, so processing never alters an original, and you can re-run it at any time. Clearing out processed originals afterwards is a separate, optional step.

Batches, not marathons

Processing is done in batches, up to 50 files per run, with a 28-second time limit. A run that reaches either limit stops cleanly and tells you how many files remain. You press the button again.

This is why bip works on ordinary shared hosting, where a long-running script would be killed. Re-running is always safe: in “new” mode bip skips anything it has already processed.

Configuration in one place

Settings live in a single configuration file: batch limits, image sizes (full-size images default to 1200 pixels and thumbnails to 240), quality, and folder locations. The admin pages show processing values as read-only, with a pointer to the file, so there is one source of truth and nothing changes behind your back.

First login

The first time you log in, bip makes you set a password of at least ten characters. After that, logins are throttled per visitor, and the throttle cleans itself up. The password is stored hashed, never in plain text.

Faster pages, if you want them

The processing admin also has a small Script & Style Minify panel. One click shrinks the gallery’s script and stylesheet by removing comments and whitespace, keeping a full copy in a protected folder so you can restore it at any time. It is optional.

What you need

A web host with PHP 8.4 and SQLite support, FTP access, and a few minutes. There’s nothing to compile and nothing to configure beyond the single file described above.

In short: four pages with one job each, a one-way flow from upload to processed image to organised album to public view, and a single configuration file.

Read next: Using bip, Part 2: bipa.php vs bipga.php, the two admin entry points.

Get the free self-hosted PHP photo gallery from the bip project page.