Title: cfoster's Replies | WordPress.org --- # cfoster [ ](https://wordpress.org/support/users/cfoster/) * [Profile](https://wordpress.org/support/users/cfoster/) * [Topics Started](https://wordpress.org/support/users/cfoster/topics/) * [Replies Created](https://wordpress.org/support/users/cfoster/replies/) * [Reviews Written](https://wordpress.org/support/users/cfoster/reviews/) * [Topics Replied To](https://wordpress.org/support/users/cfoster/replied-to/) * [Engagements](https://wordpress.org/support/users/cfoster/engagements/) * [Favorites](https://wordpress.org/support/users/cfoster/favorites/) Search replies: ## Forum Replies Created Viewing 7 replies - 1 through 7 (of 7 total) * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[All-In-One Security (AIOS) – Security and Firewall] Feature Request: List files currently in mu-plugins/ on dashboard widget](https://wordpress.org/support/topic/feature-request-list-files-currently-in-mu-plugins-on-dashboard-widget/) * Thread Starter [cfoster](https://wordpress.org/support/users/cfoster/) * (@cfoster) * [1 year, 11 months ago](https://wordpress.org/support/topic/feature-request-list-files-currently-in-mu-plugins-on-dashboard-widget/#post-17855164) * Thanks for pointing out the link at the top of the Plugins page as I didn’t know about that either, but it still seems like bad UX to have the “All” category not include MU plugins, so having a dashboard widget prominently display them still seems like a good idea since they are an easy attack vector for Malware. * This is more a suggestion for WordPress I suppose but: MUPlugins should really have to be manually activated just like regular plugins, even if their “must use” nature prevents them from being disabled. * Forum: [Developing with WordPress](https://wordpress.org/support/forum/wp-advanced/) In reply to: [`save_post` action is triggered before term_relationships is updated](https://wordpress.org/support/topic/save_post-action-is-triggered-before-term_relationships-is-updated/) * Thread Starter [cfoster](https://wordpress.org/support/users/cfoster/) * (@cfoster) * [2 years, 6 months ago](https://wordpress.org/support/topic/save_post-action-is-triggered-before-term_relationships-is-updated/#post-17243748) * At first I thought of just delaying my execution with usleep() but this didn’t help. As such something on *my* thread must be responsible (not a race with another thread) because if it was on another thread it would have executed while mine was asleep. * So, I got off my lazy butt and traced through the call. 🙂 * When one is saving a post with only Term (category / tag) changes, the post is saved through `wp_insert_post()` which, yes, does save Terms before triggering the `save_post` action but the Term data it passes to (ultimately) `wp_set_object_terms()` is the OLD terms for the post. (Why resave the old data? Dunno.) * After `save_post` is triggered here (and my routine has retrieved the post with the old terms still in place), there’s one more call to `wp_set_object_terms()`( from `WP_REST_Posts_Controller`) that has a the new terms data in it. So it really is storing this data after the `save_post` has been triggered (but my lazy has now returned and I can’t be bothered to figure out why the controller is doing it this way). * **SOLUTION** Regardless, tracing through it all I stumbled on `rest_after_insert_post` which fires only when ALL the data is saved. Yay! - This reply was modified 2 years, 6 months ago by [cfoster](https://wordpress.org/support/users/cfoster/). * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[All-In-One Security (AIOS) – Security and Firewall] Backups run every hour even though set to run once per week?](https://wordpress.org/support/topic/backups-run-every-hour-even-though-set-to-run-once-per-week/) * Thread Starter [cfoster](https://wordpress.org/support/users/cfoster/) * (@cfoster) * [3 years, 8 months ago](https://wordpress.org/support/topic/backups-run-every-hour-even-though-set-to-run-once-per-week/#post-16040386) * Ah. So you *removed* the backup module in favour of a different plugin. Well, that’s definitely stopped it from backing up every hour. 🙂 * Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/) In reply to: [[All-In-One Security (AIOS) – Security and Firewall] Backups run every hour even though set to run once per week?](https://wordpress.org/support/topic/backups-run-every-hour-even-though-set-to-run-once-per-week/) * Thread Starter [cfoster](https://wordpress.org/support/users/cfoster/) * (@cfoster) * [3 years, 9 months ago](https://wordpress.org/support/topic/backups-run-every-hour-even-though-set-to-run-once-per-week/#post-15974900) * Hi Prashat, I don’t usually do updates to the live site, but our next maintenance cycle is in a few weeks and I’ll be sure to test and update you then. Thanks, Colin * Forum: [Requests and Feedback](https://wordpress.org/support/forum/requests-and-feedback/) In reply to: [Suggestion: “Update” should use PHP’s specified upload_tmp_dir, not assume /tmp](https://wordpress.org/support/topic/suggestion-update-should-use-phps-specified-upload_tmp_dir-not-assume-tmp/) * Thread Starter [cfoster](https://wordpress.org/support/users/cfoster/) * (@cfoster) * [8 years, 6 months ago](https://wordpress.org/support/topic/suggestion-update-should-use-phps-specified-upload_tmp_dir-not-assume-tmp/#post-9760586) * I’m not sure if the web host made a change after my support request but I can now take out our WP_TEMP_DIR setting and updates work fine without it. I guess we’ll see if the problem returns. * I can see that get_temp_dir() does use the sys_get_temp_dir() (/tmp) even if upload_tmp_dir has been set. Maybe there was a weird setting like /tmp was writable by us, but not readable? Or perhaps the update files were being downloaded to the directory specified by upload_tmp_dir but trying to be read from sys_get_temp_dir()? * I guess we won’t know for sure unless the “can’t find file” problem problem returns. * Thanks, -Colin * Forum: [Requests and Feedback](https://wordpress.org/support/forum/requests-and-feedback/) In reply to: [Suggestion: “Update” should use PHP’s specified upload_tmp_dir, not assume /tmp](https://wordpress.org/support/topic/suggestion-update-should-use-phps-specified-upload_tmp_dir-not-assume-tmp/) * Thread Starter [cfoster](https://wordpress.org/support/users/cfoster/) * (@cfoster) * [8 years, 6 months ago](https://wordpress.org/support/topic/suggestion-update-should-use-phps-specified-upload_tmp_dir-not-assume-tmp/#post-9759959) * Thanks Samuel, * Sorry, I should have walked through get_temp_dir() before posting. (I expected it to be harder to work how these values are set in WordPress’s internals than it was. 🙂 ) * I’m not sure why I’m seeing a different behaviour at our web host. It seems like defining WP_TEMP_DIR the way we have should have no effect at all, yet we can’t update without it. I’ll put in some logging to figure out what’s going on (and report back if there’s anything interesting). * -Colin * Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/) In reply to: [Can’t assign posts to categories](https://wordpress.org/support/topic/cant-assign-posts-to-categories/) * [cfoster](https://wordpress.org/support/users/cfoster/) * (@cfoster) * [19 years, 7 months ago](https://wordpress.org/support/topic/cant-assign-posts-to-categories/#post-470115) * This problem just sucked away a few hours of my life. In hopes of sparing others: if you click within the 20 pixels on right edge of the blue bar you can edit the category (etc.). * I tried using wordpress with Windows IE6 Windows Firefox 1.5 Mac Firefox 2.0 Mac Safari 2.0 * and none of them showed any indicators to suggest the right 20 pixels are any different than the rest of the blue bar (which just reorganizes the post options). * WordPress, dudes: I *love* your product. It’s incredible, really! But… an icon… or something, please. 🙂 Viewing 7 replies - 1 through 7 (of 7 total)