[wp-trac] [WordPress Trac] #17246: Handling of HTTP 404 errors for non-existing files
WordPress Trac
noreply at wordpress.org
Thu Aug 16 19:37:59 UTC 2018
#17246: Handling of HTTP 404 errors for non-existing files
----------------------------+--------------------------
Reporter: azaozz | Owner: (none)
Type: enhancement | Status: reopened
Priority: normal | Milestone:
Component: Bootstrap/Load | Version:
Severity: normal | Resolution:
Keywords: needs-patch | Focuses: performance
----------------------------+--------------------------
Changes (by rpayne7264):
* status: closed => reopened
* resolution: maybelater =>
Comment:
Aborting execution with a die() is not the answer, young Padawan, as that
will kill the entire request.
I only want to abort execution of my plugin code if I know the request is
for a script, image, or stylesheet, because my plugin doesn't provide any
useful functionality for those types of files.
I have submitted proposed code for adding a highly-extensible
wp_is_bad_request() function to the core, thus making such checks an easy
matter for all plugin and theme creators. See #41934
Replying to [comment:7 dd32]:
> I'm re-closing this as `maybelater` as I don't think anything has
changed here that gives any reason to look at it again.
>
> > I propose that we add a wp_abort_execution filter to the core, which
would allow developers to tell Wordpress whether or not to load their
plugin.
>
> If you wish to abort a request, you can simply call `die()` upon plugin
inclusion if certain criteria are met, or you could delay it until
WordPress is fully loaded (`init`) to allow other plugins to handle the
request if they wish (Such as a stats plugin which wants to record all
404's).
>
> > Personally, I am now including a check in all of my plugins, after
realizing the Wordpress process executes for all missing files referenced
in client-side mark-up.
>
> I'd be very careful about doing that - It's expected that
`/blah/blah/filename.jpg` be a request that's routed to WordPress and
handled sometimes by plugins.
>
> Personally I see the bug being that either the server is routing file-
requests to WordPress when you don't want it to, or that markup is being
used which references invalid paths.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/17246#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list