WordPress.org

Make WordPress Core

Opened 13 months ago

Closed 13 months ago

Last modified 12 months ago

#51219 closed defect (bug) (fixed)

Theme editor page showing undefined variable notice

Reported by: vinayak.anivase Owned by: SergeyBiryukov
Milestone: 5.5.2 Priority: normal
Severity: normal Version: 5.5.1
Component: Administration Keywords: commit fixed-major
Focuses: administration Cc:

Description

The theme editor ('wp-admin/theme-editor.php') page showing a "Undefined variable: error" notice for a fresh installation.

After checking the 'theme-editor.php' file, I found that the error variable used on line number 159 and 277 is not defined except on line number 153, where it is defined inside an 'if' conditional block.

<?php
if ( ! is_file( $file ) ) {
        $error = true;
}

The variable should be initialized prior to line number 152:

<?php
$error = false;
if ( ! is_file( $file ) ) {
        $error = true;
}

To recreate the issue, please enable debug mode and visit 'wp-admin/theme-editor.php' page.

Attachments (1)

undefined-variable-error.png (18.1 KB) - added by vinayak.anivase 13 months ago.
Notice: Undefined variable

Download all attachments as: .zip

Change History (9)

@vinayak.anivase
13 months ago

Notice: Undefined variable

#1 @SergeyBiryukov
13 months ago

  • Keywords dev-feedback removed
  • Milestone changed from Awaiting Review to 5.5.2
  • Owner set to SergeyBiryukov
  • Status changed from new to accepted

Hi there, welcome to WordPress Trac! Thanks for the report.

Just noting that while the $error variable could indeed be explicitly defined for better readability, that is not the issue here, as the variable is already set to an empty string by this line above:

wp_reset_vars( array( 'action', 'error', 'file', 'theme' ) );

The issue was introduced in [48850] / #51073, where this variable is now unset before it can be used.

It looks like the code in wp-admin/admin-header.php should use a unique or at least a less common variable name, something like $error_get_last.

#2 @SergeyBiryukov
13 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 48938:

Administration: Give the $error variable in wp-admin/admin-header.php a more descriptive name.

This avoids a conflict with the same global variable used elsewhere, e.g. in Theme Editor.

Follow-up to [48850].

Props vinayak.anivase.
Fixes #51219.

#3 @SergeyBiryukov
13 months ago

  • Keywords commit fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for backporting to the 5.5 branch.

#4 follow-up: @SergeyBiryukov
13 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 48955:

Administration: Give the $error variable in wp-admin/admin-header.php a more descriptive name.

This avoids a conflict with the same global variable used elsewhere, e.g. in Theme Editor.

Follow-up to [48850].

Props vinayak.anivase.
Merges [48938] to the 5.5 branch.
Fixes #51219.

#5 @SergeyBiryukov
13 months ago

#51279 was marked as a duplicate.

#6 in reply to: ↑ 4 ; follow-up: @youcefb
12 months ago

Hello,

I'm having the same problem here when firing the filter hook for registration_errors. I see that the problem is fixed but I was wondering if I should also fix it myself locally or wait for an update (my registration form validation is not triggering because of this). Can you please enlighten me as what to do next?

Thanks!

Best regards,

Replying to SergeyBiryukov:

In 48955:

Administration: Give the $error variable in wp-admin/admin-header.php a more descriptive name.

This avoids a conflict with the same global variable used elsewhere, e.g. in Theme Editor.

Follow-up to [48850].

Props vinayak.anivase.
Merges [48938] to the 5.5 branch.
Fixes #51219.

#7 in reply to: ↑ 6 @SergeyBiryukov
12 months ago

Replying to youcefb:

I'm having the same problem here when firing the filter hook for registration_errors. I see that the problem is fixed but I was wondering if I should also fix it myself locally or wait for an update (my registration form validation is not triggering because of this). Can you please enlighten me as what to do next?

It's likely that there will be a 5.5.2 release before 5.6, but there is no timeline at the moment, so I would suggest fixing the issue locally or working around it for now.

#8 @SergeyBiryukov
12 months ago

#51411 was marked as a duplicate.

Note: See TracTickets for help on using tickets.