My experience with contributing to WordPress core has been awful and after years of convincing myself it’s gotten better the results might be the same. Hopefully my feeling of discouragement changes because I really want to be involved.
(sarcasm) Guns. Not the problem. Instead it’s the asshole who texted. (/sarcasm)
What I discovered is that in many ways, these jobs are a trap: They pay so little that you cannot accumulate even a couple of hundred dollars to help you make the transition to a better-paying job.
Took a few days to straighten things out but I’m no longer running this blog on a dedicated server and finally recovered a backup that could be used to export the DB. I’ve learned a lot of lessons, the big ones: one, don’t count on software RAID setups; two, always review your backups periodically, something could have gone wrong since you set them up.
This week we at Sprout Venture migrated our largest project to git. Without going into detail about our process we ran into a problem with our superproject’s submodules initialized with detached HEADs; regardless if they’re added with the branch set.
The .gitmodules file would properly show the branch, e.g.
[submodule "wordpress"] path = wordpress url = git://github.com/WordPress/WordPress.git branch = 3.7-branch
But when a branch would be checked out the branch for each submodule wouldn’t be set (or worse at times reset to detached). Not a big deal if the branch has a few submodules but ours has 100s.
I found out about $git submodule foreach and created a little command/script that would recursively loop through all of the projects submodules and checkout the branch according to the branch set in the submodules config file (see above).
git submodule foreach -q --recursive 'branch="$(git config -f <path>.gitmodules submodule.$name.branch)"; git checkout $branch'
Nacin just tweeted about a little changeset in WordPress trunk that will delete all transients after an upgrade.
Wondering how controversial this will be… WordPress trunk will clear all transients during upgrade. http://t.co/6eGGO8lAXv
— Andrew Nacin (@nacin) September 12, 2013
Obviously someone is going to make this “controversial”, there always is with a huge project like this; I’m also not looking forward to the wp-hackers thread on the topic either. Personally, I think it’s a good idea because it’s starts a new conversation about how to properly use transients and what a developer can expect from them. It could lead to some performance improvements on sites that had/have plugins/themes that improperly utilize transients, as suggested by Nacin already.
The problem, which I should preface is untested but conceptually reasonable to bring up, is upgrade/update lag.
I believe a lot of developers, myself included are hooking on init to check for a transient and if not available call an external API (and store it temporarily again). In a current project I’m doing this (technically hooking on admin_init to check on transient data) at least twice, one for an API callback and another to get a json package for an add-on marketplace. That said, immediately after an upgrade these external APIs are going to be hit because transient data isn’t available. This would ultimately delay the load of the next page, which for any user would be either: the welcome page (that the user is redirected to after an auto-upgrade) or the dashboard (redirected to after the DB update page when first visiting the admin after core was updated manually (SVN/Git)).
Consider I do a poor job maintaining these external resources and they’re slow to respond or worse timeout, that would mean a user who just upgraded would be staring at a white screen for the duration that it takes for these external APIs to respond. In the perception this WP user/admin, the burden for this delay wouldn’t be on the plugin authors or external resources it would be on WordPress. Most likely causing people to think ‘is it going to take this long every-time I upgrade?’.
There are a lot of other
rabbit holes issues that could be brought up but this is the one I’m concerned about because it affects the perception of how easy an upgrade is.
Do I still think it’s worth clearing out transients after an upgrade? Absolutely. The approach should be different, possibly a background process after the welcome page (or dashboard).
[Update] Anyone know if after an upgrade/update (with these changes) update_plugins and update_themes are fired, since their transients are deleted? This would cause our project (as an example) to need two more immediate external fetches by filtering pre_set_site_transient_update_plugins and pre_set_site_transient_update_themes, excluding the calls to the extend API which I’d expect to always be fast.
The video didn’t end showing how awesome this was but this is the best I have. What’s missing is how close we (snorkel guide with me on the outer part of the reef) got by swimming down, I had given him my camera but I didn’t get a chance to tell him it was already on, so he ended up turning it off just after this was taken.
Took a trip to the Dole plantation and toured the grounds on a train and had a ton of fun breaking up into teams to complete the huge maze, apparently the worlds largest maze.
After we went to a Haleiwa (North Shore) beach, Laniakea Beach also known as turtle beach.
Watching the turtles eat their dinner off the rocks was fun.
Avery found this turtle swimming with us within minutes of us jumping in.
Sawyer just kicked it with mom while Avery and I snorkeled.
Our second day on Honolulu was uneventful and filled with a lot of relaxing, swimming, more relaxing at the beach, relaxing, slides, lazy river and a bit of drinking in between. The kids went to Auntie’s Beach House for some activities while we relaxed and planed our next few days.
For dinner we ended up leaving Aulani (for the first time since arriving) but only walked across the way to eat at MonkeyPod.