The WordPress Plugin Directory Will No Longer Accept Frameworks

photo credit: Jaroslaw Puszczyński
photo credit: Jaroslaw Puszczyński

Today the WordPress plugin review team issued a reminder for what they said is a long-standing, unwritten rule: frameworks are not allowed in the official directory. In a post tiled “Please do not submit frameworks,” Mika Epstein outlined the reason behind the rule:

At this time, we are not accepting frameworks as we don’t feel frameworks, boilerplates, and libraries are appropriate for the Plugins Directory. We require that plugins be useful in and of themselves (even if only being a portal to an external service). And while there are many benefits to frameworks and libraries, without plugin dependency support in core or the directory, it becomes another level of hassle for users.

Until WordPress core adopts a way to support plugin dependencies, the plugin review team recommends that frameworks and libraries be packaged with each plugin in a way that doesn’t conflict with other plugins/frameworks/libraries.

The issue was most recently addressed with the CMB2 plugin, which Epstein said was mistakenly approved months ago. CMB2 is essentially a library that makes it easy for developers to build metaboxes, custom fields, and forms. It is exactly the kind of plugin that the previously unwritten rule is meant to block from being available in the official directory. Epstein further clarified the reasons why:

The issue is as follows: Having a framework as a plugin is a poor experience for the user. Not the developer. The user. The user understands “I have an add-on for WooCommerce, I probably need Woo.” They do not always understand “I have plugin Slider Joe. Why do I need Advanced Custom Fields?” In addition, by having a library as a plugin, the onus of version compatibility is now on the person least likely to understand it: the user.

The plugin repository is not, currently, a library or framework repository. It’s not meant like the NPM package manager, or even Composer as a way to define what a plugin ‘needs’ in the same ways for a developer to build a project. The plugin repository is, plain and simple, meant for plugins that users will find useful. Plugins that add functionality to WordPress in a directly inter-actable way.

The confusion lies in the fact that this particular rule has been applied inconsistently for years and has many notable exceptions, including Redux Framework, CMB2, and arguably plugins like Piklist, Titan Framework, Kirki, Options Framework, and many more. These are the types of plugins that don’t really do anything out of the box but are meant for developers to use for building things.

According to Epstein, a few of these plugins have been “grandfathered in” due to oversights in the plugin review process, but the rule stands for new submissions.

“CMB2 and Redux Framework are grandfathered in,” she said. “We don’t let any more in, since a lot of plugins include them inside AS plugins. It’s a mess. Also CMB2 shouldn’t have been approved, which is a different mess altogether. Frameworks are not supposed to be in the repo at this time. Period.”

Another commenter on the most recent post, who recently had his Advanced Term Fields plugin approved, asked, “Are you saying the best way to handle this scenario is to include the parent framework in each child plugin, as opposed to alerting the user that ‘This plugin requires XXX plugin in order to function properly?’”

Epstein confirmed that this is in fact what the team is suggesting:

Currently, yes. That would have been the best way. Since your plugin is approved, though, it’s unfair of us to yank the rug out from under you. While you don’t have a great many users, we recognize when the gaff is us.

The plugin review team has a difficult job and is working with limited volunteer resources. However, the inconsistent application of unwritten rules has led to what appears to be an arbitrary set of guidelines. One thing that would make life easier for both reviewers and plugin developers is if WordPress core adopted a way to manage inter-plugin dependencies. The TGM Plugin Activation team is working on a proposal for a feature plugin, which we’ll examine in depth in an upcoming post.

72

72 responses to “The WordPress Plugin Directory Will No Longer Accept Frameworks”

      • And maybe the new TGM activation one could require 3 other plugins to work :)

        More on point, I am exactly the type of user that finds this stuff confusing, and honestly, when I hit an issue like that, I uninstall all the dependencies and find another tool. Even if it isn’t as good. I can’t afford to have plugin 1 break something because plugin 2, 3 or 4 isn’t working or isn’t installed. I’m not a programmer, I’m a user. I work the best I can with the tools, but usually, if something goes wrong, I just have to go without or find another tool, it’s usually beyond me to actually fix.

        P

    • Wouldn’t it make more sense to have a “Libraries & Frameworks” or “Developer Tools” or “somesuch” directory running alongside? Plus suitable user warning/advisory notices, of course.

      That way we can move forward without excluding anyone’s necessary toolset.

      I’m kinda thinking, the Founding Fathers (and mothers) ~ god bless’em ~ called them “Plugin” and “Theme” directories for a reason.

  1. This is a breaking news for plugins like CMB2 or my Meta Box. I was hoping WordPress core team can resolve the plugin dependency before making this decision. Maybe create a place where developers can submit their frameworks.

    One of the best reason why frameworks were submitted to the repo is the updating mechanism. Using it with a librarly like TGM Activation Class solves a lot of problem of including the framework into a theme or plugin.

    This change will make new framework author harder to maintain the dependency when it’s used in several plugins or theme. The order of loading for plugins in the WordPress core is not clear enough at the moment.

    • The order is actually very clear, it is random and you should not rely on it. Frameworks might be used in muplugins as well so you can not even assume anything about what is loaded even if you knew the order.

      Framework creators should just write better code – avoid singleton patterns and have flexible name spacing.

      • The order is not random at all. The order is alphabetical, so plugins are loaded based on their plugin name (well actually their slug). That’s why a plugin should only start working from the plugins_loaded hook, from where it can be changed in priority or whatever to determine the order the plugins need to be loaded in.

        • The order is not guaranteed to be alphabetical. There are plugins that change it (I have developed one myself). It is dangerous to simply say it’s alphabetical because that’s what people will remember then.

          The best ways is to say that order is indeterminate and indeed should never be relied on to be any.

        • Nothing in software is truly random, so you are right in a pedantic way, but you can not develop a plugin assuming it will be loaded before or after another one as it depends upon local setting. and with the active plugins option being filterable it is not hard to imagine that someone might change order of things, even if you could relay on PHP and wordpress to be consistent about it.

          In my book any behavior not officially document should be treated as random. But I will try to be more careful when I use this word from now on.

  2. I can somewhat agree with this policy, but the answer to “bundle the framework with the plugin” is equally bad if not work because then if two plugins use the same framework in an incompatible manner it will crash on the users. The plugins won’t be able to be used together unless they are using compatible versions and the plugin that is loaded 2nd checkes before loading.

    But those caveats are not a solution. I tried to solve the problem a while back by creating a library called Imperative that by design would not need to be revised, and it could manage dependencies but it turned out doing so without willing support for changes in core was a clusterf*ck because core code is such a mess in these areas, and at the time I could find no interest from the core team in solving this problem.

    I think the approach I took to solve the problem was sound, but only if the approach found in Imperative was applied to core; it really does not work as a standalone library.

    Basically the idea was to let a library/framework register itself and its version using Semantic Versioning via a small stub php file, and then have Imperative (or better, WordPress code) decide if the versions are compatible or not. If they are compatible the newer library/framework would be loaded. If incompatible, plugin activation would not be allowed for the plugin whose library/framework was incompatible with what was already activated.

    Also, there really is a need to allow frameworks to be promoted on WordPress.org because otherwise the WordPress community is effective throwing shade at the idea of a library/framework cause many companies to shy away from them. And without a central repo and stats how can the better ones be recognized and rewarded with wide usage?

    I would propose that WordPress.org adds a section for “Frameworks and Libraries” and that they use Git and GitHub as the version control system and repo for this set of extensions, and also add a dependency manager like I’ve describe above.

    • the problem is that even for better and bigger development teams than most plugin has, it is virtually impossible to prevent backward compatibility breakage. Add to this the fact that some plugin authors will not understand that you should not mess with the code of a library you depend on, and you end with several plugins that use the same library by name, but just can not use the same code base.

      Frameworks as a plugin is a shady idea, but I agree that just throwing them out without giving any other solution do not improve anything not even for the users.

      • the problem is that even for better and bigger development teams than most plugin has,

        The bigger team does not necessarily make it a better team. #justsaying

        it is virtually impossible to prevent backward compatibility breakage.

        You could easily also say It is virtually impossible to write a bug free plugin. Yet that does not stop 40,000+ plugins from being written and added to the plugin repo.

        So just like many end-users learn to avoid the bad plugins, plugin developers who would use libraries — who by nature are more aware of best practices than end users — will learn which libraries/frameworks are reliable and avoid the bad libraries/frameworks. That’s the way the bazaar works.

        And the good ones will be able to handle it no problem, just look to Composer/Packagist, NPM, etc. where they have proven such things can work in the vast majority of cases.

        some plugin authors will not understand that you should not mess with the code of a library you depend on

        A trivially simply way to solve that is to have frameworks loaded from WordPress.org.

        and you end with several plugins that use the same library by name, but just can not use the same code base.

        Which can happen now with plugins and themes, but only of code you wrote or installed yourself, not code downloaded from WordPress.org.

        Frameworks as a plugin is a shady idea,

        It is unfair to call it “shady.”

        “When the only tool you have is a hammer then everything looks like a nail.”

        And thus far WordPress.org has only given us plugins…

        but I agree that just throwing them out without giving any other solution do not improve anything not even for the users.

        +1

        • A user has a plugin requiring library version 1.0, now he wants to install another plugin that requires version 2.0, can he safely upgrade the library “plugin”? If something breaks who should he blame , one of the plugin authors or the library author? If it is impossible to point to the party at fault you are not going to have any darwinistic improvement, all you will get is “wordpress plugins suck” or “don’t use plugins that use frameworks”

          libraries/framework should be utility code written to be able to work when two different versions of it is being used in the same execution context it is a failure of the framework author if it doesn’t.

          You compare to NPM etc, but those repositories expose services not libraries, or in case of libraries allow you to use two different version in the same context. There is really nothing new here, the framework as a plugin issue in wordpress is yet another version of DLL hell, which have solutions in both windows and unix, and the solution is basically to have multiple versions of plugins coexist at a site. WordPress forcing plugin upgrades and overwriting the older version is what makes it a shady idea.
          It doesn’t help that everything in php is in global scope by default and plugin author using singletons and global variables.

          Plugins, at their current form, are just not the long term right tool.

        • @mark k:

          A user has a plugin requiring library version 1.0, now he wants to install another plugin that requires version 2.0, can he safely upgrade the library “plugin”?

          According to the rules I developed for Imperative, they would be disallowed from installing the 2nd plugin unless and until they deactivated the first plugin. And when it is disallowed, Imperative/WordPress core would/could present that option to them along with links to deactivate the 1st plugin and activate the 2nd one, if they liked. Also they would be given a link to support for the 1st plugin so they could ask the developer to upgrade the library.

          If something breaks who should he blame , one of the plugin authors or the library author?

          If you buy a hamburger at McDonalds and get food poisoning, do you ask who to blame, McDonalds or the beef provider? You blame McDonalds, of course!

          So to would you blame the plugin author. As an end-user you have no relationship with the library author, the plugin developer does.

          If it is impossible to point to the party at fault you are not going to have any darwinistic improvement, all you will get is “wordpress plugins suck” or “don’t use plugins that use frameworks”

          You are setting up a strawman just so you can knock it down.

          The same problem exists today between two plugins that don't behave well together. Adding libraries will actually improve the situation because we'll evolve to having a few libraries that are a lot more robust than the code plugin developers currently have to reinvent over and over for every plugin that needs the same things.

          libraries/framework should be utility code written to be able to work when two different versions of it is being used in the same execution context it is a failure of the framework author if it doesn’t.

          I posit that it is effectively impossible with PHP for a library/framework developer to do this without the support of the core platform (in this case, WordPress).

          So it is not the libraries/framework author's fault or responsibility, at least not currently their fault.

          I've got a lot of experience trying to make them work when I was building Imperative and I am pretty sure I would have come up with a may to make it work because I worked on the problem for over a year, off and on.

          You compare to NPM etc, but those repositories expose services not libraries

          Services?

          NPM is a package manager for NodeJS and the packages (aka libraries) are located at https://www.npmjs.com.

          Composer is a package manager for PHP and the packages (aka libraries) are located at https://packagist.org and https://wpackagist.org.

          How are these "services" and not "libraries?"

          in case of libraries allow you to use two different version in the same context.

          Yes. And developers use them when they run a "build" process. The build process allows only one version of a library. The build process will fail if you try to load two different versions of the same library (at last I think it will.)

          That is different from plugins. Plugins are added by an end-user; there is no "build" process. However there is a "plugin activation" process and it is there were incompatibilities need to be reconciled.

          There is really nothing new here, the framework as a plugin issue in wordpress is yet another version of DLL hell, which have solutions in both windows and unix, and the solution is basically to have multiple versions of plugins coexist at a site.

          I agree with that statement. But what it is overlooking is that, with PHP you cannot have more than one copy of a library; you cannot have multiple parallel versions because there is no clean way to do it in PHP.

          (Well there may be a really scary hacky ways, but no elegant, robust and generally maintainable way…)

          Maybe in PHP 8.0 — if the right people were to make an issue of it and get a receptive ear in the toxic kindergarten — but not today.

          And not for WordPress for the next decade if WordPress' current version adoption history holds.

          _ WordPress forcing plugin upgrades and overwriting the older version is what makes it a shady idea._

          You an I have a different definition of "shady." A plugin adding a back door to a server or adding links to a theme for SEO is "shady"; providing a framework as a plugin is merely short-sighted on the part of the developer.

          It doesn't help that everything in php is in global scope by default and plugin author using singletons and global variables.

          Well you are at least grasping a bit of why the solution to DLL Hell won't work here…

          Plugins, at their current form, are just not the long term right tool.

          The right tool for what?

          And what is the "right" tool for your perceived requirements, IYO?

        • The text book solution to the DLL hell is exactly what will work here, wordpress is not that unique that all wheels have to be re-invented. This should be a combination of a kind of “service locator” in core and framework authors education about stopping to misuse global space.

          For this to work you need a new component type which is by design “shared” and then you can treat it differently from plugins.

  3. Does WP understand that its popular because of old developers and new developers… Cool, You cant fix some issues with Media Upload,
    you cant fix some issues with Navigation in backend…and you cant fix some old code in WP, if we check all WP files there are some very different aproaches to code (code guitelines etc…) and you cant even fix that in this 5years…. But Frameworks are bad for users? Why dont you delete old Plugins in REPO that arent updated in 2+ years ? – Thats bigger issue for users than frameworks… And we still love WP, and we still work with WP, and we still get 50+ new WP clients a year… – So its NOT just WP thats good or thats something good,
    I think that 30% of WP good things and new websites are from that people that create that Frameworks you want to BAN :) you call it how ever you want… but someone didnt take a good time to think about this at all…

    Will you remove WP-API from WP.org ? – If not, then you dont care about normal users – you are doing something very very shady…

  4. I’ll stick my neck out here as a potential dolt and say I don’t see how these examples of plugin frameworks fail to meet the requirement to “add functionality to WordPress in a directly inter-actable way.” I would say they most definitely do.

    I look back at my 3rd attempt at a plugin for the repo a couple of years ago. Pippin rightfully so by this definition kicked it back because it was one of those empty “theme functionality” plugins that we find on Github. Had I included an interface with switches and checkboxes, it would have been accepted.

    So, circling back, CMB2 and ACF do, in fact, add the ability within the initial plugin download to add metaboxes, powerful metaboxes, without the need to use any of the myraid other add-ons they offer. My first experience with ACF several years ago was without any add-ons and I was able to deliver, as a far junior dev than I am now, a site beyond my abilities to confidently build metaboxes, while also allowing my client to be able to edit them or add new ones after delivery.

    That said, perhaps these are poor examples of what you’re keeping an eye out for the future. If so, is there an example (without name) of one recently denied? A framework, not just a simple plugin like my failed submission was.

    • Jesse,
      I agree that ACF or CMB2 can be run successfully without requiring other plugins, and also offer the possibility of building handy data entry elements.

      I think they’d allow a plugin like ACF because it offers the non-techie user a very simple interface for creating custom fields. CMB2 does not have any admin interface, although by writing just a small amount of code, one can create very useful interface elements for the user. But a developer is required. I think that’s the distinction that they’d draw.

      Apart from that, I guess I’ll keep my eye on other sources than wordpress.org for plugin frameworks.

      Dave

    • +1

      I found most of the “frameworkds” I have used through the years through the repository. This, ultimately, is going to hurt developers in the future and make it harder for developers to help each other.

  5. The definition of “framework” is just too vague here, with too many edge cases. What about Posts 2 Posts? It’s a vital plugin that lots of people use. But one that could easily be construed as a framework because it doesn’t do anything without additional user code.

  6. I really glad WordPress has solved the whole plugin dependency pro…. oh wait. They haven’t. This has been a problem since Composer became popular in the PHP community. It doesn’t really seem like there’s a lot of traction in terms of trying to solve this problem, so to see the repository cut off the only avenue we have for dealing with this is a little frustrating.

  7. This seems like a good policy. I wouldn’t want to see WordPress’ Plugins Directory suffer from some of the design flaws of Canonical’s (Ubuntu) repositories. In that environment, you can be sure that any package name that starts with lib is not a ready-to-run package, but you can’t even begin to assume that something that doesn’t is, as there are partial packages like foo-common or foo-doc or foo-dev. For example, if I come to the conclusion that my disk is too close to full and I want to throw some software overboard, I might consult Ubuntu Software Center (USC) to take inventory of what packages I have installed…except the vast majority of items on the list are things I won’t even begin to recognize, let alone know whether they pertain to essential system tasks that I don’t want to part with. It’s quite a mess, really. You can probably say with some honesty that USC is as user-friendly as anyone’s “app store”, but then it turns out the line between apps and non-apps (or sub-apps) is clear as mud, which kind of negates the user friendliness of the interface.

  8. They seem to be focused on custom meta box plugins in this article. My question is. Why isn’t there a custom meta box GUI in core. This a really basic part of CMS’ and it’s obviously a popular feature based on the amount of plugins that are made for this.

    Why do they add emojis into core, but we still don’t have custom post types and custom meta boxes GUI’s? I feel that if the core development team focused of what features the community actually wants we wouldn’t have had this problem in the first place.

  9. Why don’t they implement a simple method of warning users when a user is about to download these so called “frameworks”?

    The plugin developer could simply indicate in a consistent manner that this might not be the king of plugin the user is after, at the same time providing links to the documentation of the plugin. This way the user could decide if she really wants to try out the plugin or not.

    “Having a framework as a plugin is a poor experience for the user. Not the developer.”
    So they kick the devs in the butt, just because… What a childish “solution”!

    • What’s the motivation at work here?

      Ignoring the unintended consequences, is it …

      Making life easier for everyone by cutting out a whole class of directory entry?

      Or, improving the ratio of easy to use, neophyte friendly, useful entries?

      I mean, what’s not to like?

      • What’s not to like, is the lack of ability to obtain reliable trusted automatic backups from WordPress.org and not being able to obtain certain plugins from WordPress.org. This now offloads this requirement to an external service, since plugin developers will need to provide automatic backups themselves.

  10. What about plugins meant for specific themes only? Are they not also frameworks then? The user has to buy the premium theme in order to have the plugin function. For anyone who does not buy the premium theme those plugins are just taking up space. It would be nice if they were at least not included in the plugin search – unless the user actually searches for Genesis plugins.

    There are other themes which do this, Genesis is just the one I thought of first.

  11. Momma said, Stupid Is as Stupid Does…

    And this is stupid and punitive to developers. Especially (as noted above) when we get BS crap like emojis and no built-in meta-box UI in core. I really wish Automattic spent as much time HELPING and FIXING stuff as they do finding new rules to impose their will.

  12. I can understand this move. If you have a look in the WP forums for the Redux plugin, there is a quite an irrate post from a user who thinks Redux is crap coz it doesn’t do anything… This user reasonably expected that a plugin on the WP plugin directory would actually, out of the box, be of benefit to their site.

    Redux is a dependency of my own plugin, for which I use TGM to advise users. TGM works fine with any source location, not just the WP directory, so I’m not sure why banning them from the directory is a problem.

    I do think it is madness to bundle the larger frameworks, like Redux, in your own plugin (or theme). That just makes lots of fat plugins and themes, risks version conflicts if a developer doesn’t set isolate it properly (which happens a lot)

    Not bundling also is better for security, as the framework will always be at the latest version (if the user does updates), whereas bundled, it could get out of date if the developer stops development of the plugin.

    I really like Mike Schinkel’s idea of a separate repository for frameworks. I think there is much value to the whole community in WP visibly supporting frameworks.

    I am concerned that those already in are allowed to stay, as it makes it inherently harder for new ones, no matter how good they are. Mike’s idea would solve that problem too.

  13. Since the plugin directory is being upgraded in the near future, maybe we could get new designations for plugin usecases.

    1) Ordinary standalone plugins,
    2) add-on/extension type plugins and
    3) framework/helper plugins.

    Imagine being able to pull up a list of popular frameworks. Or easily finding all available plugins that work with a particular parent plugin or theme.

    Addon plugins also clutter up and confuse searchers. If you search for a forms or caching plugin and you get a bunch of add-ons mixed in the results it makes finding things harder.

    I think the easiest solution is to create a separate search&index for different types of plugins. This clears up the unexpected results users get when their search intent is a standalone solution.

  14. So, there is no one definition of a WordPress framework, and there is no agreement on how to package plugins and libraries for frameworks.

    Look at how Drupal defines a distribution. Yes, it’s a complete package with core, but it gets the job done, and they are offered as default installs in Pantheon.
    https://www.drupal.org/documentation/build/distributions

    Not a solution, but a comparison in rethinking the framework conundrum.

  15. Ugh. Everybody seems to be reading into this way more than is actually there.

    The problem is simply one of managing dependencies. WordPress does not have plugin dependencies, and trying to fit plugins into a “code library” mode is a bad fit, at best.

    There are assorted problems with “libraries” in computing in general. We all know about “DLL Hell”. The problem with shared code libraries is that the libraries need to remain essentially backwards and forwards compatible, forever. If code A and code B depends on library C, and library C makes a breaking change in some update, then all three pieces of code need to be updated simultaneously to avoid breakage. Updating only one of them will break something.

    WordPress has not solved the code library problem, and even plugin dependencies as currently thought of won’t be a general solution to it. The general method that works in the most cases is the same as that of “static compilation”. Put the library in the specific code that is using it, so that no breakage occurs from incompatibilities. Each piece stands alone.

    Now, in PHP, this introduces special problems. In the long run, things like namespaces and such can help here, but we’re still working towards moving that PHP version bar up off 5.2, yeah? Can’t leave millions of people behind.

    So, do your best, is what I’m saying here. But don’t try to use the plugin directory as some way of introducing shared code libraries. We don’t need it at the moment, it doesn’t work very well, it causes problems for users down the line, it causes confusion to users who don’t understand why something takes multiple plugins, and the WordPress code doesn’t even support plugin dependencies yet. See the issues?

    At some future point, when the state of things changes, then the plugin directory will naturally change too. Nothing is ever permanent. If you want to help out, then by all means help out. Figure out solutions to these problems. Make a plugin dependency solution that actually solves some of these problems instead of simply creating new ones. Encourage hosts to upgrade their older PHP 5.2 customers to PHP 5.6 or PHP 7.0. Help raise that bar so that we can have nice things. Okay? Okay. :)

    • I see the issues. I applaud y’all deciding to finally adopt the standard.

      What I find amusing is the exemption and “accident” logic being used to allow things that shouldn’t be in the repository at all.

      BTW, how do y’all have such accidents? Don’t you have a knowledge of what a framework is from the onset of evaluation?

      Don’t you evaluate plugins closely? Accidents indeed. How is something grandfathered in due to evaluation accident?

      Having nice things is great. Consistency is a wonderfully nice thing. Why not start there?

      I know you have no problem removing plugins that for some reason violate your policies. I have seen you do it even after they have been in the repository for years. Why not remove those frameworks that violate the policy you are enforcing now? If something is not allowed, it shouldn’t be allowed.

      I agree, “Help raise that bar so we can have nice things”.

      I am basing my understanding on the presumption you have discovered how to stop the “accidents” and exemptions from happening in the future.

      • +1, untill other data is presented I also believe that people on 5.2 just don’t upgrade. neither core nor plugins and therefor should not be seriously taken into consideration.

        @otto, pity you took the discussion in this direction as I fail to see why you have to have namespace to have a locator type of service. In any case smart use of autoloading and class versioning might work even on 5.2.

        • Auto-loading sounds great to me. Help add it to core. :)

          This is a problem that needs core solutions, is all I’m saying here. It’s not something we can solve half-assed through the plugin directory. Not really. Too many problems, too many issues, and users suffer all the breakage resulting from it.

  16. Part of me agrees with this, since “Once a library is IN THE REPO it’s a plugin, and you should not include it in your plugin wholesale. It’s now a dependency to your plugin.” that can cause a lot of problems and we don’t need that.

    I also think that an end user should not know about the libraries and stuff like that, they should be embedded just like we embed JavaScript.

    Till WordPress Repo gets an algo update, I think hosting libraries like this at GitHub would be a great option.

    P.S. One can always use TGMPA to include the libraries via GitHub.

    • I definitely see an opportunity here – a framework/package repository aimed primarily at developers, complete with versioning, code-sharing. Maybe star-based ratings like npmjs.

      I personally hate telling clients that they need to install plugin XYZ so that my plugin will run. I’d rather find something that was completely hidden from the user.
      Anything that’d make my job easier would be great.

      Anyone interested in making one? :)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Discover more from WP Tavern

Subscribe now to keep reading and get access to the full archive.

Continue reading