• 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 4.x Series
    • Bug
    • [4.1 Beta 4] XF2.x user_content_change_init code event listener does not update username in database while VW is enabled (Impacts XF and addons)

    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: [4.1 Beta 4] XF2.x user_content_change_init code event listener does not update username in database while VW is enabled (Impacts XF and addons)

    • Issue Tools
      • View Changes
    1. issueid=5912 October 28, 2019 10:47 AM
      ACL ACL is offline
      Regular Member
      [4.1 Beta 4] XF2.x user_content_change_init code event listener does not update username in database while VW is enabled (Impacts XF and addons)

      With VaultWiki 4.1 Beta 4 b004 enabled, XenForo is not updating usernames in content related tables, such as xf_post, xf_news_feed plus any applicable addon tables. The service does update the username column (\XF\Service\User\ContentChange) for any applicable tables while VaultWiki is disabled.

      I first noticed odd behaviour in my own custom addon which on my test site ended up with stale usernames even though that it implements the user_content_change_init code event listener.

      On the front end, it is particularly noticeable for entries in "Latest activity" (What's new) where stale usernames may be encountered, e.g. for XFMG:
      ACL reacted to OldUsername's media
      Hopefully this is an easy fix that can be addressed for this release (in current or new build) . I had planned to upgrade my public site today or tomorrow, prior to discovering the stale username issue.
    Issue Details
    Issue Number 5912
    Issue Type Bug
    Project VaultWiki 4.x Series
    Category General
    Status Fixed
    Priority 1 - Security / Login / Data Loss
    Affected Version 4.1.0 Beta 4
    Fixed Version (none)
    Milestone (none)
    Software DependencyXenForo 2.x
    License TypePaid
    Users able to reproduce bug 0
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users (none)
    Tags (none)




    1. October 28, 2019 11:52 AM
      ACL ACL is offline
      Regular Member
      Official addon XFMG implements the user_content_change_init event listener. A fragment of XFMG's Listener.php:
      Code:
      	public static function userContentChangeInit(\XF\Service\User\ContentChange $changeService, array &$updates)
      	{
      		$updates['xf_mg_album'] = [
      			['user_id', 'username'],
      			['last_comment_user_id', 'last_comment_username']
      		];
      I see that VaultWiki extends the ContentChange service class instead. Is the above code event approach unsuitable for VW? There are some details about it in an XenForo.com post.

      Edit: Maybe something like (hypothetically, untested)...
      Code:
      	public static function userContentChangeInit(\XF\Service\User\ContentChange $changeService, array &$updates)
      	{
      		$updates['vw_page'] = ['creatorid', 'creatorname'];
      		$updates['vw_revision'] = ['userid', 'username'];
      		$updates['vw_discussion'] = ['userid', 'username'];
      		$updates['vw_comment'] = ['userid', 'username'];
      		$updates['vw_report'] = ['userid'];
      		$updates['vw_feed'] = ['userid', 'username'];
      		$updates['vw_feeditem'] = ['userid'];
      		$updates['vw_attachmentedit'] = ['userid', 'username'];
      		$updates['vw_attachmentfile'] = ['userid'];
      		$updates['vw_categoryitem'] = ['userid'];
      		$updates['vw_chapter'] = ['userid'];
      		$updates['vw_teamitem'] = ['userid'];
      		$updates['vw_langitem'] = ['userid'];
      		$updates['vw_langevent'] = ['userid'];
      		$updates['vw_pollvote'] = ['userid'];
      		$updates['vw_rate'] = ['userid'];
      		$updates['vw_redirect'] = ['userid', 'username'];
      		$updates['vw_likes_collect'] = [
      			['userid'],
      			['likerid']
      		];
      		$updates['vw_demand'] = ['userid'];
      
      	}
      Reply Reply  
    2. October 29, 2019 12:25 PM
      pegasus pegasus is offline
      VaultWiki Team
      It's not that the code event listener approach is unsuitable for VW, but we need to override the __construct method anyway (where the default __construct method would invoke any listener), so adding the $updates in the same method is more efficient than having a separate listener that also needs to be evaled.

      Fixed the issue with the stepReassignContent method not being executed. In src/addons/vw/vw/XF/Service/User/ContentChange.php, find:
      Code:
      if ($key)
      Replace with:
      Code:
      if ($key !== false)
      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:22 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 © 2025 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2025 DragonByte Technologies Ltd.
    Copyright © 2008 - 2024 VaultWiki Team, Cracked Egg Studios, LLC.