PHP Execution in GT Page Blocks Builder

PHP execution in GT Page Blocks Builder is an opt-in feature for trusted code. Turning on a block’s PHP checkbox alone does not grant it permission to execute.

The site-level gates and the block’s storage path both matter. Library blocks carry a save-time checksum; inline blocks use a separate opt-in because their code lives inside the page content.

Enabling PHP Execution

The course JSON files use HTML, CSS and JavaScript only, as shown in the visual builder walkthrough. Leave PHP disabled while completing those exercises.

For a deliberate PHP integration, the site owner must first permit execution. Library PHP uses the first constant; inline PHP needs the additional inline opt-in.

define( 'GT_PB_ALLOW_PHP', true );
// Only if inline page-content PHP is also intended:
define( 'GT_PB_ALLOW_INLINE_PHP', true );

Then enable Execute PHP on the trusted library block, or Run PHP on an inline section. These are decisions for a site administrator, not routine import steps.

How It Works

When a Page Block with PHP execution enabled is rendered, the plugin scans the HTML content for PHP opening tags (<?php and <?=). If PHP tags are found, the content is written to a temporary file in the system’s temp directory and then included via PHP’s include statement. The output is captured via output buffering and returned as the rendered content.

<section class="stats">
    <h2>Site Statistics</h2>
    <p>Total posts: <?php echo wp_count_posts()->publish; ?></p>
    <p>Total users: <?php echo count_users()['total_users']; ?></p>
</section>

The temporary file is deleted immediately after execution, whether the code succeeds or throws an exception.

The plugin uses the temp file + include approach rather than direct code execution. This gives the PHP parser proper file context for error reporting and stack traces.

When PHP Executes

PHP execution happens in two contexts.

Frontend rendering. When a visitor loads the page, PHP code in the section is executed as part of the block’s render callback. This is the primary use case.

Preview rendering. When you request a server-side preview (by toggling phpExec on and editing the section), the AJAX preview endpoint executes the PHP and returns the rendered output.

Permission Model

Execution is not automatically allowed just because the request comes from a visitor.

• The site-level PHP gate must allow it.
• A library block needs its stored checksum to match the code. New saves use a site-salted checksum.
• Inline PHP has no independent library checksum and requires the separate inline gate.
• Preview execution also requires administrator permission.
• The gt_pb_can_execute_php filter receives the conservative result and can override it.

If execution is denied, PHP spans are removed and the remaining HTML can still appear. A visible section therefore does not prove its PHP ran.

Save library PHP through the plugin editor or supported write path. Do not change its code with raw SQL and manufacture a checksum to make it execute.

Error Handling

PHP errors during execution are caught with a try/catch block around a Throwable handler.

• If WP_DEBUG is enabled, errors are output as HTML comments: <!-- Page Block PHP Error: error message -->.
• If WP_DEBUG is off, errors are silently suppressed.
• The temporary file is always cleaned up in the finally block, even if an exception occurs.

Security Considerations

PHP runs inside WordPress with access to the site’s functions and resources. It is not a sandbox.

• Only trusted code should enter an executable block.
• Do not enable inline PHP where untrusted users can modify the page content.
• A public count or query should expose only the data the page needs.
• Keep the supplied no-PHP demos as a baseline when troubleshooting an unrelated layout problem.

Use Cases

Common use cases for PHP execution in Page Blocks.

• Displaying dynamic content (post counts, user data, custom queries).
• Conditional content based on user roles or other criteria.
• Calling WordPress template tags and functions.
• Rendering dynamic forms or interactive elements.
• Fetching and displaying data from custom database tables or APIs.

Combining with wpautop

When both settings are enabled and PHP is permitted, PHP output is produced first, then wpautop() applies paragraph formatting. Shortcode processing is separate; it does not require enabling Auto-format.

For a structured layout such as the pricing grid, keep Auto-format off unless you intentionally need it. Extra paragraphs can change spacing and nesting.

Quick answers to common questions:

Who can add PHP to a Page Block?

Only trusted code authors should create PHP sections. Library writes require administrator access, PHP previews require administrator permission, and execution still depends on the site-level gates. Avoid enabling inline PHP on sites where untrusted users can modify page content.

Is PHP in blocks a security risk?

It’s the same risk class as theme template editing: safe in trusted-admin hands, dangerous if granted broadly. Keep the capability tight, never enable it on sites with untrusted editors, and prefer shortcodes for anything an editor-level user needs.