Twenty Seventeen: Fatal error

[swapnild]

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

[karmatosed]

@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?

[swapnild]

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?

[karmatosed]

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

[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. :)

[swapnild]

Thanks @davidakennedy, I got your point...

[ocean90]

#38471 was marked as a duplicate.

[TJNowell]

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

[ocean90]

@TJNowell You should see such a message if you activate the theme, see https://core.trac.wordpress.org/browser/trunk/src/wp-content/themes/twentyseventeen/inc/back-compat.php.

[danielbachhuber]

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

[Rarst]

#39187 was marked as a duplicate.

[Rarst]

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)

[davidakennedy]

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.

[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.

[Rarst]

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.

[dd32]

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)

[Rarst]

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.

[jbpaul17]

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.

[dd32]

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.