The state of handling custom metadata in WordPress

Categorized under:

, ,
Photo of author
Written By Brian Krogsgard

40 thoughts on “The state of handling custom metadata in WordPress”

  1. Totally agree. I’ve always thought one of these custom field plugins will end up getting rolled into core as it adds almost essential functionality to WordPress as a CMS.

  2. ACF is great and I love what Elliot has done to put this plugin together. I wasn’t aware of the upcoming changes with the new version – will have to look in to this a bit deeper!

    It would be great if the additional plugins that you mentioned were interchangeable and only represented the UI part of handling custom fields, while core took on how this data was stored. I’m surprised this hasn’t taken more focus in WordPress 4.0.

  3. I have serious issue with referring to backwards compatibility breaks as “irresponsible” and so on.

    Yes, when something stops working it sucks. It’s loss aversion — it makes you feel not just bad, but out of proportion bad to the actuals problems it creates for you.

    When one of my staple (tens-times-a-day-used) desktop apps removed major feature from free version I threw a fit. Then I changed to alternative. But the size of the fit I threw was way larger that practical challenge I was facing (take out credit card or move to different app).

    The thing is backwards compat compromises long term life cycle of software. It’s just technical reality. You cannot extend code base endlessly with perfect backwards compatibility without major technical sacrifices. And yes — WordPress core is compromised in serious ways by it, however chooses to live with it, in line with their priorities.

    But! WordPress core priorities are not our own. We are too used to off-the-shelf priorities like that handed out and treat as holy scriptures. Comes with being a young industry.

    But major versions and backwards compatibility breaks happened around much longer than WP did. They serve purposes. There are code development and consumption practices to handle practical implications of them, just as there are to handle land of eternal compat in WordPress.

    We benefit greatly from backwards compatibility.

    We also benefit greatly from software that is not coding itself into a toxic mess.

    Nailing both is software development level hardcore. WordPress thinks it’s handling it. Maybe it does. Maybe it doesn’t as well as it thinks, depending on whom you ask.

    Not everyone is WordPress. Especially not one (or even two, or even five) developer shop.

    We are not owed eternal backwards compatibility. We are not owed for every theme, plugin, and framework to only ever have one major version because it’s convenient for *us* and their developers can drunk themselves to sleep for all we care.

    The client’s site broke because they changed major version of a plugin? That is *your* screw up (not talking to Brian personally). You made a site on the foundation of assumption other people will bend backwards to make life effortless for you. Now go look up “dependency management”, you are supposedly a professional dammit.

    Don’t like that ACF released major version? Fix the things that got broken, learn from that what your processes lack. Maybe switch to competitor if you feel that’s necessary technically or emotionally.

    But the pestering of developer for it is unseemly, mean, and entitled.

    • I agree in principal, but from a business point of view, the convenience of your customers is a costly thing to throw away.

      I suspect, most of ACF’s customers are developers doing client work. Affording them a degree of laziness is, effectively, a feature. And, as you point out, being in the WordPress industry, one that is more or less assumed. Removing it therefore will upset your customers. They may, as you suggest, take their custom elsewhere – but as a business, you don’t really want that.

      Of course, it’s a matter of weighing up the code-architecture pros with the business-loss cons.

      • Note that in no part I claim developer handled it perfectly.

        But there is a line between being upset customer and being a jerk. I think in this case WP community is being a jerk and justifies that with its [unrealistic and bubbled up] backwards compatibility expectations.

        Releasing major version is not “out to ruin your life” situation. It’s normal. The reason it’s not normal in WordPress is that what “normal” is skewed and people need to be much more aware of it to throw well grounded judgments around.

      • In short, Stephen expresses my feelings exactly.

        “Of course, it’s a matter of weighing up the code-architecture pros with the business-loss cons.”

    • You are correct, although one of the reasons people use WordPress is for backwards compatibility, so a plugin not meeting their expectations is sure to cause a raised eyebrow or two.

      • Based on? I mean it’s part of the “story”. And it has objective benefits. But how important it really is to people?

        And instead of wild guess let us go look at stats http://wordpress.org/about/stats/ showing how 84% of said people don’t bother to update to current stable version. I highly doubt developer concerns like backwards compatibility are genuinely important to them.

        • For what it’s worth, I consider backwards compatibility to be extremely important for my own projects. I am lazy and can’t be bothered testing every update and just hope like heck that some putz isn’t going to break my site. But I’m incredibly anal about what plugins I run, so I’ve never had any problems.

    • Hey @Rarst,

      While I pretty much agree with your sentiments, I think directing them toward Brian might be a bit misplaced? I read his post as:

      “Here’s what happened, here’s why it causes problems and why you should be careful using ACF in the future, and here’s a solution (put it in core) that I’d like to see happen.

      OTOH I think your comment might have been more appropriately posted here:

      http://chrislema.com/backward-compatibility-advanced-custom-fields/

      Just sayin… 🙂

      • Not as much at Brian as at topic. 🙂 I explicitly wrote that I am not talking about Brian personally closer to the end.

        But as for his coverage of topic I do think he screwed up with ACF angle here both by praising questionable (for my taste) post by Lema as explanation and muddling the issue in general.

        Plenty people (from how discussion on twitter was going today) ended up with a lot of misunderstanding about the actual issues with and stage of ACF update, not to mention that documentation of said looks great to me and was bashed unfairly in my opinion (not sure if Brian *saw* the latest documentation however, depending on timing of it and this post being written).

        • Not as much at Brian as at topic. 🙂 I explicitly wrote that I am not talking about Brian personally closer to the end.

          That’s why I suggested Lema’s post. Seemed like commenting there would be closer to the source…

          But as for his coverage of topic I do think he screwed up with ACF angle here both by praising questionable (for my taste) post by Lema as explanation and muddling the issue in general.

          …but, I do have to agree with you there, on both counts.

          from how discussion on twitter was going today

          Thankfully, I’ve stayed out of that fray today.

          BTW, seems like about 3+ years ago you said to me it was best not to comment on the ideological rantings of this community. I guess either your opinion on that has changed, or you’ve lost the self-control not to comment, eh? 😉

      • Rarst and I have had an open channel for many years. We certainly don’t always agree, but we always listen to one another! His is one of the most valued voices I hear in the WordPress world, even if he is oft an antagonist 🙂

    • Yes, when something stops working it sucks. It’s loss aversion — it makes you feel not just bad, but out of proportion bad to the actuals problems it creates for you.

      For managing a single site, I completely agree.

      I think many developers forget the variety of client – developer relationships that exist in the world though. This is going to be an incredible burden on a lot of folks.

      Note that I should’ve clarified I think backward compatibility is important, but shouldn’t be “not allowed”. As Stephen noted, it needs to be balanced as a code architecture vs business decision. If I have to manually configure a plugin every year for every site I use it on (let’s say that number is 50, but it could be hundreds for some folks), that’s a very real cost. And I’d rather use one where the developer chooses to make back compat a priority.

      The client’s site broke because they changed major version of a plugin? That is *your* screw up (not talking to Brian personally). You made a site on the foundation of assumption other people will bend backwards to make life effortless for you. Now go look up “dependency management”, you are supposedly a professional dammit.

      Yep, I’ve learned this lesson before. And I took your exact advice below that statement, and switched to a competitor. As Mike noted, I warned folks that they should have noted it the first time.

      But the pestering of developer for it is unseemly, mean, and entitled.

      In this case, I think (despite how pretty the docs site is), Elliot didn’t answer some pretty important questions, which are mostly workflow related, and simply things that could aid developers bringing ACF up to speed for their clients. In addition, he was requested numerous times to do so, and from my POV he could’ve handled the feedback much better.

      I get someone needing to change their business model. With a “tool” plugin like ACF, it could easily be a foundational piece of a website. So in this case, back compat is even more important, and it’s not unreasonable to be concerned about what happens when you upgrade, and if you’re going to be bombarded by past and current clients. On the other hand, it was everyone’s choice that used ACF. I myself do not use it for clients, partly for these very reasons I’ve noted.

      Anyway, thanks for the comment. You make some really good points. I probably could’ve left this ACF aspect out of the article, as I would’ve much preferred the conversation to be centered around metadata UI in core, vs this. But alas…

      • Just a comment, in alignment with @Rarst’s comments; I’m not sure someone providing a free plugin has any obligation to users whatsoever. Yes ACF has muddied those waters by having both free and paid plugins, but even so he made his choices and now the chips can fall where they may.

        Now I’m not saying that people should use plugins where the developer has no obligation, only that they should not expect anything of the developer. If they are building a site that would be harmed if a plugin causes them a problem they should know in advance that that is a risk they are taking and if the risk becomes reality then they’ve got no one to blame but themselves. Or they should buy a plugin that is better supported, or build (have built) a custom one.

        From the developer’s perspective, if they want to keep and grow users then they need to do a better job of maintaining backward compatibility. But it’s not a moral imperative, it’s just sound “business” where “business” here could mean maintaining a large user base or strengthening a personal brand, if that’s what motivates the developer.

        But even so, companies like Oracle, Microsoft, and Apple make breaking changes all the time, so commercial support is no guarantee of panacea. The irony is that most companies just suck it up and fix the problems but the users most effected are the ones with no budget to fix problems because they no business model or one that generates very little revenue. And that’s probably why they get so mad about it, even though they really have no real right to.

        There’s an old story told about a man that got kicked by a jackass; he considered the source and then went about his business.

  4. Those of you having problems are probably better off using the version maintained by 10up anyway … https://github.com/10up/secured-advanced-custom-fields

    I’m guessing they’ll keep it backwards compatible, but that’s just a guess on my part.

    I’ve never been wiling to use ACF in my own projects. I was recently introduced to Custom Meta Boxes by Human Made though and quite like it. I find it is simpler and easier to work with than ACF, albeit the feature set isn’t as good … https://github.com/humanmade/Custom-Meta-Boxes

  5. Both this page: http://www.advancedcustomfields.com/resources/updates/upgrading-v4-v5/

    and the general “What’s New in Version 5” page:
    http://www.advancedcustomfields.com/resources/updates/whats-new-version-5/

    cover what is changing in ACF. I can see if someone clicks “Update” blindly they might be in trouble, but I don’t understand the headache – “(the existing posts and documentation is very confusing)”. I just read it and it seems pretty straight forward.

  6. Brian, you shot the nail!

    I think that plugins like ACF are great but they aren’t the final solution to push WP towards CMS functionalities, some improvement to handle post meta data should be implemented into the core, but I would like to choose where put these data if inside wp_postmeta or in other tables/sources.

    The power of WP is simplicity and extensibility so we should think how add custom (strongly typed?) properties to posts (and, why not, users, categories, etc), without breaking WP philosophy but with the power to automatically display metaboxes for these “properties”. It should be interesting also make searches and filtering posts on these properties, am I asking for the moon?

    • Hi @Taloweb,

      but I would like to choose where put these data if inside wp_postmeta or in other tables/sources.

      Would you mind posting this as a feature request here? Please be sure to provide as many details about what you are envisioning that you think we’ll need for your ideas to be clear.

      Also, if you have multiple ideas/requests, please post them as separate issues so it will be easier for us to address and close an issue.

      • Hi @mikeschinkel,
        thanks for your interest, but this is not a simple feature request nor an issue posting by now, my comment was a “can we push WP to be a real CMS? How?”.
        We have to discuss about it, so WP can go “a step further”, don’t you think so?

        • @taloweb:

          We have to discuss about it, so WP can go “a step further”, don’t you think so?

          Certainly. Which is why I asked for specifics. If we only speak in abstract then we’ll not move forward. BTW, I’m currently working with Scott K Clark and others on the #metadata feature-as-plugin which is why I was specifically interested in your ideas. But if you (and others) don’t post your ideas there to discuss, we’ll have no other option than to simply build what we think is important which might not cover everyone’s needs.

          Said another way, if you want to have discussions and/or input, then https://github.com/wordpress-metadata/metadata-ui-api/issues is going to be your best bet.

        • We’ve been discussing this exact topic for years, and more recently as the WP Metadata API / UI project has moved forward, we’ve had numerous plugin authors who have built Custom Field plugins involved. We’ve considered a lot of options, patterns, and features, but we’re still open to good ideas. We won’t turn away a good idea if it makes sense and meets the requirements for implementation in WP core.

  7. Hey guys.

    Just wanted to quickly address the upgrade concern before I write an article about it.

    As mentioned in the upgrade documentation, if an ACF4 user upgrades to ACF5 (when it is publicly released in a month or so) and is using 1 or more of the ACF4 add-ons, a clearly written message will display and allow the user to downgrade from ACF5 back to ACF4 with the click of a button.

    Thanks
    E

  8. Why, for the love of god, WHY is wp_postmeta a separate table?
    Why not just add an additional field in the wp_posts table? WHY WHY WHY??

    This is stupid design right there. To this date there is no easy way to grab post data together with its meta. Everything just has to result in a gazhillion database requests..

    This is why your WordPress, ACF and all other kinds of Advanced Custom Fucks suck.

    • I’d probably venture to say you’ve never dealt with scalable database design with millions upon millions of sites..

      I won’t deny, tables are better when they have columns for what they need, indexes, etc. But putting everything into wp_posts would be even worse because there could be tens to hundreds or more post types using that table with god knows how many weird custom fields someone would want.

    • Konnie, wp_postmeta is a great place to store additional info for posts since you can’t store it in wp_posts: we don’t know before “what” info needs to be stored.
      The problem about wp_postmeta is that every theme or plugin can store any information in it, using any key, that can cause conflict or a lot of garbage written (and forgotted when plugin is deleted), an improvement could be to ask to plugin developers to declare (in some easy but usable way) which values are stored in meta_key…

Comments are closed.

A2 Hosting
WordPress.com