On Windows machines register_activation_hook() does not work if plugin is in a subfolder of the plugins dir

[McShelby]

If you try to create a plugin in a subfolder of the 'plugins' directory and your are running Wordpress on a Windows machine, the function registered by register_activation_hook() will not be executed.

This is because of different backslashes on UNIX and Windows and the way the function plugin_basename()/admin panel works.

On Windows plugin_basename() returns the backslash in its return value while on Unix returning the slash. The plugins activation screen in the admin panel of Wordpress is always using slashes. You can easily see this by hovering over Askimets activate/deactivate button.

register_activation_hook() is using plugin_basename() to install the activation filter while the file wp-admin/plugins.php will use the value from the plugins activation screen to access the installed filter. Because of different slash types, the filter will not be found and so will never be executed.

If you take a look into the Bad Behaviour 2.0.4 plugin, you'll see from the comments that other guys have had the same problem with register_activation_hook().

We can convert everything to slashes when registering the hook.

From my point of view I am not sure which one to fix: plugin_basename(), the codepart in plugins.php or the code location where the activate/deactivate links for the plugin admin panel are generated.

I fear that different slash types may cause problems in other parts of WP too.

I think it's not the best idea to fix the slash during registration of the hook. I would prefer having the correct slash in the link of the activate/deactivate button.

Why is there no interest in fixing this hook with the next *gasp* "major" version of WP?

The release of 2.1 is nearby, therefore people don't want to change anything "major" anymore for that release, but just get it stable and out of the door.

The 2.2 version will have a much shorter release time than 2.1 has had. It's expected to be around 4-6 months after the 2.1 release, so pushing this back to 2.2 doesn't mean you'll have to wait very long for it to be incorporated.

Also providing patches helps getting things in faster. We can't fix anything without somebody creating a patch.

Patch avail on #4408

plugin_basename fix from #4408

(In [5924]) Fix plugin basename for Windows servers. Fixes #3002 props Ozh

re-open for backport to 2.2.3

(In [5928]) Fix plugin basename for Windows servers. Fixes #3002 for 2.2.x props Ozh