Make WordPress Core

Opened 5 years ago

Last modified 6 weeks ago

#47154 new enhancement

Prevent "Call to undefined function: get_header()" error in theme files

Reported by: devonto's profile devonto Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version: 5.1.1
Component: Bundled Theme Keywords: dev-feedback
Focuses: Cc:

Description (last modified by SergeyBiryukov)

Referencing a ticket from 14 years ago(!) (#1530), I would like to propose that the default WordPress themes - and the theme developer guidelines - be updated to include protection from accessing theme files directly.

Accessing these files give PHP warnings, usually as follows:

Fatal error: Call to undefined function: get_header()

Whilst @markjaquith was correct in stating that theme files are not supposed to be accessed directly, bots are finding their ways into theme folders (and triggering index.php) specifically, resulting in the errors being logged.

I believe it'd be good practice to extend the recommendation from the "Writing a Plugin" documentation (https://codex.wordpress.org/Writing_a_Plugin#Plugin_Files) to the "Theme Handbook" (https://developer.wordpress.org/themes/template-files-section/page-template-files/)

Following that recommendation, updating twentynineteen et al to include this (or at least code similar in intention) as the first lines of PHP coding.

defined( 'ABSPATH' ) or die( 'No script kiddies please!' );

Change History (9)

#1 @SergeyBiryukov
5 years ago

  • Component changed from General to Bundled Theme
  • Description modified (diff)

Related: #47109

#3 @SergeyBiryukov
5 years ago

#47109 was marked as a duplicate.

#4 @SergeyBiryukov
3 years ago

#53183 was marked as a duplicate.

#5 follow-up: @SergeyBiryukov
3 years ago

Hi there, welcome to WordPress Trac!

Thanks for the ticket, sorry it took so long for someone to get back to you.

I think the reason this has not seen any traction yet is because these fatal errors are considered a server configuration issue rather than a security issue per the Security FAQ:

Why are there path disclosures when directly loading certain files?
This is a server configuration problem. Never enable display_errors on a production site.

#6 in reply to: ↑ 5 @devonto
3 years ago

Replying to SergeyBiryukov:

Hi there, welcome to WordPress Trac!

Thanks for the ticket, sorry it took so long for someone to get back to you.

I think the reason this has not seen any traction yet is because these fatal errors are considered a server configuration issue rather than a security issue per the Security FAQ:

Why are there path disclosures when directly loading certain files?
This is a server configuration problem. Never enable display_errors on a production site.

Thanks for the update.

I completely agree that errors should not be displayed on a production site, however logging of errors is still good practice.
It is from the server error logs where this is being displayed.

My suggestion is simply to change the recommended setup for PHP files to follow what you have already recommended for plugins.

In addition to triggering index.php files, I often see header.php etc being directly accessed. These are all bot-accessed; so I can only assume they are snooping for vulnerabilities.

Changing the recommendations to include a check if WP is loaded would only serve to improve security.

#7 @karmatosed
6 weeks ago

  • Keywords close added

Unless I am mistaken this is possibly not something should be fixed inside the theme. I would like clarification of that though particularly considering the time that has gone by. For now, I am going to cautiously add the keyword 'close' and leave for opinions incase we need to pivot from that.

#8 @devonto
6 weeks ago

If the file is being accessed directly, how else would you suggest handling this?

My suggestion is to change how the core both implements in their own themes and recommends to all theme developers that they open their theme files with the simple check if ABSPATH is defined.

Thanks

#9 @karmatosed
6 weeks ago

  • Keywords dev-feedback added; close removed

@devonto I am happy to remove close and put this back to dev-feedback, however it has already received some feedback from @SergeyBiryukov which I agree with. That said, let me move it back to that key word for further discussion.

Note: See TracTickets for help on using tickets.