• Register
    • Help

    striker  0 Items
    Currently Supporting
    • Home
    • News
    • Forum
    • Wiki
    • Support
      • Manage Subscriptions
      • FAQ
      • Support For
        • VaultWiki 4.x Series
        • VaultWiki.org Site
    • What's New?
    • Buy Now
    • Manual
    • 
    • Support
    • VaultWiki 3.x Series
    • Bug
    • When trying to physically remove post from thread

    1. Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

      VaultWiki allows your existing forum users to collaborate on creating and managing a site's content pages. VaultWiki is a fully-featured and fully-supported wiki solution for vBulletin and XenForo.

      The VaultWiki Team encourages you to join our community of forum administrators and check out VaultWiki for yourself.

    Issue: When trying to physically remove post from thread

    • Issue Tools
      • View Changes
    1. issueid=85 July 15, 2008 1:08 PM
      NickyPhils NickyPhils is offline
      VaultWiki Team
      When trying to physically remove post from thread
      When I tried to do the thing written above, there was an error.

      I made a post in the thread with the poll on categories and special pages. However, my post was double posted by the Quick Reply. I thought it would add the post to the thread by Ajax, but instead it reloaded the page. Thinking the double post to be a routine lapse of intelligence by the forum, I proceeded to edit the second of the double post, leaving the first intact. I then thought it was stupid to have both, so I used the Edit button and then the Delete button. I tried to Physically Remove the message, under the reason "Double post".

      The action resulted in a white error page.
      Code:
      Warning: implode() [function.implode]: Invalid arguments passed in /home/crackede/public_html/vault/special_plugins_data.php on line 326
      
      Database error in vBulletin 3.7.2:
      
      Invalid SQL:
      
      		DELETE FROM forum_vault_link
      		WHERE postid IN ();
      
      MySQL Error   : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')' at line 2
      Error Number  : 1064
      Request Date  : Tuesday, July 15th 2008 @ 10:54:18 AM
      Error Date    : Tuesday, July 15th 2008 @ 10:54:18 AM
      Script        : hxxp://www.crackedeggstudios.com/editpost.php
      Referrer      : hxxp://www.crackedeggstudios.com/showthread.php?p=2908&posted=1
      IP Address    : xxx.xxx.xxx.xxx
      Username      : NickyPhils
    Issue Details
    Issue Number 85
    Issue Type Bug
    Project VaultWiki 3.x Series
    Category Inline Moderation
    Status Fixed
    Priority 2 - Fatal / Database Errors
    Affected Version 2.0.0 RC3
    Fixed Version 2.0.0
    Milestone VaultWiki 2.0.0
    Software DependencyAny
    Users able to reproduce bug 1
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users NickyPhils, pegasus
    Tags (none)




    1. July 15, 2008 4:40 PM
      pegasus pegasus is offline
      VaultWiki Team
      Fixed the delete part of the report. In this situation only a single ID was passed into the link cache cleaner, and was not part of an array when the implode was attempted. Thus, an error was thrown and a 'false' value inserted into the query, causing this 1064.

      The double posting bug looks like it is going to be a pain to locate, though.
      Reply Reply  
    2. July 15, 2008 5:31 PM
      pegasus pegasus is offline
      VaultWiki Team
      Okay... here's a break-down of why the Double Post error appears.

      1. You attempt to post via Quick Reply. If the Quick Reply will be AJAX, the chain continues.
      2. AJAX fetches the new posts to the thread.
      3. A database error occurs because $threadinfo[threadid] in NULL, so AJAX receives no posts.
      4. AJAX thinks it failed to make the reply, so it tries to post again without using AJAX, and just reloads the page.
      5. The second attempt is the Double Post, and we see a notice that we already made this post.


      So the question becomes: why was $threadinfo['threadid'] NULL?

      By saving the value of threadinfo before the reply is saved and restoring it afterwards, we can narrow down the origin of the change to occurring during the Link Caching process, when the BB-Code Parser is run to find valid wiki links. However, since replies do not use the Wiki Code Parser, this seriously limits the extent to which $threadinfo can be modified (for example Redirects would not be processed).

      So now I'm looking at the parser plugins.
      Reply Reply  
    3. July 15, 2008 6:11 PM
      pegasus pegasus is offline
      VaultWiki Team
      Because the Wiki Code Parser is passed through the Link Cacher frequently enough anyway, it's probably best to save/restore the various infos at that point anyway. This fixes the problem, but bothers me that I can't find the exact line it occurs on in the standard BB-Code Parser. If somehow the Plaintext Parser were loaded, I would understand.

      Anyway, Fixed. But not really. Still errors, but caught. So no more DB error and double posting.
      Reply Reply  
    4. July 16, 2008 7:48 AM
      Hilary Hilary is offline
      Junior Member
      Should I be upgrading to get this fixed? (And are there special upgrade instructions somewhere?)

      By the way, the error messages (1064, post.threadid = blank) are still generated when there is no sign of anything wrong during posting.
      Reply Reply  
    5. July 16, 2008 12:03 PM
      pegasus pegasus is offline
      VaultWiki Team
      This was not fixed in RC3. You will have to wait until the next release. Another way around this is turning off AJAX in Quick Reply until then.
      Reply Reply  
    6. August 4, 2008 8:46 PM
      pegasus pegasus is offline
      VaultWiki Team
      Reopening this, because the Quick Reply issue happened again today.
      Reply Reply  
    7. August 5, 2008 1:55 AM
      pegasus pegasus is offline
      VaultWiki Team
      My newest theory is that this is caused by the fix for legacy wiki links on newthread.php, which was mainly added because $threadinfo['namespaceid'] was not set before the thread was saved. This code sets $threadinfo = $vault->parser['thread'], which may or may not include a thread ID. Why this branch of special_postdata_postsave() would ever be called on newreply.php is beyond me, but why it does not occur consistently is just as baffling.

      I changed this code to an array_merge(), so hopefully an existing thread ID will not be affected. Marking this as fixed until I see it again.
      Reply Reply  
    + Reply

    Assigned Users
    Loading Please Wait
    Tags
    Loading Please Wait
    • Contact Us
    • License Agreement
    • Privacy
    • Terms
    • Top
    All times are GMT -4. The time now is 11:55 PM.
    This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Learn more… Accept Remind me later
  • striker
    Powered by vBulletin® Version 4.2.5 Beta 2
    Copyright © 2023 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2023 DragonByte Technologies Ltd.
    Copyright © 2008 - 2013 VaultWiki Team, Cracked Egg Studios, LLC.