• Content count

  • Joined

  • Last visited

Parisian's Activity

  1. Parisian added a record in IP.Board   

    XCache variables should not be serialized
    I see that when XCache is enabled variables are being serialized/unseralized which is unnecessary since XCache knows how to handle native PHP variables.
    This redundancy should be removed to squeeze extra horsepowers out of the caching layer.
    • 0 replies
  2. Parisian added a record in IP.Board   

    Template hook point in Registration Screen > showAuthorize
    I don't know why this was left out but there should be a template hook point on the successful registration page (i.e. for custom tracking code).
    • 0 replies
  3. Parisian added a comment: Option to disable session_id cookies for guests   

    This is not a suggestion it IS a bug with nginx/varnish caching.
  4. Parisian added a record in IP.Board   

    Option to disable session_id cookies for guests
    For those with high traffic boards using varnish or [url=""]nginx caching[/url] the session_id cookies are useless and produce to incorrect stats.
    An option to disable them entirely would solve many problems in these environments.
    • 0 replies
  5. Parisian added a record in IP.Board   

    Add "Unanswered" to default sort filter in forum postable settings
    This way certain support/Q&A forums can be configured to hide answered posts (with the "best answer" feature) without locking them or moving those topics to a different archive/answered section.
    • 0 replies
  6. Parisian added a record in IP.Board   

    Replace PHP charts with Google Chart Tools
    The charts in and around the Admin CP and IP.Nexus can very easily be replaced with [url=""]Google Charts[/url] which produce better looking graphs that are interactive.
    • 0 replies
  7. Parisian added a comment: Fast reply post won't parse the javascript in a custom bbcode   

    [quote name='teraßyte' timestamp='1340791619']
    Just a quick note I forgot: I haven't tried it but a work-around could be to use a custom php plugin for the bbcode and return directly the JS from there. Not tested but *should* work in this way.
    I can confirm that this doesn't work. There's no way for me to use Javascript in my custom BBCodes any more, please fix!
  8. Parisian added a comment: Session table locks, performance issues and fixes.   

    Sorry to reply to an old ticket but I'm having the same problem on my large board. Using an InnoDB table didn't help. What did however was disabling sessions for search engines who don't really need it:

    diff --git a/admin/sources/classes/session/publicSessions.php b/admin/sources/classes/session/publicSessions.php
    index 42d5fa5..2c58bdd 100644
    --- a/admin/sources/classes/session/publicSessions.php
    +++ b/admin/sources/classes/session/publicSessions.php
    @@ -1039,6 +1039,8 @@ class publicSessions extends ips_MemberRegistry

    if ( $uAgent['uagent_type'] == 'search' )
    + $this->settings['no_print_header'] = 1 ;
    + return false;
    $this->session_id = substr( $uAgent['uagent_key'] . '=' . ( md5( uniqid( microtime(), true ) . $this->_member->ip_address . $this->_userAgent ) ) . '_session', 0, 60
    $memberName = $uAgent['uagent_name'];
    $memberGroup = $this->settings['guest_group'];

    In my Admin CP settings both [i]Log all search engine visits[/i] and [i]Show search engine in the active users list[/i] are set to [i]No[/i], but sessions were still created for them. This is obviously redundant and detrimental to performance for sites that have many thousands of concurrent users online and should be changed.
  9. Parisian added a comment: permission_index table needs index for app column   

    Actually please ignore this message - table already has an index perm_type which includes this column. It must be hitting my slow query log for another reason.
  10. Parisian added a record in IP.Board   

    permission_index table needs index for app column
    Seeing a lot of these messages in my MySQL slow query log:

    [code]SELECT f.*,p.* FROM forums f LEFT JOIN permission_index p ON ( p.perm_type='forum' AND'forums' AND );[/code]

    Adding an index for fixed it.
    • 0 replies
  11. Parisian added a comment: Results of a slow query should be cached   

    Sorry you are correct - this was caused by an old hook which I have now disabled.
  12. Parisian added a record in IP.Board   

    Results of a slow query should be cached
    My MySQL shows thousands of these messages:

    [CODE]# User@Host: ipb[ipb] @ localhost []
    # Query_time: 0.441955 Lock_time: 0.402645 Rows_sent: 138 Rows_examined: 403
    SET timestamp=1341353249;
    SELECT f.*,m.member_group_id as last_poster_group_id,p.* FROM forums f LEFT JOIN members m ON ( m.member_id = f.last_poster_id )
    LEFT JOIN permission_index p ON ( p.perm_type='forum' AND'forums' AND );[/CODE]

    Could the results of this be cached, even for a minute or two?
    • 0 replies
  13. Parisian added a record in IP.Board   

    Group Icon Image doesn't recognise protocol-relative URLs
    [color=#008000][b]HTTP works:[/b][/color] [code][/code]

    [color=#008000][b]HTTPS works:[/b][/color] [code][/code]

    [color=#008000][b]Relative path works:[/b][/color] [code]/public/admin.png[/code]

    [color=#ff0000][b]Protocol-relative paths does not work:[/b][/color] [code]//[/code]

    Please fix the parser so it recognises paths that start with // as protocol-relative links. I don't want to mix forced SSL on non-SSL pages, nor do I want browser warnings for HTTP links on SSL pages.
    • 0 replies
  14. Parisian added a record in IP.Nexus   

    nexus_purchases table needs a unique index to prevent duplicate records of the same type
    ALTER TABLE `nexus_purchases` ADD UNIQUE INDEX `unique`(`ps_member`, `ps_item_id`, `ps_original_invoice`);

    That unique index should be created, otherwise on rare occasions you can get duplicate records for the same purchase.
    • 0 replies
  15. Parisian added a comment: Sessions table needs an index for ip_address column   

    All the indexes [url=""]should be BTREE[/url] instead of HASH if you're using MEMORY tables.