[wp-trac] [WordPress Trac] #22802: Empower Plugin Developers to make Symlink Compatible Plugins

WordPress Trac noreply at wordpress.org
Sat Dec 8 00:48:05 UTC 2012


#22802: Empower Plugin Developers to make Symlink Compatible Plugins
------------------------------------------------+--------------------------
 Reporter:  MikeSchinkel                        |       Owner:
     Type:  enhancement                         |      Status:  reopened
 Priority:  normal                              |   Milestone:  Awaiting
Component:  Plugins                             |  Review
 Severity:  normal                              |     Version:  3.4.2
 Keywords:  has-patch dev-feedback 2nd-opinion  |  Resolution:
------------------------------------------------+--------------------------

Comment (by MikeSchinkel):

 Replying to [comment:12 scribu]:
 > > there is an existing load_theme() function
 >
 > I can't find it.

 <redfaced> I can't find it now either. Maybe it was in a plugin I had in
 my test site.  Or maybe I was confused when I saw
 `load_theme_textdomain()`.  Fortunately though, the name of the function
 is not important to the concept.

 > > In summary this addresses symlinking by enabling a new best practice
 >
 > Could you give an example of that best practice, from the POW of a
 plugin author?

 Sure.

 I implied it above in the example but explicitly stated it would be for
 the plugin author to capture the value of global `$wp_plugin_file` into a
 constant at the top of the plugin's entry point. So instead of this which
 is common in plugins:

 {{{
 define( 'MY_PLUGIN_FILE', __FILE__ );
 }}}

 This new ''"best practice"'' would be to do this instead:
 {{{
 global $wp_plugin_file;
 define( 'MY_PLUGIN_FILE', $wp_plugin_file );
 }}}

 Then anywhere in the plugin where `__FILE__` might be otherwise used the
 plugin developer would use `MY_PLUGIN_FILE` instead.

 Of course it doesn't have to be captured and made available as a global,
 it could be stored as a class property or something else, and the value
 doesn't have to be captured as a constant, it could be captured into a
 class property or another variable as well.  The key point is simply to
 somehow make sure that there is always a simple method to capture the
 plugin's file name that WordPress uses instead of the real path that has
 been symlinked.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22802#comment:13>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list