2
Quote:
redheadedrod wrote:
I am creating a group module that will add subscriptions to groups among its other functions and I need to know the PROPER way to handle the following issues.
I need a cron type maintenance function. This should run the first time someone comes to the website for the day unless I can actually run a time related method. When someones subscription expires it would change their group. It would also support emailing a warning so many days before a subscription runs out. If It can be done in the back ground or be done without requiring someone logging in that would be great as I don't want someone to have to wait for this to finish. It might not be a big deal on a small site with a few users but if you have to do thousands of users it might take a couple seconds or so.
If you do not want users to wait then you need to make a Cron job in your server and hit a certain page from time to time( weblinks module works that way, it uses a password via get parameter to check if the request is made from trustable source).
If you want to simulate a Cron job in xoops then it requires a browser and a waiting user . I could be wrong.
To simulate a Cron job you can build a preload. Preloads are executed at every page request. You can use a cache file to save the timestamp of the last update and compare it to the current time. If an update is needed, you run the update script and update the file timestamp.
You can also use a block that is displayed in every page(instead of preloads). You can return false; in the block so it does not get displayed.
Quote:
Since it is dealing directly with groups I would also want to support a way to catch when another module or something changes the group someone is in so that this subscription field can be populated with a default value. Assuming a module programmer will add their own method for changing the group someone is in as opposed to using the core functions is there an easy way to catch this?
Nope, no (easy) way. Xoops does not have an event system. We have preloads but they are very limited in scope.
Quote:
I will also be looking at modifying the theme used as I plan to support allowing each group to have their own set of themes to choose from both for user and admin themes. Just wondering if there is anything I need to be aware of here. It appears to be a relatively simple thing but may require changes to any profile modules and such to support. However I hope to "intercept" any requests for available themes and use my methods for choosing the themes instead of the core methods.
You can use preloads for that, check out defacer module. Problem with intercepting is that you are not the only one in town. Defacer could be after you and change the theme that you have just set up for your user. Preloads do not have a order for execution so the last running will take the girl.
Quote:
Thanks ahead of time.
Rodney
You're welcome!