Could someone explain to me what preloads are and how do we use them?

I never did quite catch the grasp of what they are. I noticed in the Database connector that my initial 5 minute inspection of the file showed that the logger variable no longer appeared to be addressed and instead there was a preload reference.

I can duplicate what the 2.6 database file had I think pretty seamlessly but I am trying to understand what a preload is and what it is used for.

I understand partially the concept with protector using preloads but I am thinking those are different. My understanding of protector is that it would be loaded prior to some code so it could reside in memory then it could actually access some items before they were passed to the rest of the code. But I never quite understood what the preloads were in the core or how they worked.

Thanks to anyone who can help me understand them better. They are much more used with 2.6 from what my initial impression is.

hhttps://xoops.org/modules/newbb/viewtopic.php?topic_id=71841

http://xoopscube.org/modules/xhnewbb/viewtopic.php?topic_id=755

Below are some links that I've had collected:

https://xoops.org/modules/newbb/viewtopic.php?post_id=329873#forumpost329873

https://xoops.org/modules/newbb/viewtopic.php?post_id=342744#forumpost342744

https://xoops.org/modules/newbb/viewtopic.php?post_id=321626#forumpost321626

Discussion on XoopsCube:

http://xoopscube.org/modules/xhnewbb/viewtopic.php?topic_id=755

We clearly need a more comprehensive tutorial on Preloads, especially going forward to XOOPS 2.6.0

actually they are simpler than you can expect.
the concept of having preloads is "Loading some functions prior to loading the module itself"

These functions can be load in some defined places in Core.

The most current defined places are:


to use a defined preload in your module you just need to do this:
1- create YOUR_MODULE/preloads/core.php file

2- add the name of preload by removing all dots, add a "event" and uppercase of the first letters for all.

eg: core.footer.start => eventCoreFooterStart


You can define preloads in some places of Core without hardcoding.
one of the amazing places is defining a new xoops_smarty function for your module.

for an example please look at:
xoops255\class\smarty\xoops_plugins\function.xoInboxCount.php:



IMO the above is all you should know as a module developer.

Thanks for the information guys, I will go back through them as I can and if they don't make sense ask questions.

Won't really affect me for a couple months yet but it would also be nice to hear more information about the plugin system and how modules can easily share information between them that is new to 2.6. When I get to rewriting some modules I want to make full use of things such as these preloads, plugins and whatever else is available. But in another thread of course.. ;)

You should know preloads are a last resort for module developers.
preloads invented because previously you sometimes need to hack core (e.g.: Protector module) to make your module works.
So you should try any other solution like a hidden block in the whole website. If you could not solve your issue and you need to hack core file then you can use preloads.

Any module using preloads can be consider as a core module and should be tested more than regular modules.

Ok, I did look through the threads and there was no clear examples of a preload and how they are used. Maybe I am just being dense with this subject and I am sure once the light goes on it will make a lot of sense but that bulb is pretty dim at the moment.

Don't know that a full understanding will be necessary to be able to finish up the PDO stuff but would be nice to know what I am tweaking.

I think my example of preloads usage is clear enough.

I forgot to mention defining the class.

sop the whole instruction would be this:
1- create YOUR_MODULE/preloads/core.php file

2- add the class and the related function name of preload by removing all dots, add a "event" and uppercase of the first letters for all.

eg: core.footer.start => eventCoreFooterStart



The class name for any module would be {$Modulename}CorePreload

irmtfan,

A preload can also be used instead of creating a cron job. For example if a module needs to check the status of some event or activity a preload can accomplish this so that it can all be contained within XOOPS instead of forcing inexperienced site administrators to learn about cron jobs.

You are right that other methods could be used - hacking a theme, hacking the core, or a hidden block but using a preload is a cleaner solution in my opinion that requires no action by the site administrator. You are also correct stating that the preload must be tested very carefully. Improper use of a preload could potentially bring down the whole site, not just the module using the preload.

Ok let's start a little sooner in the food chain here...

Doesn't make sense to me how to use it if I don't know what actually happens.

Lets start from the aspect that I have no clue what a preload is. Not even a hint...

From the links and comments here things are not really clear but with the comment zyspec gave I am beginning to wonder if I might not be getting a better hint about what they might be.

If I had to guess today what a preload is I would guess it is a function that is run at some point in a page load but prior to accessing any modules or block contents thus it happens every time a page loads. (From zyspec's comment this would make sense.)

From the structure mentioned by irmtfan and his comments plus the links I am guessing that the structure of preloads are similar to delegates in C#. In other words the preloads are sorted into a queue that would be run one at a time in the order placed into the queue.

So if I am right things would make better sense BUT at what point in the system do these preloads get run? Will I still have access to all of the normal xoops variables? Obviously if this is the case you really don't want to do a large query if you use it in a module and the comments about including it in a module etc make more sense as well.

Also, is there a specific order for these preloads? Core preloads first then modules I assume?

Thanks... Hopefully I am on the right track to clarity with this.

Rodney