Finally, no more secrets. They are too hard to keep!
Trent
And here I imagined the secret to be some way to transport chocolate through the internet! This is good too . . . just not as good. 
Interesting – checking it out in a moment.
It will be helpful to more tightly knit the bbpress community.
I was thinking of making a voluntary plugin that would ping a bbpress stats site either nightly or weekly with your number of members, total topics, total posts. It would make a showcase for bbpress possibilities.
Right now it’s hard to get a count of the number of installed bbpress users. I’ve tinkered with various search engine commands and come up with an active number of 200-300 but this could be wrong do to path or file renaming (or template editing).
Okay the plugin list is blank for me. It did seem to pull down the plugin list. But I don’t see any new plugins offered?
Oh duh, I just re-read that it won’t show any plugins it hasn’t installed itself.
Can’t that just be copied from the bbpress table?
But wait, shouldn’t it show new available plugins not installed yet?
@M
Mmmmmm…… Choc.O.I.P.
@ck
I don’t think there’s much point in trying to align this tool with manually installed plugins. It’s easy enough to remove the manually installed plugins and then re-install using the browser (provided they are in the repository and not hosted elsewhere of course). The re-installed plugin even picks up the old plugin’s settings. I’m managing all my plugins this way now.
Hmmm, great idea, but it doesn’t cope with complex plugins very well yet.
For example, Avatar Upload and Private Messaging (which doesn’t even show up in the browser for some reason), where files need to be placed in different locations to the my-plugins folder.
Still, useful to know when new versions of plugins come out.
@louisedade
That’s always going to be a problem. I haven’t looked closely at all plugins, but I do find that a lot of those that require extra fiddling in templates and what-not don’t actually need to work that way. They often just aren’t taking advantage of the various API hooks a lot of the time. Perhaps one like your avatar plugin that has to create folders etc. could do so using a post-install script, maybe even one that is triggered from the plugin’s admin page?
Private messaging doesn’t show up because there is nothing in the trunk. There are only tags. If the author just copies the latest tagged version to the trunk then it will show up too.
i dont see any plugins in the list either.. i dont have any other plugin except this one..
am i doing something wrong! 
@so1o
Did you update the list? That’s the first step.
Be patient though, it can take a while.
I’ve updated the plugin to version 0.1.5 which adds support for plugins with sub-directories.
Great stuff. I think this is something it would be cool if WordPress should attempt- though it’d require one heck of an organizational system.
There is a project with much broader scope to implement a full-blown plugin updater on WordPress which is part of the Google Summer of Code.
Would it be possible for you to properly use fsockopen or curl instead of “file()” for remote files? Like many hosts, I disable file() for remote urls for security vulnerability reasons which cripples your plugin. You’re likely to get many complaints that “nothing happens”
Warning: file() [function.file]: URL file-access is disabled in the server configuration in /home/example/public_html/forums/bb-admin/admin-functions.php on line 798
.
update: actually this is not directly your fault, though you are trying to use a bb-admin function that was meant for local file access to do remote file access?
If I am not mistaken, you just found a bbpress security loophole.
ps. any concerns about eventually 2,000-20,000 bbpress users hammering the svn with so many file downloads to examine all the plugin headers?
> update: actually this is not directly your fault, though you are trying to use a bb-admin function that was meant for local file access to do remote file access?
If you check the short “to do” list at the top of the plugin you’ll see that I plan to address that issue in the future. I might just copy and paste the code from that internal function and then hack in my own curl/fopen alternative function.
> If I am not mistaken, you just found a bbpress security loophole.
Explain your concerns, how do you think this would be exploited? If it can be we should patch it up.
> ps. any concerns about eventually 2,000-20,000 bbpress users hammering the svn with so many file downloads to examine all the plugin headers?
36 downloads so far, let’s start worrying at 1,000
> you are trying to use a bb-admin function that was meant for local file access to do remote file access?
I’ve replaced this call in the new version (0.1.7) with a custom function that doesn’t use the file() call. So it will now use CURL where possible.
New version also only retrieves headers where possible to speed up transfers.
Also fixed sub-directory support for PHP installs that don’t use CURL.
Just a quick heads-up, 0.1.7 and 0.1.8 have bugs which are addressed in 0.1.9
Oh sweet. Heading off to try it.
Thanks for making it use curl.
*pout* still no list…
“The plugin list was updated from revision 0 to revision 519.”
but I don’t see any plugins listed
Warning: preg_match() expects parameter 2 to be string, array given in /home/example/public_html/forums/my-plugins/plugin-browser.php on line 309
@_ck_
Do you have version 0.1.9?
That error was in 0.1.8 and fixed in 0.1.9
Gah! In 0.1.9 I changed all the version numbers but didn’t actually change the code!
0.1.10 is now committed, and *it* will fix your problem.
Okee, will try and report back in a minute.
Thanks as always!
*** cries tears of joy ****
it works, yay!
(note I had to manually delete the two options already inserted into bbpress to get it to load the entire plugin list)
Wow, very nice work…
idea: “power user toggle” that will turn the revision number into a hotlink to the svn directory so I can directly preview the source and maybe show the filesize since curl/fopen has to pull the entire file down anyway so it knows the size
a tally at the bottom of how many plugins shown would be interesting to see too… will it paginate if one day there are over a hundred plugins?
> it works, yay!
Great!
> idea: “power user toggle” that will turn the revision number into a hotlink to the svn directory
Good idea, I’ll ad it to my “to do” list.
> maybe show the filesize since curl/fopen has to pull the entire file down anyway so it knows the size
It only completely pulls down the .php files from the trunk of each plugin to interrogate then and create the list, so I could only accurately report on the size of those. Otherwise I would have to traverse through all the subdirectories and add up the totals. Which would be a bit onerous.
> a tally at the bottom of how many plugins shown would be interesting to see too
A bit superfluous, but I’ll add it.
> will it paginate if one day there are over a hundred plugins?
That wouldn’t be too hard. But there aren’t that many plugins right now.
For a lark I pointed the plugin to the WordPress Plugin SVN. It got about 1/4 of the way through retrieving the list of plugins and died (script timeout). Ultimately if this plugin is going to remain in use I’ll have to either compile the plugin list on a server somewhere and serve it as a single file to all plugins, or build a “specs” file format for plugins to use if they want to be in the browser. But that is what the WordPress plugin I mentioned earlier is attempting to do, so I’m more likely to assist in porting that plugin over to bbPress than extending this one to do it.
>For a lark I pointed the plugin to the WordPress Plugin SVN. It got about 1/4 of the way through retrieving the list of plugins and died (script timeout).
With many people accessing it, yeah it will necessary to pre-compile a default list of a full revision weekly.
Or to be sneaky for now you can set a flag in options after each curl fetch and restart bbpress if you calculate approaching 30 seconds.
Both ways sound like headaches.
I wonder if the trac cache is faster/more efficent?
ie.
https://plugins-svn.bbpress.org/plugin-browser-for-bbpress/trunk/plugin-browser.php
vs.
https://plugins-dev.bbpress.org/browser/plugin-browser-for-bbpress/trunk/plugin-browser.php?format=raw
I wonder if trac can be tricked to pre-gzip it all to download beforehand as a bundled revision? It’s got to compress wonderfully as it’s entirely plain text and repeating php functions.
ps. be sure to take advantage of gzip support in curl / fsockopen – I have some code I wrote somewhere to do this if you need ideas
My other option is to make the update check more atomic. Here, your pagination idea could help. So instead of fetching all the plugins, I could just fetch the first page, then the second etc. etc. on request. More complicated to code, but it might be the best long term solution to keep the best of both worlds. I could also add a way to list installed plugins first, or even have a separate view of installed plugins.
I wouldn’t think Trac is faster, it has a few more overheads on the server side I think. I don’t think it will come down to that though.
Neither the Trac site nor the SVN repository use compression on their output, so gzip is useless, but that was a good suggestion. I’m not sure the SVN repository could use gzip anyway as it would potentially get in the way of some SVN clients, I’m not sure SVN even supports compression techniques like that (although it probably should).
Web compression is on an “offered/accepted” handshake of sorts.
It would not affect clients that do not support gzip.
Everytime IE or Firefox (etc.) requests a webpage, it tells the server “I support gzip” in the headers and then if the server supports it, it sends it that way.
Technically compression can be forced through the server – if trac is under the same litespeed server as wordpress/bbpress then it’s just a matter of making sure it’s enabled.
A quick test shows both the svn+trac are using apache, so depending on which version it’s either a matter of building with mod_gzip (for apache 1.3.x) or if apache 2.0 they need to just add a couple of easy httpd.conf directives.
Really though, Matt knows how good litespeed is over apache, both the trac+svn should on litespeed. I bet it could even work with the free 150 connection version instead of buying a license.
