WordPress Integration

Before beginning this process, please be sure you are able to log in to your OFS installation as a “Site Administrator” and that the login and logout functions are working properly. Also be certain that your WordPress installation is working properly and that you can successfully log in as a WordPress administrator. This is important so that any troubles during this process will not be the result of either OFS or WordPress being misconfigured.

Install and activate the WordPress “Groups” plugin.

Add new groups that match the OFS auth_types for which you would like to give permission-based access to your wordpress site. For example, if you want to give producers specific access to certain pages, then add a “producers” group. The group names need not exactly match the auth_types, but a close match will make things easier to manage in the future. For greatest flexibility, the following groups are recommended: member, producer, institution, and site_admin. These other groups might also be useful: member_admin, producer_admin, route_admin, cashier, board.


Adding groups through a page’s access restrictions


Example display after groups have been added

An easy way to add groups is to open a new WordPress page for editing and enter group names in the “Access restrictions” section as shown below. Enter each group name on “Quick-create group & capability” line. Then press <enter> to accept the group name and add it to the “Enforce read access” field at the top. This has the benefit of adding the groups and assigning access permission at the same time.

In the Open Food Source configuration, under Optional Modules, enter the group_id numbers and their corresponding auth_type. See the figure for an example (your number assignments may be different):

Example setup

Connecting Wordpress group_ids with OFS auth_types

Note that auth_type=site_admin will be given WordPress administrative privileges.

Now modify the WordPress configuration to keep secure WordPress values with the OFS configuration directory (this is a security improvement over WordPress because it takes this sensitive information out of a server-accessible directory). Locate the WordPress configuration file (possibly at [document_root]/wordpress/wp-config.php). You will be removing the content between the blue-dotted lines (after the introductory comments that includes the @package WordPress line and down to the comment that says /* That’s all, stop editing! Happy blogging. */) and replacing it with code that will call the configuration at its new location.


Copy the configuration content from wp-config.php to config_wordpress.php

In order that WordPress be able to find its new configuration settings, be sure the ofs_includes directory is included in either php.ini or .htaccess files for WordPress. Copy the code that will be removed and paste it into your /ofs_includes/config_wordpress.php file. Be sure to leave the opening <?php and closing ?> php tags. Then replace the removed content in wp-config.php with the following, which will link to the new configuration:

/** All wordpress configurations have been moved above document_root
into /ofs_includes/config_wordpress.php ... and are included from there */

require_once ('config_wordpress.php');

At this point, access any WordPress page to check that WordPress is still working properly. Next, we will configure the WordPress database to use the OFS “members” table instead its own “users” table. We will take this action because OFS will automatically add new members and we want to keep the two systems properly synced. NOTE: WordPress will be broken until this step is complete. You may need to modify the following queries to match your database and table names.

First, save the existing WordPress “users” table. If things go terribly wrong, you can restore this table to get WordPress working again. The query will look something like this:

RENAME TABLE wp_users TO wp_users_orig

Next, create a view of the OFS “members” table for WordPress to use for its new “users” table The query will look something like the following:

openfood.ofs_members.member_id AS ID,
openfood.ofs_members.username AS user_login,
openfood.ofs_members.password AS user_pass,
openfood.ofs_members.username AS user_nicename,
openfood.ofs_members.email_address AS user_email,
openfood.ofs_members.home_page AS user_url,
CONCAT(openfood.ofs_members.membership_date, ' 00:00:00') AS user_registered,
'' AS user_activation_key,
0 AS user_status,
openfood.ofs_members.preferred_name AS display_name
FROM openfood.ofs_members);

Note that your WordPress admin user is probably ID=1, so that will correspond to the OFS member_id=1, which may have a different username/password from the one that was used to set up WordPress. If there is no OFS member_id=1, it may need to be created before further Wordpress access.

At this point, we need to activate the connection between OFS and WordPress. From the OFS configuration page, set the wordpress_config to the full file path of the now-modified wp-config.php file and “check” the wordpress_enabled flag to tell OFS to log into WordPress when a member logs into OFS.

Activate WordPress in the OFS configuration

Activate WordPress in the OFS configuration

If everything went well, you should be able to log into OFS as an administrator with auth_type=site_admin privileges and be able to access the WordPress administrative areas.

SPECIAL AWARENESS: WordPress sessions usually timeout according to a different schedule from OFS sessions. A user might be logged into either WordPress or OFS when the “other” has expired and logged the user out. If either session is not providing the desired access, the easy solution is to log out from OFS and log back in. This will begin a new OFS and WordPress session together.

Follow instructions for Additional WordPress Setup to make the OFS-Wordpress integration even more seamless.

Leave a Reply