@DaveRomsey, looked now at meta and after 5 seconds it was very easy to summarize what is my problem with all of them. Right there at the description it says "supporting 35 types of input" which for me screams bloat as I will never use more than 3 types. I need a very compelling reason to make my code less maintainable by the need to do upgrades which are related to the other 32 features.

So the question is how much time it save me? I see that in 2016 they had 6 releases, assuming 30 minute to handle the upgrade (backup first, upgrade and then test to see nothing got broken) so in total I had to spend 3 hours just to maintain the plugin. Does it realy take me 3 hours to write a meta handling code? Even if you do not copy and paste from previous projects this is the kind of code that wordpress developers should be able to write while drunk sleeping

and it should never take 3 hours to do that.

... and then there is the usuall problem with all the free plugins (I have one so I know first hand) that they are useful but their main aim is to make you upgrade to pro, which leads them to be evaluated by their PR value instead of quality and usefulness of the code.

I can see how it is easier to develop with such tool, but by using them you just shift the cost of development of that part of the code from the developer to the user. and the user usually do not understand the implications

Actually ACF isn't that bad... You can declare fields programmatically much like you would any other framework and out of all the shitty frameworks that exist for this purpose, it is one of the better ones. So I've come to surmise after being forced into using it on several projects.

I've not been happy with performance there, but I didn't have time/resources to look. and when I pondered doing that on my own time I went to look how active GH issue tracker is and decided against it

header('AddType application/octet-stream .mp3'); That's a novelty. :D

so if you install Twenty Seventeen on earlier core version is fatals the site

smooth

or maybe it's reacting badly to my dev setup...

it uses functions such as get_theme_root that were introduced in 4.7

I added an MU plugin that defines those functions if WP is < 4.7 to test on 4.6

I raised the point on GH and the response was that it'll warn you if you activate the theme

ok, the next problem is that it fatals on 4.7-src

am I the only one actually using dev repo? because this is not the first time...

@MarkKaplun I hear where you're coming from. For me, CMB2 has been perfect because it is lean (no UI for example), extendable, and free (it doesn't use the 'free base plugin, buy extensions' model), and it does what I need. I'm already sold on using a library for meta boxes and options pages, but since things change so fast, I was poking my head out to see if there was something new and cool.

Sometimes it's easy to miss out on new things when existing approaches are 'good enough'. For example, I had been using Ruby to compile Sass, and that was pretty cool coming from plain old CSS. But then I stumbled upon task runners and settled down with Gulp and a workflow that was substantially more powerful and efficient (faster compilation, script minification & concatenation, source maps, linting, live reloading, etc.).

I missed out on these goodies for too long because I was fine with the status quo.