User:TerryE/phpBB3.0.7 Upgrade/Closed Issues and Actions

The Core Build

This work is now complete and all databases migrated to 3.0.7.

Code Base

• The core phpBB code base from phpBB 3.0.7 Download
• The following language packs from phpBB 3.0.x Languages repository. These are maintained in the site /files/language_packs_30x/ sub-directory

Language	Language files	Prosilver GIFs
English (U.K.)	(built-in)	(built-in)
English (U.S.)	lang_en_us.tar.gz	prosilver_en_us.tar.gz
French	lang_fr.tar.gz	prosilver_fr.tar.gz
Catalan	lang_ca.tar.gz	prosilver_ca.tar.gz
Catalan (Valencian)	lang_ca_pv.tar.gz	prosilver_ca_pv.tar.gz
Dutch	lang_nl.tar.gz	prosilver_nl.tar.gz
Hungarian	lang_hu.tar.gz	prosilver_hu.tar.gz
Italian	lang_it.tar.gz	prosilver_it.tar.gz
Japanese	lang_ja.tar.gz	prosilver_ja.tar.gz
Mandarin Chinese (Traditional script)	lang_zh_cmn_hant.tar.gz	prosilver_zh_cmn_hant.tar.gz
Mandarin Chinese (Simplified script)	lang_zh_cmn_hans.tar.gz	prosilver_zh_cmn_hans.tar.gz
Polish	lang_pl.tar.gz	prosilver_pl.tar.gz
Spanish	lang_es.tar.gz	prosilver_es.tar.gz
Spanish (Argentina)	lang_es_ar.tar.gz	prosilver_es_ar.tar.gz
Vietnamese	lang_vi.tar.gz	prosilver_vi.tar.gz

I've pulled these down to a kits directory from the phpBB server.

for co in ca ca_pv en_us es es_ar fr hu it ja nl pl vi zh_cmn_hant zh_cmn_hans; do
  wget http://www.phpbb.com/files/language_packs_30x/lang_$co.tar.gz
  wget http://www.phpbb.com/files/language_packs_30x/prosilver_$co.tar.gz
done

On top of this I also have two tarballs and one custom module for my OOo specific additions:

• OOoImages.tar.bz2 which includes the extra avatar libraries, smileys etc. used on the forums.
• OOoProsilver.tar.bz2 which includes the forum logos for each of the NL forums and Oracle GIFs.
• acm_mysqli.php a module which uses MySQL to implement the phpBB cache.

Forum Customisation

The following customisations have been carried over from Version 3.0.5, and the patch file which applies these changes has been regressed from the 3.0.5 code base to the 3.0.7 code base:

1. Reorder window title to make multi-tab title more usable. All browser tabs are labelled with their title. The phpBB3 default is to begin the title with the forum name then page category, hence if you have a lot of tabs open they are called openOffi... By putting the specific title first, it makes it a lot easier to pick the correct tab.

   viewforum.php, viewtopic.php

2. Add Expand option to Code Block. phpBB3 now puts each code block in a scrollable window. This makes it a pain if you want to see all of the code in the browser. This mod adds an Expand option to the code block to allow you to blow it up to full size.

   template/bbcode.html, template/forum_fn.js, theme/content.css, theme/bidi.css

3. Tweak Access key codes to remove conflicts. For those that use keyboard accelerators within the browser, the lack of a shortcut for Preview Post is a pain. This makes <Accel>+P a shortcut for Preview and <Accel>+G a shortcut for graphics.

   template/posting_buttons.html, template/index_body.html, template/posting_editor.html

4. Add Active Post count to View Active Topics. This just adds a count of new posts in the Active topics heading.

   index.php

5. Add truncated title of last topic to Forum View. Lots of OOo volunteers asked for this one. It enables you to recognise at a glance if a forum has any new posts in it.

   includes/functions_display.php, template/forumlist_body.html

6. Customise Headers and Footers to OpenOffice.org branding. Add OOo Community logo and adjust framing colours to match. Add OOo favicon.

   includes/functions.php, template/overall_footer.html, template/overall_header.html, theme/colours.css, theme/bidi.css, theme/common.css, XX/common.php

7. Add OpenOffice.org Qs to BB FAQ. The FAQ button goes to a phpBB3 standard FAQ which is all about using phpBB3. I've added a Q0 which points the user to the wiki and forum FAQs for openOffice.org info.

   en/help_faq.php

8. Add instruction to “read Survival Guide before posting” to post form. The posting form now includes an instruction to read the survival guide before you post. (This is only shown if you have less than 15 posts).

   posting.php, template/posting_layout.html, XX/common.php

9. Optional Mandatory Subject on Registration. This is a customisation which was introduced in the French forum, and we have now rolled this out across all forums.

   includes/functions_user.php, includes/ucp/ucp_register.php, template/ucp_register.html, XX/common.php

10. Change move topic default. This no longer leaves a shadow topic by default.

    template/mcp_move.html

11. Add Poster's warning count for moderators. This was a specific request from the FR moderators. If a poster has outstanding warnings then moderators will see his/her warning count in the post heading column.

    template/viewtopic_body.html

12. Allow Cron to be run as batch script. This allows cron jobs to be scheduled using a cron script.

    cron.php

13. Runtime optimisations. This is replace the file based caching with SQL caching.

    includes/acm/acm_memory.php

14. Miscellaneous OOo configuration. The batch equivalent of the interactive phpBB setup.

    config.php, install/database_update.php, fr/mcp.php, fr/acp/common.php

15. Customisations that are configurable through phpBB. These don't need code or style changes:
    • Add custom fields to define users, main OS, installed OOo version and supplementary OSs.
    • Add additional BBcodes for [edit], [pre], [strike], [center], [sub], [super], [hr]

Note that the XX above refers to all 15 language variants ca, etc.

The build process

This is a modified rerun of what I did for the 3.0.4 and 3.0.5 upgrades. I use a VirtualBox/ customised LAMP VM appliance based on Ubuntu JeOS. OK, this is Linux rather than Solaris, but in terms of the AMP stack elements it is functionally the same, and contains a full copy of the live database. I build and dress rehearse the 3.0.7 build and 3.0.5 → 3.0.7 upgrade on this. I then move and blow the complete 307 tarball into the live system and repeat the 3.0.5 → 3.0.7 upgrade live. (I prefer to do it this say since I prefer the Linux utilities and the gnu extensions to diff, patch, etc.)

The painful bit in all this is regressing the 3.0.5 patch file to the 3.0.7 code base as this is a largely manual activity, but once this has been done I have scripted the various steps to automate the build. These are pretty simple and self-explanatory so I won't go into details here. However, I have changed the installation in line with the Debian standard of phpBB:

• The phpBB install is now homed in /var/lib/phpBB with two separate sub-directories for each version, e.g. ref307 and com307. The first of these is an "out of the box" phpBB install with no modifications. The second is the OOo customised install. OK, this incurs a 20Mb overhead, but this is a very simple method of tracking any uncontrolled changes in prod as diffing the refXXX and comXXX will throw these up.
• All templates and code are designed to be mappable into all code bases.
• Each of the forums is contained within its own directory hierarchy under the Apache root directory /var/www, so the English instance is under /var/www/en in the /var/www/en/forum directory root.
• Within each forum, the relevant PHP files and directories are symlinked across to the corresponding files or directory in the /var/lib/phpBB/com307 hierarchy. In general, directory symlinks are used, but due to a quirk of the phpBB implementation, each module picks up the root path of the phpBB install from the directory of the invoked module, so the English forum's View Topic module must be /var/www/en/forum/viewtopic.php and this is a symlink to /var/lib/phpBB/com307/viewtopic.php, and so on.
• Whilst this may seem a convolved and inefficient, remember that all of the PHP code is cached through APC. APC is symlink aware, and therefore treats all of the copies of viewtopic.php as the same cached item /var/lib/phpBB/com307/viewtopic.php, etc., so this symlinking is crucial to good cache performance when running ten separate language instances.
• I have a simple script maps the necessary symlinks from this directory hierarchy to the common production directory, that is /var/lib/phpBB/com307 for version 3.0.7.

The scripts does this rehook only takes a split second. The main time delay is the phpBB script to upgrade the databases from the 3.0.5 schema to the 3.0.7 schema and this only takes seconds to run for all databases except the EN and FR ones, with these taking ~90sec. So the whole upgrade for a given language instance can, in practice, be carried without a scheduled service drop.

Oracle Branding

Now that Oracle has acquired Sun, some of the Sun Footer logos have been replaced with Oracle branding ones. I will sort this out as part of this upgrade. I've done this earlier by request of Clayton.

Automated Unactivated Users Prune

This is another batch script that I have developed to automate a tedious twice weekly task. There were two approaches to this one:

• Use a screen-scrape approach. This is what I've done in the Mailbox robot. Though in this case it would involve interrogating the ACP->Inactive User form after going through ACP authentication.

• Use a dedicated minimal housekeeping function. This would be board-specific piece of PHP code somewhat similar to the pseudo cron task coding. It would take no parameters as the algo would be fixed and autolog-on.

There are pros and cons to both approaches. Programmaticly accessing ACP functions especially without authentication just involved too much effort, so I fell back to my old python based screen-scrape approach for carrying out the updates themselves since this also ensures that necessary audit is carried out. This involved:

1. Establish an authenticated session context through http://localhost/XX/forum/ucp.php?mode=login and screen scraped response. The session is then hoisted the session to ACP access, via direct database update (a lot easier than doing this via screen-scrape).
2. Enumerating the inactive users through http://localhost/XX/forum/adm/index.php?i=inactive&sid=SIDa&mode=list&start=0 to acquire form credentials for delete request.
3. Interogate D/B to get list of users to delete.
4. Reply to inactive form with list of users to delete.
5. Confirm deletion and log-out.