This is the next release candidate for the extension. It has a couple of new features. See this post for more details.
Updated October 13, 2019 to mention that the phpbb_migrations table is always changed with an update.
When updating phpBB, you should backup your database. That’s the guidance given by the phpBB Group. Updates occur when you are moving from one micro version of phpBB to another, say 3.2.6 to 3.2.7. When moving from minor versions, like 3.1 to 3.2, you are doing an upgrade and different procedures apply.
It’s never a bad idea to backup your database. It can be done manually in phpBB: ACP > Maintenance > Backup. This method though is not foolproof. Particularly on larger forums or on shared hosting, backups can time out. Sometimes you think you have a complete backup and you don’t. The only way to know for sure is to download it, and examine it in an editor. If the bottom of the file shows the phpbb_zebra table is being populated and ends with a semicolon, it should be complete. Web hosts often offer features that make automatic database and file backups for you.
But it turns out that when making updates, generally not much of your forum’s database actually changes. Only two tables are guaranteed to change: phpbb_config and phpbb_migrations. (I use phpbb_ as your table prefix. Yours may be different. You can see your actual table prefix in your forum’s config.php file.) This is because phpBB always tracks the current version of phpBB installed, and it is stored as a row in the phpbb_config table. And with each update, one or more rows are added to the phpbb_migrations table to indicate what migrations were made.
Most updates don’t affect many tables. In fact, it’s typical that only the phpbb_config and phpbb_migration tables are affected.
So there is no point in making a full backup of your database prior to updating if you don’t need to. It’s a real hassle on larger forums.
It turns out that if you look through phpBB’s code you can figure out which tables are updated. The /phpbb/db/migration folder contains a number of subfolders. The programs in these subfolders do the work of changing your database during updates.
For example, there is a v320 folder. This contains the migration programs used to bring phpBB up to version 3.2.0.
There is also a v32x folder. This contains the migration programs used for each version update of phpBB 3.2. You can infer from the file names which these are. For example, v321.php and v321rc1.php are used to update from phpBB 3.2.0 to 3.2.1. “rc” in the file name means “release candidate”. There is typically at least one release candidate before an official release. So it’s a matter of reading these programs to see what tables are actually affected.
That’s what I did, and you can see the results on my Do I need to update page. Or you can examine them yourself. I’ll keep the update page updated as new micro releases occur. You might want to bookmark it and refer to it before doing your own update.
If you do it yourself, follow the official procedures on phpBB’s update page. But you may decide to backup only the tables that are actually changed to save yourself extra hassle. If an error occurs, restore these tables and recover your files.
The first half of the month was slow, the second half medium busy. After the very busy months of June and July, I didn’t mind that things slowed down. Some of the work was a continuation of work not quite completed in July:
- Here was more work for a client mentioned in my July report. This was a large rehosting effort off of Microsoft servers to Linux for a client in Australia
- August 1. I answered various questions, investigated DNS settings for client’s domains, and moved files for a dormant domain from Windows to Linux. I created database user “root” on the Windows MySQL database so his web host could create a successful extract of this database, which I couldn’t do with their control panel. It seemed strange the host couldn’t figure this out or chose not to, and I had to do it just to get the database exported.
- August 2. I discovered one of the client’s domains was blacklisted. I recommended remediation procedures. I moved the database for a Wiki based on Windows technology from Windows to Linux hosting, and placed in a .sql.gz extract of the database in a specified folder so it could be created later when the client chooses to take this up as a project.
- August 3. I created a scheduled task (cron) to run every five minutes to use with the forum to send out board emails. The limiting factor here is that the web host’s policy is to not allow more than 200 emails per hour outgoing per domain, so a scheduled cron in phpBB was needed. To do this I set the email package size to 16 with the cron to be invoked every five minutes. This got it under 200 emails per hour quota for domain. I also changed the queue_interval in database to 300 so phpBB crons would not run more often than every 5 minutes, to avoid going over quota. Created a test.php email program to help with troubleshooting emails.
- August 4. I tested emailing using contact form. The email was received but appeared to be sent outside of normal email queue. I found and looked at queue.php in the /cache/production folder and discovered emails were being, albeit sent slowly and there were several thousand email notifications in the queue that would take a couple of days to clear. I changed the cron (which used curl) to use www in the URL to call to avoid HTTP 301 messages.
- August 5 and 6. Provided additional guidance and answered questions.
- Styling work on new forum. Trying to get a logo to meet with width of the content (used CSS cover attribute) but leaving a proportional amount of vertical whitespace. I couldn’t figure out a way to do it with CSS, so wrote a little jQuery code to do it tied to window resize and page loading events. Glad to figure this out. This required advanced skills I rarely get to use and which I suspect are beyond most web developers.
- Troubleshooting. The forum was not sending emails. I noted messages in phpBB error log saying “Email message was blank”. I tried a number of things, but eventually determined that if the SiteSplat BBCore extension was disabled it wasn’t an issue, so the issue had to be somewhere inside the extension. The latest version of that style and its extension was installed. It’s possible a newer version of the extension will fix the issue. I suggested client talk with SiteSplat’s technical support to see if it’s been addressed and to update style plus extensions if there is a fix. Otherwise they have the ability to reproduce the issue. There is a user interface for the style. The client eventually figured out the if the Minify HTML setting for the style was checked, then allowed emails to go out. This is still a bug with the extension.
- This was a multistep project, still not completely finished. A domain had two phpBB forums, one an old legacy phpBB2 forum, the other a phpBB 3.0.11 forum. Server upgrades were making upgrading both of these to phpBB 3.2 important.
- In the first phase, I converted forum from phpBB 2.0.19 to phpBB 3.2.7. There were 548,000 posts that had to be converted. Placed in new folder for analysis, old forum is still in the original folder so it could be used. I recreated the search index. No issues during the conversion, but it was tedious taking about three hours overall. I disabled the contact form and new registrations, added a home link and installed PRO_UBUNTU LUCID style. This parent style was to be tweaked with additional styling changes to be used on both forums.
- Had a conversation on the phone to discuss styling requirements. I ended up doing 4.5 hours of styling work, including adding a banner, logo, moving site title and description, changing column for profiles in view topic, adding a line with links under the navigation bar, etc. Later, I did more styling work based on refined requirements.
- With the styling changes done, I upgraded the main forum from phpBB 3.0.11 to 3.2.7. I had to empty the phpbb_modules table and repopulate it from a 3.0.14 reference because nonstandard changes had been made to the ACP interface that triggered an error during the upgrade. Once I did that, the upgrade completed. I replicated the styling and extensions on the converted old forum. I changed the not logged in message, which is different on the active forum. I disabled the contact form. I set up and enabled the reCaptcha V2 spambot countermeasure. I moved the old converted phpBB 2 forum to its proper folder and moved the unconverted forum to a new space for the time being. I provided guidance on upgrading PHP to 7.2 and files and databases that can be deleted. There is at least one loose end on this work: a third-party program failed because with the move to phpBB 3.2, the old coding standards fail in the new environment. User may opt not to have me fix this program.
- I did some online tutoring on new forum that needed to be set up properly. I answered lots of questions, mostly related to permissions and moderation, roles and such, and how to configure phpBB correctly. I did ninety minutes of tutoring in total.
- I upgraded a forum from phpBB 3.1.10 to 3.2.7. The forum has 17,000 posts. I updated the following extensions: 24 hour activity stats, Lightbox, LMDI Delete Re:, Profile side switcher and Media Embed. Installed updated Lucid Lime style and reapplied style changes. I updated the German language pack. Noticed that an invalid SSL certificate needed updating. PHP should go from 5.6 to 7.2 when client is ready. I encountered HTTP 500 errors related to extension name changes in the file structure.
- A forum was rehosted but database was not loaded, so basically I was asked to stand it up again. I loaded the database from a database extract provided. The forum is a phpBB 3.0.11 board in a PHP 7.2 environment. I had to step PHP to version 5.6 to get it to come up. I added two statements to config.php so that mb_string support would work, and enabled mysqli so it would work when the forum is upgraded and moved to PHP 7.2. I recommended upgrading of forum to phpBB 3.2.7.