• 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
    • Can't undo changes

    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: Can't undo changes

    • Issue Tools
      • View Changes
    1. issueid=2013 October 3, 2010 10:31 AM
      ElvenSoft ElvenSoft is offline
      New Member
      Can't undo changes
      There seems to be a bug with some changes not being undoable

      Hi,

      I just installed VaultWiki and whenever I try to undo/purge the most recent changes, I get the following errors:

      Invalid revision specified. If you followed a valid link, please notify the administrator

      Undoing/Purging only works for any changes before the most recent one, but even then, it doesn't UNDO those changes, but rather REVERTS to them.

      For example,

      First Change: Text: Test article (Article creation) (report)
      Second Change : Added text: <some bad words> (controls)
      Third Change : Added text: <more bad words> (controls)

      Clicking on Third Change Undo >> Invalid revision specified. If you followed a valid link, please notify the administrator
      Clicking on Second Change Undo >> Undos Third change, but keeps second change
      Clicking on First Change Undo >> You can't, because you only have the report option for this one

      Therefore Second Change can never be undone. I don't know if I'm missing something, but this is what I'm getting.

      My test article Url is the following:
      Code:
      http://forums.tibianeobot.com/showwiki.php?title=Test+Wiki
      The other issue I'm having is that users with edit permissions can delete book chapters. This doesn't seem to be undoable anywhere and is a potential venue for abuse and vandalism which I could be getting a lot. Please advise.
    Issue Details
    Issue Number 2013
    Issue Type Bug
    Project VaultWiki 3.x Series
    Category History / Revisions
    Status Fixed
    Priority 3 - Loss of Functionality
    Affected Version 3.0.4
    Fixed Version 3.0.5
    Milestone VaultWiki 3.0.5
    Software DependencyAny
    Users able to reproduce bug 0
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users (none)
    Tags (none)




    1. October 3, 2010 1:27 PM
      pegasus pegasus is offline
      VaultWiki Team
      Users who can edit books can add/remove chapters from being part of the book. They cannot delete the chapters themselves or the book itself. If this is a concern for you, you may want to increase the permissions needed to edit a book (using Forum Permissions). Changing this behavior would require creating a new permission, please post the request here: http://www.vaultwiki.org/projectpost...ypeid=featu re

      As for the revisions, thank you for making this observation, I will post back when I have some more information or a fix.
      Reply Reply  
    2. October 3, 2010 3:11 PM
      ElvenSoft ElvenSoft is offline
      New Member
      Yes that is what I meant about the book chapters, that they can be removed, not deleted.

      Neither is a huge deal and I'm sure I can get around them, but just letting you know.

      Thanks and I will post that feature request.
      Reply Reply  
    3. October 3, 2010 6:50 PM
      pegasus pegasus is offline
      VaultWiki Team
      In vault/tab/history.php, find:
      Code:
          if (!$_REQUEST['action'] == 'purge' AND !$_POST['action'] == 'dopurge' AND $revisionid == $extreme['current_revisionid'])
          {
              eval(standard_error(fetch_error('vault_current_rollback_error')));
          }
      
          $revision = $db->query_first("
              SELECT revision.*, COUNT(revision.revisionid) - 1 AS revisioncount
              FROM " . TABLE_PREFIX . "vault_revision AS revision
              WHERE revision.revisionid >= " . intval($revisionid) . "
                  AND threadid = " . intval($threadinfo['threadid']) . "
              GROUP BY threadid
              ORDER BY revision.revisionid ASC
          ");
      
          if (empty($revision) OR $revision['revisionid'] == $extreme['current_revisionid'])
          {
              eval(standard_error(fetch_error('invalidid', $vbphrase['vault_revision'], $vbulletin->options['contactuslink'])));
          }
      Replace with:
      Code:
          if ($_REQUEST['action'] == 'rollback' OR $_POST['action'] == 'dorollback')
          {
              if ($revisionid > $extreme['current_revisionid'])
              {
                  eval(standard_error(fetch_error('vault_current_rollback_error')));
              }
      
              $last = $db->query_first("
                  SELECT lastrevisionid AS revisionid
                  FROM " . TABLE_PREFIX . "vault_revision
                  WHERE revisionid = " . intval($revisionid) . "
              ");
      
              $revisionid = $last['revisionid'];
          }
      
          if ($revisionid)
          {
              $revision = $db->query_first("
                  SELECT revision.*, COUNT(revision.revisionid) - 1 AS revisioncount
                  FROM " . TABLE_PREFIX . "vault_revision AS revision
                  WHERE revision.revisionid >= " . intval($revisionid) . "
                      AND threadid = " . intval($threadinfo['threadid']) . "
                  GROUP BY threadid
                  ORDER BY revision.revisionid ASC
              ");
          }
      
          if (empty($revision))
          {
              eval(standard_error(fetch_error('invalidid', $vbphrase['vault_revision'], $vbulletin->options['contactuslink'])));
          }
      Reply Reply  
    4. October 3, 2010 8:13 PM
      ElvenSoft ElvenSoft is offline
      New Member
      Thanks for the fix pegasus. It gets rid of the problem, but only if you are careful with the purges and undos as some sequences lea to errors.

      Let me show you the test cases which I've found causing problems:

      Create an article
      Add 1 edit to it
      Undoing that first edit >> Invalid revision specified. If you followed a valid link, please notify the administrator

      However, purging that edit works correctly and it gets listed as "Reverted edits by ekx to version #427 by ekx"

      From there, if you try purging this "Reverted edits by ekx to version #427 by ekx", you get a fatal error right after confirming the purge.

      PHP Code:
      Fatal error:
      The changes to this article are not sufficient to create a new revision.
      Unable to proceed with save while $errors array is not empty in class vB_WikiRevision_Manager in [path]/includes/class_dm.php on line 849
      #0 vb_error_handler(256,
      The changes to this article are not sufficient to create a new revision.
      Unable to proceed with save while $errors array is not empty in class vB_WikiRevision_Manager, /var/www/html/includes/class_dm.php, 849, Array ([die] => 1,[this] =>........... 
      If you now create another edit, you can successfully purge the first edit/reversion which was causing the fatal error.

      Now you should have 1 edit listed and undoing that gives you the invalid link error. If you add a second edit, undoing this second edit which is the top most works.

      Then if you purge the "Reverted entry", you delete this one and revert the article back to containing both edits and get another reverted entry for the purge. If you try purging this reverted entry you get the fatal error once again. You are however able to purge those "reverted" entries created by a purge without the fatal error if that entry isn't the most recent in the history list.

      Anyways that's probably confusing but I'm sure you'll be able to make something out of it if you follow these steps.

      Thanks for your time.
      Reply Reply  
    5. October 3, 2010 11:12 PM
      pegasus pegasus is offline
      VaultWiki Team
      Okay, the first line of the edit above should instead be:
      Code:
          if ($_REQUEST['action'] == 'rollback')
      Since the form submits the correct revision ID, it doesn't need to be rolled back on the 'dorollback' action.

      The purge fatal error occurs when you attempt to purge the current revision, and the current revision is actually a duplicate of the version right before it (like if it's a "reverted" entry). However, the number of cases where this occurs should ideally be significantly lower than it does now - you should only need to purge the current revision, and it should not create a "reverted" entry, but this is not possible to fix with the current database structure. This is something we plan to address in VaultWiki 4.

      In order to prevent the error from occurring when purging the duplicate entry, in vault/dm/revision.php, find:
      Code:
                      $this->info['roll_back'] = $target['revisionid'];
      
                      if ($doquery)
                      {
                          $threadinfo = fetch_threadinfo($this->existing['threadid']);
                          $foruminfo = fetch_foruminfo($threadinfo['forumid']);
                          $post = fetch_postinfo($threadinfo['firstpostid']);
      
                          require_once(DIR . '/vault/functions/rollback.php');
                          $rolldata = revision_history_rollback($target, $foruminfo, $threadinfo, $post, array(
                              'is_automated'
                          ));
      
                          if (!empty($rolldata->errors))
                          {
                              eval(standard_error(implode('&lt;br />', $rolldata->errors)));
                          }
                          unset($rolldata);
                      }
      Replace with:
      Code:
                      if ($target['revisionid'] == $this->existing['rollback'])
                      {
                          // do nothing, purged was duplicate of target
                      }
                      else
                      {
                          $this->info['roll_back'] = $target['revisionid'];
      
                          if ($doquery)
                          {
                              $threadinfo = fetch_threadinfo($this->existing['threadid']);
                              $foruminfo = fetch_foruminfo($threadinfo['forumid']);
                              $post = fetch_postinfo($threadinfo['firstpostid']);
      
                              require_once(DIR . '/vault/functions/rollback.php');
                              $rolldata = revision_history_rollback($target, $foruminfo, $threadinfo, $post, array(
                                  'is_automated'
                              ));
      
                              if (!empty($rolldata->errors))
                              {
                                  eval(standard_error(implode('&lt;br />', $rolldata->errors)));
                              }
                              unset($rolldata);
                          }
                      }
      This will not catch all cases. Like if you had 5 edits, like so:
      1. A
      2. B (purged)
      3. A (reverted)
      4. C (purged)
      5. A (reverted)

      In this scenario, purging the following order 2, 4, 3, 5 will result in the same error because 5 was not recorded as identical to 1 but rather to 3. All cases will actually not throw a stop error in the next release because of a fix for a related bug: http://www.vaultwiki.org/issues/2000/ Instead they will die quietly without creating a duplicate revision, but performing the purge.
      Reply Reply  
    6. October 4, 2010 4:14 AM
      ElvenSoft ElvenSoft is offline
      New Member
      This seems to work really smoothly now. At least I'm not getting any errors with the basic operations that I have tried so that's a big relief and I doubt I'll even be getting into situations like the one you described which probably are fixable somehow regardless.

      Great work on the software. Take care.
      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 10:52 AM.
    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.