Make WordPress Core

Opened 10 years ago

Closed 10 years ago

#38411 closed defect (bug) (wontfix)

Twenty Seventeen: Fatal error

Reported by: swapnild Owned by:
Priority: low Milestone:
Component: Bundled Theme Version:
Severity: normal Keywords:
Cc: Focuses:

Description

There is a fatal error on front page.

Fatal error: Uncaught Error: Call to undefined function twentyseventeen_edit_link()

Screenshot: http://bsf.io/7rdnc

Note: After short debug found - function twentyseventeen_is_frontpage() called in file \twentyseventeen\functions.php - Line 116
But, Defined in file \twentyseventeen\inc\template-functions.php` - Line - 90

Change History (24)

#1 @karmatosed
10 years ago

  • Milestone Awaiting Review
  • Resolutionworksforme
  • Status newclosed

@swapnild I am unable to get this despite trying both to set a static page and also showing blog posts on front. You need to have the latest version of 4.7 (nightly) running for this theme. Could you also make sure you have no other plugins on that install just incase.

Should you still be experiencing this issue, can you let us know more about your setup please. What browser, what system are you running this on?

#2 @swapnild
10 years ago

Thanks @karmatosed , with the nightly version of 4.7 it is working, but I have one question is twenty seventeen theme is not compatible with WP4.6.1?

#3 @karmatosed
10 years ago

@swapnild no it's not compatible backwards beyond 4.7.

#4 follow-up: @davidakennedy
10 years ago

@swapnild This probably happened because you were running a version of the theme that didn't have its needed backward compatibility script, added before its merge into Core. So when you updated and the theme was still active... you got fatals because the theme shouldn't have been running on a version lower than 4.7.

Sorry for the trouble. :)

#5 in reply to: ↑ 4 @swapnild
10 years ago

Replying to davidakennedy:

@swapnild This probably happened because you were running a version of the theme that didn't have its needed backward compatibility script, added before its merge into Core. So when you updated and the theme was still active... you got fatals because the theme shouldn't have been running on a version lower than 4.7.

Sorry for the trouble. :)

Thanks @davidakennedy, I got your point...

Version 0, edited 10 years ago by swapnild (next)

#6 @ocean90
10 years ago

#38471 was marked as a duplicate.

#7 @TJNowell
10 years ago

If the theme is incompatible with <4.7, it should check and say so,else people will install it and get cryptic messages. I see back-compat.php has a notice that displays when the theme has been switched, but I did an svn up, and if the notice did show it doesn't now.

twentyseventeen_edit_link is defined in inc/template-tags.php and included via get_parent_theme_file_path, hence the 4.7 restriction, it would be better to display a note on the frontend rather than a stack trace though

#9 @danielbachhuber
10 years ago

@ocean90 The version numbers in some WordPress builds are incompatible with version_compare(), see https://github.com/wp-cli/wp-cli/pull/2237

#10 @SergeyBiryukov
10 years ago

  • Summary Twenty Seventeen:Fatal errorTwenty Seventeen: Fatal error

#11 @Rarst
10 years ago

#39187 was marked as a duplicate.

#12 @Rarst
10 years ago

  • Resolution worksforme
  • Status closedreopened

Yep on builds, clearly the issue on dev checkout of core at least:

var_dump( $GLOBALS['wp_version'], version_compare( $GLOBALS['wp_version'], '4.7-alpha', '<' ) );
// string(7) "4.7-src" bool(true)

#13 @davidakennedy
10 years ago

  • Priority normallow

Thanks for reopening @Rarst!

I chatted with @ocean90 about this because I originally couldn't reproduce it. Here are the steps:

  1. Enable 2017
  2. Open /wp-includes/version.php and change $wp_version to '4.7-src'
  3. Now visit the home page

Fatal error: Call to undefined function twentyseventeen_is_frontpage() in /srv/www/wp-develop/svn/src/wp-content/themes/twentyseventeen/template-parts/header/site-branding.php on line 30

This probably happens with all default themes that have some kind if back-compat file to limit the version it's activated on.

It's possible we could do something similar to this:

https://meta.trac.wordpress.org/browser/sites/trunk/api.wordpress.org/public_html/translations/core/1.0/index.php?marks=10#L10

But this would be low priority, I think.

#14 @dd32
10 years ago

  • Milestone4.7.1

#15 follow-up: @dd32
10 years ago

[39576] will help here, I don't think we need to do anything else.

The only people who would have 4.7-src as their version would be those who were running from the branch - if they're running from the branch, you'd expect them to be keeping up to date with it.

#16 in reply to: ↑ 15 @Rarst
10 years ago

Replying to dd32:

[39576] will help here, I don't think we need to do anything else.

The only people who would have 4.7-src as their version would be those who were running from the branch - if they're running from the branch, you'd expect them to be keeping up to date with it.

I don't see how this helps. I run stable version, just from dev repo (because reasons), alpha states are usually irrelevant to me.

Broadly if WP relies on version checks then they should be implemented consistently with its own versioning convention. WP came up with -src on its own (as it does), it's WP's problem that version_compare() doesn't handle it out of the box.

#17 @dd32
10 years ago

I don't see how this helps. I run stable version, just from dev repo (because reasons), alpha states are usually irrelevant to me.

No, you're running a development version, as designated by running from a source repo (-src in version number) - these are builds which do not have our build processes applied to them.

If you want to run a stable version from version control, you should be pulling from a built version, such as from https://core.svn.wordpress.org/ instead (which is src run through the build process)

#18 @Rarst
10 years ago

To be clear I know the difference between sources. As I said I need to run development version for my purposes, but my way of using it is checking out tag which corresponds to stable versions.

Those do have versions like 4.7-src and do fail with this check.

I don't think this is something that can be talked away. At the moment WordPress core uses versioning scheme and versioning checks which are incompatible with each other. As long that is the case this is not the first time (I had issues before) and not the last time this causes problems.

This ticket was mentioned in Slack in #core by azaozz. View the logs.


10 years ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


10 years ago

#21 @jbpaul17
10 years ago

  • Milestone 4.7.14.7.2

Per the bug scrub today in #core: this will be punted to 4.7.2 as it won't be ready for commit in time for 4.7.1.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


10 years ago

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


10 years ago

#24 @dd32
10 years ago

  • Milestone 4.7.3
  • Resolutionwontfix
  • Status reopenedclosed

I'm closing this as wontfix.
My reasoning is:

  • 4.7-src should no longer be run in production, 4.7.2 is the minimum secure version that the theme supports
  • 4.7-src is still a super edgecase that we don't really need to handle here, but should be kept in mind for TwentyEighteen.
Note: See TracTickets for help on using tickets.