plugin_basename() functionality change?

[ringmaster]

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.

[ryan]

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

[ryan]

(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

[(none)]

Milestone 2.0 deleted