event addon file is loaded before e_module addon... was it always this way?

[Jimmi08]

Hi,
I wouldn't notice this but I use constant in e_module and there was an error if I used it e_event file (outside class).
Then I noticed that e_event file is loaded before e_module file in class2.php
So I put code into config method of event class, but result was the same.

There is this note in class2.php
// Load e_modules after all the constants, but before the themes, so they can be put to use.

• this is correct behavior

But with this
e107::getEvent()->init();
are register all events before e_module.

If this is correct and planned, I can put code from e_module in e_event file directly. Correct?

And why is not e_module file example used in _blank plugin?

Thanks

[Vodhin]

I can put code from e_module in e_event file directly. Correct?

I do not recommend it. As far as I can tell, class2.php does not look for an e_event.php file in the plugin folders directly. An e_event.php file may be called by other steps called by class2. I think a plugin's e_event.php file was intended as a way to neatly integrate your own event handlers into e107 core events. I've never used it.

And why is not e_module file example used in _blank plugin?

Your plugin's e_module is loaded on every e107 page - front end or back end - regardless of weather or not the user is viewing a page in your plugin. It is very useful when your plugin needs to do things when a user is NOT on a page of your plugin. Most plugins shouldn't need to use e_module unless you need information that is either shared by a companion plugin or used in conjunction with sidebar menu: e_module can examine e_QUERY, fetch DB results and be used to create Globals that your plugin's pages and menus can then both use, instead of querying your DB multiple times.

Since e_module is loaded all the time, many plugins with bloated e_module files can slow down your website. I typically check e_PAGE to see if the user is on a page that needs e_module scripts to run. On some custom websites I've made, I modify the e107core/templates/footer_default.php file to unset any Globals generated by the e_module file, just to be nice.

[Jimmi08]

As far as I can tell, class2.php does not look for an e_event.php file in the plugin folders directly.

It is. These lines before e_module loading are loading e_event.php files:

$e_event = e107::getEvent(); 
e107::getEvent()->init();

I tested and checked with the practice example. So using constant in e_module is too late. Because it surprised me (I had that same opinion as you), I asked if it is intention or bug.

Your plugin's e_module is loaded on every e107 page.

Yes, and it is intention. e_module is for loading before the theme. And I need this behavior. I was including Wordpress functionality, so e_module was the right way. Now, it is not, but it is not important for me anymore.

regardless of whether or not the user is viewing a page in your plugin.

You could say this about e_header addon too. It is loaded in admin area too (it wasn't in early e107 2 version this way) - e_header should be for frontend theme loading only... long story. Not mention that checks for admin area or user area sometimes fail.

I typically check e_PAGE to see
Check closed issues related to e_PAGE. No good idea. Use routes or e_CURRENT_PLUGIN or something like that.

But thanks for your time. You are awesome in how you are trying to explain things. I appreciate this, but for some time I don't want to do anything with e107.

[Moc]

I think a plugin's e_event.php file was intended as a way to neatly integrate your own event handlers into e107 core events. I've never used it.

e_event.php is used to run your own plugin code whenever an event is triggered. This could be core events or (other) plugin events. It basically is a listener. For example, it could listen to the event user_signup_activated, so whenever a new user signup is activated, you can then run some custom code.

Also @Vodhin is entirely correct about the e_module.php file and its potential bottlenecks.

I can put code from e_module in e_event file directly. Correct?

No. They are two separate addons with each separate use cases. They're not interchangeable.

@Jimmi08 If you can describe your end goal (what is it that you're trying to achieve) we can give better advice on how to do it (e.g. choosing the right addons or methods)

[Jimmi08]

@Moc I know what is use of e_event module, but the file itself is included before e_module file.

I have a plugin (like a global plugin) that defines constant XY.
If this constant is defined, then the event for user login is used (I mean, inside e_event function is test for this constant and next action depends on its value).

This fails on undefined constant because e_event file is loaded before e_module file.

Or the same thing different way: I have plugin for WP integration. If it is active (pref is set in admin area of plugin), in e_module is this pref checked and set related Constant.
In e_event after user log in e107, this constant is checked and if it is set, then user is automatically logged in Wordpress too.

Workaround: moving test of pref and setting of constant into e_event file (before class code), file is included before e_module, so it works now.