Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#55489 closed defect (bug) (invalid)

Defining SHORTINIT creates an error when index.php is loaded

Reported by: gerendo's profile gerendo Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.9.2
Component: Bootstrap/Load Keywords: has-screenshots close 2nd-opinion has-patch
Focuses: rest-api Cc:

Description (last modified by sabernhardt)

hi brothers and sisters
I am a software developer .. in my current project i use WordPress as dashboard for web app using WordPress Rest-API .. for trying to minimize the response time of the API . I try to minimize the load of WordPress libraries by define this constant (SHORTINIT) in the wp-config.php .. I got that error https://prnt.sc/BCnjCnsmyv0k

Error: Call to a member function main() on null in D:\wamp64\www\wordpress\wp-includes\functions.php on line 1310

Attachments (1)

55489.diff (786 bytes) - added by SergeyBiryukov 2 years ago.

Download all attachments as: .zip

Change History (10)

#1 @sabernhardt
2 years ago

  • Description modified (diff)
  • Focuses rest-api added

Hi and welcome to Trac! Thanks for the report!

Line 1310 is in the wp() function.

#2 follow-up: @TimothyBlynJacobs
2 years ago

  • Keywords close added
  • Severity changed from critical to normal
  • Summary changed from SHORTINIT define make error in the core to Defining SHORTINIT creates an error when index.php is loaded

SHORTINIT doesn't load the majority of WordPress, you can see where it stops loading in `wp-settings.php`. This includes the REST API.

It looks like you are defining SHORTINIT for all requests to WordPress, which is not a supported configuration.

#3 in reply to: ↑ 2 @SergeyBiryukov
2 years ago

  • Keywords 2nd-opinion added

Replying to TimothyBlynJacobs:

SHORTINIT doesn't load the majority of WordPress, you can see where it stops loading in `wp-settings.php`. This includes the REST API.

Maybe we could check early in the REST API bootstrap whether SHORTINIT is defined, and display an appropriate error message in that case? I think that would be a better developer experience.

#4 @TimothyBlynJacobs
2 years ago

I think placing it in the REST API would be too late. I think the code would need to live in wp() and it wouldn't really be specific to the REST API I think, just any request that utilizes the WP request handler.

#5 @johnjamesjacoby
2 years ago

Hello everyone! 👋

Please correct me if I am mistaken, but I believe the error message that @gerendo is seeing is not specific to the REST API using SHORTINIT – rather, I believe this error message can be expected to be thrown on every non-wp-admin request. 😬

(wp-admin/profile.php – for example sake – shows a different missing function:

Fatal error: Uncaught Error: Call to undefined function is_customize_preview() in wp-admin/includes/admin-filters.php:56 
Stack trace:
#0 wp-admin/includes/admin.php(20)
#1 wp-admin/admin.php(97)
#2 wp-admin/user-edit.php(10)
#3 wp-admin/profile.php(18)

)


I'd like to politely suggest to @gerendo that he simply not use SHORTINIT inside of wp-config.php 🥷

While wp-config.php is generally where WordPress documentation all over the web recommends that developers put their configuration constants, SHORTINIT is quite unique in that its usage should typically be outside of the global WordPress configuration, so that WordPress itself (and all of its innards) continue to work as intended (including the REST API) – not-much inside of WordPress is coded with SHORTINIT support directly in mind.

When using SHORTINIT you are basically "on your own" when it comes to including & requiring all of the files you need to avoid PHP fatal errors while also achieving your goal of loading fewer files to keep your memory usage low. To do this, traditionally, you would start with what is in the root index.php, wp-blog-header.php, wp-settings.php, etc... cherry-picking the parts of those files that you do-or-do-not need.

As you've identified, this is not very straightforward 😅 but I do think it is a fun challenge and can be a rewarding exercise, especially on long-running requests that do not require plugins or themes to be loaded, need to avoid wp_magic_quotes(), run a custom application, or something even more fun 🛝

See also: https://wordpress.stackexchange.com/a/28347/3588


To @SergeyBiryukov, @TimothyBlynJacobs, and @sabernhardt, I think it would be OK to close this ticket, as it's not quite as accurate of a report as maybe it could be. I would personally like to see some version of an improved SHORTINIT experience (autoloading or otherwise) but I also think that's a bit outside the scope of what's being discussed here.

Thoughts? 🧐

#6 @TimothyBlynJacobs
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Please correct me if I am mistaken, but I believe the error message that @gerendo is seeing is not specific to the REST API using SHORTINIT – rather, I believe this error message can be expected to be thrown on every non-wp-admin request. 😬

This is my understanding as well.

I would personally like to see some version of an improved SHORTINIT experience (autoloading or otherwise) but I also think that's a bit outside the scope of what's being discussed here.

Agreed. I'm not sure what it would look like. Feels similar to making wp-settings.php more "modular". Feels like maybe a more broad version of #34936?

@SergeyBiryukov
2 years ago

#7 follow-up: @SergeyBiryukov
2 years ago

  • Keywords has-patch added

I think encountering this issue is not entirely unreasonable :)

Maybe something like 55489.diff would help make the experience a bit better?

#9 in reply to: ↑ 7 @johnjamesjacoby
2 years ago

Replying to SergeyBiryukov:

I think encountering this issue is not entirely unreasonable :)

Maybe something like 55489.diff would help make the experience a bit better?

I like it! 🤙

If this is proves viable, I believe we may want to also document publicly a guideline about when notices like you are suggesting here are the recommended resolution.

WordPress core obviously interacts with a number of its own global values in a very trusting way, not only expecting that they will always already exist but oftentimes that they are even of the correct type.

What’s the difference between “being done wrong” vs. “something did you dirty?” 😅

Note: See TracTickets for help on using tickets.