Version 3.3.4 of phpBB was released today. It’s a maintenance version with no critical security fixes and no important new features. The only new feature that I could find is that it supports a new image format: WEBP, introduced by Google and supported by most browsers which provides more compact, lossless image rendering than PNG.
Mainly it offers better support for PHP 8. It contains a bug fix that I drew to their attention and an important fix that I stumbled across recently if you have unusual characters in your database name, which kept the database size from displaying and actually wouldn’t let you get into the ACP at all! But if you had this issue, you would have patched it already.
One thing you might notice: the RESET button goes away on a number of forms because, arguably, a RESET button is obsolete. One way to reset a form is simply to refresh the page.
So update to it if you want, but there is probably no tearing hurry for you to do so. You can download it from phpbb.com’s download page, read the announcement, see a summary of the release here and see all the issues addressed here.
(If you decide to buy DreamHost hosting, please use my affiliate link. This way I earn a commission. You won’t pay extra.)
Hosting is changing
The world of hosting has been changing, and often not for the better (at least from the perspective of hosting customers). As I noted in this post, many hosts are getting gobbled up by other firms, usually Wall Street firms looking to maximize profits by consolidating hosts, cutting services and maybe raising prices.
Another big trend is to go virtual. GoDaddy, for example, is moving into Amazon’s cloud. That certainly saves the expense of managing their own hosting centers and paying a hosting staff. More recently, the same is true with Siteground, which I have been using for a few years, which is going into Google’s cloud. Siteground has also raised prices rather substantially, hoping most clients will opt for inertia. For its shared hosting, Siteground keeps an eagle eye on resources you are using and will quickly complain if you go over these resources.
So I’ve been looking for acceptable alternatives, always aware to not to put too much faith in my web host of the moment, since there’s a good chance they’ll get bought out, raise prices, reduce staff or do all of these things. I tend to be irritated by hosts that provide generally incompetent support staff, obscure really important features like limits on disk space or outgoing emails, or who raise prices way beyond the rise in inflation.
A week spent in GoDaddy support hell
I thought GoDaddy had been improving in general. Going virtual wasn’t necessarily bad if the cloud provider can provide greater speed and reliability. But this month I got caught up with a client using GoDaddy which suggested they were reverting to old habits. It might have been because his board was on an old machine that hadn’t transitioned to the cloud yet. The support experience with GoDaddy though was just horrible.
His plan was so old it only supported PHP 5. There was no migration path to PHP 7 except to buy a new plan, and they couldn’t be bothered to help him move his gigabytes of files from the old to the new hosting, or transition the database. Not that we didn’t try. Downloading and uploading files from home is generally a painful, tedious and slow experience. The volume of files was large and the uploading was very tedious because his ISP severely limits upload speeds. It took days.
On the back end I was busy trying to upgrade his board and get that working. The shared hosting timed out exporting a database and timed out uploading it too. I tried all sorts of tricks to get it to work and upgraded the database on my machine since the upgrade scripts would time out due to resource caps. This went on for more than a week.
DreamHost turned out to be reasonably dreamy
Eventually I recommended he get rid of GoDaddy. But where to go? I sent him to DreamHost.
I had a good impression of DreamHost based solely on a seminar I attended at a Boston Wordcamp in 2019. In the seminar the speaker talked about how they fended off lawsuits by the Trump Administration to monitor their servers, and succeeded. I asked my peers about DreamHost and the reviews were generally positive. Still you don’t know until you try.
Was rehosting with DreamHost a wonderful experience? Overall it was pretty good, but it had its quirks. Like most hosts they offer various kinds of hosting, and the client chose the shared hosting plan. Loading his database on DreamHost, it timed out there too with resource limitations, but I was able to work around the problem. His database is nearly a gigabyte in size. Essentially I figured out where it failed (in the middle of populating the phpbb_posts table) and created an extract of the rest of the database. That got the rest of it. I’m just glad I have a text editor that can handle really big files (BBEdit, BTW).
Their tech support was responsive, helpful and reasonably quick. One thing I liked was that they didn’t have explicit quotas on database sizes and overall file sizes. That was important for this customer. Looking through the fine print of the hosting plan, I saw only one red flag: there was a limit of 100 outgoing emails per hour. That didn’t matter for this customer. It looked like a good fit.
Curiously my hosting plan with Siteground was up for renewal, so I took the plunge myself buying their multi-site shared hosting plan. Siteground wanted about $300/year, and this initial 3-year DreamHost contract was about $142, which is a huge savings. This got me more into the weeds.
The good:
It’s a very good value. Naturally new customers get a discount. Mine is $3.95/month for three years (my contract) which is a great value if they can maintain the same level of service. The discount is 72%, so the non-discounted price is probably $12.95/month. This gives me unlimited storage, bandwidth and databases, making it a good deal if you have to store lots of stuff online. However, it is shared hosting so it’s not appropriate for highly trafficked sites.
Technical support was reasonably quick, responsive and helpful, and I threw a lot of issues at them.
Moving WordPress sites is easy. They offer a plugin you put on your old host. You enter the WordPress username and password and wait. It does the work for you.
It’s easy and quick to set up free Let’s Encrypt certificates. But you have to wait until the DNS transfers to DreamHost. (There’s no way for any host to get around this.) So for a short period of time there will be certificate errors.
End to end solid state hosting. This speeds up rendering of web pages and makes the hosting more reliable.
The bad:
While tech support was good, they are based on the USA West Coast, and they work standard hours. It doesn’t appear that support is available outside of this window, although it is available seven days a week.
100 emails per hour is pretty skimpy. Anything over that just doesn’t get sent and won’t go into a queue for sending later.
Testing your domain can be confusing. Your database server will have a subdomain like mysql.mysite.com but until the DNS transfers over the only way to test it with a database is to configure the database server’s IP address. (This was a problem with phpBB, but not with WordPress thanks to their plugin.) Otherwise modifying the local hosts file worked for testing. So you really need to remember that the server’s IP could change, so after the domain moves you should go back and replace the IP with the subdomain name.
Their support system has no way to reply to a ticket, as best I can tell. So I coped by entering a new ticket with the same subject line.
The weird and unusual:
No cPanel. They rolled their own control panel and it’s not the most intuitive. For example, it’s unintuitive to go to Domains > Manage websites to manage a website. Most hosts cleanly split domain functionality from web hosting.
For each domain or subdomain you get a separate set of SSH and FTP credentials. Keeping these organized is a bit of a challenge!
If you can deal with these oddities, DreamHost may be for you. It is for me, presumably for the next three years at least! It does appear to be a very good value.
phpBB has lots of features and some are very obscure. I ran into one of these recently for a client. Apparently, it’s possible for users and groups to not have their posts count in their total post count.
Obviously this is not an issue for most boards, and it’s hard to figure out a use case for why you would want to do this. One case is to avoid unearned ranks. phpBB has an optional ranking system which is typically based on the number of posts. Making lots of replies that aren’t really substantive can do this and it’s an issue on some boards. Presumably these boards are not well moderated, as moderators are usually tasked to find and remove these posts.
Whether a post is counted in a user’s total post count or not depends on whether the post_postcount column in the phpbb_posts table is 0 or 1. If it’s 1, it gets counted. If it’s 0, it doesn’t get counted.
For example, you could have a general chat forum and posts in these forums might not want to be counted in a user’s total posts because they are considered trite. Then you could have other forums where the meat of the board’s content is, and posts in these forums could count.
Changing the post count policy
By default, all posts count in a user’s total post count, so if you don’t want posts to count for certain groups or users, you will have to change phpBB’s settings.
This is controlled by a permission. Typically you set this group forum permission. ACP > Forums > Forum based permissions > Group forum permissions.
Next you pick the group, then the forums for the group where the permission will be changed. Next you select the Advanced permissions link and then click on the Post tab. Then set the Increment post counter setting to either Yes or No as desired for the group and the forum. Do this for all the forums whose permission you want to change for the group and save your changes. If you want to change this permission for other groups, repeat.
Increment post counter permission
If you want to remove this permission for a particular user or users only, you can avoid groups by selecting ACP > Forums > Forum based permissions > User forum permissions. In general though I think you’d want to avoid doing this on a user-by-user basis, and do this only for groups.
Changing post counts for old posts
While this works for future posts, it doesn’t affect existing posts. How do you fix these old bogus post counts? As best I can tell there is no extension to help you out. So you have to get down and dirty with your database, using a tool like phpMyAdmin.
Before attempting anything like this, disable your board and back up your database, or at least backup the posts table. This can be done in the ACP on the Maintenance tab.
Generally you need a list of forum_ids and group_ids. A tool like phpMyAdmin makes it simple to look inside your database. Your web host control panel will usually have a tool that runs phpMyAdmin. Make sure you select the database for your board. Your board’s config.php file will provide the database name, if there is any ambiguity.
Database tools like phpMyAdmin are very powerful. It is possible to make large, irreversible changes to the database if you type commands incorrectly.
A forum_id is a number assigned to a forum in the database. You can see a list of forum_ids with this query, which can be executed on the SQL tab for your database in phpMyAdmin. (Change phpbb_ if your table prefix is different):
SELECT forum_id, forum_name FROM phpbb_forums;
Getting forum_id for forums in phpMyAdmin
Next, you need a similar query to get the group_ids for your groups:
SELECT group_id, group_name FROM phpbb_groups;
Getting group_id for groups in phpMyAdmin
With these group_id and forum_id values, you can then write a query to change the post_postcount value in the phpbb_posts table for a particular group and forum. Using the example above, if you wanted to change this flag to 0 (don’t count) for all members in the Registered users group (group_id = 2) to the forum “Your first forum” forum (forum_id = 2), the SQL would be:
UPDATE phpbb_posts p, phpbb_groups g, phpbb_forums f, phpbb_user_group ug SET post_postcount = 0 WHERE p.forum_id = f.forum_id AND p.poster_id = ug.user_id AND ug.group_id = 2 AND f.forum_id = 2
If you wanted to set post_postcount to 0 (zero) for all posts made in a forum, the SQL is somewhat simpler. In the case of forum_id = 2 the SQL would be:
UPDATE phpbb_posts p, phpbb_forums f SET post_postcount = 0 WHERE p.forum_id = f.forum_id AND f.forum_id = 2
Recalculating the post counts
There is one last step: you need to recalculate these statistics:
ACP > General > Resynchronise post counts
Clean up
If you messed up, restore the table you backed up.
In part one I looked at the technical approach I used for this unusual Delphi forums to phpBB conversion project. In the interim I have delivered something to the customer based on a somewhat dated extract they provided from their Delphi forums.
One thing I didn’t realize until recently was that moving their forums into phpBB was actually an interim state. The goal is to move it into bbPress, a WordPress plugin. Apparently bbPress can import from phpBB, but clearly not Delphi forums.
So it’s off to another contractor for that step. They might find they lose too much functionality moving to BBPress. phpBB after all has twenty years to mature and it has more functionality than any other forum solution, with one major exception in that it can’t do threads inside topics. Maybe that will show up in phpBB 4.0. If they lose too much functionality, they may keep it in phpBB, but they will need two sets of credentials because, in general, WordPress and phpBB don’t mix.
Some of the things I have learned and discovered since my last post:
Their guy who provided a YAML extract made a GitHub project out of it, so feel free to use if it you dare.
His parser though wasn’t perfect. It may be imperfections in Delphi’s software at fault. As noted in the last post, a few posts wouldn’t parse.
Downloading the attachments was challenging. Delphi does its best to not let you download them outside of its system. I ended up using curl and passing some authorization cookies in curl to download them successfully. Once downloaded, they then needed to be copied into a files folder so that phpBB could find them.
I had to write many PHP scripts to do the work and execute them in a defined sequence. Among these scripts were:
One that calculated the attachment size and placed it in an attachments table
A master script I called load_threads.php that did most of the initial work for reading the .yaml files and placing content into a set of denormalized tables that was used to store the posts and attachments data called phpbb_posts_load and phpbb_attachments_load. Subsequent scripts moved the data into phpBB 2 database tables after doing a lot of data jiggering.
Not all attachments had file suffixes, so I had to figure out what kind of file types they actually were and rename them accordingly. The Unix file command has a -mime_type argument that helped a lot.
One to load the users by examining user .yaml files provided in the extract.
One to resize images so they would not exceed a maximum height or width.
I also kept a set of notes documenting the sequence and issues discovered, and how to check the results. At points I had to move tables to my Raspberry Pi, which has PHP 5.6 installed, which can run the old phpBB 2 software, do some clean up there, then move the phpBB 2 database back to my machine so I could convert it to phpBB 3.3.
I created some pretty exotic SQL to do things like update the first and last posts (and posters) for topics, set the post count correct for topics.
In short, it turned out to be pretty tedious and a learning experience, but is definitely doable with the right skills.
The phpBB group released version 3.3.2 yesterday. Since one security issue was fixed, an update to that version is a good idea.
I have updated the Do I need to update? page to indicate the tables that are changed in this update. If updating from phpBB 3.3.1, you don’t need to backup any other tables than those shown for the release on this page.
phpBB 3.2.11 was also released and contains the security bug fix in 3.3.2, but which was present in 3.2. It’s better to migrate to phpBB 3.3 if you are on phpBB 3.2, but if you can’t you can at least address this security issue.
Most of my work is pretty much the same: upgrades and updates to existing phpBB boards. Lately though I’ve been tackling some unusual projects. One of these is to move a Delphi board to phpBB.
Delphi forums are proprietary and are available only on their website. I understand it has no official way to export a Delphi forum. A board there has twenty years of conversations they did not want to lose. A clever user though has figured out how to export the board using YAML.
Example of YAML file for importing
After looking at it, I figured it was cost prohibitive to do. I did a proof of concept for them, demonstrating that I could read the YAML file and get basic user, forum, topic and post information from it, and display it neatly in HTML. I explained that this would be custom work and that it would take a lot of labor, even at my nonprofit rate. I estimated $2000 – $3000 and assumed it was cost prohibitive.
Proof of concept to display user information from YAML file
That was back in February but I was recently given the go ahead to start this project. Which raises the question: how on earth to do something like this?
What convertors from other forum solutions to phpBB that do exist tend to be for phpBB 3.0, and we’re now on phpBB 3.3. And no one has written a Delphi forums converter because it has no export capability. Since then phpBB has evolved, and due to the way post text is now encoded, it’s very challenging to write any new convertor.
Which is why I said if it can be done I would want to populate an old phpBB 2 forum with its data, and convert that to phpBB 3.3. There’s a convertor built into phpBB that does just this. But phpBB 2 became obsolete 13 years ago. However, its database is relatively simple so it should be straightforward to populate from data elsewhere.
But phpBB 2 was built for versions 4 and 5 of PHP, versions now obsolete and dangerous to use, or even acquire. It’s hard to even stand up a PHP 5 environment now. Most web hosting won’t support PHP 5, and mine doesn’t. So I’d have to roll my own development environment with PHP 5.
There are two ways to do this:
Via a virtual machine
Via a separate machine
I’ve used VitualBox on my Mac for years for standing up virtual machines. While it works, it doesn’t work well on a Mac. It’s a pain to use, particularly if you need to move files between the Mac and the VM.
Because I need PHP 5 for clients generally at least once a month, I decided a separate machine was more practical. So I bought a Raspberry Pi 4 (4GB) for less than $100. The actual machine is about $35 but I added a keyboard, mouse and a book. It took some help online to figure out how to install a web server and PHP 5 for it. The Pi is cheap because it uses RISC-based processors, so it’s not Intel compatible. Also, I could use FTP to move files to it, and using a free VNC viewer, I could work on it from my Mac desktop.
Processing the YAML turned out not to be easy. I tried various things, including PHP’s PECL YAML class, which I couldn’t get to work. I was able to eventually get Symfony’s YAML class to work.
Given the go ahead, I created a phpBB 2 board on my Pi with PHP 5.6 installed. While this worked great, my script wouldn’t run there. Symfony requires PHP 7.2. So I exported the phpBB 2 database and imported it into my Mac where I run PHP 7.4. I would have to populate the database from the YAML files I was given there, and eventually move it back to the Pi when it was time to try to upgrade the database.
Loading the phpbb_users table was not too challenging. A few fields needed to be escaped using mysqli_escape_string so the data could be loaded into the table. Some fields had to be trimmed to fit inside the maximum field length.
phpBB 2 places user data in a number of tables. Topics and posts haven’t been created yet, but there is a phpbb_user_group table. Each user had to belong to a group. Creating a test user on phpBB 2, I learned that it will create a new personal group. Then I had to write some SQL to put all 600+ users into this table. I also needed to populate a number of other columns in the phpbb_users_table. Each should have a new password, but since these users were added in bulk, they share the same password for now. All share the same bogus email address too, since I didn’t have that in the YAML. They will have to change both after the board is converted. Back in the old days, the password was encrypted with a simple md5 hash.
But the customer’s thread YAML wasn’t 100% clean. It wasn’t a major issue, but 22 threads (which amount to topics) wouldn’t parse. Even the good threads though had some issues. Some threads have no name to them. I will have to create a synthetic topic name for them. Some don’t have a forum name either, so those have to go into some sort of catch all forum.
There is a major issue is that the YAML’s attachment information provided a file upload name, but the name is not in the /files folder provided with the YAML. Files seem to have some sort of hash name. This may mean that attachments cannot be imported. If I want to import any attachments, I will have to install the old phpBB 2 attachment mod.
But at least this approach looks viable, if tedious. More learning experiences ahead.
If you recently installed or updated to phpBB 3.3.1, be aware there is a bug that affect mobile displays. It is discussed here and you can see the code changes required here.
After making the changes, make sure to purge your board’s cache: ACP > General > Purge the cache
Board administrators typically want their board’s content to rank highly in search engines. It can help attract traffic and new members. That said, for the most part your users determine your board’s content, based on what they post. So it would seem kind of pointless to make your board search engine optimization (SEO) friendly. So is SEO a lost cause and waste of time on phpBB boards?
Not really. But remember that bulletin boards are structurally different than most web content, in that the contents changes frequently as users make posts. And you can’t do much to control what users post.
Moderators can remove offensive or off-topic posts. Moderators can also change topic titles, which might help in a topic’s ranking in a search engine. Most won’t because there are too many topics to deal with, the topic poster may feel offended and there is no guarantee that a moderator’s title topic will be more SEO-friendly than the poster’s topic title.
Also, phpBB does most of the deciding for you. The <title> tag for a page is usually a mash up of the board’s name and the topic name. This is not easily changed as it’s built into phpBB’s templating system.
Most phpBB boards fill niche areas. It’s hard to find a phpBB board that discusses general politics, for example, as it is done in so many other mediums. A board that discusses classic Mickey Mouse cartoons is more likely to be a board because it’s more granular. But because it’s more granular, it’s likely to get fewer views. Consequently, I see many more boards with 10,000 posts than 1,000,000 posts. In a way, this is good. This is where phpBB excels.
If you buy my book I go into a lot more detail on SEO and phpBB, so you might want to buy it. But here are a few points you may find useful:
Your board’s title and description are the most important factor you can control to influence search engines. The board’s title appears on almost all pages. So if SEO is important, you might want to work with a SEO expert to find an optimal title for your board. This often involves trying various board title’s over time to see which one has the most impact. You can set the title in the ACP: ACP > General > Board settings. The board title is more important than the board description, which can be left blank if it adds no value.
Analyze who is using your site and what they are reading. You can’t measure what you don’t track. So if you are not tracking your board’s traffic, you should, and you should be regularly reviewing the analytics for your board. There is a Google Analytics extension for phpBB that is easily installed. You first need to create a site in Google Analytics. Enter the tracking key on the board settings page after the extension is installed. Other analytics sites will require entering HTML or Javascript code into the overall_header.html and/or overall_footer.html templates for your style. Purge the cache after making these changes for them to take effect.
Actively moderate your board. Remove clearly irrelevant or off-topic posts if you have the energy. Search engines are trying to connect searchers with answers to specific questions, so the more concise a topic is in answering a question, the higher the page is likely to rank. Ideally you will empower your moderators to do this for you. Give forum users clear guidance on the forum’s moderation criteria in a sticky post. And make sure users know how to flag off-topic or spam posts for moderator review. The icon is easy to miss on the view topic page.
Using the SEO Sitemap extension doesn’t hurt. While it won’t make your board rank higher, it does provide a definitive list of your topics and posts for search engines, hopefully ensuring all your content gets indexed.
Encourage relevant pictures. Pictures make a topic and a post more engaging, providing the pictures are relevant. so all things being equal should make the topic rank higher than similar page. Encourage your posters to add a relevant attachment comment to each picture. This markup will be studied by search engines and helps identify the picture.
I also found this article online today that you may find useful.
Tapatalk is a service that lets users interact with bulletin boards using mobile devices. Rather than going to a bulletin board with a mobile device’s browser, users can use a Tapatalk app instead.
Tapatalk’s app supports phpBB as well vBulletin, IPBoard, kunena, myBB, WoltLab, SimpleMachines and xenForo. Used with phpBB, you must install a Tapatalk extension downloaded from its website and configure it. If you have an older phpBB 3.0 board, a Tapatalk modification can be installed as well.
Tapatalk provides a common interface for accessing all these forum solutions. This makes things simpler for users if they frequent lots of forums, not all of which are phpBB, providing these forum solutions also integrate with Tapatalk.
In addition to providing a common app, more recently Tapatalk has started hosting their own forums which you can use, called Tapatalk Groups. This has some advantages: they maintain your bulletin board, and host it as well, so it’s effectively free hosting. Users use their app to interact with it. You may be able to import your phpBB bulletin board and create your own Tapatalk Group.
Tapatalk Groups have certain advantages. It’s mobile first. You can integrate donations to fund your board because it’s built into their architecture. But it will serve ads, which is how they normally monetize their service through donations. You can use its built in donations feature to help monetize your board. Spam protection is built in and some customization of the group’s look and feel is available. It’s also cloud hosted, making access very fast with extremely high uptime.
When used with phpBB, not only do you install their extension, but you must also upload a mobiquo folder to your board’s root directory. Most of the work between phpBB and Tapatalk is done by libraries in the mobiquo folder. Your users don’t have to use Tapatalk, but could access your board using a browser as well.
Tapatalk allows you to create a branded app, but they charge for this service. This allows people download your app, not a Tapatalk app per se. They would find the app in the store for their mobile operating system under your brand name. This obviously can simplify things. To access your board, people simply open your branded app.
About twenty percent of my clients have Tapatalk installed. These days, Tapatalk seems less useful. This is because phpBB is now responsive, i.e. you can use a browser on your mobile device to access phpBB and it will size down intelligently for the device’s screen size. Most styles for the old phpBB 3.0 software were not responsive, meaning boards were often be hard to read because they were scrunched down so much to fit the narrow screen width. You had to pinch to zoom in and read content in many cases.
Still, some would prefer to use an app optimized for bulletin boards rather than a mobile browser. For these people, using Tapatalk might be a preferred solution.
You won’t find Tapatalk as one of phpBB’s approved extensions. Why is this? It’s because their mobiquo library is proprietary software and works independently of phpBB’s software, so it violates its GPL-2 license. This makes it ineligible for inclusion in their list of approved extensions.
Also, the Tapatalk app provides a standard user interface, but it won’t reflect your board’s style. You can make posts, create topics and make attachments to posts, but any additional features made available through phpBB’s extensions cannot be used. So you won’t get the same experience with a Tapatalk app that you will get interacting with a web browser.
If you install the Tapatalk extension, be aware that it works outside of phpBB and may introduce problems.
A recent release of my digests extension revealed underlying problems not only in the extension, but also on guidance I’ve been giving for setting up phpBB and system crons. I can’t seem to edit the Wiki page, but I left notes on my digests extension discussion forum. I need to place them here for wider visibility. I will update the Wiki page when that technical issue is resolved.
With my digests extension, it’s generally important for digests to be mailed on time. Otherwise it depends on board traffic to send digests, which on sites with low traffic could result in significant delays in receiving digests.
There are two ways to do this in an automated way:
Create a system cron
Use a phpBB cron, but use a tool to call the board at least hourly, which kicks off phpBB’s cron process, which includes handling any scheduled outgoing digests
With a system cron, it turns out that you can’t use a semicolon to separate commands on one line in most cases. So this guidance is wrong in most cases. It all depends on the Linux shell used by the root user, which is usually bash. So when programming a cron job, to get two commands to work on one line, you need this instead:
cd /path/to/board && ./bin/phpbbcli.php cron:run
The && acts as a conditional, essentially saying that if the command to the left of the && succeeds, then issue the command to its right.
On my test board I also discovered I had to change the permissions on the /bin/phpbbcli.php program to 755, as the cron needs the execute permission, and it’s lacking with 644 permissions. This is not ideal as this introduces a potential security issue. Considering it’s just one file, I consider the security implications minor at best. With a system cron, you need to program a real cron job and tell phpBB to not use its built in cron based on board traffic: ACP > General > Server settings > Server settings > Run periodic tasks from system cron > Yes
If you want to use phpBB’s built in cron, you need to call it at least hourly and create a cron using curl, wget or lynx to hit your phpBB board as if it were a browser. If you follow the Wiki approach it causes a HTTP redirect, which basically causes it to fail. So the cron should look more like this (all on one line):
