Recap: Part 1 and Part 2 covered the four pages and the split between bipa.php (processing) and bipga.php (organising). This last part of using bip looks at what visitors see and how to keep the install tidy.
The public gallery
index.php is read-only. It has no login and no controls that change anything, the forms simply select user preferences. A visitor chooses a gallery, then browses its thumbnails and opens a photo in the viewer. A few behaviours are worth knowing:
- Page sizes. A visitor can choose 24, 60 or 120 thumbnails per page, or “all”. The “all” option loads in chunks of 60 as you scroll rather than in one heavy load, which matters on phones.
- Deep links. A single photo has its own address using a
?photo=parameter, so you can send someone straight to it. - Caching. Images are served with long cache lifetimes, so returning visitors load them from their own browser.
- Restraint by design. Unless the starter album is populated, the site shows little until a gallery is picked. That’s intentional.
- Themes. A small switcher lets visitors choose Default, Light, Dark or the Photographer’s Theme, and their choice is remembered. The owner sets which one new visitors see first.
- Page security. The page uses a Content Security Policy that allows scripts only from the site itself, with no inline script handlers.
Tweaks made during the release candidate
The index page received a few small user-interface refinements during the release-candidate cycle, all of which are in 1.02. Thumbnail columns are centred and sized to the number of images in the gallery, never more than four across.
Thumbnails display at their true dimensions, with portrait and landscape pictures centred against each other so captions line up. The welcome note is centred above a thin rule, and the photographer credit sits below the bottom pagination, above the copyright line. None of it changes how you use bip. It just makes a finished gallery look more settled.
Scale
bip is designed for libraries in the region of two to three thousand images for best performance. It can go somewhat further if needed, and the simplest way to grow beyond that is to deploy another copy in another folder.
The log viewer
Each processing run writes its own small JSON log file. process_log.php lists them, and you can delete a single log or all of them from the top of the page. Nothing accumulates unless you let it.
Configuration
The config file holds the batch limit (50), the time limit (28 seconds), the image sizes and quality, and the folder paths. Edit it with care; the database filename is generated once per install and must not be renamed or hand-edited, otherwise bip can’t find its own data.
Keeping it healthy
Two small habits help. First, re-run the Security Self-Test after any hosting change, such as moving servers or changing server software, because it checks the protections are still working.
Second, if the admin ever reports that the database is not connected on a site that has been fine, check free disk space on the host before anything else. A full disk looks exactly like a broken database.
Before you go live
- Run the Security Self-Test in bipa.php and confirm it passes.
- Change the default admin password through the forced first-login setup.
- Check that the public page shows what you want visitors to see, choose a default theme, and fill in Index Content and Photographer if you want them.
- Remove the INSTALL, README and ChangeLog files from the server as the last step.
In short: the public page is read-only, paged, cached and deliberately restrained; logs and configuration are simple; and a short checklist gets an install ready for visitors.
That’s the series. Revisit the story behind the product from Build Story, Part 1: The Brief.
Get the free self-hosted photo gallery from the bip project page.
Leave a Reply