Thread

The MY_Loader extension from Modular Extensions HMVC is designed so you can modify it as you wish. The only requirement is that it extends MX_Loader (which does extend CI_Loader in turn)

Simply copy the contents of any other MY_Loader class into the version provided, but leave the class declaration as is.

Thank you wiredesignz,

That seems to have fixed it. I was not aware that I could just move the code over like that. Maybe add that piece to the install instructions for us newbs 😊 Sorry if it’s there and I missed it.

Thanks again

I wanted to add since I’ve been doing some testing,

I can’t have any of my existing controllers extend MX_Controller because it doesn’t extend CI_Controller.
I tried extending CI_Controller from MX_Controller and get blank pages on some and on others they can’t access session which breaks them.

I tried

class MX_Controller extends CI_Controller
{
     parent::__construct();

//then the rest of the MX code below

It doesn’t like that. I found that in one case it has something to do with the __get magic function but of course I can’t leave that commented out as it’s part of MX functionality.

Is there a way to have MX_Controller extend CI_Controller?

MX_Controller does not extend CI_Controller.

Your controllers should extend MX_Controller if you wish to develop using modules together with the HMVC design pattern.

If you wish to develop using modules only (without HMVC) then your controllers can extend either CI_Controller or MX_Controller.

Yep I just about have it all figured out now. One more question. I have a mytest application controller successfully loading a modules/modtest/ controller which is loading a view modules/views/mod/mod.php. from the index() function. The reason for the directory structure is I am trying to mimic the base applications layout management but that’s something I need to work on later and I don’t think will be affected by using MX. The problem that I am having is that I have to call index() in the constructor. It’s not running automatically.

Here’s the module controller where you can see that I call index() in the constructor. If I don’t do that it stops after the constructor runs and gives me a blank page. I put a echo/die to confirm it is running the constructor.

This only happens with module controllers. The application controllers run index() as expected.

<?php  if (!defined('BASEPATH')) exit('No direct script access allowed');
require_once(APPPATH . 'third_party/MX/Controller.php');
class Modtest extends MX_Controller
{
    var $user = FALSE;
    
    public function __construct()
    {
        parent::__construct();
        if($this->session->userdata('user_id'))
        {
            $this->user = $this->session->userdata('user_id');
        }
        $this->index();
    }
    
    public function index()
    {
        
        if($this->user){
        $this->load->view('mod/mod');
        }
    }
}

Thanks for your help thus far.

The MX_Controller is automatically loaded via spl_autoload, you do not need the require_once code unless your own __autoload code is causing the existing loader to fail.

Your call to run a module needs to include the module name, the controller name and the method name like so:

//module and controller names are different, you must include the method name also, including 'index'
modules::run('module/controller/method', $args, ...);

//module and controller names are the same but the method is not 'index'
modules::run('module/method', $args, ...);

//module and controller names are the same and the method is 'index'
modules::run('module', $args, ...);

//$args are optional

Well the MY_Loader I asked about previously does include a lot of modification/overriding of ci’s autoload. It’s autoloading sparks. So, it may be causing the problem.

I took out the require_once lines and tried both modules::run() and $this->load->module() and they both work all except having to explicitly call index() in the constructor of the module controller. I’ll look at the autoload code for sparks and see if I can see where it might be causing the issue. Otherwise it’s not a big deal having to put in the short call to $this->index();

I don’t know if you use sparks with codeigniter but here’s the link for the MY_Controller.php if you want to see if it is interfering with MX. http://getsparks.org/static/install/MY_Loader.php.txt

I added the require path and changed it to extend MX_Controller like you told me to but haven’t touched any of the other code.

It could also have to do with phpar which is the spark I have installed. I haven’t even begun to look at that code.

Or it could be that I"m still doing something wrong. I’ll spend a while going through all the code and maybe figure it out.

Thanks

You do not need to call index() from your constructor if your modules:run() calls are structured correctly. (See my previous post)

FYI. The ci_autoloader() method is not the same as using the php magic method __autoload or spl_autoload.
Modular Extensions HMVC uses spl_autoload to load base classes, your code may be interfering with its functionality.

Sorry about that. I was thinking my names were the same but it was the module and module view that were the same and I was using the first method as if my main controller and module controller were the same. Big duh! moment on my part.

It seems to be working perfectly now along side php active record and I was also able to add the debug-toolbar spark this morning and get it working very easily with the module pages.

Thank you very much for your patience and help.

I love HMVC but when I’ve installed sparks and php-activerecord spark on it, sparks did not run. I looked around so much but could not solve the problem. sparks use a loader library as hmvc and this causes problem.

I hope this will be solved soon and a I roll my code back to happy modules 😊

thanks.

I love HMVC but when I’ve installed sparks and php-activerecord spark on it, sparks did not run. I looked around so much but could not solve the problem. sparks use a loader library as hmvc and this causes problem.

I hope this will be solved soon and a I roll my code back to happy modules 😊

thanks.

I did get mine to work by putting the sparks MY_Loader code into the MX MY_Loader.php.

Actually I got rid of the one that came with MX and just changed my existing one that autoloads the sparks to

require(APPPATH . 'third_party/MX/Loader.php');
class MY_Loader extends MX_Loader
{
     //sparks autoload code here
}

It works as wiredesignz says because MX_Loader in turn extends CI_Loader.

It does concern me though. Not just for MX but for all addons/extensions/whatever

There can be only one ‘MY_Loader.php’ and it won’t always work to just chain extends together in a loop to get back to the ci loader. Imagine if there were 2 or 3 other third_party apps that all require MY_Loader to extend their specific loader class. And in my humble newbial opinion it is strange and breaks hierarchical order to extend a third party that extends a core file. But as I say, I’m a newb and I don’t fully understand the complexities of making hmvc work.

Can someone please post a link to download [the latest version of] this extension the referenced URL https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home, no more contains a download link for this extension.

Can someone please post a link to download [the latest version of] this extension the referenced URL https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home, no more contains a download link for this extension.

https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/get/tip.zip

Thanks Glazz, though was able to later locate the link myself as well but am not sure how to use it, hmm .. would love to find a sample application using it.

@Tanver

Hero CMS http://www.heroframework.com

@wiredesignz
Thanks, am just looking at it.