Skip to:
Content
Pages
Categories
Search
Top
Bottom

Version 1.7 Beta

Viewing 25 replies - 26 through 50 (of 69 total)
  • Avatar of thekmen
    thekmen
    Participant

    @thekmen

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

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    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.

    Avatar of thekmen
    thekmen
    Participant

    @thekmen

    It should be in the WordPress options table, option_name = bp_cubepoint_per_page & option_value = 20

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    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.

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    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.

    Avatar of josh101
    josh101
    Participant

    @josh101

    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

    Avatar of josh101
    josh101
    Participant

    @josh101

    http://pastebin.com/augCDn66

    there the file that is doing it I pasted the frist 70 lines

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    @thekmen @xberserker Ok the root cause is the same as before with DB prefixes.

    In bp_cubepoint_core.php

    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?

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

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

    Avatar of thekmen
    thekmen
    Participant

    @thekmen

    @hnla, does your $wpdb->prefix fix the rank images or the pagination errors?

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    @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

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    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.

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    @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 :)

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    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

    Avatar of thekmen
    thekmen
    Participant

    @thekmen

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

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

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

    Avatar of Gpo1
    gpo1
    Participant

    @gpo1

    @hnla, Job well done..Are you going to amend the CPBP plugin?

    Avatar of Anton
    Anton
    Participant

    @antonrsaopencirclecoza

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

    Avatar of Anton
    Anton
    Participant

    @antonrsaopencirclecoza

    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″

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    @ 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
    http://pastebin.com/DMm7bP9n

    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.

    Avatar of Hugo
    Hugo
    Moderator

    @hnla

    @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:

    http://buddypress.org/community/groups/cubepoints-buddypress-integration/forum/topic/cubepoints-wordpress-mu-fix/

    Avatar of pcwriter
    pcwriter
    Participant

    @pcwriter

    @hnla

    Sorry, can’t find @thekmen‘s workaround for that annoying “division by zero” message. Could you post a link?

    Also, I’ve implemented your suggested fixes for WPMU, but I see no points awarded when I post a test comment to a member blog. Any suggestions for that one? :-)

    Avatar of Anton
    Anton
    Participant

    @antonrsa

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

    Avatar of thekmen
    thekmen
    Participant

    @thekmen

    Just wondering, did the previous 1.6x versions work on WPMU?

    Avatar of pcwriter
    pcwriter
    Participant

    @pcwriter

    @thekmen I had 1.6.4 installed previously and it didn’t work on WPMU

Viewing 25 replies - 26 through 50 (of 69 total)

The topic ‘Version 1.7 Beta’ is closed to new replies.