11 Comments


  1. It would seem to me these could be classes. Some baseline standard with the option to extend(s) as each dev see fit.

    That said (and thinking out loud), I’m not so sure this is really data portability per se. This is closer to data standardization – which given WordPress’ Wild West approach to growth / market share is a 180.

    Perhaps instead it would make sense to have some sort of XML (?) defined mapper between one plugin and the next? That would still give each dev the liberty to move ahead and the users a backdoor to switch horse if they want to.

    Heck, a great start to that would be an XML export / import standard for plugins setting. Wouldn’t it be nice to config a plugin in dev and just export / import the setting over to production?

    Reply

    1. It is about data standardization. Portability can be a byproduct of standardization though, which is a goal I think we should shoot for.

      I’d also love to see tools that map or do whatever when switching between plugins like that. I think standardization may even help with that.

      Reply

      1. Justin – Please pardon my Devil’s Advocate-ness for the sake of this sub-thread / discussion. (I want to be clear: This is not push back. I for one believe the WP framework product should be mature enough at this point – i.e., 10+ yrs – to begin to address such issues.) That being said…

        It feels like apple and oranges to me. Many would argue that standardization can and does squash innovation, or at least the ability to experiment. On the other hand, (data) portability – which btw perhaps isn’t the right word since the data is staying put, it’s the plugin that’s changing – allows the eco-system to thrive more or less unregulated (if you will).

        Off the top of my head…

        Step 1 – An intra-plugin export / import standard. (In my mind, provide a class / toolkit so implementation is uber ez for devs.) Again, for example, the plugin is config’ed in dev and it’s easy to export and import those baseline setting into staging / production. That (XML file) would provide a level of transparency as to what data the plugin is generating / using.

        Step 2 – As the various approachs to a given solution become clear, chances are good one plugin author – in order to gain market share – is going to write a sub-plugin (?) that will migrate data from competitor A over to their plugin. I believe a couple of the SEO plugins kinda do that now, yes?

        Step 3 – Eventually, the market settles out (if you will) and the deviations slowly become standardization. I’m not sure what the proper economic term is but I’ll go with: Competitive Cooperation (if you will), or perhaps Cooperative Competition :) That is, (for example) “Well, if I do X, Y and Z like industry leader plugin #1 then that’s one less thing to convert / migrate.” Or something like that. Currently, in theory that’s possible but WP’s general Wild West mindset doesn’t see value in NOT inventing the wheel, eh?

        That being said, if nothing else some sort of actual documentation standard would certainly help. Trying to figure out someone else code (e.g., what a given meta data element actually represents) shouldn’t take prayer and monk-esque chanting, as it often does now.

        Such a level of transparency is also a benefit to end users in a buy beware sorta way. I’m not saying they’ll read it, but devs knowing they are “exposed” has a tendency to influence behavior.

        p.s. Ping me if you want to take this up offline. I don’t want to hi-ijack Ms. Gooding’s article, nor suck up your time responding to my madness.

        Reply

    2. Going a step forward, you could have traits that are used by these classes to greatly improve DRY. Though WordPress requires PHP 5.2.4 (released August 2007) and Traits were introduced in PHP 5.4 (released March, 2012)… sigh.

      Reply

  2. As a theme developer, I’m really pleased to see this happening. Hats off to Justin for organizing this.

    Reply

  3. I am against this because I don’t think it’s necessary.
    Instead I support incorporating the technology behind the http://generatewp.com site into building CPT’s into an on the fly plugin that would abstract the data.
    In effect, there would be a interface to assign a particular existing CPT to a particular vertical function for a plugin. As a result it wouldn’t matter what a CPT is called.
    Also building a wizard type interface for basic WP code generation that can be shared by all plugins would be extensible to many uses in the future.

    Reply

    1. The whole point about this is that something like the approach you favor would lead to arbitrary names like “portfolios” and “portfolio” and “my_portfolio.” Apologies if I am missing your point.

      Reply

      1. I don’t favour arbitrary names as much as I don’t think fixed names for anything but the bare minimum is a good idea.
        Instead I am suggesting that the user would assign an existing CPT to a use (portfolio as you suggested). The interface could say,
        “Select an existing CPT for use as XYZ’s Portfolio CPT” with a pulldown of existing CPTs.

        Reply

    2. Based on what I’ve noticed, much of Gen WP can be abstracted (?) into classes and those classes can be (in theory) add to WP core. For me WP Gen is simple proof that a fair amount of WP dev (read: code writing) is simply filling in the blanks (i.e., setting the args). So why can’t we just do that from the get go, instead of having to write the code AND the args?

      A better use of array and classes could – imho – go a long way to making WP dev more efficient AND result in better, cleaner code.

      Or something like that ;)

      p.s. My sense is Justin is talking about something other than code generation. I could be mistaken.

      Reply

      1. From what I can tell, Justin is just a developer with a large audience saying – ‘Hey, can we reduce the insanity that currently exists in the ecosystem.’ He’s right, its nuts out there right now.

        I don’t think it has much to do with code generation or even code in general; he’s just attempting to wrangle in this area of complete chaos. A lot of developers are doing their own thing and it makes much more sense to have some community guidelines about how to approach these things.

        My concern is what does this look like, or how does it impact anything if the effort is successful?

        Reply

        1. As you mentioned, these are only guidelines, and it would be non destructive by design, as previous implementations would still be working.

          Of course in case of post type name collision, it would be care of developers to handle it by either accepting this new set of shared conventions and adapt their code, or ignore them and making their implementations live side by side.

          Reply

Leave a Reply