Version 1.7 Beta
@hnla, the only way I can reproduce it is by deleting bp_cubepoint_per_page from the DB Prefix _options table.
Can you do a search in your DB to see if this value exists?
If you want to give me temporary access to your server, I can debug the issue there if it helps.
What is this table? I have a feeling this is the crux of the issue and something that seems a minor flaw with WP/BP that sometimes tables aren’t created quite correctly or at all.
The fact that you can only replicate the issue by deleting a value seems to virtually confirm this. I tend to follow a set procedure for updating plugins to try and avoid this issue one being that I never use the dashboard upgrade, in this instance on the two seperate dev networks I did upgrade after disabling the plugin rather than usual delete and fresh upload.
At present I have only tested 1.7 on the two dev networks and haven’t uploaded to my live test server, I’m afraid the dev networks are secure environments and I’m not really willing to open them up, I will however try uploading to my live test server in the morning (although thinking about it I’m betting this test will be Null and void as it will be a virgin install of CPBP and I bet it works first time ) I will try and test that as soon as possible if it doesn’t work I’ll set up access to the server for you tomorrow.
It should be in the WordPress options table, option_name = bp_cubepoint_per_page & option_value = 20
Yep got that row and value as you state.
Have to get out of the office now but will try a virgin install later and let you know the outcome.
Did a very hasty upload of CPBP 1.7 to test server running WPMU/BP 2.23 but sadly same issue, despite clearly having points and CPBP displaying them in profile, your two pages for points and site wide points say no points earned.
Can’t look further now but will delve again in the morning. Irritating as was convinced that due to the fact that the issue was not reproducible it had to rest with the table/s and that a clean activation would work.
yeah I have logs on but I still get that error.
Warning: Division by zero in /home4/techtro2/public_html/wp-content/plugins/cubepoints-buddypress-integration/includes/bp-cubepoint-templatetags.php on line 56
Warning: Division by zero in /home4/techtro2/public_html/wp-content/plugins/cubepoints-buddypress-integration/includes/bp-cubepoint-templatetags.php on line 65
there the file that is doing it I pasted the frist 70 lines
Where you set up your globals you are adding the base_prefix from base-prefix this returns ‘wp_’
$bp->cubepoint->table_name = $wpdb->base_prefix . 'cubepoints';
cubepoints tables live in main blog which would be fine but WPMU prefixes that with ‘wp_1_’
To correct I have changed to:
$bp->cubepoint->table_name = $wpdb->prefix . 'cubepoints';
The correction I used in the original cubepoints.php does not hold true and at this moment not sure why, however I’m checking to see if ->prefix actually works regardless whether WP or WPMU – think it might? either way what there has to be, logically, is a definitive method of checking what install is in operation and flip flopping the DB prefixes to correct one required, thought that was what I had achieved crudely on the cubepoints fix.
The division by zero warning is still popping up, I guess you will need to decide whether you simply want to suppress that or rethink the maths?
@josh101 yep it is that file that the problem is encountered by the script, it is however a warning and the guys will no doubt decide on a preferred method of handling that. The other issue/problem was simply that the two screens ‘points’ and ‘site wide’ were not correctly getting their data, this issue I’ve identified and a definitive? fix will be arrived at shortly.
@hnla, does your $wpdb->prefix fix the rank images or the pagination errors?
@thekmen It fixes neither as neither were an issue? Rank images was cleared up through a fix in cubepoints.php and the other issue in the parent file where WPMU was concerned was due to using $wpdb->prefix to query the user and usermeta tables which broke as ->prefix returns the main blog prefix in the case of wpmu that is ‘wp_1_’ so I had to run a check on what ‘prefix’ was returning and replace it for the user/usermeta queries.
The issue presently – ignoring the division by zero, as a non issue – is that of no values returned for the two screens “there are no points yet” (sic) despite the fact that there definitely are.
This time it looks to me as thopugh $wpdb->prefix is actually safe to use in bp_cubepoint_setup_globals as it will return ‘wp_’ if a single WP or ‘wp_1_’ if WPMU HOWEVER! not 100% certain of that and which is why I asked an open question about $wpdb->base_prefix as this doesn’t exist in single WP but as used will always? return ‘wp_’ which isn’t correct for WPMU
Quickly set up a WP 3.0 beta to have a look at the table array (base_prefix was in there simply missed it when looking earlier) prefix is there and I’m thinking that as soon as I can work out how MS is set up then ->prefix will be returning the primary install blog, but it’s that which it seems to make sense to establish and write a function or conditional to get the correct table prefix in all circs and that even though in beta this aspect I would bet is one that wouldn’t be changing between now and stable release.
@thekmen sorry yes ‘pagination’ errors when I see that word/phrase I always think in terms of a series of links to paginate to 2nd page of results so was thrown slightly
Set up WP 3.0 as MS
and dumping $wpdb->prefix now shows ‘wp_’ when in the main blog switch to a subdomain blog and I now get ‘wp_2_’
So it looks as though the main blog prefix is simply ‘wp_’ and then all subsequent blogs created start at and are prefixed by ‘wp_2_’ and I assume incrementing.
So ->prefix or ->base_prefix will find the main blog and cubepoint tables will and do prefix simply with ‘wp_’
This appears to make more sense all general wp tables are ‘wp_’ as soon as a MS blog is created it receives the prefix ‘wp_2_’
Don’t quote me but I think this means that ->prefix is safe to use as it will either return ‘wp_’ single WP 2.9 or single WP 3.0 whereas for WPMU it will return ‘wp_1_’
Sidenote: like the look and feel of 3.0
@hnla really wish I could help you with your issues but without being able to reproduce them, it’s pretty impossible.
If you get an environment set up that I can access, let me know & I’ll do what I can.
It’s fixed?? that’s what the four posts above establish, admittedly they do ramble a bit but I have attempted to also establish for you both a safe path forward with db prefixing that works whatever flavour of WP one is running which is why I set up a local install of WP 3.0 to check how db prefixing was being handled.
The issue is all about multi blogs and what is the primary blog that the sub blogs are built from. I’m attempting to resolve the issue with prepending the correct DB prefix regardless of WP type.
I’m guessing that you are running single/standalone WP which is why you can’t reproduce the issues without resorting to removing DB fields. I t may make sense to install a test copy of WPMU or WP 3.0 so you can test in a multi site environment, WPMU must make up a significant proportion of BP users, how things are dealt with when and if they upgrade to WP 3.0 is important if CPBP is to work for everyone.
I’m running latest WPMU and BP and I’m experiencing the same error’s as @hnla experienced -Warning: Division by zero in /home/socialpr/public_html/wp-content/plugins/cubepoints-buddypress-integration/includes/bp-cubepoint-templatetags.php on line 56
On my member points page in my profile it shows that I don’t have any points even though next to my profile name it shows “10 Points”.
On a side note – using the top users widget results this error “Warning: Invalid argument supplied for foreach() in /home/socialpr/public_html/wp-content/plugins/cubepoints/cubepoints.php on line 276”
@ Anton @gpo1
I can’t say for sure what will be the ultimate resolution or when the core plugin files will be updated, but for now the best I can offer is the admendment to make to get the profile points page and site wide points page working. it does mean editing a core file I’m afraid.
This is the fix for WPMU
Please note this does not settle the division by zero error which is related to page pagination but @thekmen did offer a workaround that suppresses that warning but as to why there is no page pagination I’m still uncertain, I’ll post that on pastebin if I have a moment.
@opencircle.co.za Hmm it’s awkward to find your @mention name Anton
The error you are getting with the displayed top lists was covered earlier in another thread and is an issue with the parent cubepoints plugin.
The fix is now stickied in the group please read and follow instructions on the pastebin link:
@hnla – don’t know why my username had the @ in, I never use a username with @ in it. I had to register a new account – antonrsa
Well anyway, I will test your fix for wpmu and let you know.
Just wondering, did the previous 1.6x versions work on WPMU?
- The topic ‘Version 1.7 Beta’ is closed to new replies.