WordPress CMS Integration for Site Management
WordPress is not only a blog engine. Properly configured, it is a full-featured CMS where editor manages content without touching code. Integration means: connecting WordPress to existing site or new project, setting up content types, access rights, publication workflows.
Integration Variants
Full WordPress — engine returns both frontend and backend. Templating via PHP themes. Works if entire site is WordPress-based.
WordPress as Backend (Headless) — WordPress manages content via REST API or GraphQL (WPGraphQL), frontend on separate stack (React, Next.js, Vue). Works if frontend application already exists or maximum flexibility needed.
WordPress in Subfolder — main site separate, blog/news on site.com/blog via WordPress. Nginx routes requests between two applications.
Installation and Basic Configuration
Minimum requirements: PHP 8.0+, MySQL 8.0+ or MariaDB 10.4+, Nginx or Apache, 512 MB RAM.
# Download WordPress
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz -C /var/www/site.com/
wp-config.php — critical security parameters:
define('DB_NAME', 'wp_production');
define('DB_USER', 'wp_user');
define('DB_PASSWORD', getenv('WP_DB_PASSWORD')); // not in code
define('DB_HOST', '127.0.0.1:3306');
// Unique salts — generate at https://api.wordpress.org/secret-key/1.1/salt/
define('AUTH_KEY', '...');
define('SECURE_AUTH_KEY', '...');
// ... remaining 6 keys
// Disable file editor from panel
define('DISALLOW_FILE_EDIT', true);
// Security updates only
define('WP_AUTO_UPDATE_CORE', 'minor');
// Limit revisions
define('WP_POST_REVISIONS', 5);
// Move wp-content
define('WP_CONTENT_DIR', '/var/www/site.com/content');
define('WP_CONTENT_URL', 'https://site.com/content');
WP CLI — essential tool for command-line management:
wp core install \
--url="https://site.com" \
--title="My Site" \
--admin_user="admin" \
--admin_email="[email protected]" \
--admin_password="$(openssl rand -base64 24)"
Content Types for Site Tasks
Custom Post Types (CPT) — foundation of flexible CMS:
// functions.php or separate plugin
add_action('init', function () {
register_post_type('portfolio', [
'labels' => [
'name' => 'Portfolio',
'singular_name' => 'Project',
'add_new_item' => 'Add Project',
],
'public' => true,
'has_archive' => true,
'show_in_rest' => true, // essential for Gutenberg and REST API
'supports' => ['title', 'editor', 'thumbnail', 'excerpt', 'custom-fields'],
'menu_icon' => 'dashicons-portfolio',
'rewrite' => ['slug' => 'portfolio'],
]);
});
Custom Fields via ACF (Advanced Custom Fields) — most common way to add structured data:
// Programmatic registration (without GUI, convenient for teams)
add_action('acf/init', function () {
if (!function_exists('acf_add_local_field_group')) return;
acf_add_local_field_group([
'key' => 'group_portfolio_details',
'title' => 'Project Details',
'fields' => [
[
'key' => 'field_client_name',
'label' => 'Client',
'name' => 'client_name',
'type' => 'text',
],
[
'key' => 'field_project_url',
'label' => 'Project URL',
'name' => 'project_url',
'type' => 'url',
],
[
'key' => 'field_technologies',
'label' => 'Technologies',
'name' => 'technologies',
'type' => 'checkbox',
'choices' => ['react' => 'React', 'vue' => 'Vue', 'laravel' => 'Laravel'],
'layout' => 'horizontal',
],
],
'location' => [[['param' => 'post_type', 'operator' => '==', 'value' => 'portfolio']]],
]);
});
Roles and Access Configuration
For multi-editor sites — permission granulation:
// Custom "news editor" role
add_role('news_editor', 'News Editor', [
'read' => true,
'edit_posts' => true,
'publish_posts'=> false, // cannot publish without approval
'delete_posts' => false,
]);
// Restrict CPT access
$role = get_role('editor');
$role->add_cap('edit_portfolios');
$role->add_cap('publish_portfolios');
$role->remove_cap('edit_pages'); // does not touch static pages
Members or User Role Editor plugins simplify role management via interface, but for production project better fix roles in code and deploy with version control.
Performance
Object caching mandatory for CMS under load. Redis Object Cache:
wp plugin install redis-cache --activate
wp config set WP_CACHE true
wp config set WP_REDIS_HOST 127.0.0.1
wp config set WP_REDIS_PORT 6379
wp redis enable
Page cache via Nginx (static delivery without PHP):
location / {
set $cache_uri $request_uri;
if ($request_method = POST) { set $cache_uri "null cache"; }
if ($query_string != "") { set $cache_uri "null cache"; }
if ($http_cookie ~* "comment_author|wordpress_logged_in|wp-postpass") {
set $cache_uri "null cache";
}
try_files /wp-content/cache/supercache/$http_host/$cache_uri/index.html
$uri $uri/ /index.php?$args;
}
Deploy and Updates
WP CLI in CI/CD:
# Check pending updates
wp plugin list --update=available --format=json
# Update all (test on staging first)
wp core update
wp plugin update --all
wp theme update --all
# Reset cache after deploy
wp cache flush
wp rewrite flush
WordPress databases should be versioned via migrations if using wp-cli/wp-cli-bundle or via WP Migrate DB Pro plugin for staging/production sync.
Timeline
Installation, security configuration, CPT, ACF fields, user roles — 1–1.5 working days. Redis Object Cache, Nginx page cache setup — 3–4 hours. WP CLI in CI/CD pipeline — 4–6 hours.







