Sam Bauers (@sambauers)

Forum Replies Created

Viewing 25 replies - 851 through 875 (of 1,069 total)
  • In reply to: Caching in bbPress?

    @sambauers

    Participant

    @HowToGeek

    Would you mind sharing the work you did to optimise the plugins, I’d be interested if any of them are ones I take care of?

    @sambauers

    Participant

    There are lots of built-in functions for querying the topic meta, they are all in the same place in the code, so searching in the code for the functions I mentioned above will reveal them all.

    Joining tables to create one query is better than using two queries to retrieve the same data. The new BB_Query class could easily handle the query you wrote up there.

    By the way, I suggest you build your plugin against the latest trunk rather than the latest release.

    @sambauers

    Participant

    It might be a bit confusing, because it is a complex plugin, but the Support Forum plugin uses the topic meta table to store topic support status. This data used to be in a column in the topic table but was moved to the meta table a few versions ago.

    The basic usage is (with some guessing as to what you would call your data):

    // To add
    bb_update_topicmeta($topic_id, 'topic_geolocation', $latlong);

    // To delete
    bb_delete_topicmeta($topic_id, 'topic_geolocation');

    The topic metadata is automatically included in the results when you call get_topic().

    No table manipulation should be necessary.

    @sambauers

    Participant

    I usually fix the bugs I find and then the trunk catches up with me a day or two later after I submit a patch…. ; )

    @sambauers

    Participant

    > Any idea what I could be doing wrong here?

    Are you using the latest trunk or the standard 0.8.2.1 release?

    Latest trunk won’t work with the above code.

    @sambauers

    Participant

    mdawaffe has committed to try and bring the point releases closer together. I believe there are no hard targets set, but it should be better than last time. I would estimate that 0.8.3 will be out within a month, but that is just an estimate. mdawaffe gets pulled from bbPress all the time to do other things.

    I can’t talk with authority about the XML-RPC features being added, but they will potentially open up a whole heap of options for people wanting to connect their forums with other forums and blogs. You should enquire about the development priorities and directions on the bbPress dev list though, you may get more joy there.

    @sambauers

    Participant

    Apache processes rewrite directives in the order they are found.

    First the main Apache config file is used, then (if they are allowed) the .htaccess files are used in the order they are encountered from the root of the website out through the directories until the final directory that contains the file that is being accessed.

    So if you have a page at http://www.example.com/blog/forum, then the order of processing is like:

    Apache config
    |
    +-> /path/to/site/www.example.com/.htaccess
    |
    +-> /path/to/site/www.example.com/blog/.htaccess
    |
    +-> /path/to/site/www.example.com/blog/forum/.htaccess

    So the “blog” rewrite rules will be assessed first. This means that you may want to place your bbPress rewrite rules in the same .htaccess file as your blog rules, before the blog rules, as they are more specific and should be handled first.

    Also, there were some problems with WordPress throwing 404 errors based on what mod_rewrite was doing. This was specifically with version 2.1 I think, so your WordPress may need to be upgraded.

    @sambauers

    Participant

    Yes, I know all that, but I was talking about Subversion clients, which I don’t know as much about.

    I also don’t know if LiteSpeed can do subversion, LiteSpeed doesn’t do DAV at last check.

    Subversion repositories tend to be set up more cautiously, so performance doesn’t really get a look in.

    @sambauers

    Participant

    > is there a method way to delete a view

    In current trunk…

    bb_deregister_view( $view )

    @sambauers

    Participant

    You should be aware that views are registered differently in the latest versions in trunk. Views are now constructed using the BB_Query class.

    See the latest Support Forum plugin for a way to use both the new and old, although it is wrapped in a Class in there so the basic idea is:

    if (is_callable('bb_register_view')) { // Build 876+
    $query = <SOME ARRAY ACCEPTABLE TO BB_QUERY>;
    bb_register_view('myview', __('My view name'), $query);
    } else { // Build 214-875
    add_filter('bb_views', 'my_addView');
    add_action('bb_custom_view', 'my_processView');
    }

    @sambauers

    Participant

    That’s right as long as you don’t have any users in those tables that you need to transfer to the other wp_* tables.

    @sambauers

    Participant

    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).

    @sambauers

    Participant

    This is fixed in the latest trunk. I believe, the WordPress tag closing function has been moved across to bbPress.

    @sambauers

    Participant

    You’ll need to order that query by using ORDER BY post_time DESC. There is no guarantee that the last row of a table is the last row that was added.

    @sambauers

    Participant

    Oh OK, good news. Well done.

    @sambauers

    Participant

    > 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.

    @sambauers

    Participant

    I believe the only way to do this is to create one big file containing all the translation strings.

    In reply to: forum.wp-persian.com

    @sambauers

    Participant

    > so i have my bbpress full translating where can i upload it?

    You should post it on your own site and add a comment with the location in the blog here.

    I’ve also added a link to your translation file at http://www.bbpulp.org

    @sambauers

    Participant

    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.

    @sambauers

    Participant

    @_ck_

    Do you have version 0.1.9?

    That error was in 0.1.8 and fixed in 0.1.9

    @sambauers

    Participant

    Just a quick heads-up, 0.1.7 and 0.1.8 have bugs which are addressed in 0.1.9

    In reply to: forum.wp-persian.com

    @sambauers

    Participant

    I noticed the “support forum” plugin was outputting english strings in your forum. I have just updated the plugin to use gettext on all the strings that weren’t using it. So if you want full translation it is now available (you will need to modify your language files to add the strings).

    @sambauers

    Participant

    > 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.

    In reply to: Plugin: Avatar Upload

    @sambauers

    Participant

    New Plugin Browser now in SVN.

    Fixes the subdirectory problem for non-CURL PHP installs that affects this plugin.

    In reply to: Plugin: Avatar Upload

    @sambauers

    Participant

    > Using the latest version of your plugin, I tried installing the new version of Avatar Uplaod, but it still wouldn’t read the additional-files directory.

    If you don’t have the CURL library functions installed it falls back to fopen. fopen was failing to retrieve sub-directories.

    I’m fixing it now.

Viewing 25 replies - 851 through 875 (of 1,069 total)