• 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
    • Renaming article creates a "ghost article"; Reverting history removes all thumbnails

    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: Renaming article creates a "ghost article"; Reverting history removes all thumbnails

    • Issue Tools
      • View Changes
    1. issueid=2644 April 9, 2012 11:18 AM
      iMav iMav is offline
      New Member
      Renaming article creates a "ghost article"; Reverting history removes all thumbnails

      We've been using VaultWiki for quite a while and have noticed quite a few issues. I would love to find out that these are simple misconfigurations on my part.

      Pegasus, can you take a look at this thread and help me understand where the issues lie? http://geekhack.org/showthread.php?1...per-wiki/page3

      Any help would be greatly appreciated. (everyone is clamoring for MediaWiki and, frankly, I'd rather get the VW issues resolved)
    Issue Details
    Issue Number 2644
    Issue Type Bug
    Project VaultWiki 3.x Series
    Category Wiki Pages
    Status Fixed
    Priority 1 - Security / Login / Data Loss
    Affected Version 3.0.17
    Fixed Version 3.0.18
    Milestone (none)
    Software DependencyAny
    Users able to reproduce bug 0
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users (none)
    Tags (none)


    Page 1 of 2 12 Next LastLast


    1. April 9, 2012 3:27 PM
      pegasus pegasus is offline
      VaultWiki Team
      If I understand the "ghost" issue properly:
      1. You have an Article with name "Article Name"
      2. You rename the Article to "Article Renamed"
      3. You revert the last edit
      4. When viewing the article "Article Name" and "Article Renamed", you see an arrow to the other but never the original content.

      I'm wondering about the best way to solve this - when a revert would cause a title collision because another article already exists with the old title. Possibly not renaming the article back, but reverting everything else about the article.

      However, you can get a list of all articles affected by this simply by visiting AdminCP > Wiki URL Manager. That page also gives the admin the option to clean up the affected articles, by deleting them or renaming them. I recommend deleting the duplicates - they will usually only be a redirect to the real one anyway. You may have to use the [Rebuild Page URLs] link afterwords to restore some articles that were previously "ghosted".

      Also, when renaming Island articles you get a redirect to the renamed article. Redirects to Islands never work.

      I will see if there's anything else. Haven't looked at the attachments after revert yet.
      Reply Reply  
    2. April 9, 2012 3:46 PM
      pegasus pegasus is offline
      VaultWiki Team
      Fixed the reversion issue in tests here. To prevent future edit reverts from causing the ghost problem, in vault/functions/rollback.php, find:
      Code:
      	$revision['pagetext'] = $revhandle->decompress($revision['pagetext'], $revision['unzip']);
      Add after:
      Code:
      	if (!isset($threadinfo['namespaceid']))
      	{
      		$vault->fetch_instance('field');
      		$threadinfo['namespaceid'] = $vault->field->fetch_namespaceid($threadinfo['forumid']);
      	}
      
      	if ($threadinfo['namespaceid'] != ISLAND_SPACE)
      	{
      		// avoid making this article disappear after revert due to title collision
      		if ($revision['title'] != $current['title'] OR $revision['prefixid'] != $current['prefixid'])
      		{
      			// find any collisions
      			require_once(DIR . '/vault/functions/automate.php');
      			$collide = special_read_article_title($revision['title'], $threadinfo['forumid'], false);
      
      			if ($collide['threadid'] != $revision['threadid'])
      			{
      				// is it a redirect, if so overwrite
      				$redirect = $vbulletin->db->query_first("
      					SELECT link.postid
      					FROM " . TABLE_PREFIX . "post AS post
      					LEFT JOIN " . TABLE_PREFIX . "vault_link AS link ON (link.postid = post.postid)
      					WHERE link.redirect = 1
      						AND post.threadid = " . intval($collide['threadid']) . "
      						AND post.parentid = 0
      					LIMIT 1
      				");
      
      				if ($redirect)
      				{
      					// delete this
      					$redirectinfo = fetch_threadinfo($collide['threadid']);
      
      					global $countposts, $physicaldel, $delinfo;
      
      					$delinfo = array(
      						'userid' => $vbulletin->userinfo['userid'],
      						'username' => $vbulletin->userinfo['username'],
      						'reason' => '',
      						'keepattachments' => false,
      					);
      					$physicaldel = true;
      
      					$redirectforum = fetch_foruminfo($redirectinfo['forumid']);
      					$countposts = ($redirectforum['options'] & $vbulletin->bf_misc_forumoptions['countposts']);
      
      					$threadman = datamanager_init('Thread', $vbulletin, ERRTYPE_SILENT, 'threadpost');
      					$threadman->set_existing($redirectinfo);
      					$threadman->set_info('is_automated', true);
      					$threadman->delete($countposts, $physicaldel);
      					unset($threadman);
      
      					if (fetch_threadinfo($collide['threadid'], false))
      					{
      						// delete failed; don't rename back
      						$revision['title'] = $current['title'];
      						$revision['prefixid'] = $current['prefixid'];
      					}
      				}
      				else
      				{
      					// it's a regular article, don't rename this back
      					$revision['title'] = $current['title'];
      					$revision['prefixid'] = $current['prefixid'];
      				}
      			}
      		}
      	}
      In vault/dm/revision.php, find:
      Code:
      		$old['shout'] = $this->registry->options['stopshouting'];
      Add before:
      Code:
      		global $vault;
      
      		$vault->fetch_instance('field');
      		$this->info['is_island'] = ($vault->field->fetch_namespaceid($this->info['forumid']) == ISLAND_SPACE);
      Find:
      Code:
      					!$this->info['prevent_redirect'] AND
      					(
      						$this->fetch_field('title') != $this->existing['title'] OR
      						$this->fetch_field('prefixid') != $this->existing['prefixid']
      					)
      Add before:
      Code:
      					!$this->info['is_island'] AND
      Find:
      Code:
      				if (
      					$this->existing['title'] != $this->fetch_field('title') OR
      					$this->existing['prefixid'] != $this->fetch_field('prefixid')
      				)
      				{
      					require_once(DIR . '/vault/functions/data.php');
      Replace with:
      Code:
      				if (
      					!$this->info['is_island'] AND
      					(
      						$this->existing['title'] != $this->fetch_field('title') OR
      						$this->existing['prefixid'] != $this->fetch_field('prefixid')
      					)
      				)
      				{
      					require_once(DIR . '/vault/functions/data.php');
      Reply Reply  
    3. April 9, 2012 8:07 PM
      pegasus pegasus is offline
      VaultWiki Team
      The attachments becoming links after revert only occurs in two cases:
      • The attachment was added before applying the update 2.2.1 which was released March 18, 2009, OR
      • The attachment was added at the time the article was created,

      AND you attempt to rollback to the first version of the article, or a copy of that version (like a rollback to another rollback).

      I will look into what goes wrong at creation time that the record is missing, but this will require an upgrade script to fix existing articles that experience this.
      Reply Reply  
    4. April 9, 2012 10:39 PM
      pegasus pegasus is offline
      VaultWiki Team
      To fix future articles that get attachments at creation time, edit the VaultWiki plugin at hook newpost_complete. Find:
      Code:
      	$post['userid'] = $dataman->fetch_field($userfield . 'userid');
      Add after:
      Code:
      	$post['attach'] = $dataman->fetch_field('attach');
      Now to work on the upgrade script to fix already broken attachments...
      Reply Reply  
    5. April 9, 2012 11:10 PM
      pegasus pegasus is offline
      VaultWiki Team
      Upgrade script written, closing this issue.
      Reply Reply  
    6. April 9, 2012 11:44 PM
      pegasus pegasus is offline
      VaultWiki Team
      Merged the changes to VaultWiki 4, they had to be rewritten somewhat, and included an additional check for collisions when reverting a custom path. Additionally, fixed a bug where reverting these fields didn't also update the cached version of the page's path.
      Reply Reply  
    7. April 16, 2012 6:13 AM
      iMav iMav is offline
      New Member
      So, the upgrade script foo to fix the already broken attachments will exist in the upgrade to 4.x of VaultWiki? Or is this something you that can be fixed in my current install before the 4.x upgrade is released?

      (implemented all the other changes and will have my wiki authors test)
      Reply Reply  
    8. April 16, 2012 7:36 AM
      pegasus pegasus is offline
      VaultWiki Team
      No the fix will be included in the next release of VaultWiki 3.x. I just noted above that the changes also needed to be added to 4 since the bug was there also.
      Reply Reply  
    9. April 16, 2012 7:44 AM
      iMav iMav is offline
      New Member
      Ok, thanks Pegasus. I won't have any problems with the next upgrade due to the modified files will I? (I assume not but just wanted to check)

      Any idea when the next 3.x release is due out?
      Reply Reply  
    10. This petition for a change to Awaiting Feedback was rejected
      April 22, 2012 9:38 AM
      iMav iMav is offline
      New Member
      I'd love to be able to fix the the remaining attachment issues. Do you have any idea when the next version will be released so I can leverage the fix in the upgrade script? (or is this something you could provide ad hoc to run separately to fix those outstanding thumbnails?)
       
    11. This petition for a change to Awaiting Feedback was accepted
      April 26, 2012 11:17 AM
      iMav iMav is offline
      New Member
      The upgrade script does not appear to have fixed the attachments...

      http://geekhack.org/showwiki.php?title=IBM+Wiki
       
    12. April 26, 2012 5:40 PM
      pegasus pegasus is offline
      VaultWiki Team
      Was the article "missing" at the time of the upgrade? If so the script would have ignored it.
      If you go to the edit tab, are the attachments still attached there? If not, there's no way for VaultWiki to know this article ever had attachments and the script can't do anything.
      You can always run it again if you want to try again: upgrade_3x3018.php
      Reply Reply  
    13. May 22, 2012 10:29 PM
      pegasus pegasus is offline
      VaultWiki Team
      I see that a fatal error stops the upgrade script from continuing if it finds broken attachments while run under a normal upgrade environment. Since we had already run the script stand-alone we didn't see this at the time. You may have noticed it stalled, and you may have manually moved to the next step. The script is fixed in the 3.0.19 package. If you still need to fix the attachments, try manually running the 3.0.18 upgrade script by modifying the URL after going to upgrade.php.
      Reply Reply  
    14. This petition for a change to Awaiting Feedback was rejected
      June 7, 2012 8:18 PM
      iMav iMav is offline
      New Member
      Upgraded to 3.0.19 without issue...but none of the thumbnails were fixed. Not sure what to do about it.
       
    15. June 7, 2012 9:51 PM
      pegasus pegasus is offline
      VaultWiki Team
      Did you re-run the 3.0.18 upgrade as I suggested? There was a problem in the original release, but the script should work now. If it still does nothing, there is no record of the attachments in the database, so it's not possible to fix without reattaching them manually.
      Reply Reply  
    Page 1 of 2 12 Next LastLast
    + 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 5:41 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.