How best to define plugin directory across multiple classes?

[MickeyKay]

I'm currently working on a plugin with various require_once calls located in various classes. Some files are at the root, while others are nested at various levels. My question is, what's the best way to globally get the plugin URL/path? Since the files are all nested at different levels, plugin_dir_url( __FILE__ ) ) won't always return the same url.

With a global define? define( 'PLUGIN_URL', plugin_dir_url( __FILE__ ) );

With a call to a public function in my main plugin class? MyPlugin::get_instance()->get_plugin_url();

Some other method?

And this brings up another question I have (which is a noob OOP question): is it better to have all includes/requires in my main plugin file (with all the filter/logic to decide when to include what), or to include include/require calls only in the files that depend on them (this means potentially writing the same include/require call in multiple files, instead of just using some logic)?

Thanks Mark! Loving this format.

[markjaquith]

I tend to instantiate the "main" plugin class from the main plugin file, and pass along FILE. Like this:

<?php
/*
Plugin Name: Example
*/

include( 'classes/foo.php' );
include( 'classes/bar.php' );

FooPluginClass::get_instance( __FILE__ );

Then, have get_instance() pass that value on to the constructor which can set it and use it in get_plugin_url() and get_plugin_path() methods. Then other classes can do, as you suggested: FooPluginClass::get_instance()->get_plugin_url(), or, each of them can set up a reference to the main plugin and do $this->plugin->get_plugin_url().

I like this method because it lets you move the classes around without having to change how you set the base file path. You're saying "Okay, I want to spin up this plugin, and here's the location of the main file". Still lets your main plugin file to be pretty sparse.

I tend to do most of my includes in the main file. It might seem wasteful, but on most PHP systems with opcode caches, the parsing of those files is cached, so it's a negligible hit. In fact, I've seen suggestions that conditionally loading the files might actually be worse for performance due to opcode magic that I don't entirely understand.

[rmccue]

In fact, I've seen suggestions that conditionally loading the files might actually be worse for performance due to opcode magic that I don't entirely understand.

Supposedly, if files are non-conditionally loaded, the opcache will cache them all together rather than separately, meaning it can be loaded all at once. This is also the argument I've heard against ever including an autoloader in core. (Conditionally loaded files can't be cached like this, for a similar reason to that of the halting problem.)

Personally, I think autoloaders are cleaner and the conditional loading isn't an issue. :)

[MickeyKay]

Fantastic, thanks guys!

On Thursday, May 8, 2014, Ryan McCue notifications@github.com wrote:

In fact, I've seen suggestions that conditionally loading the files might actually be worse for performance due to opcode magic that I don't entirely understand.

Supposedly, if files are non-conditionally loaded, the opcache will cache them all together rather than separately, meaning it can be loaded all at once. This is also the argument I've heard against ever including an autoloader in core. (Conditionally loaded files can't be cached like this, for a similar reason to that of the halting problemhttp://en.wikipedia.org/wiki/Halting_problem .)

Personally, I think autoloaders are cleaner and the conditional loading isn't an issue. :)

Reply to this email directly or view it on GitHubhttps://github.com/markjaquith/feedback/issues/18#issuecomment-42521743 .