WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 11 years ago

#9105 closed defect (bug) (duplicate)

with empty 'show_on_front' option is_front_page always show false

Reported by: kookoooo Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8.6
Component: General Keywords:
Focuses: Cc:

Description

maybe just me, I don't have a 'show_on_front' value in db, by default the latest posts shows, but function is_front_page() won't work.

orig

function is_front_page () {
// most likely case
if ( 'posts' == get_option('show_on_front') && is_home() )
return true;

should be

function is_front_page () {
// most likely case
if ( (!get_option('show_on_front') || 'posts' == get_option('show_on_front')) && is_home() )
return true;

Attachments (1)

show_on_front.9105.diff (532 bytes) - added by filosofo 12 years ago.

Download all attachments as: .zip

Change History (9)

#1 @filosofo
12 years ago

  • Keywords has-patch added

You should have a "show_on_front" option, as it's part of the default database schema, so it should be part of either a new install or an upgrade.

My attached patch is a more succinct way of expressing the idea.

#2 @Denis-de-Bernardy
12 years ago

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

closing this as invalid. it gets added in the installer/upgrader, and never gets deleted. if it contains an invalid value, it's a plugin broke it.

#3 @danaronson
11 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 2.7 to 2.8.6

turns out this bug DOES exist (fix included). There is some conditional code that sets option values in options-reading.php. In a VERY standard case there is no else clause which sets them to the default values so later on options.php sets them to null.

I fixed it one way, but perhaps the better and more global fix is options.php to ONLY update the option is the value was set in the form (I didn't want to do that fix, because I don't know what it would break).

The way to duplicate this bug is to go to the options reading panel if there are no pages, update the option and voila, show_on_front gets cleared...

Here's the diff of the fix:

*** options-reading.php	Fri Jan 15 12:02:03 2010
--- options-reading.php.save	Fri Jan 15 11:44:00 2010
***************
*** 53,63 ****
  <?php endif; ?>
  </fieldset></td>
  </tr>
- <?php else: ?>
- 
- <input type="hidden" name="show_on_front" value="<?php echo get_option("show_on_front") ?>">
- <input type="hidden" name="page_on_front" value="<?php echo get_option("page_on_front") ?>">
- <input type="hidden" name="page_for_posts" value="<?php echo get_option("page_for_posts") ?>">
  <?php endif; ?>
  <tr valign="top">
  <th scope="row"><label for="posts_per_page"><?php _e('Blog pages show at most') ?></label></th>
--- 53,58 ----

#4 @scribu
11 years ago

  • Milestone set to 3.0

#5 @sivel
11 years ago

  • Keywords is_front_page has-patch removed
  • Milestone 3.0 deleted
  • Resolution set to duplicate
  • Status changed from reopened to closed

Dup of #12737

#6 @nacin
11 years ago

  • Resolution changed from duplicate to fixed

(In [14362]) When no pages are present add a hidden input field so that the show_on_front option is not blanked. Fixes is_front_page return value in an edge case. props sivel, fixes #12737, fixes #9105.

#7 @nacin
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Shouldn't have referenced this ticket in the commit, but I wanted to cross reference. Forgot it would move the resolution to fixed after it was already closed.

#8 @nacin
11 years ago

  • Resolution set to duplicate
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.