Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-9782

Board disable radio in Board-Settings set on when server load high

    Details

    • Type: Bug
    • Status: Unverified Fix
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.7-PL1
    • Fix Version/s: 3.0.8-RC1
    • Component/s: ACP
    • Labels:
      None
    • Environment:
      Any with Linux OS server

      Description

      When the board is temporarily disabled due to system load greater than limit_load, if admin logs into ACP and navigates to Board Settings, the "Disable board" setting will be set to Yes (board_disable=true)

        Activity

        Hide
        narqelion narqelion [X] (Inactive) added a comment -

        Yes. In either case, there should be a clear message that the board is temporarily disabled due to load.

        phpBB already distinguishes between a board disabled manually and one disabled due to load settings in the language presented on the board index to guests. If a load setting has disabled the board the language string presented is:
        BOARD_UNAVAILABLE' => 'Sorry but the board is temporarily unavailable, please try again in a few minutes.',
        That has always seemed fairly clear to me but that could be because I am very familiar with phpBB and know that when the board is disabled by an admin a different string is used:
        'BOARD_DISABLE' => 'Sorry but this board is currently unavailable.',

        I propose the best way to address the issue the OP experienced is just to be even more explicit in the BOARD_UNAVAILABLE string, instead of "Sorry but the board is temporarily unavailable, please try again in a few minutes." how about "Sorry but the board is temporarily unavailable due to high system load, please try again in a few minutes."

        That should provide sufficient detail to any non-logged in users/mods & admins. For admins/mods who happen to be logged in when the board goes offline or have persistent logins you can add a warning or notice box on the ACP index (similar to the install folder or config.php permission checks) that displays the BOARD_UNAVAILABLE message.

        Also now that I am looking at the language strings I see some annoying inconsistencies and word choices that do not accurately convey the situation.

        Personally I would refine the language strings as follows:

        'BOARD_DISABLE' => 'Sorry but This board is currently unavailable.',
        'BOARD_UNAVAILABLE' => 'Sorry but the This board is temporarily currently unavailable due to high system load, please try again in a few minutes later.'

        "temporarily" is a subjective label at best and you honestly have no way of knowing how long the the server resource issue will take to be resolved. By using the language you have now you create an expectation that the outage will be momentary when you have no information to base that on. Better to be conservative when setting expectations and report back the current state of the board, no more no less.

        Show
        narqelion narqelion [X] (Inactive) added a comment - Yes. In either case, there should be a clear message that the board is temporarily disabled due to load. phpBB already distinguishes between a board disabled manually and one disabled due to load settings in the language presented on the board index to guests. If a load setting has disabled the board the language string presented is: BOARD_UNAVAILABLE' => 'Sorry but the board is temporarily unavailable, please try again in a few minutes.', That has always seemed fairly clear to me but that could be because I am very familiar with phpBB and know that when the board is disabled by an admin a different string is used: 'BOARD_DISABLE' => 'Sorry but this board is currently unavailable.', I propose the best way to address the issue the OP experienced is just to be even more explicit in the BOARD_UNAVAILABLE string, instead of "Sorry but the board is temporarily unavailable, please try again in a few minutes." how about "Sorry but the board is temporarily unavailable due to high system load , please try again in a few minutes." That should provide sufficient detail to any non-logged in users/mods & admins. For admins/mods who happen to be logged in when the board goes offline or have persistent logins you can add a warning or notice box on the ACP index (similar to the install folder or config.php permission checks) that displays the BOARD_UNAVAILABLE message. Also now that I am looking at the language strings I see some annoying inconsistencies and word choices that do not accurately convey the situation. Personally I would refine the language strings as follows: 'BOARD_DISABLE' => ' Sorry but This board is currently unavailable.', 'BOARD_UNAVAILABLE' => ' Sorry but the This board is temporarily currently unavailable due to high system load , please try again in a few minutes later .' "temporarily" is a subjective label at best and you honestly have no way of knowing how long the the server resource issue will take to be resolved. By using the language you have now you create an expectation that the outage will be momentary when you have no information to base that on. Better to be conservative when setting expectations and report back the current state of the board, no more no less.
        Hide
        nickvergessen Joas Schilling added a comment -

        Narq, open a new ticket, if you think that there is an issue with the language strings.
        That has nothing to do with this issue here...
        and remember to keep it SHORT!

        Show
        nickvergessen Joas Schilling added a comment - Narq, open a new ticket, if you think that there is an issue with the language strings. That has nothing to do with this issue here... and remember to keep it SHORT!
        Hide
        narqelion narqelion [X] (Inactive) added a comment -

        That has nothing to do with this issue here...

        On the contrary, it has everything to do with the issue here, it is the proposed improvement to address the issue that your "fix" doesn't address at all.

        OP's situation with the "fix":
        Board was disabled by the script due to load setting threshold defined in ACP being met.
        OP logs into ACP to see that the 'Board disable' switch is No (False)
        OP wonders "how can this be, the board is disabled but the setting says it isn't."
        That is no solution, the OP still has no idea what is going on and you have added the new issue that the setting no longer reflects the actual state of the board being enabled or disabled.

        Both bantu & Brf have stated that what is needed is:

        What would be needed is a message in the ACP main page saying that the board is disabled due to load issues,

        Yes. In either case, there should be a clear message that the board is temporarily disabled due to load.

        My suggestion is to use & improve the existing language strings to achieve that, not your fix which doesn't fix anything.

        Show
        narqelion narqelion [X] (Inactive) added a comment - That has nothing to do with this issue here... On the contrary, it has everything to do with the issue here, it is the proposed improvement to address the issue that your "fix" doesn't address at all. OP's situation with the "fix": Board was disabled by the script due to load setting threshold defined in ACP being met. OP logs into ACP to see that the 'Board disable' switch is No (False) OP wonders "how can this be, the board is disabled but the setting says it isn't." That is no solution, the OP still has no idea what is going on and you have added the new issue that the setting no longer reflects the actual state of the board being enabled or disabled. Both bantu & Brf have stated that what is needed is: What would be needed is a message in the ACP main page saying that the board is disabled due to load issues, Yes. In either case, there should be a clear message that the board is temporarily disabled due to load. My suggestion is to use & improve the existing language strings to achieve that, not your fix which doesn't fix anything.
        Hide
        bantu Andreas Fischer added a comment - - edited

        I agree that instead of introducing a message in the ACP saying that the board is unavailable due to load problems, we could also adjust the BOARD_UNAVAILABLE string. But either requires a new ticket.

        The fix in this ticket is still correct though.

        Show
        bantu Andreas Fischer added a comment - - edited I agree that instead of introducing a message in the ACP saying that the board is unavailable due to load problems, we could also adjust the BOARD_UNAVAILABLE string. But either requires a new ticket. The fix in this ticket is still correct though.
        Hide
        narqelion narqelion [X] (Inactive) added a comment -

        But either requires a new ticket.

        I will be sure to send users in support right back here to create a new bug ticket reporting the regression this commit introduces. The description will be something along these lines I predict:

        Hey my board says across the top of the forums that it is disabled but I didn't disable it. I went into the ACP to Board Settings -> Disable board: but it is set to No there so it's not disabled.....so why is there a message saying it is? What the heck, this is broken!"

        The fix in this ticket is still correct though.

        The fix attached to this ticket does not even address the original issue, which was that the OP had no idea why the board was disabled in the first place. He would not have played with the board settings an ended up disabling his board manually in the first place if he had been notified as soon as he went into the ACP that the board was offline due to a load settings issue. My proposal was targeted at fixing the root cause of the confusion thus preventing the OP's mistake from happening. Your fix does nothing to help the OP here and is very likely to result in an admin toggling the setting back and forth in a desperate attempt to find out why it appears to have no effect on the status of the board. If the only thing that will resolve this difference of opinion on what the real issue is here and the best way to to address it is time, I am perfectly willing to wait for the impact of this change to play out on the user base and trickle back through support and the tracker.

        Show
        narqelion narqelion [X] (Inactive) added a comment - But either requires a new ticket. I will be sure to send users in support right back here to create a new bug ticket reporting the regression this commit introduces. The description will be something along these lines I predict: Hey my board says across the top of the forums that it is disabled but I didn't disable it. I went into the ACP to Board Settings -> Disable board: but it is set to No there so it's not disabled.....so why is there a message saying it is? What the heck, this is broken!" The fix in this ticket is still correct though. The fix attached to this ticket does not even address the original issue, which was that the OP had no idea why the board was disabled in the first place. He would not have played with the board settings an ended up disabling his board manually in the first place if he had been notified as soon as he went into the ACP that the board was offline due to a load settings issue. My proposal was targeted at fixing the root cause of the confusion thus preventing the OP's mistake from happening. Your fix does nothing to help the OP here and is very likely to result in an admin toggling the setting back and forth in a desperate attempt to find out why it appears to have no effect on the status of the board. If the only thing that will resolve this difference of opinion on what the real issue is here and the best way to to address it is time, I am perfectly willing to wait for the impact of this change to play out on the user base and trickle back through support and the tracker.

          People

          • Assignee:
            nickvergessen Joas Schilling
            Reporter:
            Brf Brf
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development