Make WordPress Core

Opened 8 years ago

Closed 7 years ago

#41572 closed defect (bug) (invalid)

Twenty Seventeen 'Call to undefined function get_template_part()'

Reported by: laserjobs's profile laserjobs Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Bundled Theme Keywords:
Focuses: Cc:

Description

Twenty Seventeen theme is NOT the active theme but must be getting some scrapers trying to access the file. These are the errors I am seeing in my logs causing a 500 error.

Error: Uncaught exception 'Error' with message 'Call to undefined function get_template_part()' in /home/wp-content/themes/twentyseventeen/footer.php:22

Error: Uncaught exception 'Error' with message 'Call to undefined function get_header()' in /home/wp-content/themes/twentyseventeen/404.php:13

Change History (4)

#1 @laserjobs
8 years ago

  • Component changed from General to Themes

#2 follow-up: @knutsp
8 years ago

  • Component changed from Themes to Bundled Theme
  • Version 4.8.1 deleted

This the expected behaviour if the folder wp-content is not protected from running .php files directy. This affects not only these Twenty Seventeen templates, but all php files in all installed themes and plugins. WordPress core isn't even loaded.

WordPress could add a protection at the top of all php files in the standard themes, but has quite deliberately not done so. It wouldn't eliminate the errors you see in the logs.

A few plugins I know use this at the top of the files:

defined( 'ABSPATH' ) || exit;

I use something like this in a /wp-content/.htacces file:

Order deny,allow
Deny from all
<Files ~ ".(xml|css|jpe?g|png|gif|js|eot|ttf|woff|svg|pdf|doc|docx|xls|xlsx)$">
Allow from all

The requirements here will be different from server to server, and from installation to installation. It's in it's nature a server issue when running php applications in general, not a WordPress core issue (IMO). At least until there is a way to handle this safely for all environments at installation time.

Last edited 8 years ago by knutsp (previous) (diff)

#3 in reply to: ↑ 2 @laserjobs
8 years ago

Got it, thanks. I was just thinking this could be abused due to the default naming across all WP sites.

Or I guess I could just remove the unused themes but I like to have at least one default for testing purposes.

https://codex.wordpress.org/Hardening_WordPress
Limit access: Reduce the number of people who have administrative access to your WordPress site to a minimum. You should also reduce the number of possible entry points to a minimum. You can do this by only installing web applications that you need and use. Remove any unused plugins and themes. These follows the principle of least privilege and provides administrative and logical controls to help preserve confidentiality, availability and integrity.

Replying to knutsp:

This the expected behaviour if the folder wp-content is not protected from running .php files directy. This affects not only these Twenty Seventeen templates, but all php files in all installed themes and plugins. WordPress core isn't even loaded.

WordPress could add a protection at the top of all php files in the standard themes, but has quite deliberately not done so. It wouldn't eliminate the errors you see in the logs.

A few plugins I know use this at the top of the files:

defined( 'ABSPATH' ) || exit;

I use something like this in a /wp-content/.htacces file:

Order deny,allow
Deny from all
<Files ~ ".(xml|css|jpe?g|png|gif|js|eot|ttf|woff|svg|pdf|doc|docx|xls|xlsx)$">
Allow from all

The requirements here will be different from server to server, and from installation to installation. It's in it's nature a server issue when running php applications in general, not a WordPress core issue (IMO). At least until there is a way to handle this safely for all environments at installation time.

Last edited 8 years ago by laserjobs (previous) (diff)

#4 @davidakennedy
7 years ago

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

@laserjobs,

Thanks for filing this ticket! And thanks to @knutsp for diving in with the explanation.

This doesn't look like a theme bug so I'm going to close it.

Note: See TracTickets for help on using tickets.