Tom Nowell wrote a great breakdown of what is new in version 2.0, and the documentation on the VVV website goes into great detail on the different configuration options available to you. I also recommend reading through the README file for the Custom Site Template repository (which your custom site definitions will most likely use for provisioning instructions). I am not going to cover the changes or the different options or settings in this post, so feel free to read through these links to get up to speed.
My vvv-custom.yml File
Recently, during the 4.7.4 release process, I was helping to test the built package files generated for the maintenance release. In addition to the 4.7.x version being updated, some changes were backported all the way back to the 3.7 branch (currently, the oldest maintained version of WordPress).
I realized that I did not have anything set up for testing older versions of WordPress when I started testing the builds. So, I spent a few minutes expanding my vvv-custom.yml file to accommodate this need.
Here is my current vvv-custom.yml file with some of my personal and work sites removed. In addition to the two default sites (wordpress-default and wordpress-develop), I include a multisite environment, and each WordPress version back to 3.7.
What does your vvv-custom.yml file look like? Do you have any cool tricks worked into yours? Share them below!
First, in case you are not familiar, here is a little bit of background on how translations work for WordPress.
Way back in 2013, WordPress 3.7 added support for something called language packs. When combined with Glotpress and a few automated processes behind the scenes, anyone who is multilingual with a WordPress.org account can translate plugins, themes, and even WordPress core through a simple front end interface.
Once a specific locale reaches the 95% translation mark, a language pack will be generated and automatically made available to anyone using the plugin on their WordPress site with that language locale selected.
Anytime you push an update to your plugin’s SVN repository, identical strings from past versions are automatically synced to the most recent versions. You can even watch this happen in the #meta-language-packs channel of the Making WordPress Slack.
Now, on to the issue that I experienced. When I pushed my updates to the plugin’s SVN repository, I noticed that the “Stable” column was empty. This was weird because “Development” and “Stable” were the same code.
I had committed my new code and changed the plugin’s stable version in the plugin file’s header in the same commit. Because of this, the automated processes that generate the translations behind the scenes could not generate a list for “Stable”.
To fix this, just make a commit to the plugin’s repository. I did this by increasing the version number while leaving the stable version alone. I watched the #meta-language-packs channel for my plugin to be regenerated after doing this, and all was well.
Do you speak another language? Hop over to the Toggle wpautop translation page and spend a few minutes translating my plugin. All contributions are appreciated.
For more background info on how translations work on wordpress.org, check out these Make WordPress blog posts.
Today I was migrating SVN repositories over to GIT using BU’s svn2git utility. I came across one repository that GitHub would not allow me to push because it contained a file that was over 100MB.
After some investigation, I realized that the file it specified was only 25KB. However, at some point in its history it was over 100MB, Because I was pushing the entire commit history for that repository, it was rejecting everything.
The solution is to remove the file entirely from the repository’s history. It took some trial and error for me to find something that worked for me because most snippets relied on history already existing in the origin repository. Here is what worked for me:
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch path_to_file" HEAD