rbook (PHP 8 fork)

rbook is a simple, self-hosted recipe book: categories, search, users, comments, and optional images. No ads, no social feed, no account-farming—just a recipe database and a clean view.

This repository is a maintained fork of the original SourceForge rbook project, updated so it runs on modern PHP (8.x) and MariaDB/MySQL.

Original project: https://sourceforge.net/p/rbook/code/
This fork: https://github.com/clazarowitz/rbook

Full disclosure - I am not a web programmer at all. I like C/C++, assembly, optimization, DSP, and that sort of thing. In fact, I believe there are far to many things converted to webapps. But the recipe database is something I've used many times from a browser. It has simplified many things. I got rbook many many many years ago. It was simple. Perhaps too simple. We may fix some of that. But, like I said, I'm not a web programmer. At all. Pretty much the exact opposite. So how do I have this on php8? Grok. Ai. Vibe coding. I know its a despised idea. As someone who makes a living from code, I should despise it too right? Nope. It doesn't do a fantastic job. Its trained on the code thats out there, and much of it is garbage. So AI is basically an average coder, at best. It will get better. It will exceed us. But not yet. This project is a rather simple one too. The issues with PHP8 seem to be realatively minor. I admit I initially cheaped out and used grok-code-fast, and it made some dubious changes. It did get it so it wasn't immediatly crashing though. But then it got stuck in a weird loop, so I switched to grok 4.5, which was able to actually solve problems! I made one change that didn't need to be changed. In testing, because I wanted to test most of the basics, I found the my recipies button. To me that means recipes I contributed. Apparently to the original author, that meant bookmarked recipes. So grok happily fixed it and told me it was plumbed to bookmarks. Well great, now I just removed functionality! So I had it add in a bookmarks UI item to revive it. Sorry/You're welcome?

Anyhow, most of the rest of this readme was written by AI. I'll clean up a few things, but its mostly ok. There may well be things that are broken, especially new installs!

---

Why this fork?

The upstream project is effectively abandonware and does not run cleanly on PHP 8. This fork focuses on:

• Making the app functional on PHP 8
• Fixing the worst breakage (constructors, mysqli result handling, schema after import)
• Keeping the original design: simple and useful

Shortcomings (password hashing, Smarty vintage, UI polish, etc.) can be improved later. The goal right now is a working recipe book others can actually deploy. Ok, here's one place grok didn't grok - mentioning the shortcomings on passwords isn't really descriptive. Perhaps it was trying to keep it short, perhaps it didn't really understand what I was saying, so here's the full explanation (Warning: On top of optimization, I'm a bit of a crypto nerd, and not in the currency sense!)

Password storage in rbook is an unsalted md5. DO NOT USE A GOOD PASSWORD WITH RBOOK! If there is any sort of sql injection attack in this code (probable) it can get the password out. MD5 is so broken, you can probably just google a hash and get the original text. Its that bad! Don't believe me? Try googling 5f4dcc3b5aa765d61d8327deb882cf99 That may look like garbage to you, but trust me, its not. Even the google gemini ai in the search will tell you exactly what that is. So trust me, with all the leaks of passwords, ever hash of every password imaginable, even with as many number and special character substitutions you can think of, are a simple google search away from reversing to the password from an unsalted md5. Just use password for your password until we get this fixed. Now, I Know, the chances of someone attacking your self hosted recipe database is tiny. The problem will be, it will be the neighbors kid who does it....and while its better to know your attacker, do you really want to deal with that hassle? I sure wouldn't. (Like what might happen if you used the same password for your bank that you used for rbook? Think worst case and you won't be disappointed!). We'll need to get modern cryptographic authentication added to this. Maybe even do the standard thing of allowing google/meta/x/etc logins in addition to a local (strong) option. (PBKDF2, long salts, bcrypt or better, 10000's of rounds). Until then, just use a junk password. Please.

In addition - why PHP8? I wanted this to be able to run on a semi-modern linux install. Rocky 9/RHEL9 ship with PHP8 still. Yes, you can enable newer modules, and should. I'm sure ubuntu/fedora already ship with newer. But we need steps. Rocky9 is a solid platform currently, still gets security updates, and is modern for enterprise. Yes, the caveat is needed. Enterprise linux is designed for stability. So they have old versions of pretty much every tool that other distros would laugh at calling modern. So step 1, get it running on modern enterprise linux (its not entirely an oxymoron after all). Step 2, get it truly modern. Step 3? Improvements

What sort of improvements? Obviously first the security aspect. I really do like the simplicity of the app though, so I don't want to clutter it up more. I don't want grandma's story appearing before it. (You can put it in....at the bottom!) But what might be nice is some video. Video steps. So when you say whip the egg whites until peaks start to form, you don't have to go to youtube to see what that means (yes, if you have a recipe database, you ought to know what that means). The idea being we have "camcorders" in our pockets these days. There's no reason to get overly wordy in instrutions when we can just show what it should look like in video. Then, your great grandkids who never knew you can properly duplicate your recipes! (I sure hope video gets outdated and seems "old" sooner rather than later compared to some sort of holographic recording!....and somoene will need to fix this before then)

But still....why? Arent there recipe sites all over the internet. Free sites? Sure...but they get aggregated with everyone elses. Your great grandkids won't know which are yours and which came from randos on the internet (Intentionally dating this readme with that term!) It loses that special nature of "mom's cookbook". It gets full of ads. Someone will probably write a fake story to go along with it, to try to get people to spend more time on the site, or at least provide more real estate for ads. The term "enshitification" comes to mind. And that's the point of self hosting. This may be a dated design. It may be overly simple. But thats the entire point. KISS (Keep It Simple, Stupid!). I wouldn't mind some modern CSS, better themes, etc. But I wouldn't accept enshitification. No ads. Ever. Basic. Secure. Yours. That's what I'd like it to be.

That said, I'd love to add some useful features. Like, look at all ingredients, add up the nutrition information, and divide by number of servings to give you a nutrition profile. It might be really ugly for some recipes (super unhealthy but tasty!) It would be better to know though. So that, combined with video for instructions (per step), security features, and modern CSS/themes are where I'd like to see this project go. I will probably work with grok more to achieve these ends if no one else does. But I'm not a graphic designer in any sense. So I won't be fixing the layout. If "I" do, it will be grok. YMMV!

---

Requirements

• PHP 8.0+ with extensions: mysqli, session, mbstring (recommended)
• MariaDB 10.x or MySQL 5.7+ / 8.x
• Apache with mod_rewrite (or equivalent URL rewriting) and .htaccess allowed
  (AllowOverride All for the app directory)
• Optional: ImageMagick convert for recipe images

---

Quick install

1. Copy the contents of src/ to your web root (e.g. /var/www/html/rbook/).

2. Ensure the web server can write:

   • skins/default/templates_c/
   • img/ (created on first image upload if permissions allow)

3. Open:

   http://your-server/rbook/install/
   

4. Complete the installer (database, app title, base URI, etc.).

5. Remove or lock down the install/ directory after a successful install.

6. Log in as the initial admin user from the installer (historically root / password—change this immediately).

The installer writes config.php in the app root. That file is gitignored and must never be committed.

---

Upgrading an existing install (this fork)

If you already have data from an older rbook / XML import:

1. Back up the database and config.php.

2. Replace application files with this tree (keep your config.php and img/).

3. Run schema repair (restores AUTO_INCREMENT on primary keys if it was lost during import/dump):

   php install/repair_schema.php

   Or as the web server user if config.php is only readable by that user:

   sudo -u apache php /path/to/rbook/install/repair_schema.php

4. Clear compiled Smarty templates:

   rm -f skins/default/templates_c/*

5. Smoke-test: home page, category browse, search, view a recipe, create a recipe, login.

Import via Admin → Export/Import will also run schema repair automatically after a successful import.

---

What's fixed in this fork (high level)

PHP 8 compatibility

• PHP4-style constructors (function ClassName()) converted to __construct() across model and controller classes
• Safer session access (isset($_SESSION[...]) guards)
• Smarty-related fixes for PHP 8
• Template guards for count() on missing arrays (e.g. recipes with no images)

Search / listings

• Search and listing queries use reliable mysqli result handling (get_result() where available)
• LEFT JOIN / EXISTS patterns so missing users or empty steps don't wipe out results
• Category, keyword, popular/recent, and author listings work again

Recipes

• Steps and notes render correctly (tokenizer / TokenString / Tag constructors)
• Recipes with comments no longer crash the view
• Creating a new recipe ("Save and View") works again when primary keys have AUTO_INCREMENT

Schema

• SchemaRepair restores AUTO_INCREMENT on tables that need it (common after XML import or incomplete dumps)
• Installer still creates proper AUTO_INCREMENT columns for fresh installs

UX clarity

• My recipes = recipes you submitted (matches the "Recipes: N" count)
• Bookmarks = personal favourites (mine table), with Add to Bookmarks on recipe pages and remove on the bookmarks list

---

Features (unchanged spirit)

• Browse by category, recent / popular, title search
• Full recipe view: ingredients, steps, notes, optional images
• User accounts, comments/ratings, guestbook
• Admin: users, categories, export/import
• Optional invitations, ImageMagick thumbnails

---

Security notes (please read)

This is still a small legacy app. Be aware:

• Passwords are stored as unsalted MD5. That was the original design. Do not reuse real-world passwords. Changing to a modern hash (password_hash / password_verify) is a good next step for the community. (Ah, human note, ai did capture how bad it is!)
• Keep config.php private (600 or readable only by the web server user).
• Remove install/ after setup.
• Run behind HTTPS if exposed beyond a home network.
• Treat admin accounts carefully; the app is not a hardened multi-tenant SaaS.

---

Layout

src/                 Application root (deploy this)
  classes/           Models (Recipe, User, Category, ...)
  controllers/       Front controller actions
  helpers/           i18n, auth, UI helpers
  install/           Installer + repair_schema.php
  skins/default/     Templates and CSS
  extlib/            Bundled Smarty, reCAPTCHA helper
  dispatch.php       URL router
  config.php         Created by installer (not in git)

Build helper (optional packaging):

./buildrbook.sh

Produces a zip under target/build/ (gitignored).

---

Development

• Prefer editing under src/, then deploy that tree (or zip) to the server.
• After template changes, clear skins/*/templates_c/.
• After imports or DB restores, run php install/repair_schema.php.

---

Credits

• Original rbook team and SourceForge project
• This fork: community PHP 8 maintenance aimed at keeping a simple recipe book alive

License: see src/LICENSE.txt (GPL v2 or later, as upstream).

---

Contributing

Issues and PRs welcome—especially:

• password hashing upgrade
• dependency/Smarty refresh
• accessibility and mobile CSS
• tests around search and recipe save
• documentation for nginx and Docker

Keep the project simple. If a change adds accounts-for-ads, infinite scroll of strangers' content, or a SaaS control plane, it's probably the wrong project.