Changing phpBB’s default language for all users

This post was updated 13 Feb 2018 to bring it up to date.

When you install phpBB, it installs the default British English language pack. It’s possible to install additional language packs for your users. They can be downloaded here. Instructions for installing a language pack are here.

Users can switch to the language pack they prefer in the User Control Panel. The last link demonstrates how users can do this. The language pack changes phpBB’s default text. It does not change the language of posts and private messages.

Particularly after an upgrade or conversion, you may be left with hundreds of users who used to use a different language pack but now must use the British English language pack. Suppose you want to change it so that all users are using a different language pack. Is this possible?

Yes, there are two ways of doing this:

Delete British English Language Pack so a new default language pack can be used

This approach assumes you have already loaded the new language pack and enabled it. It also assumes aside from British English you only have one other language pack installed. Warnings:

  • Make sure the language pack is up to date for your version of phpBB. You can download current language packs here.
  • Make sure the language pack contains language settings for the Administration Control Panel. You can examine the archive or check it on your file system after it is installed. Look for a /language/<lang_code>/acp folder
  • The British English language pack is not physically removed if you use this approach, it is just disabled.

Here are the steps:

  1. ACP > General > Board configuration > Board settings
  2. Change the default language from British English and press Submit
  3. ACP > Customise > Language Management > Language Packs
  4. Delete the British English language pack.

This makes the other language pack the default for all users. If you need to reenable the British English language pack do it on the Language Packs page by clicking on the Installer link.

Keep the British English Language Pack as the default and change users’ languages on the back end

You can manipulate the database using a tool like phpMyAdmin you can change it with a database SQL command.

  1. Look for a database manipulation tool like phpMyAdmin in your web host control panel and open it. Sometimes you will get a pop up window asking for a username and password. If this happens use the database username and database password in the config.php in your forum’s root directory.
  2. Select your forum’s database. You can also see the database name and the machine the database is on (the machine is usually localhost, or the server you are using) in the forum’s config.php file.
  3. Your table prefix may not be phpbb_. The forum’s config.php file will indicate if another table prefix is used.
  4. Verify the language code you need. Use a tool like phpMyAdmin to browse the phpbb_lang table. Make note of the value in the lang_iso column for the row containing the preferred language. In this example, I will assume French, which uses the fr language code.
  5. Now enter the the database command (SQL). In phpMyAdmin this is done by clicking on the SQL tab for a table in your forum’s database. Change the table name to use your correct table prefix if necessary. Also make sure the language code you use is correct based on what you saw in step 4 and change as necessary:
UPDATE phpbb_users SET user_lang = 'fr'
  1. Execute the query.
  2. Now go into phpBB and purge the cache.

That’s it!

Another Aabaco (Yahoo) Small Business hosting rant

Getting clients off Aabaco (formally Yahoo small business) web hosting is becoming something of a specialty of mine. Today I finished a three day job involving moving a client’s phpBB 2 forum off of Aabaco to a new host and a new domain. (See previous post on Aabaco.)

Earlier in the year I was finally successful getting a client’s data off of Aabaco web hosting. Mainly I was stymied by getting a copy of the database since the binaries Aabaco provides are not portable or usable. I couldn’t make a backup in phpBB 2. The functionality is there, but unless you have the tiniest forum you can’t make a backup because it times out.

So that leaves trying to get a backup using phpMyAdmin, which is installed on Aabaco sites but of course it’s a dreadfully old version. Same problem there. Any table of sufficient size (like the phpbb_posts table) you can’t export because of a web hosting timeout. Earlier in the year though I finally figured out a way to get an export. It involved taking slices of large tables and exporting that, say 10,000 rows at a time. To say the least it is tedious. You have to write your SQL very carefully. The option to export a slice of the table is there, but not obvious. Once you download it though, you need to check it. Is it complete? For each file I used the Unix tail command. Each SQL statement in the export should end in a semicolon. If you are missing a semicolon at the end of the export then, no, that slice is not complete. So you make smaller slices but with persistence, care and a great deal of tedium it can be done.

Moving the files turned out to be another issue. Last time I was successful because FTP worked. This time it didn’t. A query to their customer care line provided instructions that didn’t work. I think it’s part of a deliberate strategy. If you can’t get your files off of their site, how can you move it? You are a customer for life. The files that mattered were images, most for the attachment mod for phpBB 2. It seemed like a lost cause and given that there were 7900 images, downloading them one at a time with their file manager was not an option. (Of course their file manager is not intelligent enough to allow you to choose multiple files for downloading!)

Necessity turned out to be the mother of invention. I was able to write a short PHP program to at least list the images and output them to the screen. I had to write it using their file manager. With a list of files I could cut and paste this into a program I wrote on my local machine. No FTP? No problem as I could grab the file with HTTP if I knew what the file names were, which I now had. I used PHP’s curl library and some file commands to fetch them one at a time and store them on my local machine.

So with many hours of effort I was able to grab all the images and populate a local database on my machine from the Aabaco database. I had to dig for a copy of phpBB 2 to set up the file structure the phpBB conversion program expected. I created a phpBB 3.2 instance and eventually succeeded in converting it. (I had to fix a few data issues with the database.) And I was able to upload files and database to the new host. It was quite a challenging job but getting off Aabaco is possible, just costly for this particular client.

I have to laugh though. Looking at phpMyAdmin I could get a sense of how “current” their infrastructure is:

  • MySQL version 4.1.4 – released August 31, 2004. (It used MySQL client version 3.23.49, even older!)
  • phpMyAdmin 2.1.19 – released August 28, 2008

All this plus no hidden files allowed! Moreover we were delayed for a while because the phpbb_sessions table had to be repaired. The client told me it happens regularly. Yes on very old machines with problematic disk heads, I’m not surprised that all these reads and writes means this table has to be regularly repaired, by hand of course.

If you absolutely must get your forum off Aabaco web hosting however, you might want to contact me. Given the effort involved though I’m sorry to say it won’t be fast, cheap or easy.

Digests 3.2.4 (RC11) released

Finally, a new release of digests! What was the hold up? Busy doing other things, vacations, but also it’s very hard to test all the permutations and to fix bugs that manifest only in cron modes. Such bugs must be tracked down by sending messages to the Admin log through debug statements. Very tedious!

As for what’s new, really except for closing bugs there is no new functionality. It should be more stable and reliable. You can download the archive on my Digests page or on GitHub. If upgrading, make sure to follow standard procedures. The first post of the digests topic provides a lot of guidance.

Change log:

New features

  • None

Major bugs fixed

  • Fixed bug in mailer that incorrectly reported the hour that was run using 12 hour format (0-12) instead of 24 hour format (0-24), leading to false log entries such as hour 1 could actually have been hour 13
  • Fixed bad positional parameters in the DIGESTS_DISCLAIMER language variable, fix from petr-hendl pull request (thanks)
  • Fixed bug that creates a user timezone object if it does not exist. In cron mode sometimes it was not present or deallocated. It is needed to make dates and hours print out in a language independent fashion.

Minor bugs fixed

  • All hours and time zone offsets are cast as floats since time zones are not necessarily offset by an integer from UTC.
  • Default text for maximum display words in the ACP is no longer the same as what is in the UCP. Needed to revert to the previous language string because -1 in this value will show full display text by default.
  • Language string LOG_CONFIG_DIGESTS_HOUR_RUN uses positional parameters, fix from petr-hendl pull request (thanks)
  • When digests are run manually they are no longer stopped if it’s been less than an hour since a digests was sent to the same user
  • Fixed certain admin log entries that were added even if the logging option was turned off

Tweaks and improvements

  • New check_send_hour helper function reduces duplicative code and centralizes all send hour offset logic
  • PHP and template variables with gmt in the name are changed to utc
  • <br /> changed to <br> when used inside of variables and expressions
  • <hr /> tags in templates changed to <hr> when used inside of variables and expressions
  • Constants are used to identify the mode the mailer is running (manual, regular and phpbb), makes code easier to read
  • Function validateDate renamed validate_date for consistency
  • Pretty quotes &rsquo;, &ldquo; and &rdquo; in language strings since this was an issue flagged by the extension review team while reviewing my Smartfeed extension
  • Removed language string LOG_CONFIG_DIGESTS_DIRECTORY_CREATE_ERROR (no longer needed because this error is not easily trapped in ext.php)
  • digests_html.txt uses new .newline class which makes it less likely digests will look odd, from petr-hendl pull request (thanks)
  • Version check checks a new file specific to phpBB 3.2 releases
  • Logic for creating and removing a /cache/phpbbservices/digests folder moved into ext.php from /cron/task/digests.php where it logically belongs as it should happen when the extension is installed
  • Constructor for digests class is fully documented
  • Moved board disabled check (which keeps digests from going out when the board is disabled) into the should_run function of the cron
  • Made the logic in the run function of the mailer less complicated
  • Since largely the same code was used to create attachment markup for both posts and private messages, moved it into a function
  • Log date format shows two digit months, days and hours


July 2017 work summary

The phpBB Group released a new version of phpBB, 3.2.1 in July. For me and a number of my clients updating and upgrading to it has been nothing but trouble. In two cases I was simply unable to get the upgrade/update to work on their machines. Both the automatic update and the changed files methods didn’t work. When I’ve had success it was from copying upĀ all the files (minus the config.php file) and then running the update. This can mess up any style changes that were made, so they have to be reapplied. Notes on these upgrades are below. Work in general was slow in July and due to the upgrade issue time consuming and not very profitable. I hope the phpBB Group gets this figured out. As usual all client information has be anonymized.

  • A client that sent me $50 in February finally asked me to do some work. He tried to upgrade to phpBB 3.1.10 and failed. I helped straightening out issues with his site after his upgrade. There were module errors (caused by a duplicate extension tab) that required replacing the content of the modules table with content from a reference database. After trial and error I also reinstalled Tapatalk. I then reinstalled the BOOTS proprietary style.
  • Client failed installing my digests extension (3.2.2). An error said the ACP digest module category already existed, which was most likely a result of not installing it correctly. I removed the digests modules from modules table, uploaded digests version 3.2.3 and it installed. I made corrections to address timezone object bug. Testing however revealed issues. Digests were going out for periods months in the past as the extension had not been working for many months. Resetting the digest mailer didn’t work, or changing the last timestamp for digests going out to the current time. So there was a large queue to get through. Also the digest cron seemed to work when digests are disabled. This condition was not detected before and should not happen due to the extension architecture. Some sort of cron seems to be triggered on the forum once a minute causing digests to go out.
  • Troubleshooting. Alleged malware, not in the forum (I checked forum software against a reference) but found in site’s index.htm file, at the bottom. Removed <div> tag on the page, started a rescan and sent a support ticket to Siteground to unblock the site.
  • Client had a new version of the black style he wanted installed to fix an annoying issues with the navigation dropdowns, which were shown by default overlaying content for the first post in a topic. Moved the old version to an old_black folder. Placed new version of style in the black folder. Reuploaded the two logo files. Since it is a SCCS style, I edited _style_config.sccs to hide the forum sitename text. Recompiled style by first downloading Artodia’s SCCS compiler and using that to recompile the style. Made some minor stylesheet edits to not show the navigation dropdown by default, which took a lot of testing using the browser’s object inspector to figure out what CSS changes were needed.
  • Moved a website plus its forum to a new host. phpBB was performing oddly on old host. Moved to on my recommendation. There were lots of files to move. Unclear for awhile which files to move. HTTP authentication was set to get into forum, so the mechanism had to be recreated on the new host. Changed absolute path to .htpasswd file but it didn’t work. It resulted in HTTP 404 (not found) errors. Eventually after futile tech support chat I figured out it was due to PHP not being enabled. Enabled PHP 7.0 and it worked. Client asked me to install extensions I thought would be useful so installed Advanced BBCode, Precise Similar Topics and Recent topics extensions.
  • Updated forum from phpBB 3.2.0 to 3.2.1. Discovered an apparent bug in the update program, as I had to delete vendor folder, upload 3.2.1 source for the folder, delete cache/production and then I could run the database update.
  • Updated forum from phpBB 3.2.0 to 3.2.1. Expected errors occurred when uploading only changed files so I uploaded all files, purged the cache and the upgrade worked. This approach meant I had to reapply the logo.
  • Attempted to upgraded forum from 3.0.12 to 3.2.1. There were issues during upgrade, essentially and inconsistent database. Cleaning up the database with Support Toolkit (STK) caused a STK error. I eventually figured out the STK error was due to language file common.php not being in the en folder. Upgraded to 3.0.14, then 3.1.7-PL1 (could not get into ACP), then 3.2.1. Applied flat style and logo. The upgrade seemed to work, at least for me, but failed for the client the next day during multiuser use. The failures produced core dumps, but the local system administrator could not determine the exact issue. This is still ongoing. I suspect there are new things about phpBB 3.2 that won’t work on the current host that are causing the issue. I suspect he could upgrade to 3.1.11 successfully.
  • Ultimately failed attempt to upgrade plain vanilla forum on GoDaddy hosting from phpBB 3.1.10 to 3.2.1. Issue was during updating the database. A “No file input” error message was traced to incompatibility between FastCGI or nginx and the Symphony2 library. Symphony2 could not see the file. Attempted to use SSH to upgrade the database. Issue for me was I could not connect reliably with SSH over my Comcast connection. Apparently Comcast routers slow down SSH traffic, at least to GoDaddy and there’s nothing I can do about it! Client was able to SSH successfully and tried to run a manual database upgrade. He tried various versions of PHP and couldn’t find PHP 5.4+. So restored 3.1.10 forum and provided guidance for future. When GoDaddy contract is up client may rehost elsewhere. He is considering Siteground.
  • Applied a new logo on a phpBB 3.0.13-PL1 forum. Turned off mChat.
  • Updated a client from phpBB 3.2.0 to 3.2.1 but it would only work by uploading all the files for 3.2.1. This messed up his styles which inherited from prosilver. Reapplied the file changes as best I could, however the icons and row heights look a bit off. However, the client was satisfied.