Great to hear that Jeffrey!
Looking forward to seeing that in action. If there’s need for beta-testers or even developers, feel free to contact us, we’ll be more than glad to help.
– other plugin loading custom script into our plugin admin pagethat indeed is a problem, but it is one that can be easily avoided, without any compromise, from the plugin author’s side. You just need the proper hooks, that’s all.
But there can be legitimate reasons to deregister the default jQuery. For some plugins with heavy JS use, new jQuery features and speed improvements can really make a difference. And I’m not even talking about jQuery bugs, this was especially apparent in WP 3 .1 and before. WP included jQuery 1.4 when 1.5 and 1.6 has been already out, so why you shouldn’t be able to update to the newer jQuery when it provides better functionality and fixes to some important bugs? And the old jQuery is the only thing preventing your plugin from running on WP 3 .1 and lower?
All I’m saying is that if you write your code defensively and make sure it is compatible with the latest version, which it should be anyway, there can be no conflicts if a plugin registers the newer jQuery. And from my experience as plugin and theme author I can only confirm this.
I can understand your frustration, but not everything is black&white. That’s all I’m trying to say. I’ll even go so far as to say that for 95% of the plugins you are completely right and they should not deregister the default jQuery. But there is that 5% that should have the ability to do so if it is done responsibly.
OK, first of all, we’ve decided to do this based on our experience. This is ultimately less work for the customer, because, if any, he has to do some work when setting up his website and not after each update, secondly an updated version of a plugin distributed via CC takes time (could be weeks) before the customer is installs it. And lastly, we’ve had very little to no reports related to jQuery version conflicts. We’ve had conflicts with other libraries like Prototype, or conflicts related to themes that include jQuery directly in header.php rather than by the WP queue mechanism.
I agree that deregistering jQuery is a dirty solution, and I’m glad a debate has been started on this issue. I’m just trying to add a practical viewpoint from our experience.
we’ve been asked recently by several people why is it that our WordPress plugins do not appear in the updates. We told them that it is because they are not distributed through the WP plugin directory which handles this automatically. I would like to solve this problem though.
Problem: How to enable autoupdate for your WP plugin or theme in a way that would be both easy to use for the customer and yet would prevent unauthorized copying.
I know there are brilliant minds in this community, that could help out.
My idea is that we could create either a separate WP plugin that would take care of every item installed from the marketplaces with a simple hook or interface that would enable plugin and theme authors to join, or a framework that people could embed into their themes or plugins.
I would like to this to be open source, so we could all benefit, something like OptionTree, so I’m thinking a repo on GitHub? I’m also willing to invest my own time and energy into this for the community.
The only thing that seems to be problematic so far is the mechanism for authentification, I think we might need some help with that from Envato. Some of this can be achieved via the API right now, but I don’t think that would be the ultimate solution. Until we get proper support from Envato we can develop an earlier version of this, that would only notify the user that the update is available.
Please let me know what do you think, or if you are interested in helping me out. I would also like to hear from Envato staff if this is something that they would be willing/able to help us with.
I personally agree that deregistering jquery is bad. With that said, however, it is very difficult to rely on the default jQuery. Especially in branch 1.5 of jQuery we used in uBillboard v2, they broke our JS with every update, so we had to release a new version for 1.5.1, 1.5.2, etc. because something always broke. Therefore we decided to force a specific version.
You are going to have conflicts no matter what.
If WP uses a new version of jQuery in an update, and you rely on WP’s jQuery, you’re going to have to update your plugin, and possibly have to include all kinds of ugly hacks to make sure your JS works with multiple versions of jQuery. And you have to test every version every time you change anything in your code.
If you register your own jQuery, you will avoid that, but will induce compatibility issues with other plugins.
It is choosing the lesser evil…
First, Jeffrey, you should set up something at Google Moderator (http://www.google.com/moderator/), so we can all vote/add/discuss ideas and it will be much cleaner than here in the forums
My personal favorite would be the ability to download the full statement, instead of just last 100 records and even that within a 28 day frame at maximum. I could use that in SalesDonkey to generate better graphs/statistics for every item etc.
Right now we have a system like this, but I wrote importers and imported the original data from the downloadable csvs with the statements for previous months into a DB and now it just updates itself with the latest data via the API . We have stuff like weekly sales global, a pie chart that shows the composition of earnings by item for the last seven days and per-item weekly sales. This information is great to have, but with the current system it would be very difficult to set up such a database for new users, that is why we haven’t shared it.
which SalesDonkey are you referring to? iPhone or Desktop version?