- May 28, 2007
Paying & installing twice to get quality code is a bit weird. It would make more sense to me to just offer one addon with quality code that can be run without performance issues.
I'd say pretty damn decent performance. TAZ uses it. And TAZ is known for making use of the best-made add-onsI've got a paid add-on with that feature (post areas) for XF1, and it is a heck of a lot larger than that. It'll have that feature in XF2
And it has decent performance!
Four people agree with your capitalist dribble.I would think that at first, with competition relatively narrow, prices will be higher. As competition grows, this will drive prices down. Often we pay a premium to be on the leading edge.
It took me years to find out where the paid addons for vbulletin were and it was very hard for developers to monetize on vb. It was nice to have so many free addons, but I dont mind paying for quality. Unfortunately the current situation means that we are often paying for poor quality. In this sense the concept of paid addon marketplace does not necessarily lead to better addons.Well, you have to admit vBulletin only allowing free plugins on vBulletin.org and WordPress only allowing free and open source plugins in their plugin directory likely helped their community a lot.
I’m not sure I fully agree with this. It sounds good on paper, but that system is also part of the reason why WP makes security conscious people cry and/or turn to alcoholism.What XF really needs is access to the plugin directory from within the XF ACP.
That way users can search, read about, install, upgrade and manage any and all free plugins from an XF repo, as with Wordpress.
How is that different from an admin downloading any old code from a free resource on XF.com and uploading it themselves? Genuinely curious.For instance, if you open the code XF files to be writable by your web server, a malicious script now has the ability to modify and subtly change your entire installation, and if it also overwrites the hash file, file health check becomes worthless.
It definitely wouldn't be a simple or easy system to get right, but I feel it's something that will have to be implemented at some point and it's only a matter of time of who can execute it right and do it first. It has lots of potential pitfalls that need to be addressed, but the benefits to admins and add on developers are immense.In short, I don’t disagree with you but there are some significant concerns.
Oh, I didn't mean code from XF.com, sorry I should have clarified! I was typing on mobile.How is that different from an admin downloading any old code from a free resource on XF.com and uploading it themselves? Genuinely curious.
99.9% of people aren't going to bother checking the files before just uploading the entire directory to their site and it could easily have rogue code in it. Is that any different from pulling code from a public XF plugins repo through the ACP?
Agreed. I do feel like this sort of updating / installation would need to be in some way powered by the actual server itself, rather than being done in raw PHP, in order to mitigate some of the security risks.It definitely wouldn't be a simple or easy system to get right, but I feel it's something that will have to be implemented at some point and it's only a matter of time of who can execute it right and do it first. It has lots of potential pitfalls that need to be addressed, but the benefits to admins and add on developers are immense.