Codeigniter 3 - Third_party and controllers / loading ressources

Question

I'd like to use the controllers from the /third_party/myapp/controllers folder without having to move them to the /application/controllers one

It doesn't seem possible (at least not without hacking the core). Though the question concerns loading model, limitations are mentioned here

I don't feel like using HMVC - as stated in the solution proposed there, cause I don't need any other functionality than avoiding to multiply file transfer in CI base folders (i don't really need the 'hierarchical' part of it)

But I don't really get it... if one declares its third_party app, CI will load resources from those folders (as stated by the doc)

config/

helpers/

language/

libraries/

models/

[metaphysical] Why wouldn't it be possible to simply load controllers as well ?

[pragmatic] is it a good idea to try to hack the core system or should I stay on the "HMVC or do copy your files" choice ?

[optimistic] do someone have a solution ?

EDIT

While looking further to trajchevska tip in another installation of CI, I tried to implement DFriend example of spl_register. I read several times the manual and this answer as well : So far I understood that spl_autoload_register is triggered when a class is called, which allows to skip their manual loading

So I've tried simply adding the spl_autoload_register at the end of the config file in application/config/config.php, expecting it to print Auto load ClassName when a first class is called - a bit naïve, I know.

but from what I understood (thanks to DFriend), this spl_autoload_register would NOT work with controllers, as CI will always check if the file exists (in its own path) before trying to declare the controller.

It seems on the other hand that it could work with other classes (core, model ... see DFriend answer below)

Conclusion

So, after a few hairs pulled out of my head, I decided to try the HMVC extension for CI - MX from WireDesign. It solved my problem of loading any resources from different folder, along with bringing a brand new scope of shared classes and their attached issues (what is available where ?).

As it's the beginning the project I had the opportunity to switch to the "hierarchical" side, otherwise I'd followed Dfriend's advice of

going with the flow and putting controllers for third-party packages where CI expects them to be

Answer 1

I assume it's because of the routing process - the CI Router checks whether a corresponding controller exists in the application folder, or a respective route is defined in the config. If none of them is found, 404 is returned.

You can override the Router file to enable loading controllers from other locations. In the core folder, create a MY_Router file that will extend the CI_Router. Then extend the _validate_request function, to allow loading controller files from different path than the default.

UPDATE: So, I've spent some time on this and didn't manage to extend the Router to get the controller file from the third party folder. It's easy to do when it comes to subfolders of the default controllers directory, but setting up a custom directory for reading the controllers is not that straightforward and unfortunately, I couldn't find any documentation on that.

Answer 2

You could use PHP's spl_autoload_register to implement an autoloader. A google search will reveal multiple approaches for using one within the CI framework.

One that works and is often described is to register the autoloader in config.php or maybe a site-specific constants file. Such a solution is to put something like this in one of the mentioned files.

spl_autoload_register(function($class)
{
  if(strpos($class, 'CI_') !== 0)
  {
    if(file_exists($file = APPPATH.`/third_party/myapp/controllers/`.$class.'.php'))
    {
      require_once $file;
    }
  }
});

You can use hooks if you want to avoid hacking config.php or some other file. Here's one way to do that.

application/config/config.php

$config['enable_hooks'] = TRUE;

application/config/hooks.php

$hook['pre_system'][] = array(
  'class' => '',
  'function' => 'register_autoloader',
  'filename' => 'Auto_load.php',
  'filepath' => 'hooks'
);

application/hooks/Auto_load.php

<?php

defined('BASEPATH') OR exit('No direct script access allowed');
function register_autoloader()
{
  spl_autoload_register('my_autoloader');
}

function my_autoloader($class)
{
  if(strpos($class, 'CI_') !== 0)
  {
    if(file_exists($file = APPPATH.`/third_party/myapp/controllers/`.$class.'.php'))
    {
      require_once $file;
    }
  }
}

Addendum

On further digging and consideration the above will not work because CI insists that Controllers be in the application/controllers directory or a subdirectory thereof.

PHP will run a registered autoloader when you try to use a class/interface which hasn’t been defined yet. Controllers are php classes so you might expect an autoloader to come to the rescue. But CI is very explicit about where it looks for controller files. If the file is not found then it never attempts any calls to the class. Instead it abandons all hope and immediately issues an 404 error. The autoloader never gets a chance to look for the file.

The answer to the metaphysical question is that CI's routing and URL parsing are tightly coupled to the file storage structure making the desired functionality impossible. (without some serious core hacking)

The answer to the pragmatic question is very subjective. I'm not fond of the HMVC approach and personally would opt for going with the flow and putting controllers for third-party packages where CI expects them to be.

Start: Serious diversion from question at hand

So, what good is registering an autoloader in the CI environment?

Controllers are defined like so.

class Home extends CI_Controller{ ...

The class being extended, CI_Controller, is a core class. If you want to extend this core class for use by multiple other controllers you can use the CI convention of prepending the class name with "MY_". e.g.

class MY_Controller extends CI_Controller
(
   //class implementation
}

and then use it to define actual controllers using the extended core class

class Home extends MY_Controller{ ...

The problem is that you can only extend the core CI_Controller once using this convention. What if you have a need for more than one extension to the CI_Controller core class? One solution is registering an autoloader. (A good discussion of this and other ways to overcome the MY_Controller monopoly is HERE.)

An autoloader for these purposes could look this.

spl_autoload_register(function($class) 
{
  if(strpos($class, 'CI_') !== 0)
  {
    if(file_exists($file = APPPATH.'libraries/'.$class.'.php'))
    {
      require_once $file;
    }
    elseif(file_exists($file = APPPATH.'models/'.$class.'.php'))
    {
      require_once $file;
    }
    elseif(file_exists($file = APPPATH.'core/'.$class.'.php'))
    {
      require_once $file;
    }
  }
}

Note that the above also allows you to extend models from other models.

End: Serious diversion from question at hand