I’ve been playing around with WordPress Multisite, and (in some custom plugin code) wanted to be able to get posts from and save posts to a different site to the one that I was in. Thankfully, there are a couple of functions that make this very easy:
switch_to_blog( $id )
What these do is probably fairly self explanatory, but if you give switch_to_blog() the id of a blog, it will switch to that blog. Calling restore_current_blog() with then switch back to the original blog.
For example, to save a post to the current blog, and another blog, you can do the following:
$newPost = array(
'post_title' => 'title',
'post_content' => 'content',
'post_status' => 'publish',
'post_author' => $userId,
'post_category' => 'category
$postID = wp_insert_post($newPost, false); //Insert post into current blog
switch_to_blog( $otherBlogID ); //Switch to the other blog
$otherPostID = wp_insert_post($newPost, false); //Insert post into other blog
restore_current_blog(); //Switch back to the current blog
I wasted a few hours on Saturday morning struggling with the fact that CakePHP on my production server refused to save to a newly added field on a table in my database, while everything worked beautifully on my dev server. After hours of debugging on the live server I suddenly remembered that, with:
in core.php, as it should be on a production system, Cake uses the cached model definitions in tmp\cache\models and would therefore ignore any changes in the underlying database until these were refreshed. Simply either:
- Change temporarily to
Configure::write('debug', 2); and then run your code before changing it back again or;
- Delete the contents of tmp\cache\models
and it will pick up your new field.
We’ve been struggling for a while now with an unexplained three hour offset in log files and error messages created by QuestionMark Perception – commercial software which runs under PHP on IIS. I thought it would worth sharing a few gotchas in trying to pin down what was causing the problem:
1. Make sure you are looking for the
setting in the correct php.ini file (there are usually at least two) – you can identify which is being used by looking in IIS Manager | PHP Manager under ‘PHP Settings’ | ‘Configuration file’.
2. Use phpinfo to check what timezone PHP is reporting. You can either use the function –
– in an otherwise empty php page or by choosing IIS Manager | PHP Manager and then under ‘PHP Setup’, choose ‘Check phpinfo()’.
3. Be aware that the windows PHP installer adds a section at the end of the php.ini file:
. A date.timezone setting in this section will override any earlier date.timezone settings.
4. If you make any changes to php.ini, you will need to restart IIS in order for them to be picked up. At the command prompt, type
or use IIS Manager.
5. If it’s your own code you can override the value in php.ini with:
This is useful if you can’t restart IIS on e.g. a production server.