Posts by Tim Düsterhus

    1. Create a thread with type “Announcement”.
    2. De-select all boards.
    3. Submit.
    4. Notice it works fine.
    5. Open the “Edit Thread” dialog
    6. De-select all boards
    7. Submit the dialog.
    8. Notice the following Exception:
    Requested URL
    Error Message
    Undefined index: boardIDs
    File (Line)
    /var/www/virtual/xxx/ (346)
    1. /var/www/virtual/xxx/ (124): wcf\system\WCF::handleError(…)
    2. /var/www/virtual/xxx/ (84): wbb\system\thread\editor\DefaultThreadEditor->validate(…)
    3. /var/www/virtual/xxx/ (683): wbb\system\thread\ThreadHandler->saveEdit(…)
    4. [internal function] (?): wbb\data\thread\ThreadAction->saveEdit(…)
    5. /var/www/virtual/xxx/ (204): call_user_func(…)
    6. /var/www/virtual/xxx/ (75): wcf\data\AbstractDatabaseObjectAction->executeAction(…)
    7. /var/www/virtual/xxx/ (104): wcf\action\AJAXProxyAction->invoke(…)
    8. /var/www/virtual/xxx/ (47): wcf\action\AJAXInvokeAction->execute(…)
    9. /var/www/virtual/xxx/ (63): wcf\action\AbstractAction->__run(…)
    10. /var/www/virtual/xxx/ (83): wcf\action\AJAXInvokeAction->__run(…)
    11. /var/www/virtual/xxx/ (96): wcf\system\request\Request->execute(…)
    12. /var/www/virtual/xxx/ (9): wcf\system\request\RequestHandler->handle(…)


    Thus regarding what you stated in your response to me in Post #5, do you think I should have them change the setting to PHP Version 7.3?

    If you don't run any plugins then I recommend PHP 7.3. If you do you might need to check with the authors whether PHP 7.3 is supported. It should be supported for most.


    I may be mistaken, however I seem to recall Alexander Ebert stating that the preferred PHP Version to use is 7.1; additionally, using version 7.2 OR 7.3 can lead to various problems with various apps and plugins - among other problems as well.

    The preferred version is the newest version that supports all your apps and plugins. Apps and plugins from us will support PHP 7.3 just fine!

    Yachtie Apparently a database table the plugin created during installation and tries to remove during uninstallation is missing, leading to this issue. I can second the existing advice to file a ticket so that we can look into it and hopefully fix the database of your community.


    One thing I noticed - and hopefully Matthias Schmidt and others at Woltlab Development - have noticed the several misspellings, and words which are not needed, in a few of the sentences under "Stop Forum Spam".

    I just looked at the screenshot and noticed one typo (“ignore” instead of “ignored” for “do not check”). But as none of us are native speakers: Could you clarify where you would make changes?


    JavaScript should always reside in WoltLab Suite Core which would be:

    <instruction type="file" application="wcf">files_wcf.tar</instruction>

    Unless you are developing a full-blown app (such as WoltLab Suite Forum or WoltLab Suite Calendar) the first one would be equivalent, because it defaults to WoltLab Suite Core for non-apps.

    1. Create a new thread without a poll (polls = 0)
    2. Create a reply with a poll (polls = 1)
    3. Trash the reply (polls = 0 because of ThreadEditor::rebuildThreadData not counting trashed posts)
    4. Delete the reply (polls = -1 because of PostAction::delete calling updateCounters for the poll count)

    I suggest that the updateCounters call is replaced by a rebuildThreadData call, possibly the one a few lines above could just be moved down.

    1. Create a category and check “Hide forum on the forum list”.
    2. Create a forum in that category.
    3. Create a new main menu item pointing to the category.
    4. Create a thread in the forum created in step 2.
    5. Log-In with a user that did not yet read the thread.
    6. Notice that the main menu item does not show that one thread is not yet read.
    7. Uncheck “Hide forum on the forum list”.
    8. Notice that the main menu item now shows that one thread is not yet read.

    In addition: The “Forum” main menu item probably should not count threads in boards that are below a board that is hidden in the forum list. Only when a hidden forum is directly linked it (and it’s children) should be included in the counters.


    GameDevJon Can you try the following, please:

    1. Open the file filebase/lib/page/DownloadPage.class.php.
    2. In that file find: HeaderUtil::redirect($this->version->downloadURL, true);.
    3. Replace with: @header('HTTP/1.1 303 See Other'); HeaderUtil::redirect($this->version->downloadURL, false);.
    4. Check whether it now works on the first try on Windows (log out of the community, restart the browser and log into the community).
    1. Create a new thread and opt for “Delayed publishing”
    2. Move the thread into Trash.
    3. Restore the thread from Trash.
    4. An Exception in thrown in PostAction, line 1390 because of the $post->isDisabled check in line 1312.
    Requested URL
    Error Message
    Undefined index: posts
    File (Line)
    /var/www/html/lib/system/WCF.class.php (346)
    1. /var/www/html/forum/lib/data/post/PostAction.class.php (1390): wcf\system\WCF::handleError(…)
    2. [internal function] (?): wbb\data\post\PostAction->restore(…)
    3. /var/www/html/lib/data/AbstractDatabaseObjectAction.class.php (204): call_user_func(…)
    4. /var/www/html/forum/lib/data/thread/ThreadAction.class.php (3157): wcf\data\AbstractDatabaseObjectAction->executeAction(…)
    5. /var/www/html/forum/lib/data/thread/ThreadAction.class.php (1168): wbb\data\thread\ThreadAction->restorePosts(…)
    6. [internal function] (?): wbb\data\thread\ThreadAction->restore(…)
    7. /var/www/html/lib/data/AbstractDatabaseObjectAction.class.php (204): call_user_func(…)
    8. /var/www/html/lib/action/AJAXProxyAction.class.php (75): wcf\data\AbstractDatabaseObjectAction->executeAction(…)
    9. /var/www/html/lib/action/AJAXInvokeAction.class.php (104): wcf\action\AJAXProxyAction->invoke(…)
    10. /var/www/html/lib/action/AbstractAction.class.php (47): wcf\action\AJAXInvokeAction->execute(…)
    11. /var/www/html/lib/action/AJAXInvokeAction.class.php (63): wcf\action\AbstractAction->__run(…)
    12. /var/www/html/lib/system/request/Request.class.php (83): wcf\action\AJAXInvokeAction->__run(…)
    13. /var/www/html/lib/system/request/RequestHandler.class.php (96): wcf\system\request\Request->execute(…)
    14. /var/www/html/forum/index.php (9): wcf\system\request\RequestHandler->handle(…)

    Administrators might want to proxy images from a specific external provider, e.g. due to terms that disallow hotlinking, but might not want to proxy arbitrary user generated content, because of possible copyright infringement.

    It should be considered to separate the options into:

    1. Enable the ImageProxy in general (e.g. for use in plugins). This can be disabled if the administrator does not want external connections at all.
    2. Enable the ImageProxy for user generated content (e.g. posts). This can be disabled if the administrator does not want to proxy arbitrary URLs, but only URLs as generated by plugins (e.g. a plugin specific to a single external provider).