[gravitypdf-bot]

Summary

6.18.0 stops processing merge tags that users submit in rich text Paragraph and Post Body fields. Those were the only fields that did, and some sites may rely on it. This PR keeps the old behaviour on sites upgrading from an earlier version, so the update doesn't break them. New installs show the tags as text. gfpdf_process_merge_tags_in_submitted_rich_text can still turn processing on or off on any site.

• The 6.18.0 upgrade routine records a gfpdf_process_submitted_rich_text_merge_tags network option. The 6.18.0 block is now skipped on a new install, which has no previous version.
• On Multisite the option is stored in the shared network options table (sitemeta). Once any site in the network upgrades, every subsite keeps processing.
• The option is the default for the gfpdf_process_merge_tags_in_submitted_rich_text filter.
• Uninstalling removes it, from sitemeta on Multisite too.
• The changelog line for the filter says it's off by default.
• Submitted PDF merge tags and [gravitypdf] shortcodes are still never signed.

Try it

1. On a site running 6.17.x, update to this branch, then load any wp-admin page as an administrator.
2. Submit a form with a rich text Paragraph field containing {form_id}, then view its PDF. The form ID is shown.
3. On a fresh install of this branch, do the same. {form_id} is shown as text.
4. Add add_filter( 'gfpdf_process_merge_tags_in_submitted_rich_text', '__return_true' ); on the fresh install. The form ID is shown.

Test plan

• Upgrade routine test: a version change from 6.17.2 records the option, and an install (no previous version) doesn't.
• Textarea and Post Content tests: tags are left as text by default, processed with the option, and the filter overrides both defaults.
• The uninstaller tests remove the option from the options table and from sitemeta.
• Full PHPUnit suite passes locally on single site (1507 tests; 45 multisite-only skips) and on multisite (1507 tests; 2 skips).
• PHPCS is clean on the changed files.
• Manual test on a single site, with the version set to 6.18.0 to simulate the release:
  • Updating from 6.17.2 saves the flag only after an admin loads wp-admin. Before that, the default is off.
  • 6.18.0-RC5 to 6.18.0 saves it.
  • A new install doesn't save it.
  • A repeat visit on 6.18.0 doesn't run the routine again.
  • The PDF output matches all four combinations of flag on/off and filter true/false.
• Manual test on a subdirectory multisite with Gravity PDF network-activated:
  • Upgrading the main site saves the flag once in sitemeta, with no per-site rows.
  • A subsite still on 6.17.2, whose wp-admin was never visited, then processes merge tags in its PDFs. Before the upgrade it showed them as text.
  • A subsite created after the upgrade processes them too.
  • A brand-new network doesn't save the flag, so subsite PDFs show the tags as text.
  • Model_Uninstall::remove_plugin_network_options() removes the flag from sitemeta.
  • No PHP errors or 5xx responses.

Technical details

When the option is recorded: upgrade routines run from gfpdf_version_changed. That hook fires from Controller_Install::check_install_status(), which only runs when an admin with activate_plugins loads a wp-admin page. A site updated automatically or with WP-CLI shows submitted rich text merge tags as text until then.

Why sitemeta: on a network-activated Multisite, subsite admins usually can't activate plugins, so a subsite may never run the routine itself. With a network option, a single upgrade (normally a super admin on the main site) covers every subsite. On a single site, get_site_option() / update_site_option() use the options table.

Fresh installs: check_install_status() fires gfpdf_version_changed with get_option( 'gfpdf_current_version' ), which is false on a new install and reaches maybe_run_upgrade() as ''. The 6.18.0 block requires $old_version !== ''. Its other two routines (fix_logged_out_timeout_out_of_range(), remove_nested_mpdf_cache()) did nothing on a new install anyway.

Autoload: update_site_option() on a single site calls update_option( ..., false ), so the row isn't autoloaded. On Multisite it lives in sitemeta, which isn't autoloaded either. The option is only read in Helper_Abstract_Fields::process_value_tags(), which only runs when a rich text Paragraph or Post Body field is rendered for a PDF or GPDFAPI::get_form_data(). That costs at most one small query per such request, after which WordPress caches the value or the miss.