{9} All ticket comments (for feed) (20 matches)

Ticket Author
Description
#998 sambauers

Works for me. Are you fiddling with the cookie settings at all in your bb-config.php?

#997 sambauers

(In [1817]) bb_number_format_i18n() not number_format_i18n(), Fixes #997 - props lstelie

#995 _ck_

Does WordPress really work that way? If so, that's insane because it's a tremendous performance hit to not have a mysql key on the meta_key and just serialize the data inside if it's an array.

To update a specific value in such a pseudo array using multiple rows, a plugin author would have to specify the old value and the new value, otherwise all values for the meta_key would be replaced (and duplicated). Is that functionality even in wordpress's update meta? I am not familiar with the newest versions but old versions didn't have it.

#994 _ck_

Nice, but a tiny shortcut instead of using if ( !isset( $bb->safemode ) || $bb->safemode !== true ) { probably could have used if ( empty( $bb->safemode )) { unless you really, really want to make sure they are using true and not "true" or 1

#994 sambauers

(In [1812]) Try out a "safe mode" option - set $bb->safemode = true; in bb-config.php to temporarily deactivate all plugins and the current theme. Removing the setting will put them all back again. Props _ck_ for the idea. Fixes #994

#996 sambauers

(In [1811]) Typo in bb_get_postmeta(), fixes #996, props transom.

#972 sambauers

Thanks for the footwork svennid. It is very helpful.

#995 sambauers

INSERT ... ON DUPLICATE KEY may be an option if we decide not to do anything with the idea in #629, basically doing this closes that door pretty much completely. I'm happy to have a conversation about the merits of that other ticket as well.

The second part (from the previous comment) about reloading the topic is quite necessary I think. Firstly, updates don't happen all that often and secondly, the only sure fire way to make sure your cache matches your database after an update is to read from the database again. Considering that topics and their meta are stored as one object in the object cache, the rereading is required unless we create some way to selectively update parts of the cached objects. But since the object cache is fairly generic and... well... dumb, it doesn't have anything like that. In the end rereading is a lot easier from a maintenance of code perspective.

#950 sambauers

Although, we don't have to do it the WordPress way, and this might solve some other problems we are having too. One way forward with the WordPress implementation may be to still store the data the old way as well.

#995 _ck_

Oh and to make matters worse, updating meta (at least topic meta) causes not only the above two queries to execute, but in addition it causes the topic and then the topic meta to re-load, for reasons I cannot fathom.

So a single topic_updatemeta causes no less than FOUR queries. 1. SELECT (to find any existing meta rows to either INSERT or UPDATE) 2. INSERT (or UPDATE, the meta) 3. SELECT (re-load the topic) 4. SELECT (re-load the topic meta)

That's insane. There should be a table key, an INSERT ON DUPLICATE KEY and the redundant topic re-load should be avoided. I believe it's to re-load the object cache, which should be modified in memory directly by the data it was passed instead.

#988 sambauers

Generally I would be creating small functions in a functions.php theme file to deal with globalising and then displaying various new data.

I'm loath to add this particular filter because it provides a very big hammer to plugins and templates to be able to stomp over each others variables. Adding simple functions or just using "global" discreetly in templates seems to be safer than this idea.

#989 sambauers

Granular control of the get_thread() SQL query is available through the following filters:

  • get_thread_where
  • get_thread_group_by
  • get_thread_having
  • get_thread_order_by
  • get_thread_limit

Using these you can affect the relative parts of the underlying query and I believe that also flows onto other things like adjusting the pagination accordingly.

#990 sambauers

(In [1810]) Return instead of echo get_post_author_link(). Fixes #990, props simonwheatley

#985 sambauers

(In [1809]) Fix comment typos. Fixes #985 and #986

#986 sambauers

(In [1809]) Fix comment typos. Fixes #985 and #986

#983 _ck_

You've somehow changed the pagination .nav CSS structure to where the spacing between page numbers is now broken in every 0.9 theme under 1.0

This means that every single bbPress install in existence that doesn't use the absolute default kakumei theme will have to edit their CSS after upgrade to 1.0 - can that be avoided ?

To see my point, try a 0.9 theme under 1.0 and look at the page number spacing.

also the kakumei view.php template needs

<?php topic_page_links(); ?> added on the end of line 26 for consistency.

I noticed you also leave it out on stickies on the front-page.

#972 svennid

I tried to figure this on my own, but I didn't get very far. Though, I thought I should share my experiences.

In the first place, the login did not stay open so that I would be able to enter the admin menus of bbPress after loggin in to WP.

Doing these steps made it possible to keep the login from WordPress open when entering bbPress:

1. bb-settings.php : Change the $bb->authcookie from "wordpress_" to "wordpress_logged_in_" 2. pluggable.php : rename "wp_validate_auth_cookie" to "bb_wp_validate_auth_cookie" (rename all occurences in bbPress) 3. class.wp-auth.php: remove the hmac hash check

Now I was able to log in to WP and stay logged in when entering bbPress. And even use /bb-admin/.

Next, I fixed the problem with role names in the forum in bb-includes/template-functions.php:

1. change "@$caps = array_keys($user->capabilities);" to "@$caps = array_keys($user->bb_capabilities);"

This was the closest I got to making the integration work. The next step would be to be able to enter /bb-admin/ without getting returned to the home page.

I made it by uncommenting some redirect-functions, but I did however not have the caps to edit any info, more than a moderator. I figured it had to be the caps which are wrong.

So I checked the $bb_current_user variable, and it proved me correct. The ->allcaps does not show the caps from bb_press, but only from wordpress. It is also missing the role as keymaster, even though keymaster is one of the ->bb_capabilities.

You would probably have figured this on your own when you were trying to fix this bug, but I hope I might have provided som info to help you troubleshoot it :)

#690 _ck_

Bumping this because we really should remove unthemed branding from the crash page if only to prevent a bad rep for bbPress like mdawaffe said.

Three possibilities: 1. move function bb_die to pluggable.php 2. change the header/footer functions to bb_get_header/bb_getfooter 3. call the header and footer via a do_action hook that can be unhooked and replaced by plugins

#964 sambauers

(In [1806]) Return the created object on certain XMLRPC methods that used to just return ID. See #964

#984 sambauers

Fixed in [BP167]

Note: See TracReports for help on using and creating reports.