ocPortal Tutorial: Manually editing your database with phpMyAdmin

Written by Chris Graham, ocProducts

ocPortal stores most of its data in a database, as almost all web applications do. This allows it to efficiently read and write data to a predefined structure, without requiring complex customised file formats to do so.

If something goes wrong with ocPortal/mySQL/the-server that leaves your database in a corrupted/intermediate state, you may need to manually edit the database contents to resolve the problem. Note that it is very rare for this to occur, as ocPortal is designed to be fault tolerant in common situations, but it can never fully protect against all situations such as those that might be triggered by a power-cut at a critical time, or a faulty disk.

Table of contents

ocPortal Tutorial: Manually editing your database with phpMyAdmin

phpMyAdmin

phpMyAdmin as found in the Plesk hosting control panel

mySQL is designed as a lightweight database system, not as a full database management system (DBMS). As a result, and as a result of you not being likely to be sitting in front of the server, you will need a tool to perform database management remotely. Most web-hosts provide control panel systems to do account management, and these almost always include the 'phpMyAdmin' tool. It is beyond the scope of this tutorial to explain how to enter it, but it is usually linked to on the configuration page for a mySQL database, and on Plesk the link is re-titled as 'DB WebAdmin'.

phpMyAdmin is powerful web application for managing databases and database contents.

Corrupted databases

Repairing tables

mySQL has an unfortunate tendency to corrupt when a server crashes, or is stopped abruptly. ocPortal does provide an interface to the repair mechanism as an option in the caches module of the Admin Zone, but if corruption is bad, you may not be able to reach it. In this case, you will need to use phpMyAdmin, as shown in the screen-shot.

Note that if it looks like corruption has happened due to a physical disk problem, then it is absolutely crucial you back up ocPortal (and anything else on the server) as soon as humanely possible and make sure the server gets a disk scan, and it necessary, a new hard disk. Disk issues tend to spread, and files that touch the damaged area are 'scarred': an initially small problem could quickly irreparably destroy all your data. ocProducts can not accept any responsibility for repairing problems resulting from hardware issues.

Browsing the database

Choosing a table to edit rows of

Databases consist of:

tables
rows
fields

Choosing a row to edit

A table is basically defined by a name, and the fields it contains. That table then contains many rows that specify data for each of the table fields. Databases have a special concept of a row field-value being NULL; a NULL value might indicate many things, such as:

an unknown value
a non-calculated value
N/A

NULL does not, however, indicate a blank string.

Editing a row

All tables have a 'key' that allows the unique identification of any row without having to know the whole contents of that row. Usually keys are just unique numbers (ID's) assigned to rows automatically. Some people advocate choosing keys from data, but this presents problems if the data that makes up the key needs to change; for example, a username could be used as a key to a member table, but if the username was changed, ocPortal would need to changing potentially 1000's of references.
To find the ID for some ocPortal content, the best way is usually to find an ocPortal URL that points to a page that is set to view or edit that ID; the ID will be included as a part of the URL.
For example, in the URL "index.php?page=news&type=view&id=30", the ID is 30. By convention, when IDs like this are being used as keys, they are always given the field name 'id' in the database.

phpMyAdmin supports very user friendly features to browse the database tables, and to make changes. To browse a table, click the table icon to the left of the table names in the left hand frame, you can then browse and sort the table contents, and select rows for modification.

Running queries

Choosing to execute an SQL query

A query is a command, or a question, sent to a database in a special language called 'SQL' (which informally is interpreted as 'structured query language').

To run a query, you need to click the 'SQL' tab once you have chosen a database to view/edit. You then type in the query. In phpMyAdmin, it is often easier to use the interface to make changes, rather than working out what query to type. Occasionally ocProducts might suggest a query that could help solve a problem, as it is easier for us to give the query, than to explain all the mouse-clicks required. The screen-shots shown an example for executing a query to delete an item of news.

Typing in the SQL query to execute

SQL is beyond the scope of this tutorial, but basic queries fit one of the following structures:

INSERT INTO <table-name> (<field-name>,…) VALUES (<field-value>,…)
UPDATE <table-name> SET <field-name>=<field_value>, … WHERE <key-field>=<key-value>
DELETE FROM <table-name> WHERE <key-field>=<key-value>
SELECT * FROM <table-name> WHERE <key-field>=<key-value>

ocPortal database structure

This is an advanced section, and you may wish to skip it.

At the time of writing, ocPortal uses 111 tables, or 123 when official add-ons are installed.

For the technically inclined, the database table structure is mostly in 4NF form, with the main exception being fields that are for caching purposes (such as post count) and other fields that remove the need for complex and slow "JOIN"'s or "EXIST"'s clauses.

A common cause of confusion is where text is located. ocPortal was redesigned in its second version to support content translatable into multiple languages; this feature was dropped, as it was used by few, gave efficiency problems, and primarily because it was very difficult for us to beta test (and we will not release any feature that has not been very thoroughly tested). Text is located in the 'translate' table, and linked into other places by language ID. The 'translate' table is also used to store parsed Comcode, which works out very cleanly. If an entry in the 'translate' table is being edited by hand, and has Comcode, then setting the text_parsed field to NULL will cause the Comcode to be re-parsed on demand.

Since ocPortal 2, ocPortal has been designed to work with many different databases, not just mySQL. We dropped this feature, because like multiple language content, we could not thoroughly beta test it, especially due to very strange and varying limitations and differences in different database systems. However, ocPortal still avoids using mySQL-specific features wherever possible. Instead of using highly specialist (if they exist at all) queries to analyse database table structure, for systems such as backup or OCF-member-id-migration, ocPortal actually stores database structure in the 'db_meta' table. ocPortal's own installation techniques for creating and changing database tables will properly update this table, and if modifications are being made, it is preferable that the db_meta table is updated to reflect them.

Concepts

database: Simple a system that stores structured information
relational database: A system that stores information in a very strict pre-determined structure based on set-theory
SQL: A language for communicating with a database
mySQL: A free database system; ocPortal requires this
phpMyAdmin: An excellent web front-end to mySQL
query: An instruction or request to a database
schema: The specification of the fields rows in a table use
table: A collection of rows and the schema the rows fit
field: An element of a row that may store a value, of a certain configuration
row: A number of elements that together represent a single entry of some sort
key: An identifier for a row, consisting of some pre-chosen (in the schema) combination of fields
ID: In ocPortal this is a numeric identifier associated with a row, and usually also a specific piece of ocPortal content