Skip to content

PHP 8.5: "Using null as an array offset" deprecation in acf_pro_options_page::get_page() (pro/options-page.php:226) #1034

Open

Description

@justinjsp

Describe the bug
On PHP 8.5, ACF PRO 6.8.9 logs this on a large share of requests — about 850 entries a day on our site:

PHP Deprecated: Using null as an array offset is deprecated, use an empty string instead in wp-content/plugins/advanced-custom-fields-pro/pro/options-page.php on line 226

Line 226 is the body of acf_pro_options_page::get_page():

function get_page( $slug ) {

	return isset( $this->pages[ $slug ] ) ? $this->pages[ $slug ] : null;
}

It is being called with $slug === null, and PHP 8.5 deprecates using null as an array offset.

To Reproduce

  1. Run ACF PRO 6.8.9 on PHP 8.5 with WP_DEBUG and WP_DEBUG_LOG enabled, on a site with options pages registered.
  2. Load front-end and admin pages.
  3. See the deprecation in wp-content/debug.log.

We have not pinned down which caller passes the null slug; anything that reaches get_page() with null triggers it.

Expected behavior
No deprecation. A null key has always addressed the same array entry as '', so converting it first changes nothing about what the method returns:

function get_page( $slug ) {

	if ( null === $slug ) {
		$slug = '';
	}

	return isset( $this->pages[ $slug ] ) ? $this->pages[ $slug ] : null;
}

Tested on PHP 8.5: get_page( null ) still returns the page stored under '', normal and missing slugs behave as before, and the deprecation no longer appears in our log (250 entries in the 40 minutes before the change).

Screenshots or Video
Not applicable — the log line is quoted above.

Code
No field group export needed; the notice comes from pro/options-page.php itself.

Version Information:

  • WordPress Version 7.1
  • PHP Version 8.5.8
  • ACF Version ACF PRO 6.8.9
  • Browser not applicable (server-side)

Additional context
The same $this->pages[ $slug ] pattern also appears on lines 140, 145 and 207 of pro/options-page.php. They are not firing for us, but they would raise the same notice if they ever received a null slug, so they may be worth the same guard.

Activity

  1. johnstonphilip commented on Sep 16, 2026

    @johnstonphilip

    Thanks for the report, we'll make sure this works without that issue on PHP 8.5.

  2. justinjsp commented on Sep 16, 2026

    @justinjsp
    Author
  3. faisalahammad commented on Oct 12, 2026

    @faisalahammad

    I checked this against the public repo. The pro/ folder isn't included in this GitHub mirror, so the fix has to go into the PRO build.

    Some notes that may help whoever picks it up:

    • The free plugin's only caller, acf_current_user_can_edit_in_context() in includes/api/api-helpers.php, already checks ! empty( $options_page_slug ) first. The null slug isn't coming from there. It is most likely a theme or plugin calling acf_get_options_page( null ), which passes the slug straight to get_page().
    • update_page( $slug ) does the same $this->pages[ $slug ] lookup and write, so it should get the same guard as get_page().
    • add_page() reads the slug from menu_slug after validate_page(), so it shouldn't need a change.

    Something like this in get_page() and at the top of update_page() should cover it without changing behavior:

    if ( null === $slug ) {
    	$slug = '';
    }
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions