Welcome Guest, Not a member yet? Register   Sign In
Adding additional "packages" to Autoload->psr4

I am in the process of learning some of the new ideas in CI4 before it goes live (next year???)
One of my more important libraries is my Package Manager and I am looking into how I can dynamically add to the CI4 $psr4 array and where.

Currently in CI3 my package manager gives a client/user the ability to upload a package or they can simply "composer it in". After which they can use the GUI/CLI to installer/upgrader/uninstaller those packages this is done by modifying the application/config/autoload.php -> $autoload['packages'] array. Of course the current system of loading libraries in CI3 creates a lot of file system scans.

Since we are now using the composer autoloader (ya!) and the autoload configuration file is no longer a simple array (var_export() did a great job there!) what is the best way to add additional namespaces (packages) to the application/Config/Autoload.php $psr4 array()?

I see a public $psr4 in the Autoload.php class and a array_merge at the bottom of the constructor? Is there some where early enough in the bootstrap process I can attach some thing on to that?

One other thing I noticed is that there doesn't seem to be a root path constant like APPPATH or BASEPATH. Since we are now working with a "public" folder by default (ya!). It would be nice to have a constant point to the project root. ROOTPATH or something? Then in my code I don't need to use APPPATH.'/../Orange' like below to attach a namespace.

PHP Code:
$psr4 = [
'Config'                     => APPPATH.'Config',
APP_NAMESPACE                => APPPATH// For custom namespace
'App'                        => APPPATH// To ensure filters, etc still found
'Orange'                     => APPPATH.'/../Orange',

It could just be ROOTPATH.'/Orange' or ROOTPATH.'/personal_packages/Orange'

I look forward to your comments.


The use of classes for configuration does make it a little more difficult to change the configuration programmatically and save those changes back to the original configuration file. However, it does mean that you can modify your application's Config\Autoload class to pull that data from another location in whatever manner makes sense for your application.

If you're more comfortable modifying the index.php file than the Config\Autoload class, you could modify the psr4 property as needed before it is passed to $loader->initialize(), like so:

PHP Code:
$loader CodeIgniter\Services::autoloader();
$loaderConfig = new Config\Autoload();
$loaderConfig->psr4 array_merge($loaderConfig->psr4$dataRetrievedFromElsewhere);

If you can wait a little longer, you could use a 'pre_system' hook or a 'before' filter to re-initialize the autoloader.

Another possible alternative would be to handle it with Composer instead of CI4's Autoloader, if it's easier for your application to configure Composer. Then you would just enable Composer by setting the $composerAutoload property in Config\App, just like CI3's composer_autoload setting.

(This post was last modified: 07-29-2016, 02:06 PM by mixinix.)

This is my poor skill and trick... and works.

PHP Code:
$psr4 = [
APP_NAMESPACE                => APPPATH,
'Config'                     => APPPATH.'Config',
       // Base Class
       'App\Base'                   => APPPATH.'Base',
array_merge((array)(@include(WRITEPATH 'modules.php')), $psr4); 

In CodeIgniter4, many tricks and combinations I can do, everywhere and anywhere. Of course, with namespace.


PHP Code:

return [
   'Module\Template\AdminLTE'   => APPPATH.'../modules/Templates/AdminLTE',
    'Module\Blog'                => APPPATH.'../modules/Blog',
    // Widgets
    'App\Widgets'                => APPPATH.'Widgets',
    // Third Parties
   'ThirdParty\Mixinix\Template'  => APPPATH 'ThirdParty/Mixinix/CodeIgniter4-template',
    // From Github libraries
   'Pug'  => GITHUB_PATH 'pug-php/pug/src/Pug',
   'Jade'  => GITHUB_PATH 'pug-php/pug/src/Jade',

That modules.php file can be created and modify form database.

mwhitney - I noticed hooks weren't working shortly after I wrote the original post. Since this is more of a CI4 discovery phase for some of my more complex CI3 workarounds (not sure if that's the right word?) I have no problem waiting. On a side note I like that hooks have been expanded. I currently have a events library but, it looks like the expanded hooks with priorities and closures will replace that!

mixinix - That's actually a pretty good idea as well.


Theme © iAndrew 2016 - Forum software by © MyBB