You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PHP 8.5: "Using null as an array offset" deprecation in acf_pro_options_page::get_page() (pro/options-page.php:226) #1034
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():
It is being called with $slug === null, and PHP 8.5 deprecates using null as an array offset.
To Reproduce
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.
Load front-end and admin pages.
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:
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.
🙏Justin PrestOn Sep 16, 2026, at 12:59, Phil Johnston ***@***.***> wrote:johnstonphilip left a comment (AdvancedCustomFields/acf#1034)
Thanks for the report, we'll make sure this works without that issue on PHP 8.5.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
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:
Activity
johnstonphilip commentedon Sep 16, 2026
Thanks for the report, we'll make sure this works without that issue on PHP 8.5.
justinjsp commentedon Sep 16, 2026
faisalahammad commentedon Oct 12, 2026
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:
acf_current_user_can_edit_in_context()inincludes/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 callingacf_get_options_page( null ), which passes the slug straight toget_page().update_page( $slug )does the same$this->pages[ $slug ]lookup and write, so it should get the same guard asget_page().add_page()reads the slug frommenu_slugaftervalidate_page(), so it shouldn't need a change.Something like this in
get_page()and at the top ofupdate_page()should cover it without changing behavior: