Using one function for two scheduled events and a form

Hi Piotr! Sounds like you’ve been busy and have made good progress, well done!

Getting values from the options table where settings are stored and placing the values in a query string is fairly straight forward. You use get_option() and assign it to a variable, like so: $forum_ids = get_option('forum_ids');

Depending on exactly how this data is structured, you may be able to use the variable directly, or you my need to convert it into a format compatible with mySQL. If you data was stored as a comma delimited string such as: “12,23,32,34”you can use the string value in mySQL directly. If your data was in array form:array(12,23,32,34,)you need to useimplode()` to convert it into the comma delimited string.

Once you’ve gotten the data in the correct form, you can use the variables in the query string just as you had done in your examples. Don’t forget to use double quotes to delineate the query string so that the variables get expanded into their values. This will not happen if single quotes are used.

Executing a command from the settings page is a fair bit more involved. The technique though is used quite often in programming, so it’s a skill well worth learning. I’m referring to AJAX techniques. You can send commands from the settings page and the server can report the results on the same page without any need to reload the current page.

You will need some content on the settings page unrelated to the Settings API. If this is solely your own creation, this is no problem. If you’ve added onto another existing page, you’ll need to find an action to hook onto in order to output some HTML

The submit button is not a real submit button, you are not POSTing the form data like a submit button would do. It can be any HTML element capable of registering a click event. It can even be an inactive submit button. The click event triggers some jQuery code that sends a request to the server. The server does its assigned tasks and sends a response back to the jQuery function. jQuery interprets the response and displays something on the page accordingly. Thats AJAX in summary.

You probably will not be surprised that it’s very much more involved than my brief description indicates. You can start understanding AJAX by reviewing AJAX in Plugins. This document is quite confusing to novices unfortunately. The WP Documentation Team is attempting to rectify that with Plugin Developer Handbook. This is still a work in progress, but the AJAX chapter is mostly complete.

I’m actually involved with Documentation as well as these forums. If you have any comments or suggestions regarding the Handbook, we’d love some feedback. Especially if there’re particular sections you found confusing and/or needs improvement. You may either respond here or directly on the article page if you register for the “Make” site.

Oops. I neglected to address that aspect in my response, my apologies. There’s a few ways to do this. You could create completely separate callback functions for each scheduled task. One function specifies a limit, the other does not.

You could use one function with two scheduled tasks. Each scheduled task has the opportunity to pass arguments to your callback function. This is in the form of an array, even if it only contained a single value. For example, the argument could be the actual limit in string form. In the no limit case the argument could be an empty string. When the variable containing the empty string argument is expanded into the query string, it would be as if there was no variable there.

A variation would be to store the limit in options so you could alter the value easily through settings. In this case the argument passed from the schedule task could be a simple boolean true/false. There is logic code in your callback to get the option in one case and to assign the empty string in the other case.

You don’t even really need two scheduled tasks. You could just run the hourly task and your callback could keep track of the current time. On any call where it’s been more than 24 hours since the last daily run, it will do both the hourly and daily queries automatically. The daily timer is then reset and the cycle repeats. Of course only the hourly version has a limit, in the daily the empty string is assigned.

If you really want to postpone AJAX, it would be possible to execute the special query without it. The resulting page loads make for a clunky user experience, but the possibility does exist. I think you realize AJAX will need to be part of your skill set at some point. Would you rather put the time in now and have a nice interface? Or postpone the inevitable and have a clunky interface? There’s always decisions to make 🙂

You’ve wandered into an area I have little experience in, so I’m pretty much guessing. My best guess is you need to pass an argument through the daily_import action even though you don’t need it. Even though you don’t need it, News::news_import() is expecting one. It can be just an empty array, but something needs to be passed.

If that doesn’t work, my other ideas get illogical very quickly. First be sure wp_schedule_event() is being called, the if() condition may not be returning as expected. If there’s a problem adding the same callback to two events, you could create a wrapper function that merely calls the other function.

I’m assuming you correctly created custom intervals and didn’t just make them up. Please don’t be offended at the inference. I’ve done some pretty stupid things though I’m not stupid. You may have done similarly?

Beyond that you’d have to do a detailed debug into the core function to determine where things fall apart. It’s OK to edit core files if it’s just temporary and you restore things when you’re done.

About your array question. I’m not sure I understand. Do you mean the optional arguments parameter that is passed back to your callback function? You’re saying that though you passed a single value as an array, it came back into your function as a single value, not an array? That is surprising!

I don’t really know, I would guess it is because scheduled events need to persist so are stored in the options table. Thus arrays must be serialized. It may be that in the serialize/unserialize process that single element serial arrays do not become arrays again. In the case of settings fields, the form is constructed on the fly and the arguments do not need to persist so are never serialized.

If you’re having time out issues, use set_time_limit( $secs ); to get more time. The default is 30 secs. There may not be much point in a value more than around 300 because there is a HTTP time limit that kicks in around then. You can use a value of zero to have no time limit. This can be dangerous if a script should fall into an infinite loop condition.

Calling the function actually resets the timer, so you could just repeatedly call set_time_limit( 30 ); in your loop and still finish in the default condition.

I believe the default Apache timeout value is 300 sec., at least it is on my test server and I never changed it. You could change the value in httpd.conf or one of it’s included files, mine’s in extra/httpd.default.conf. If you do not have access to this file, I suppose you’ll need to find a way to chunk the data into manageable blocks.

Other ideas: If it’s a one time thing, maybe you could ask you host to up the value for a couple days. Or: Import to a locally installed clone, then export the DB to the live version. I’m unsure if this will be faster or not, mySQL may have different limits, no idea at all on what that may be.

OK, I could sort of see how a single array value could become just a simple value, but an associative array with a key? That’s not right at all! Loss of the key name is destroying possibly important data. Wrong enough that I would consider it a bug. I will look into this further, but it will take some time. I’ll let you know what I find.

Uh, never mind??

We’ve been looking at this wrong! We were expecting the array we provide to be passed through to our scheduled function. Bad assumption! The array elements are sliced into individual parameters by do_action_ref_array() in wp-cron.php.

When we add the action that calls our scheduled function we need to specify the priority and number of elements in the array. When we declare our function, we must receive each parameter into a separate variable. If we pass a two element array when we schedule an event, the add action and function declaration may look like this:

add_action('my_schedule', 'do_my_event', 10, 2);
function do_my_event( $parm1, $parm2 ) {
    //do stuff...

It’s actually always been this way. Before PHP 5.4, we got away with accepting an array through a single parameter because that parameter was actually a reference pointer to an array. In 5.4, references are no longer passed, so we need to provide variables to copy the array elements into.