wire("config")->urls->admin in autoload module init() not available?

[Soma]

Why is this?

The config doesn't seems to fully work, but for example wire("config")->httpHost does. One would assume it should work, if it says in the comments that in the init() will have the API ready, it took me a while to realize the wire("config")->urls->admin doesn't return anything.

[ryan]

The reason for this is that init() is called before any pages are loaded. This is so that you have the opportunity to hook into things like $pages->find and expect that your hook won't miss any pages. The admin URL is dependent upon what name you've given to your admin root page. I think it's actually the only $config->urls property that wouldn't be ready in init(). Given that, I could probably come up with a way for it to be populated before init() (like a direct SQL query)--I think I will do this. However, for now, I'm thinking that you probably want to use ready() rather than init(), since the requested page and admin page have been loaded by that time. When you use ready(), the API is fully ready without exception. But for some autoload modules, the events they wanted to hook into have already occurred, or their hook was attached after $page was already loaded by $pages->find(), etc. I think it's best to start with ready(), and if it's not doing what you need, switch to init(). Also, this may be obvious after the above, but if your module needs to access any kind of data or function from the loaded $page, then ready() is the only way to go.

[Soma]

Thanks Ryan for the explanation. I have to use init() as to change the $_GET("it") before page load. I have used $this->pages->get(2)->url to get the admin url (which may have changed).

[ryan]

I've made some updates to have $config->urls->admin ready before init() is called. I can't think of any reason not to have it available, especially since (as you mentioned) the $pages API var is accessible (even if no pages have been loaded yet). I'll commit to the source here within the next day or so.

[Soma]

If it's not of an issue to have it set in the init. Just thought I'd ask here since I assumed it should be available and couldn't see why it shouldn't. Thanks Ryan!

[porl]

I wonder if this is related to the odd behaviour I had in the Twig module when I had to use wire('config') rather than $config?

[apeisa]

In modules you always have to use either wire('config') or $this->config

[porl]

Sorry, I meant $this->config. wire('config') works fine, but $this->config failed when I had a tilde in the url (I had localhost/~porl/processwire as the url at the time). I ended up using wire('config') instead and it all worked well. At one point I added a line at the start of $this->config = wire('config') and then it worked but that was obviously a bit of a nasty hack so I didn't use it.

[ryan]

I don't think it's a related behavior here. Ultimately $this->config and wire('config') are the same call. But $this->config gets passed through a __get() method method, so it can be interrupted if __get() gets overridden and doesn't pass control to wire() when it finds an unrecognized property. It's still a mystery to me as to why $this->config didn't work in your module.

[porl]

I don't think it's a related behavior here. Ultimately $this->config and wire('config') are the same call. But $this->config gets passed through a __get() method method, so it can be interrupted if __get() gets overridden and doesn't pass control to wire() when it finds an unrecognized property. It's still a mystery to me as to why $this->config didn't work in your module.

No problem. As I said it works fine with wire('config') and I'm happy to use that. It is most likely that I missed something or did something braindead and this was causing the error. If it isn't related t this issue I'll politely step out of the way