Look. I still hate Your frameworks.
I really do. They’re a decent idea with a terrible reality. The concept of ‘a plugin to build other plugins’ is nothing at all like a Parent Theme. A plugin that builds other plugins is synonymous with a theme framework or, perhaps you’ll understand this better, a starter theme.
Have you met _s?
_s (aka underscores) is a starter theme. Themes are built from it. In and of itself, it’s not a theme you’d see on WordPress.org because in and of itself, it’s useless. It’s not a parent theme, it’s not even a ready to use ‘drop this theme in and you have a site’ sort of thing. No, in fact if you installed it, it would look terrible.
Because the point is not to use it as a theme, but to use it to build your theme. No one in their right mind uses Underscores as a parent theme. No one uses it as a drop-in to their themes. It’s a, literal, framework where you say “This is my Theme Name, this is my slug.” And then it drops out the code for you to start plugging into.
What do the existing framework plugins do?
The problem isn’t what they do it’s how they do it. They’re not frameworks. They’re libraries. A library is like the AWS SDK library. It’s a vendor based addition to your code that enables it to do ‘a thing’ but, in and of itself, doesn’t do anything. A library is a great tool and lets you include code that you’re going to use but don’t want to reinvent the wheel. I love them. Another example would be that Font Awesome is a library.
But we don’t allow libraries, themselves, in the repo. That means if you write a Font Awesome plugin, it has to actually do something besides just include Font Awesome.
And the point here is that a plugin, like a theme, has to be usable. It has to stand up on it’s own and do something.
Is a library perfect?
Once you take your framework plugin out of the repo, how do you handle upgrades?
Obviously you can run your own upgrader (which we’d encourage) but if the plugin is folded into another plugin, you’re not able to just upgrade YOUR portion. So you have to wait (and trust) the plugin dev will update their plugin and include your latest version.
Mind you, this is an existing problem with plugins and libraries and, in a way, is related to why we don’t allow you to use your own copy of jquery. Conflicts! Yay!
How does _s handle updates?
This is something Konstantin’s thought about before. Funny thing, Underscores is versionless and it doesn’t update often.
Here is a list of reasons why you should not update your _s-based theme with our changes to _s:
- Most likely your theme code will have evolved to a degree where merging _s changes would lead to conflicts. They also won’t be applied to anything you created on top of it.
- We are in the unique situation to not having to worry about backwards compatibility when we commit changes. And we don’t!
- Once you release your theme, you’ve probably fixed all the things in _s that needed fixing for your case. Just because we push an update to _s, it does not necessarily mean it applies to your theme.
Basically there should be no updates to your framework.
And that terrifies a lot of people. Because the extant framework plugins update a lot. In fact, some of them want to be in the .org repository specifically because they update a lot.
They shouldn’t. And that’s why I think they’re doing it wrong.
Be a Starter Plugin
Stop trying to be a framework. They don’t work, they’re not sustainable, and they’re problematic.
Be a starter plugin. Be a plugin that I can download. Use that underscores form so I can download everything set up for ‘me’ right away, no search and replace needed. Have a template settings page that creates basic options, just like a theme. Except that plugins are not themes. And there’s the real issue. A theme is ‘easier’ (and this is subjective) because it only has one interface: The customizer.
Plugins can add a menu section, they can add an option to an existing area like discussion, they can be silent and have no information and just work. Plugins can do anything and in any way. There’s not a ‘standard’ because there really can’t be.
Is There An Answer?
I think the starter plugin would work, if it came with options. It would more likely be a workflow. Where do you want your menu? Will you connect to an API? Will you need settings?
If someone can boil that down, it would all be better.
Comments
4 responses to “Underscores (A Plugin We Need)”
Boilerplate is like _s for plugins, or not?
@Musilda: It is and it isn’t.
The Boilerplates are great, except when you start messing with the settings API (aka – the wet bag of hair that all plugin devs hate). There’s no really easy way to add in things like saving settings that work for all plugins, nor is there a great way to add in options and naming conventions.
For the basic ‘This is how you structure plugin files’ those boilerplates rock. It’s the next level I hate.
Okay, I read what you wrote in the other article and it makes a bit more sense. I think I only have two disagreements.
1. WordPress should add plugin dependency support. I know this has been proposed before and it has failed for various reasons. I also know that people are working on getting composer to work with WordPress and there is a really good solution that works well.
I believe that this should still be independent of WordPress, but also have some integration with the wordpress.org site. Once wordpress.org starts supporting composer natively, then solutions will start using it and a lot of the problems may go away.
A 7Mb download is still going to cause problems and I’m can’t even comprehend what that might be.
Can you give some examples of plugin frameworks? I have never heard of this before. It sounds like an incredibly bad idea. I think that if people are doing it, then it is to meet a demand that the developers think exists. If WordPress doesn’t meet their goal, then they will work around WordPress. Not the best solution, but you have to do what you have to do, to provide a solution.
2. A starter plugin only works for the most trivial of tasks and would merely provide a base or example for others on how to create a WordPress plugin. I mean, people have attempted it in the past and no one has used them, because well. They can’t really be used for anything useful. Once you start interacting with a third-party API (REST or PHP), then it all falls apart.
There are two proper solutions to the problem. Well I guess three with the third being either ignore the problem and let it fester or continue or someone smarter will suggest a better solution than the ones below.
1. Provide a dependency solution. Either composer or home-grown.
2. Find out why the frameworks exist and what they are doing and integrate more of that into WordPress in a way that reduces the load of what the frameworks need to do.
I would suggest some combination of both solutions as they are not mutually exclusive.
Oh right. I found a couple and it seems to be along the lines of what I attempted to do by forking WordPress. I do still think your criticism is misplaced. You should be objecting to the way WordPress does things instead of how others are working around WordPress. I will say, that at that point, you are almost better off just using Laravel, but I guess having a working CMS is better than hacking together a web site solution.
@Jacob Santos: So in a way WP already has ‘dependancies.’
You can build your plugin to say “On activate, if plugin X is not installed and active, do not let MY plugin activate.” But it’s a bit janky and I’d love someone to write a simple
wp_plugin_dependancy( 'foo', 'bar', 'baz'). That said, if you look at is_plugin_active, you can see that the lack of strict requirements in plugin design makes that harder. We don’t have a ‘style.css’ like we do with themes, so you can’t easily enforce naming conventions or other checks. Plus with plugins, you’d have to toss in the ability to check for versions.So really, yes, that’s the primary hangup for a lot of things, but not, I feel, why ‘frameworks’ suck. And it’s not why I think we need a plugin ‘like’ underscores.
I think, ultimately, the reason I hate frameworks is because the Settings API is a bag of wet hair.
What the majority of the frameworks (at least the ones I see submitted to the repo) are doing is making it ‘easier’ to interact with the API and to design a plugin. Which means the issue is not dependancies at all, but the shit that is our settings API.
Personally I think that the reason the API sucks so much is to make us constantly make decisions and not options. But I don’t like that answer.