1
redheadedrod
Cron type need. How do I? Making a Groups module

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.

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?

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.

Thanks ahead of time.

Rodney

2
trabis
Re: Cron type need. How do I? Making a Groups module
  • 2010/8/7 18:46

  • trabis

  • Core Developer

  • Posts: 2269

  • Since: 2006/9/1 1


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!

3
redheadedrod
Re: Cron type need. How do I? Making a Groups module

Quote:

trabis wrote:

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.


Ok, I was going to use a timestamp in the database but either way works. I may just look at doing it one of two ways.. Hack the core to get it to run a routine or create a simple php script to be run as a cron job from the host. If I include the mainfile.php I get the database connect information and can go from there. I already will be hacking the core to get the group stuff to work so it would really just be one more thing.. Seems like I saw a cron module somewhere so I might go look for that and see what it is and maybe find a solution there..

Quote:

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.

Ok, best thing for me to do then is to copy the current group id to a "verification" field then. That field wouldn't get changed by any other module unless it is "group module aware" and use that as my method of checking for changes. Can just do a query and look for when the fields are not the same.

Quote:

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.

Will have to look further into that then. Will likely be another core hack but shouldn't be that big a deal. Likely will be a limitation that in order to use group based themes that system won't be able to use other modules to change themes unless they are "group theme" aware. But since the admin theme can only be changed from the admin preferences screen it should just work.

Thanks again.. Atleast I know better what I am up against.

Rodney

Login

Who's Online

162 user(s) are online (113 user(s) are browsing Support Forums)


Members: 0


Guests: 162


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits