Make WordPress Core

Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#1866 closed defect (bug) (fixed)

plugin_basename() functionality change?

Reported by: ringmaster Owned by: ringmaster
Milestone: Priority: normal
Severity: trivial Version: 1.6
Component: Administration Keywords: plugin
Focuses: Cc:


It's very useful to have a function that returns the filename and optional subdirectory of a plugin file from within the plugin.

For example, it makes it much easier to do something like this from within a plugin:

<script src="<?php echo get_settings('siteurl') . '/wp-content/plugins/' . dirname(plugin_basename(FILE)); ?>" ...></script>

Otherwise, every plugin with this type of functionality needs to include its own plugin_basename()-like function.

In rev #3025, stripslashes() is applied to the returned basename, rendering it useless for the above purpose on Windows systems, IIS or Apache (even if it does enable option pages from subdirectories).

Roll back this change and suggest that affected plugins use the newer function-based add_options_page() parameters with just basename(FILE), which works fine even from subdirectories.

Change History (3)

#1 @ryan
10 years ago

stripslashes() needs to be called before calling plugin_basename(). In the case of #1599, we could do stripslashes in admin.php.

#2 @ryan
10 years ago

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

(In [3139]) Don't stripslashes() in plugin_basename() since this breaks established expectation of being able to pass a non-escaped FILE. Instead, stripslashes further up the stack. fixes #1866

#3 @anonymous
9 years ago

  • Milestone 2.0 deleted

Milestone 2.0 deleted

Note: See TracTickets for help on using tickets.