HTML Logo by World Wide Web Consortium ( Click to learn more about our commitment to accessibility and standards.

Moving forward with Composr

ocPortal has been relaunched as Composr CMS. ocPortal 9 is superseded by Composr 10.

Head over to for our new site, and to our migration roadmap. Existing ocPortal member accounts have been mirrored.

Reporting emergency problems

There are no pages beneath this page

Submitted by Chris Graham
This document describes how to report emergency problems.

It is about:
  • emergency events that have substantially and suddenly taken down your website
  • …legitimate bugs or undocumented major usability problems that could serious trip regular users up

It is not about:
  • general bugs in functionality
  • problems with your hosting, e.g. databases suddenly corrupting

If you have a major problem that you believe to have been caused by an ocPortal bug, you can open a free bug report support ticket. The staff will respond appropriately (although if it is a problem with your computer's software or hosting, they may say so and not be able to tackle as an ocPortal bug report).

It is important that you help the staff help you. Remember that no staff are not employed 24x7 to manage your bug reports, they have to fit it in within their working hours, and it is a secondary job to what pays the bills. You need to make it really easy for them to jump in to fix the problem, the first time they open the ticket. The staff will not want to:
  • negotiate for the access needed to fix the problem
  • have a protracted back-and-forth over hours or days
  • have to schedule processing of the ticket
  • have to keep requesting additional information
In short: provide the access they need to solve the problem immediately when they open the ticket for the first time, i.e. FTP or control panel access. Ideally, the staff should be able to look at your ticket, have the access they need to resolve the problem immediately, resolve it there and then, and then simply be able to tell you it has been resolved.

Don't make the staff have to do detective work just to extra crucial information from you. Explain the exact situation and anything pertinent. For example, if it is a problem upgrading, describe the exact process you used to upgrade, what you upgraded from, and what you upgraded to.

In return, the staff will try their best to ensure unintended glitches don't cause you unnecessarily pain. They have a very strong track record for this.

Specifically for upgrading, the developers do advise taking backups as part of the upgrade process. If you did have a problem upgrading, the best process you could follow would be:
  1. Take a backup
  2. Do an upgrade
  3. (Find it went wrong)
  4. Move the current site into a temporary directory (e.g. "failed_upgrade"), and rename the database (e.g. "failed_upgrade")
  5. Restore the backup to its original directory and database
  6. Open a support ticket explaining the problem, and providing access to the temporary site
  7. (The staff would then quickly resolve)

Bear in mind that the primary defence to something suddenly going wrong with your site is to take backups, and know how to restore them (having practised it at least once). The staff are committed to ensuring ocPortal's stability as a product, but bug fixing is not a free concierge service that puts the responsibility for your site onto the staff's shoulders. The staff can provide this kind of service via commercial support, but not via free bug fixing.
CEDI change-log Post