The following is a non-exhaustive list of things you can do to get your plugin rejected or removed from the WordPress.org plugin directory.
Yes, this is tongue-in-cheek. This is a list of things NOT TO DO.
- Give it a license that is incompatible with WordPress’ license.
- Host your plugin elsewhere, and only use the WordPress.org plugin listing as a pointer to that.
- Use base64 encoding to hide your plugin code or obfuscate HTML that you’re injecting into people’s blogs.
- Insert SEO spam links into people’s blogs (like <a href=”http://example.com/”>video poker</a>).
- Insert external links (like a credit link, <a href=”http://example.com/”>My Awesome Plugin by Awesome Sauce</a>) into their blog without explicitly asking their permission, or make the default option be to insert the link.
- Load portions of the code from an external site for no valid reason, or use any other trick to work around #3, #4 and #5.
- Harvest people’s e-mail addresses or require registration to activate the plugin.
- Explicitly state or imply that users of the plugin must pay you money in order to use the plugin.
- Make the plugin a “requirements check” or bootstrapper for some other plugin, hosted elsewhere. See #2.
- Make it do something illegal.
- Make it do something sneaky, underhanded, or otherwise dishonest or immoral. Maybe a plugin that disables all plugins by a plugin author you don’t particularly like. Harvest the user’s password. Use your imagination!
Again, this is a list of things not to do. It is not comprehensive. Be cool, think of how your plugin benefits its users, and write awesome plugins.
Mark on WordPress 
haha this is what you meant, nice 🙂 I was thinking that I will comment about ‘I once installed shopping cart plugin’ and when I removed it the tables it originally created in my database weren’t deleted.
There is a good reason why plugins shouldn’t delete tables they create when you deactivate the plugin… sometimes you don’t deactivate a plugin because you want to remove it.
If it automatically deleted the tables simply by you deactivating the plugin… or even deleting the plugin… you would lose data that you might not have intended to lose because you were just doing testing. There are a wide variety of reasons why you would deactivate a plugin and NOT want to lose the data.
That is why it’s best for plugins to include some sort of “uninstaller” so you know that what you are about to do is going to delete data (such as custom database tables).
Nice post, I will have this in mind the next time I would “develop” some plugins.
Take care, Mark.
PS: Once a saw a plugin that had a SQL query that injects a link in the table wp_links. That case would be in the item number… 4?
Yeah, that’s no good. Point out the plugin if it comes to mind.
So a plug-in that puts a link on a page back to their own site is a no go? For example Powered By So and So plug-in?
I suppose he means that you must ask permission. Meaning have the check box for them to select. Like WP-Super-Cache have a button that says show the world that you are Digg Proof… Many plugins do it, but if you place a link without the user’s permission, then it is not cool.
You should ask permission, and default to “no.” How the WP-Super-Cache plugin does it is perfect. A checkbox that defaults to unchecked.
I totally agree with 10 of these, but NOT number 5.
Some of my plugins have a Powered by link, which are turned on by default – always with an option to turn it off. I only add it if it makes sense. There have been cases where I’ve left it out because it would clutter up the screen.
I don’t see a problem with this and don’t mind when other people’s plugins do this, as long as I can turn it off.
If you apply rule 5 to themes, you’d be lucky to have ANY themes left in the repository – and most themes don’t provide an option to turn the link off, the users have to edit the code.
I think an optional link is fine for free software.
I though it was fine too, but now (with this post) the rules are more specific and clear and that’s better … I guess, because, at least, exists a list that we can review to know if we are doing it right or wrong.
Even so, I think shouldn’t be problem if, by default, the credit link is checked, with the option to uncheck it. But rules are rules.
To be clear, I think it’s fine too… it should just default to off. Themes are different than plugins. You only have one theme, and it defines how the blog looks. You probably have a whole host of plugins installed. If every plugin inserted a credits link by default, that’s a lot of admin hunting people have to do to disable them.
We’ve also had issues with plugins toeing the SEO spam line with the credits link. How would you feel if my plugin linked back to me with the text “best WordPress consultant” or “WordPress security reviews” or some other SEO-optimized text? Those are the two reasons we have this policy.
Hi Mark,
I can understand your point with links being abused and I’m totally fine with a rule such as “the anchor text must be the plugin name and can only link to the plugin’s home page”. I know there would be difficulties policing this if people keyword stuff their plugin names, but in most cases it should be obvious.
Additionally, it’s just occurred to me that one of my plugins (not yet in the repository but hopefully one day when I clean it up), requires an external link to Yahoo! because it uses their currency rates api.
The plugin is free, it’s GPL, but it makes a call to a Yahoo! api and they require the link. Are you saying that plugin can’t be added to official repository?
Yes, like I said: It’s better if we can read these guidelines (sounds better than rules :D) in some place 🙂
Thanks again, Mark.
By the way: I saw a lot of themes that use base64 encoding. I don’t remember if those themes are in the WP.org repository (but I believe there’re some of those). This rule base64 encoding (with the credit link encoded in the footer) apply to themes or not? (this doubt is because themes are different than plugins.)
Mostly Base64 Coding is used in those repositories like best WordPress themes and bla bla. I haven’ yet seen a theme listed on wordpress.org which has base64 encoding. And the websites who offer illegal premium themes downloads also use such type of encoding to keep their website’s link in the footer.
The only legitimate use I’ve seen for base64 encoding in any WP code was a plugin that didn’t want to load a bunch of images from image files, but instead loaded them out of the plugin.
Not the most efficient way to do it, but he preferred his plugin to be one-file, which I can understand.
Any other use I would say is questionable.
If you find base64 text in a theme it’s usually up to no good.
If you’ve found any theme in the WPORG directory with base64 code in it email themes@wordpress.org. There shouldn’t be a single theme in the directory with base64 code in it.
Indeed, don’t add anything to other ppl sites that you’d not like in yours.
I’d like some more explanation for #1, what kind of licence is not compatible?
WordPress is licensed under the GPLv2.
See here: http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
Ain’t there plugins in the repository that uses libraries that you have to pay for to to use them in a commercial setting? (I think there is can’t just remember the name of it)
So can I tell the users to pay someone else to use my plugin if they make money of their site?
I understand you can make wrapper plugins that you have to get an API key to use which is ok. Does it have to be free API keys?
I don’t know if there are plugins that use such libraries. If there are, they shouldn’t be in the repository, as that would be a non-GPL-compatible license.
The plugin has to be free to use, without artificial barriers locking the code away. If there is an actual web service it is connecting to, that can be non-free (like Akismet). We’ve had people who won’t let you activate the plugin until you register for an account (so they can spam you) — that’s an example of that guideline being broken.
Well you can write GPL software that uses non-free libraries but it is frowned upon. http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#FSWithNFLibs
Ok good to know. Services can cost money the plugins themselves cannot.
Just thought of the plugin must be free to use. If one does a check for license key can you then include non-free libraries? The plugin is GPL, it is free and you can activate it without having to buy a license key. It just won’t work.
I hate spammers, those are cheap and never make big money with his dirty tricks…
Well, when will Akismet be removed from the plugin repository? It violates rule #7
No it doesn’t. You can activate the plugin without registration. However it just won’t do anything as it requires a third party service. The work of detecting spam is done on those remote servers.
This is no different from having to enter your Google Analytics info to get a stats plugin to start tracking your stats, or from the multiple other anti-spam plugins that use a third party service.
BTW, Defensio and Six Apart’s TypePad AntiSpam plugins are both good examples of other plugins that require entering an API key to work since the spam checking is done using a large cluster of servers.
So what if I legitimately want to remove a plugin from the repository, but don’t want to have to break a rule to do it? (perhaps because it’s functionality is no longer necessary or I no longer wish to maintain it)
How would I accomplish this?
I believe if you delete all files from SVN, it’ll go away.
If Alex’s suggestion doesn’t work, e-mail plugins at wordpress dot org and request its removal. If you’re giving up on maintaining it, please consider putting it up for adoption! We’re considering ways of making this easier.
I just tried having a plugin deleted by emailing plugins @ wordpress dot org, and within 10 minutes it was gone! Brilliant.
Thank you!
This is quite helpful.
Much of this list is complete BS for the following reasons:
1. If this list were accurate then Matt would have to get rid of his plugins from the repository. Think about it don’t Akismet and WordPress stats violate numbers 2 and 7 — two of the most egregious cases you’ve listed above.
2. Where do you fall on freemium plugins then (plugins that provide value in the repository but have a pro upgrade). Should these be removed from the repository just because they charge money for an upgrade. Does this violate requirement #8?
3. What’s wrong with getting credit for your plugin? How are plugin authors supposed to monetize anything if they can’t even insert a couple of links to promote their stuff? If that’s the case then why would anyone ever write a plugin in the first place? They wouldn’t unless they are a 25 year old geek who still lives in his parent’s basement.
So I agree with most of your points — I think that obviously developers should provide value and write awesome plugins. What I don’t agree with is the attitude shared by you and much of the WordPress community — that plugin developers can’t be rewarded for it.
I’ll tell you what — if Matt and the folks at Automattic would spend less time coming up with ridiculous/socialist ideas like “core” plugins and more time figuring out how to make it worth developers’ time and effort to write *and maintain* wordpress plugins then maybe you’d find fewer shitty plugins on the repository.
You’re misunderstanding. Akismet and WordPress.com stats are web services. You need an API key to use the web service, not the plugin. I’m talking about plugins that won’t run local code until you register.
First, I’m going to assume that the “pro” version is also licensed appropriately. We haven’t really had this tested, yet. It’s a grey area, and I don’t know if I can provide a really straightforward answer. There’s a difference between a “light” and a “pro” version, and a “regular” and an “artificially neutered” version. As long as the author wasn’t being a jerk about it (like an events plugin that only lets you have one event per week unless you get the “pro” version), I don’t really have a problem with “light” versions. Sometimes light versions are preferable and more useful than their options-laden big brothers! If the “pro” version is not GPL-compatible, then that would be an issue.
Absolutely nothing wrong with getting credit. The issue is abuse of this for SEO purposes and the anti-social nature of inserting a link onto someone’s site without asking their permission. Insert it as an HTML comment block in the header. Put a credits section in the plugin’s settings page. Or ask their permission and with their explicit “yes,” insert a link on their blog.
That’s an inaccurate characterization. First, these are policies about plugins in the repository, not plugins in general. The repository is relatively new, and having it integrated with WordPress for installation/upgrades is even newer. People did, and do, exist quite well outside of it, if their monetization goals run afoul of the directory policies. Second, I have no issue with plugin developers being rewarded for their work. My plugins have acted as an excellent calling card and have driven many of the leads for my WordPress consulting business. I’ve had companies pay me to develop alternate versions of my plugins or to add features to them. Other developers sell support services from their plugin (promoted from within the plugin’s admin).
The things we want to avoid in the plugin directory are not all bad things in an absolute sense, but may be bad for the repository or for WordPress users. Yes, that does mean that we’re not going to host plugins with certain business models in the repository (like, pay to download, or download and get used for SEO spam). And we’re going to pursue policies that are good for WordPress and WordPress users (like we believe core plugins will be).
That slur — “socialist” — has no meaning in this context. Neither WordPress users nor developers pay any sort of tax or tribute. Everything is a voluntary gathering… a non-coercive community. Everyone chooses their own level of involvement, and with the exception of protecting the WordPress trademark, no coercive action is taken against people who choose to deviate from the community standards.
Very nice points!
I think we are talking about different things here. What we don’t want is plugins abuse, is not having to read and totally understand each plugin we download before activating it, is keeping control over our site.
But developing takes time, and wordpress.org can’t force developers to work for free to have their plugins listed.
I develop plugins and themes, I do it for my sites and share them with the community, since I also get WordPress and a lot of plugins for free. If I’m blocked, I’ll just leave my plugins for me and don’t share them.
Theme gives our site visual, but plugins give it features and functionality!
One thing is a plugin randomly adding spam links in our sites (imagine if it tests if user is logged in and doesn’t do it so that we don’t see those links but our visitors do!). Another thing is it credit its author for the work he had.
Plugins authors should be credited, and we have the right to keep crediting as default.
Why credit by default? Could it be that you know it will result in more credit links staying up, due to ignorance, incompetence, or apathy? It seems much more decent to ask first, and know that each credits link that appears does so because they appreciate your work and would like to share your great plugin with others, not because the user couldn’t find where to turn it off.
I suppose I *should* be happy to run out into the woods with my fellow WordPress developers, build a bond fire and sing kumbaya while we drain the best years of our life to give plugins to the world? In the hopes that some client will come along so I can waste more of my time building his crap so I can eek out a meager existence? No, I’m interested in producing some world changing (fully GPL / Open Source) plugins of my own — and actually spend time working on them rather than trying to shoehorn stuff for a client. Sorry Mark — not drinking the koolaid.
Mark, I actually see all of your points and you’re right for the most part. Even about my comment about Socialism — bad example. Maybe this will describe my gripe about the wordpress community a little better:
I suppose I *should* be happy to run out into the woods with my fellow WordPress developers, build a bond fire and sing kumbaya while we drain the best years of our life to give plugins to the world … in the hopes that some client will come along so I can waste more of my time building his crap so I can eek out a meager existence. (yeah that was a massive run-on sentence I know)
No, I’m interested in producing some world changing plugins of my own — and actually make enough money so that I can spend time working on them full time… The ability to devote one’s self to writing and maintaining code actually does make for better code.
So maybe you can explain the actions of Automattic around plugin developers. They have actually conceded that it’s okay to charge for Themes — they even now provide links to premium themes on wordpress.org — why not the same for plugin developers? They claim that they are business friendly as far as plugin developers go but they make no effort to help these authors.
It is futile to argue against the fact that a very high percentage of plugins in the repository are either abandoned works or buggy pieces of crap. Agreed? Why do you think that is? Because most plugin authors put something out there for fun, or maybe they’ve drunk the koolaid and want to make the world a better place for free. Then, in order to pay the bills they have to keep their day jobs, or work with clients and their free plugins languish. Matt & Automattic have gotten around this by getting investors but for plugin authors that is impossible (its easy to sing kumbaya and run around the camp fire when your next meal has been furnished by an investor).
Anyway — sorry for all the ranting — I’m just really tired of the wp community’s attitude towards this and hopefully you can provide some answers to my questions to help me feel better. 🙂
Speaking of the difference between pro and neutered plugins, etc. The WordPress eCommerce (WPSC, getshopped) plugin makes you pay to get a grid layout of items. But in the default theme that comes with the free version is structure for grid. The system checks if the function for grid exists or not. I was able to bypass that check, now I have grid. The only thing is the thing you pay for gives you some options in the admin (such as how many columns) you could just code yourself into the free versions loop.
How about popular plugins like Global Translator?
They include a backlink on by default, but when you pay for the Pro version (n2h.it/global-translator-pro/), the link will be removed.
Cheers, harry
What about the “powered by” links in the various iPhone theme/plugins (most are actually plugins)? Seems like those have been getting away with this much more than other plugin types.
I guess you could think of that as a dynamic theme, provided by a plugin. With themes, I’d also prefer if credit links could be disabled, but I understand why they’re often not. Themes are sort of meant to be hacked and edited by their general users — plugins less so.
Rules are rules and this is the WordPress playground after all. So you have to play by their rules. I’m 100% fine with that. My only gripe is that the rules are not applied evenly. If no credit link is permitted by default in plugins then themes should have to abide by the same rule. There hasn’t been a single SOLID argument why themes are excused from the rules.
If the plug-in is so great and terrific – and many are – then the dev should have the confidence in their product that the user would choose to list the credit by checking “Yes-Display” in the admin section. Otherwise, it is a forced tax.
Forcing a blog to display an advertisement (credit) is a means of extracting payment from the helpless blog owner. Thus, the plug-in is not actually free because the advertisement/credit is required as the payment (and is sometimes left there even when the plug-in is removed).
The dev who does this seeks to tax the blog owner by forcing the advertisement. Some blogs (not mine) can charge serious money for an advertisement. Uncontrolled credits/advertisements create a revenue leak from the blog.
Should the blog owner invoice the dev for the SEO value of the link and current advertising rates?
If a plug-in developer forces the user to display a credit/advertisement, because the user does not know how to remove it, then that credit is a form of payment and the plug-in is not free.
It could all be handled nicely if the dev had the confidence and integrity to start with a default “no” for display with an easy way to make it “yes” if the blog owner so chose.
Btw: nothing wrong with Socialism if you think sick people, children, elderly, unemployed, should receive healthcare based on their illness and not on their ability to pay. Life has value, even someone else’s.
Semper Pax, Dr. Z
RE: Rule 5
I must disagree on the credits by default rule. I believe if the developer has spent a serious investment of time into building a useful plugin for the user, you should be free to ask for credit in a way that matters. A credit in the metatag doesn’t matter.
The position that you’ll get higher quality links by making it optional is like offering all software for free and having donations be the only source of monetization. We all know how many people donate to plugin authors (not many at all for those who don’t know.)
By restricting reward for plugin developers, you’re doing a disservice to the WordPress community.
Sure there are extremes that will make your position seem logical. Those overly aggressive plugins will likely get replaced by better quality plugins soon enough because people will be looking for replacements. By enforcing rule 5, you’ll be punishing a majority for the actions of a minority.
Well said. Some time ago there was a post saying WordPress has a thankless community. Well, if even its “owners” are thankless and block us even from receiving credit.
Maybe that’s why there are so many abandoned/orphaned plugins and nobody wanna adopt them. If I can’t get anything from sharing my plugin and still forced to do so without asking anything back, it’s better to just develop it to me without a nice finalization so that noobs can use it and have it working for me only.
WordPress must promove and make it easy for people to even live only from plugins development. If WordPress wanna be a professional tool, developing to it can’t be seen as freelance or hobby.
I prefectly understand the risk of ppl getting WordPress for free and having to pay for a bunch of plugins to make it useful. That also must be avoided. But there must be serious development for ir, or we’ll always live on the risk of our plugins dying.
A free version with base features and that fits personal users, and a pro version with provessional quality with features oriented to profitable sites. That must be incentived. And developers that can’t have that yet could at least receive some PageRank and visits from ppl that would click on their banners.
It seems to be splitting hairs to disallow plugins that require registration, but allow plugins that are useless until one registers with some other service. “It’s not the plugin they’re registering, it’s the thing the plugin connects to” doesn’t really fly if the plugin is worthless (“runs” does not mean “has worth”) without the service.
My only plugin is a pointless and silly widget and the world would not suffer if it went away. It links to a page on my site and reading this has made me realize I never got round to making that optional. Definitely not cool on my part, and a abuse of the two people who use the plugin. So I’ll fix that straightaway.
However, the link adds value to the plugin (or perhaps “value” should be “slight reduction in worthlessness”); and in my opinion the consumers of the plugin are better-served to have the link active by default.
The plugin also accesses a Web service, for which there is no charge and no registration required.
Turns out I did make the link optional in the original release. I’m less of a jerk than I thought I was.
We’re building a WordPress site with a credits/links page for all plugins, the original theme and certainly WordPress.
The publishing tradition of colophons — http://en.wikipedia.org/wiki/Colophon_%28publishing%29 — is worth emulating. I want to give full credit to the great international community that WordPress has brought together. We’ll even have a Made in Latvia logo for one of them if that plugin gets updated more regularly.
I think this would be a good practice to encourage instead of littering the site with miscellaneous links, as Mr. Hackadelic is driven to do. I’m sympathetic to his plight, so I suggest:
WordPress could set a standard for optional colophon pages and permit plugin and theme developers to automatically put their credits and links there.
If the optional colophon page isn’t implemented by the site developer, WordPress could make it routine or automatic to have credits visible in the HTML source received by the browser, which can be examined by anyone interested in how an effect was achieved.
I like this idea a lot. It would provide a standardized, organized, and attractive way to present the information and could be a win all around.
Excellent article Mark. I’ve tried to get one of mine removed only to realize that I don’t actually want it removed I want the negative posts by two people removed. (these two people signed up for multiple accounts solely to bash my plugin)
Would you have any advice on how to get those forums moderated a bit closer.
I disagree with #5 – by default enabling option to insert link to plugin author’s site. Leaving such option is not a good idea, because people are lazy. Very lazy. Some even does not bother themselves looking for plugin settings page (and have a good excuse for their own laziness – “we do not know how”). Other will look, but will see that default settings are OK for them (many times this is the case), and will not change anything – including option to show link. That’s not all – people may be not sure at first if plugin will suit their needs, so they will not enable this option. If plugin does not require any other intervention beside initial configuration, they will not have need to go to settings page again.
So what we have as an alternative? Big, ugly message in admin dashboard saying “Do you like plugin X and want to give a credit to its author: Yes, No, Let me decide later”? Or show similar nag every time plugin is upgraded, and provide many tiny updates, just to show it?
I agree with the said, but I think the suggestion is something extreme 😀
Open a “modal window” asking for credit link is much more than needed and would make everybody mad 😀
I understand WordPress authorities are worried with link abuse, with plugin authors abusing site owners laziness and noobish, and adding links without them activily accepting.
But hey, WordPress adds a lot of HTML we wanna change and they don’t wanna fix just because 99,5% of users are satisfied (I’ve read some complains along months), and it’s a standard themes have links. Why webdesigners can link their sites AND their theme’s page and web devs can’t?
Just give them the option. It’s not requiring them to edit the code (which is not hard after all, just search files for the link and remove it) or something like that, it’s a checkbox!
If they don’t want the link, they’ll remove it (and themes also should be forced to give the checkbox, interesting how no theme author gave any option 😛 ). If they want, they’ll have a click less to do (why would I require more effort to who wanna credit me than to who don’t?). And if they don’t bother and having or not is the same for them, well I bother, so 0+1=1, they’ll leave anything’s defaulted.
“Insert SEO spam links into people’s blogs” – *lol* easy AND effective 😉
Andreas
Sometimes a plug advertising the credit can probably cause security issue. Especially in the case of the Login LockDown plugin that locks out the user after so many failed admin attempts. It advertises right on the login screen “powered by Login LockDown”. Great now every knows my security measure, can download the plugin and look for a hole and hack into my blog.
I disagree. Many plugins leave tracks by features they provide, and that could have the same effect.
I myself have a page listing all plugins I have, that page even received a comment threatening me if I didn’t update 1 of my plugins.
Keep in mind that plugins developers spend a lot of their time, much more time than theme designers, to give you their plugin for free. The least you could do is credit them, and not hide you’re using it.
If you don’t wanna link your plugins sites, at least donate to them…
Maybe someone has already pointed this out and I missed it, but it’s pretty significant to me that what Mark is talking about here is the WordPress plugin repository, not the ability to have your plugin work with WordPress.
In other words, if your plugin violates every last possible item listed above, you’re still more than welcome to put it up for download on your site. You will probably have lots of people download it, just not nearly as many as if it were in the official repository.
Now, if Automattic built something into WordPress that prevented plugins from working unless they were from the official repository (ok, I know this isn’t possible–it’s open-source), I could see the validity of the ‘don’t drag me down, man’ argument that a few people have raised. They’re not, though–all Mark is saying is that, in order to maintain the official repo as a place where people can get code that at least doesn’t have obfuscated spam in it (even though it may not actually work), putting nastiness in plugins will get them removed.
@Vasken — The only problem I have with that distinction is that WordPress *does* punish non-repository plugins in the way it treats updates. The way the plugins page is set up, there is a tacit assumption in the interface that if there’s no update notice, there is no update available — which is false for non-repository plugins.
So: The WP plugins admin interface needs some sort of indication of which plugins are *not* checked for updates, so that the blog owner knows to go check manually or whatever. Otherwise, these plugins *are* being subtly punished by the way WP is designed.
(And yes, I have put patches into Trac to fix this, and they have languished for years. The powers what is simply don’t care about this issue.)
Interesting article. I don’t know alot about WP and plug-ins so I know I’m not doing anything wrong yet. Nice to know the rules up front.
What is the particular aversion to the pay to download model?
Is the thinking that someone will pay for substandard code with no recourse to return it?
It seems that the way around this is to do what apple did and create a review team that is funded by some percentage of the sales revenue on plugin’s
Under that scenario wordpress could protect the quality of the wordpress experience but also provide developers with a way to get paid for their work.
Personally I have no interest in “Credit” I can’t feed my kids with that. The idea that programming is not a “service” seems a be offensive to me. While it may become a product when you sell more than one copy, you can’t provide any ongoing service or updates without some form of pay.
I would like to see a marketplace where I can set the terms and the value of the code can be determined by the buyer and reviews.
It doesn’t seem to me that this would violate the spirit of wordpress as the product would contain code that was every bit as customizable as free code. It would just require that they user actually pay for the hard work of others to receive it.
The best way to do this would be to have a in dashboard store where the end user can purchase content, themes, plugins.
Would they end up buying some things they didn’t need? Sure, but I say so what, its up to the end user to determine what they should invest in, and its not always going to work. If they want a guarantee of results they can hire a developer to manage their project and help them with their site.
In the end I would rather pay for well tested code that someone is making money for, than endlessly downloading hacks (plugin’s from the repository) that waste far more of my time and money than paying for a plugin would.
Really the whole free concept is a recipe for lower quality not higher.
I totally agree.
Since Plugins Repository was created, and even more when it was integrated to WordPress, publishing plugins outside of it gives no visibility at all.
You can develop a high quality, professional plugin, build a site for it, and charge to make it available, but pratically nobody would know it exists.
In the new Battle.net for StarCraft II, Blizzard is saying map developers will be able to upload their maps to the system and users download them directly from Battle.net, instead of having to download from external sites or depending on a user to upload to you, and there will also be a way to charge for submitted maps, with users paying for them directly from Battle.net, and only then having access to them. Maybe Battle.net will also block a user that didn’t pay for a premium map from pirating it and entering games that use it.
Blizzard says they are sure that doing so, we’ll have top quality maps, they wanna incentive and help map developers to increase even more their quality.
It’s nice to be GPL, have plugins available for free, protect the CMS from depending of paid plugins. But still, the CMS depends on plugins to be “more than a blogging platform”. Plugin developers should be seen as friends who help, not enemies that can put the CMS in risk. Helping us is a win-win.
http://wpmu.org/wp-plugins-is-the-wordpress-app-store/
Nice. Thar she blows. I’ll have to review the whole deal.
It would be really nice to have this in both a marketplace version and a self hosted version so you can run your own marketplace if you are really proud of your own stuff or don’t like the idea of having to get someone else’s approval (or compete with other devs). This becomes especially important if you fancy yourself as the head of quality control for your clients. You would really want to approve everything they have access to and they are your clients! So getting a cut of plugins you recommend would only be fair. Sales is a job too!
Hey, Nice post
Thanks a lot for the tips. I applied the methods you explained and hope for good results.
Mark — What about a plugin that inserts an ad into the WP Admin interface (NOT the front end)? A user can see the ads or pay a small fee (2 to 5 bucks?) for a code that will remove the ads.
That seems like a legit revenue model to me. You’re not doing SEO type stuff to the person’s front-end blog. People can download your plugin and test it out without paying for it. Indeed they can use the plugin entirely for free if they don’t mind the ads, and if they don’t want the ads they can toss you a couple bucks and be done with it.
If I had a dollar or two from everyone who’s downloaded my plugins, why I’d be a thousandaire!
Oh, by the way… As pointed out recently on wp-hackers, WordPress **core code** itself has obfuscated code in it, which violates rule #3 above. Should WordPress core be removed from itself? ;-p
(I’m referring of course to the revision self-compare easter egg code.)
Great theme, do you have any more with the ajax slider function? I found some on Free Premium WordPress Themes|free premium wordpress themes|free wp themes|free premium wp themes|premium wp themes|premium wordpress themes|free wp|free wp themes|wp themes but they are not what I wanted….
great post !!! thank you for sharing… 🙂
you are good write about spam and how to write the html format for web linking & external links. you are provide in this blog so this is helpful public blog.
I just went to a plugin in repository and noted that both plugin and author’s link are gone.
All that’s left is the donation link, which nobody enters after all.
So, now wordpress.org doesn’t even credit plugin authors. It’s all blocked inside the site and nowhere we can see author’s website, even author’s name is now hidden on bottom of the plugin’s main page.
So, everybody demands to own our work, from Automattic to users that don’t even come to thank for our free job. Only authors don’t have the right to demand ownership of their work…
[…] past, much discussion and argument have taken place around these restrictions, which led Mark Jaquith to clarify and expound upon them…
I’ve tried a couple of those on your list and they havent been picked up yet!
The plugin repository has become something of a hobby for me. I am fascinated by the variety of ideas authors deposit there. I noticed that a plugin on the “new” listing might be gone a day or two later without explanation. Suppose it was taken down for malicious code: Had I downloaded it, how would I know that it was taken-down and why it was?
At last! Someone who udnertsadns! Thanks for posting!
5q5De3 bsjzutdjaozh
I can’t add anything to other sites that you’d not like in yours web.
Thanks to all of you for all that helpful comments…
How about Yoast SEO putting a their link the the header of the XML sitemaps? I wasn’t happy when I saw that. And without a way to turn it off, never mind turned off by default. I had to edit the files myself to remove it.
WordPress is free, the repository is free. You can either choose to use it or not. If you want to make the rules then make your own repository (ie:http://wpplugins.com/) . What’s wrong with writing code that is so awesome that everybody wants it and everybody wants to pay you money to write code for them. Just be the best and the rest of this stuff is irrelevant… My plugins will not do any of the things that Mark listed not to do above and I will use the repository for distribution. Thank you WordPress for all the GPL code…