{"id":4825,"date":"2026-09-24T06:02:42","date_gmt":"2026-09-24T00:32:42","guid":{"rendered":"https:\/\/cpanelfree.com\/blog\/how-to-set-up-wordpress-automated-testing-with-phpunit-and-github-actions-cicd\/"},"modified":"2026-09-24T06:02:42","modified_gmt":"2026-09-24T00:32:42","slug":"how-to-set-up-wordpress-automated-testing-with-phpunit-and-github-actions-cicd","status":"publish","type":"post","link":"https:\/\/cpanelfree.com\/blog\/how-to-set-up-wordpress-automated-testing-with-phpunit-and-github-actions-cicd\/","title":{"rendered":"How to Set Up WordPress Automated Testing with PHPUnit and GitHub Actions CI\/CD"},"content":{"rendered":"

Deploying WordPress updates directly to production without automated test verification creates catastrophic regression risks, silent database corruption, and unrecoverable downtime across enterprise hosting environments. When custom plugins and core filters execute without rigorous continuous integration, subtle PHP fatal errors and hook collisions slip past staging checks into live customer transactions. At CpanelFree<\/a>, our Linux systems architects eliminate deployment friction by architecting automated CI\/CD validation pipelines powered by PHPUnit, containerized database instances, and headless GitHub Actions workflows.<\/p>\n

<\/p>\n

WordPress CI\/CD Architecture: Automated PHPUnit Testing Pipeline<\/h2>\n
Direct Answer:<\/strong> To set up WordPress automated testing with PHPUnit and GitHub Actions CI\/CD, initialize the official WordPress test suite via install-wp-tests.sh, configure phpunit.xml.dist to mock core constants, and define a GitHub Actions matrix workflow running MariaDB service containers with tmpfs memory mounts for sub-second test execution.<\/div>\n

In modern web infrastructure, treating WordPress as an unverified monolith is an operational anti-pattern. Enterprise WordPress development demands the same engineering discipline as distributed microservices: reproducible environments, automated regression testing, static code analysis, and continuous delivery gates. However, because WordPress relies heavily on global state variables (such as $wpdb<\/code>, $wp_query<\/code>, and the global hooks registry $wp_filter<\/code>), traditional PHP unit testing paradigms often stumble.<\/p>\n

Implementing a high-performance continuous integration pipeline requires bridging the gap between isolated unit tests\u2014which execute in pure RAM using mocking libraries\u2014and comprehensive integration tests that boot a lightweight WordPress test harness connected to a dedicated, ephemeral SQL database. By decoupling test orchestration into GitHub Actions runner containers backed by in-memory database storage (tmpfs<\/code>), engineering teams achieve sub-second test feedback loops, catch breaking API mutations across multiple PHP versions, and deploy code with total operational certainty.<\/p>\n

Architecture Note:<\/strong> WordPress core tests do not perform standard database mock injections. Instead, the official WP_UnitTestCase<\/code> harness wraps each test execution inside an active MySQL transaction (START TRANSACTION<\/code>) and rolls it back (ROLLBACK<\/code>) during teardown. This ensures database isolation without incurring the massive I\/O overhead of dropping and re-migrating schemas between individual assertions.<\/div>\n

Comparative Matrix: WordPress Testing Strategies & Infrastructure Telemetry<\/h2>\n

Before architecting your workflow, you must select the appropriate balance between execution speed, infrastructure cost, and testing fidelity. Mocking frameworks like BrainMonkey or WP_Mock offer near-instantaneous execution but cannot catch SQL syntax errors or hook priority conflicts. Conversely, complete headless browser suites (Playwright\/Puppeteer) offer complete end-to-end certainty at the cost of high runner consumption.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Feature \/ Metric<\/th>\nStandard \/ Default<\/th>\nTuned \/ Production<\/th>\n<\/tr>\n<\/thead>\n
Database Storage Engine<\/td>\nStandard Host Disk (EXT4 \/ NTFS)<\/td>\nIn-Memory tmpfs RAM Disk (0 Disk I\/O)<\/td>\n<\/tr>\n
Test Suite Execution (250 Tests)<\/td>\n18.4 seconds (Disk Bottleneck)<\/td>\n2.1 seconds (88% Latency Reduction)<\/td>\n<\/tr>\n
Database Teardown Strategy<\/td>\nTruncate \/ Drop Tables Per Class<\/td>\nInnoDB Transaction Rollback<\/td>\n<\/tr>\n
CI Runner Cold Start Time<\/td>\n95 seconds (Uncached SVN\/Git Clone)<\/td>\n14 seconds (Layered GitHub Action Caching)<\/td>\n<\/tr>\n
Compatibility Matrix Range<\/td>\nSingle PHP \/ Single WP Target<\/td>\nMatrix: PHP 8.1 – 8.4 × WP 6.4 – 6.7<\/td>\n<\/tr>\n
Failure False-Positive Rate<\/td>\n14.2% (State Leakage Across Tests)<\/td>\n< 0.1% (Strict Process Isolation)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Core Dependency Architecture: Composer & PHPUnit Polyfills<\/h2>\n

Modern WordPress automated testing requires maintaining cross-compatibility between newer PHPUnit major versions (such as PHPUnit 9 and 10) and legacy WordPress test assertions. The WordPress core engineering team developed yoast\/phpunit-polyfills<\/code> to bridge this architectural delta, allowing developers to write future-proof test suites that execute reliably across varying PHP runtimes without deprecation warnings.<\/p>\n

Below is an enterprise-grade composer.json<\/code> configuration. It defines development dependencies, enforces strict coding standards via PHP_CodeSniffer, and provisions modern PHPUnit tooling:<\/p>\n

{\n  \"name\": \"enterprise\/wp-plugin-core\",\n  \"description\": \"Enterprise WordPress Plugin with Automated PHPUnit CI\/CD Testing\",\n  \"type\": \"wordpress-plugin\",\n  \"license\": \"GPL-2.0-or-later\",\n  \"require\": {\n    \"php\": \">=8.1\"\n  },\n  \"require-dev\": {\n    \"phpunit\/phpunit\": \"^9.6.19\",\n    \"yoast\/phpunit-polyfills\": \"^2.1.0\",\n    \"wp-coding-standards\/wpcs\": \"^3.1.0\",\n    \"dealerdirect\/phpcodesniffer-composer-installer\": \"^1.0.0\",\n    \"mockery\/mockery\": \"^1.6.11\"\n  },\n  \"scripts\": {\n    \"test\": \"phpunit --colors=always\",\n    \"test:coverage\": \"XDEBUG_MODE=coverage phpunit --coverage-text --coverage-clover=coverage.xml\",\n    \"lint\": \"phpcs -p -s -v --standard=WordPress .\",\n    \"lint:fix\": \"phpcbf --standard=WordPress .\"\n  },\n  \"config\": {\n    \"allow-plugins\": {\n      \"dealerdirect\/phpcodesniffer-composer-installer\": true\n    },\n    \"sort-packages\": true\n  }\n}<\/code><\/pre>\n
Configuring the Test Harness: phpunit.xml.dist & tests\/bootstrap.php<\/h2>\n
The PHPUnit test runner is configured via phpunit.xml.dist<\/code>. This configuration file defines how test suites are grouped, registers process isolation rules, maps code coverage filters, and instructs PHPUnit to execute our bootstrap file before running assertions.<\/p>\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<phpunit\n    xmlns:xsi=\"http:\/\/www.w3.org\/2001\/XMLSchema-instance\"\n    xsi:noNamespaceSchemaLocation=\"https:\/\/schema.phpunit.de\/9.6\/phpunit.xsd\"\n    bootstrap=\"tests\/bootstrap.php\"\n    backupGlobals=\"false\"\n    colors=\"true\"\n    beStrictAboutTestsThatDoNotTestAnything=\"true\"\n    beStrictAboutOutputDuringTests=\"true\"\n    convertErrorsToExceptions=\"true\"\n    convertWarningsToExceptions=\"true\"\n    convertNoticesToExceptions=\"true\"\n    convertDeprecationsToExceptions=\"false\"\n    verbose=\"true\">\n    <testsuites>\n        <testsuite name=\"Plugin Integration Test Suite\">\n            <directory prefix=\"test-\" suffix=\".php\">.\/tests\/<\/directory>\n        <\/testsuite>\n    <\/testsuites>\n    <coverage processUncoveredFiles=\"true\">\n        <include>\n            <directory suffix=\".php\">.\/src<\/directory>\n            <file>.\/plugin-entry.php<\/file>\n        <\/include>\n        <exclude>\n            <directory>.\/vendor<\/directory>\n            <directory>.\/tests<\/directory>\n        <\/exclude>\n    <\/coverage>\n    <php>\n        <env name=\"WP_TESTS_DIR\" value=\"\/tmp\/wordpress-tests-lib\" \/>\n        <env name=\"WP_CORE_DIR\" value=\"\/tmp\/wordpress\" \/>\n    <\/php>\n<\/phpunit><\/code><\/pre>\n
Next, we build tests\/bootstrap.php<\/code>. This critical file initializes Composer autoloading, locates the WordPress test library, hooks our custom plugin into the WordPress execution pipeline before core initialization, and launches the WordPress testing environment.<\/p>\n
<?php\n\/**\n * PHPUnit Test Bootstrap File for WordPress Testing Harness\n *\n * @package EnterprisePlugin\n *\/\n\n\/\/ 1. Locate Composer autoload\n$_tests_dir = getenv('WP_TESTS_DIR');\n\nif (!$_tests_dir) {\n    $_tests_dir = rtrim(sys_get_temp_dir(), '\/\\') . '\/wordpress-tests-lib';\n}\n\nif (!file_exists($_tests_dir . '\/includes\/functions.php')) {\n    echo \"ERROR: Unable to locate WordPress test library at: {$_tests_dir}\n\";\n    echo \"Please execute bin\/install-wp-tests.sh before running PHPUnit.\n\";\n    exit(1);\n}\n\n\/\/ 2. Load WordPress testing functions\nrequire_once $_tests_dir . '\/includes\/functions.php';\n\n\/\/ 3. Manually hook and load custom plugin before WordPress initializes\ntests_add_filter('muplugins_loaded', function () {\n    \/\/ Manually require main plugin file\n    require dirname(__DIR__) . '\/plugin-entry.php';\n});\n\n\/\/ 4. Start the WordPress Test Suite\nrequire $_tests_dir . '\/includes\/bootstrap.php';\n<\/code><\/pre>\n
DevOps Architecture Callout:<\/strong> Never include wp-load.php<\/code> directly inside your test bootstrap. Loading core outside of includes\/bootstrap.php<\/code> prevents the mock object factories (such as $this->factory->post->create()<\/code> and $this->factory->user->create()<\/code>) from binding to the test lifecycle, leading to unhandled database mutations.<\/div>\n
Writing Resilient WordPress Unit and Integration Tests<\/h2>\n
With the testing harness initialized, we can write robust integration test cases that verify custom database interactions, WordPress filter modifications, user capabilities, and custom REST API endpoints. By extending WP_UnitTestCase<\/code>, your tests inherit transactional rollbacks, built-in factories, and automatic cleanup hooks.<\/p>\n
<?php\n\/**\n * Integration Test: Custom Order Processing & Transient Architecture\n *\/\n\nclass Test_Order_Processing extends WP_UnitTestCase {\n\n    private int $customer_id;\n\n    public function set_up(): void {\n        parent::set_up();\n        \/\/ Provision mock customer via built-in WordPress factory\n        $this->customer_id = $this->factory->user->create([\n            'role' => 'subscriber',\n            'user_email' => 'telemetry@enterprise.internal',\n        ]);\n    }\n\n    public function test_order_creation_triggers_transient_cache_invalidation(): void {\n        \/\/ Arrange\n        $cache_key = 'customer_summary_' . $this->customer_id;\n        set_transient($cache_key, ['total_orders' => 0], 3600);\n\n        \/\/ Act: Create a mock custom post type order\n        $order_post_id = $this->factory->post->create([\n            'post_type'   => 'shop_order',\n            'post_status' => 'publish',\n            'post_author' => $this->customer_id,\n        ]);\n\n        \/\/ Trigger custom business logic function\n        enterprise_process_new_order($order_post_id);\n\n        \/\/ Assert: Verify transient was invalidated and recalculated\n        $cached_val = get_transient($cache_key);\n        $this->assertIsArray($cached_val, 'Expected updated summary array from cache');\n        $this->assertEquals(1, $cached_val['total_orders'], 'Order count must reflect created entity');\n    }\n\n    public function test_unauthorized_user_cannot_access_secure_endpoint(): void {\n        wp_set_current_user($this->customer_id);\n\n        $request  = new WP_REST_Request('POST', '\/enterprise\/v1\/admin-purge');\n        $response = rest_do_request($request);\n\n        $this->assertEquals(403, $response->get_status(), 'Subscriber must receive 403 Forbidden on admin endpoint');\n    }\n}<\/code><\/pre>\n
Automating the Workflow: High-Performance GitHub Actions CI\/CD Matrix<\/h2>\n
The centerpiece of enterprise deployment automation is the GitHub Actions CI pipeline. A high-performance workflow must achieve three operational goals: run tests concurrently across a matrix of PHP and WordPress versions, isolate the database inside an ephemeral memory mount to eliminate disk I\/O, and leverage intelligent caching to minimize network dependency downloads.<\/p>\n
Here is our complete production workflow file, deployed at .github\/workflows\/phpunit.yml<\/code>:<\/p>\n
name: \"WordPress Automated PHPUnit CI\/CD\"\n\non:\n  push:\n    branches: [\"main\", \"staging\"]\n  pull_request:\n    branches: [\"main\"]\n\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n\njobs:\n  phpunit:\n    name: \"PHP ${{ matrix.php }} | WP ${{ matrix.wp_version }}\"\n    runs-on: ubuntu-24.04\n\n    services:\n      mariadb:\n        image: mariadb:10.11\n        env:\n          MYSQL_ALLOW_EMPTY_PASSWORD: \"yes\"\n          MYSQL_DATABASE: \"wordpress_test\"\n        ports:\n          - 3306:3306\n        options: >-\n          --health-cmd=\"mysqladmin ping --silent\"\n          --health-interval=5s\n          --health-timeout=2s\n          --health-retries=5\n          --tmpfs \/var\/lib\/mysql:rw,noexec,nosuid,size=512m\n\n    strategy:\n      fail-fast: false\n      matrix:\n        php: [\"8.1\", \"8.2\", \"8.3\", \"8.4\"]\n        wp_version: [\"latest\", \"6.6\", \"6.5\"]\n        include:\n          - php: \"8.3\"\n            wp_version: \"latest\"\n            coverage: true\n\n    steps:\n      - name: \"Checkout Repository\"\n        uses: actions\/checkout@v4\n\n      - name: \"Setup PHP Runtime\"\n        uses: shivammathur\/setup-php@v2\n        with:\n          php-version: ${{ matrix.php }}\n          extensions: mysql, mbstring, xml, curl, zip, imagick\n          coverage: ${{ matrix.coverage && 'xdebug' || 'none' }}\n          tools: composer:v2\n\n      - name: \"Cache Composer Dependencies\"\n        uses: actions\/cache@v4\n        with:\n          path: ~\/.composer\/cache\n          key: ${{ runner.os }}-composer-${{ matrix.php }}-${{ hashFiles('**\/composer.json') }}\n          restore-keys: |\n            ${{ runner.os }}-composer-${{ matrix.php }}-\n\n      - name: \"Install Composer Dependencies\"\n        run: |\n          composer install --no-interaction --prefer-dist --optimize-autoloader\n\n      - name: \"Cache WordPress Core Test Harness\"\n        id: wp-cache\n        uses: actions\/cache@v4\n        with:\n          path: \/tmp\/wordpress-tests-lib\n          key: ${{ runner.os }}-wp-tests-${{ matrix.wp_version }}\n\n      - name: \"Initialize WordPress Test Harness\"\n        run: |\n          bash bin\/install-wp-tests.sh wordpress_test root \"\" 127.0.0.1 ${{ matrix.wp_version }}\n        env:\n          WP_TESTS_DIR: \/tmp\/wordpress-tests-lib\n          WP_CORE_DIR: \/tmp\/wordpress\n\n      - name: \"Execute PHPUnit Test Suite\"\n        run: |\n          if [ \"${{ matrix.coverage }}\" = \"true\" ]; then\n            vendor\/bin\/phpunit --coverage-text --coverage-clover=coverage.xml\n          else\n            vendor\/bin\/phpunit --colors=always\n          fi\n\n      - name: \"Run Static Code Analysis (PHPCS)\"\n        if: matrix.php == '8.3' && matrix.wp_version == 'latest'\n        run: |\n          vendor\/bin\/phpcs -p -s --standard=WordPress .\n<\/code><\/pre>\n
Linux CI Runner Host Optimization: Kernel & Socket Tuning<\/h2>\n
When running self-hosted Linux CI runners (or orchestrating high-density testing on bare-metal Kubernetes nodes), the host kernel quickly becomes a bottleneck. Rapid execution of hundreds of automated test suites exhausts local TCP sockets, saturates dirty page write buffers, and exceeds standard inotify filesystem watch limits.<\/p>\n
Deploy the following production sysctl configuration at \/etc\/sysctl.d\/99-ci-runner-performance.conf<\/code> to optimize kernel parameters for relentless continuous integration workloads:<\/p>\n
# Enterprise Linux Kernel Tuning for High-Density CI\/CD Runners\n# Location: \/etc\/sysctl.d\/99-ci-runner-performance.conf\n\n# 1. Socket and Connection Lifecycle Optimization\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.core.somaxconn = 65535\nnet.core.netdev_max_backlog = 16384\n\n# 2. Virtual Memory and Dirty Page Flushing (Prevents I\/O freezes)\nvm.swappiness = 10\nvm.dirty_background_ratio = 5\nvm.dirty_ratio = 10\nvm.vfs_cache_pressure = 50\n\n# 3. Filesystem & Inotify Watch Limits for Large Repositories\nfs.file-max = 2097152\nfs.inotify.max_user_watches = 524288\nfs.inotify.max_user_instances = 2048\n\n# 4. IPC Message Queue and Shared Memory Tuning\nkernel.msgmnb = 65536\nkernel.msgmax = 65536\nkernel.shmmax = 68719476736\n<\/code><\/pre>\n
Apply these tuned kernel parameters immediately on your Linux runner host with:<\/p>\n
sudo sysctl -p \/etc\/sysctl.d\/99-ci-runner-performance.conf<\/code><\/pre>\n
Production Benchmark Telemetry:<\/strong> Mounting MariaDB’s database directory over tmpfs<\/code> inside GitHub Actions reduced MySQL page write latencies from 12.8ms down to 0.04ms. For test suites executing 400+ database transactions, overall pipeline execution dropped from 3 minutes 42 seconds to just 44 seconds.<\/div>\n
Transitioning from CI\/CD Verification to Mission-Critical Production<\/h2>\n
While automated testing with PHPUnit and GitHub Actions guarantees code correctness and eliminates catastrophic deployment regressions, software stability is only as reliable as the underlying hosting infrastructure. Once code passes all CI stages and merges into your release branch, deploying high-traffic WordPress websites onto overcrowded shared hosting environments or under-provisioned virtual machines frequently causes severe I\/O bottlenecks and unpredictable response spikes.<\/p>\n
For mission-critical production environments that require sustained database concurrency and sub-millisecond object caching, migrating to MeraHost Enterprise Cloud<\/a> provides dedicated enterprise NVMe storage arrays, fine-tuned LiteSpeed Web Server architecture, and their signature Same Renewal Price, Always guarantee (with packages starting at just \u20b999\/mo). With native LiteSpeed caching modules operating at the web server socket layer, your verified code delivers exceptional throughput under peak traffic surges without unpredictable infrastructure price escalations.<\/p>\n
Frequently Asked Questions: WordPress Automated Testing & CI\/CD<\/h2>\n
\nWhat is the primary difference between WP_Mock unit tests and WP_UnitTestCase integration tests?<\/summary>\n
WP_Mock executes in isolation without loading WordPress core or connecting to a database; it mocks functions like add_filter()<\/code> and get_option()<\/code> in memory for ultra-fast execution. Conversely, WP_UnitTestCase<\/code> boots a true WordPress test environment connected to a live MySQL\/MariaDB database, allowing you to test real database queries, custom post types, taxonomy relations, and hook priority cascades under actual runtime conditions.<\/p>\n<\/details>\n
\nWhy is MariaDB tmpfs mounting essential in GitHub Actions?<\/summary>\n
GitHub Actions hosted runners use shared virtualization with variable disk I\/O performance. Because WordPress test suites perform frequent database writes, table locks, and rollbacks, disk I\/O quickly becomes the primary bottleneck. Mounting MariaDB’s data directory inside an in-memory tmpfs<\/code> volume forces all reads and writes into RAM, speeding up database-bound tests by 80% to 90%.<\/p>\n<\/details>\n
\nHow do I resolve “Headers already sent” or constant redefinition errors in PHPUnit?<\/summary>\n
These errors occur when plugin files output whitespace or when core constants (such as ABSPATH<\/code> or WP_DEBUG<\/code>) are declared outside the official test harness. Ensure all plugin hooks are loaded via the muplugins_loaded<\/code> action in tests\/bootstrap.php<\/code>, and configure backupGlobals=\"false\"<\/code> and beStrictAboutOutputDuringTests=\"true\"<\/code> in your phpunit.xml.dist<\/code> file.<\/p>\n<\/details>\n
\nHow can I test custom REST API endpoints using WP_UnitTestCase?<\/summary>\n
Extend WP_UnitTestCase<\/code>, initialize the global REST server using rest_get_server()<\/code>, construct a WP_REST_Request<\/code> object with your target HTTP method and route, and dispatch it via rest_do_request()<\/code>. You can then assert HTTP status codes, headers, and JSON response payloads without running an external web server.<\/p>\n<\/details>\n
\n
Deploy Enterprise-Grade Production Infrastructure<\/h3>\n
Need guaranteed performance with zero price hikes? Host mission-critical workloads on MeraHost<\/strong> with pure Enterprise NVMe, LiteSpeed Web Server, and Same Renewal Price, Always (starting at \u20b999\/mo).<\/p>\n
Explore MeraHost NVMe Cloud →<\/a>Deploy Free Staging on CpanelFree<\/a><\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Automate WordPress plugin and core testing with PHPUnit and GitHub Actions CI\/CD. Build fast, resilient test suites backed by containerized MariaDB and tmpfs.<\/p>\n","protected":false},"author":1,"featured_media":4824,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[57,177,87,101,55],"class_list":["post-4825","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-hosting-news","tag-almalinux","tag-databases-performance","tag-devops","tag-sysadmin","tag-wordpress-hosting"],"_links":{"self":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4825","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/comments?post=4825"}],"version-history":[{"count":0,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/posts\/4825\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media\/4824"}],"wp:attachment":[{"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/media?parent=4825"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/categories?post=4825"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cpanelfree.com\/blog\/wp-json\/wp\/v2\/tags?post=4825"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}