FrankPereiro
Active member
Hi there, I just bought the add-on but I can't get it to work, all I get are a bunch of errors. Is there an instructions file or something like that where I can setup the wiki in my board? Thanks...
Please beware that if you are using any version of VaultWiki acquired before June 1, 2023, if you have or will update to the newest XenForo version 2.2.13, you may experience fatal showstopper issues on your site while using VaultWiki, due to incompatible code changes introduced in that XenForo release, specifically while XenForo's debug mode is active.
We have now patched the issue from our end. We strongly recommend that any users running VaultWiki who also plan on upgrading to XenForo...
Make your tutorials as chapters of a "book" and it will handle Next / Previous links like this.What about adding a link to the bottom where they can click next page or previous page? If someone is reading tutorials it's kind of an inconvenience for them to have to back out and scroll down to the next one.
Tried, and getting this error now-Please do not batch install VaultWiki. It takes multiple browser refreshes to batch install it, which can cause issues like this. Instead, you should follow the installation instructions here: https://www.vaultwiki.org/pages/Help/VaultWiki-4-Manual/VW4:Installing-VaultWiki
entity
content type field is implemented as a full class path (or points to a class which can't be autoloaded) which breaks \XF::finder("Addon:ShortName")
and attempting to call \XF::em()->getEntityStructure("Addon:ShortName")
would just break with class loader exceptions.rebuildContentReactionCache
to force a rebuild in cases where this is requested by admins, with code the is semantically equivalent to:$structure = null;
try
{
$reactHandler = \XF::repository('XF:Reaction')->getReactionHandler($contentType, false, $isLike);
if (!$reactHandler)
{
$entityName = $this->app->getContentTypeEntity($contentType, false);
if ($entityName)
{
$structure = $this->app->em()->getEntityStructure($entityName);
}
}
}
catch(\Exception $e)
{
\XF::logException($e, true, 'Broken reaction implementation for content-type; ' . $contentType);
return;
}
...
\XF::repository('XF:Reaction')->rebuildContentReactionCache($contentType, $id);
$structure
, and use XF's finder to load each entity and then pass extract the ID to rebuildContentReactionCache
Why is the add-on Content Ratings trying to apply ratings to another add-on's content-type when that content-type doesn't have a rating handler class? Unless it has a rating handler class, having a rating for a vwattachedit doesn't make much sense in a generic ratings sense, just based on what that content-type actually refers to.
In general VaultWiki, does not provide "entity" values except in rare circumstances, because the content-type data must be retrieved in a specific way, especially for history-based content types. Again, that's why we implement handler classes for each content-type, where we implement a function, such as reactions, tags, etc.
TLDR; If Content Ratings is going to magically handle content-types without those content-types having a "Content Ratings" handler class, and it is assuming that various other content-type fields exist, like it assumes "entity" exists, it can avoid errors like this by checking if all those values exist for the content-type, before trying to implement its rating system on those content-types. This is a bug in the Content Ratings add-on.
VaultWiki provides its own rating system with a special handler for history-related content-types. It is unlikely another add-on would apply its own ratings in anywhere near an expected manner (history ratings are weighted over time, against other history types, consider various flags, and contribute to the overall page rating).
VaultWiki content-types are not compatible with SV Content Ratings. Please do not enable SV Content Ratings support for those content-types. VaultWiki content-types already have their own ratings if you need similar functionality.
VaultWiki content-types have a reaction implementation that is not broken, using the classes and methods in its implementation, which follows XenForo's design of allowing for various implementations. But SV Content Ratings is trying to shoehorn a generic implementation instead, which will of course fail. This has been reported before years ago (by you it seems), but it seems like SV Content Ratings may not have taken the suggestions seriously.
- If SV Content Ratings is in the business of interacting with other add-ons, SV Content Ratings should not assume that any add-on has a generic implementation. Assumptions like this create conflicts. If they are attempting to use a content-type field value, they should check if it exists first and not attempt any operations on a content-type that is missing a field they require.
- SV Content Ratings should not automatically enable for any content-type. Just like other XenForo features (like reactions), a content-type should have to provide a handler_class for SV Content Ratings. Again, XenForo doesn't just automatically add reactions to a content-type and assume it to work without input from the coder of the content-type, so why does SV Content Ratings do that for its ratings?
Yeah, this is the same error message as before, and it is caused when an add-on like Xon's assumes that another add-on's content-type "entity" field is safe to use however they want. In VaultWiki, this field is only intended to be used for type-hinting in XenForo's default Tag\Changer service. All other default uses of this field are inside content-type field handlers, and VaultWiki writes its own handlers.
Xon's add-on is ignoring the fact that VaultWiki and other add-ons might implement custom handlers for search, which leads to an error in VaultWiki.
I believe it would be possible for Xon's add-on to avoid this issue by:
- When finding the entity field, also compare the content-type's search handler. If the search handler is using the default XenForo method for ::getContent, then it is safe for Xon to implement their method. If the search handler is using a non-default method for ::getContent, then it is unsafe for Xon to implement their method, and they should fall back to the search handler's custom method instead.
entity
content type field to point at a valid entity with a working getStructure
static method.Translation: "I don't know how to code for XenForo and the only reason my add-on is available in the Resource Manager is that the add-on policy isn't proactively enforced"If SV Content Ratings is in the business of interacting with other add-ons, SV Content Ratings should not assume that any add-on has a generic implementation. Assumptions like this create conflicts.
Hahah point taken, but in my defence, I'm not personally affected by this add-on so I'm here mostly for moral supportThe resource standards are there for a reason, and in cases where it is believed that an add-on is not following resource standards, this can be reported to us so we can investigate.
In other words, it shouldn't rely on a XF developer happening upon reports in the course of browsing the forum
I'm struggling to understand how any other add-on can generate a conflict if you provide aVaultWiki had to remove "entity" field values because of a conflict with one add-on. Then another add-on has a conflict because we removed "entity" field values. Unfortunately it's a no-win situation for us.
getStructure()
function in your entities, which is what I presume you're referring to when you say "entity field values". Could you please elaborate?I'm pretty confident in categorically saying there's no use case where you need to extend any of the following entity functions due to "order of steps":However, we are unable to use several standard methods for writing due to "final" designations and the order of steps that take place within those "final" methods. Still, writes do go through the entity process, just with a few custom methods which are accessed through a wrapper class. Because this wrapper must be used and there were prior add-on conflicts, we no longer provide the "entity" content type field value. So regarding the XenForo standards, we never saw VaultWiki as at odds with #7, as it is currently worded (we also noted the "should" language compared to "must" language elsewhere). If you are aware of another way that VaultWiki may not be meeting minimum resource standards, please specify and I would be glad to address the issue.
toApiResult
- extend setupApiResultData
insteadsave
- extend _preSave
, _fillDeferredValues
, _validateRequirements
, _saveToSource
or _postSave
as neededsaveIfChanged
- don't call this method if you need to inject new values on save.preSave
- extend _preSave
delete
- see preDelete
belowpreDelete
- extend _preDelete
or _postDelete
as needed_postSave
or _postDelete
due to reasons, don't forget about \XF::runLater()
. That'll cause your code to run closer to the end of the current script - right before shutdown I believe. Or, you could defer to a job using \XF::app()->jobManager()->enqueueUnique()
. If you need jobs to run in order, you can have the job run a Service that uses \XF\MultiPartRunnerTrait
. Or you can use XF:Atomic
as the job runner to ensure the jobs are ran in order.VaultWiki contains what I can most accurately describe as a platform-agnostic external library that contains most of the instruction sets, similar to code in XenForo's vendor libraries. This library includes the code for how wiki data is saved. Using library hooks and library class extensions, it becomes possible to do things like: make the library use XenForo's database adapter, make the library use XenForo string manipulation, etc. In the example that's currently under discussion, this allows for the following code sequence:But perhaps I'm just ignorant, what is it about VW that's so special it can't use any of these methods to work within the normal entity system?
With that context, I can answer this question better.I'm struggling to understand how any other add-on can generate a conflict if you provide a getStructure() function in your entities, which is what I presume you're referring to when you say "entity field values".
I don't see any reports from you within the last two years, nor any reports from you that were not resolved. So I'm confused by your first statement. If you have an issue, it needs to be reported otherwise we can't do anything about it.Since this add-on hasn't worked properly for ages and I simply stopped caring about it, I wanted to uninstall it after this debacle. However... lol
ErrorException: [E_WARNING] Trying to access array offset on value of type bool in src\addons\vw\vw\_core\model\area\xf2.php at line 27
if (!$area['parentid'])
if (!$area)
{
continue;
}
return \vw_Hard_Core::model('Area')->tree();
if (defined('VW_UNINSTALL'))
{
return new \XF\Tree([], 'parentid', 0);
}
I've tried maintaining such a code base in the past, and it's pretty cursed. It's no wonder you run into these kinds of issues. Does vBulletin even have a large enough market share in 2024 for you to warrant continuing this? I understand the concept of not fixing what isn't broken, but it's reasonable to say that if you haven't already, you're at some point going to hit a point where you're spending more time fixing bugs that would never occur if your code was "fully native".VaultWiki contains what I can most accurately describe as a platform-agnostic external library that contains most of the instruction sets, similar to code in XenForo's vendor libraries. This library includes the code for how wiki data is saved. Using library hooks and library class extensions, it becomes possible to do things like: make the library use XenForo's database adapter, make the library use XenForo string manipulation, etc.
That's not an issue at all, I think you might be misunderstanding the fundamental concept ofOne sore point with entity->save, from what I remember (it's been many years since the entity code was first written), was that the library expects preSave and save code to be decoupled.
preSave()
. Its purpose is to provide last-minute validation as well as being able to set certain values. For example, you may do something like this in _preSave()
:if ($this->isUpdate())
{
$this->last_update_date = \XF::$time;
}
else
{
$this->creation_date = \XF::$time;
}
_preSave()
for anything else, you're misusing it and that code should be running outside of the entity.It's very much intended for third parties to manipulate an entity even if they don't know everything that goes on inside the entity, and no one is against this behaviour. For instance, if your Page entity doesn't provide a view counter, someone might add that feature and add aHowever, I had thought it was fair to say (until seeing the ire in this thread) that no one wants third-parties manipulating an entity if they don't know what's going on inside that entity. An add-on can generate a conflict if they use getStructure to see an add-on's database columns, and that add-on then makes changes to the column outside the normal operation of that entity, especially without even looking at how that entity operates first. In particular, this can cause issues when dealing with wiki entities, where many changes are supposed to be stored in history.
view_count
or similar column to your entity. 3rd party addons that extend other 3rd party addons are commonplace.dbtech_vwe_view_count
for "DragonByte Tech: VaultWiki Extended" to avoid conflict should XenForo/yourself add the feature in a future update.TheWhen I refer to "entity field values", I am talking about the specific content-type field, stored in xf_content_type_field, which has "entity" as its key. VaultWiki doesn't need this key defined for any of its entities to function, especially since VaultWiki knows the names and paths of its own entities. But other add-ons tended to find this key and do things to VaultWiki entities, some of which caused data issues, some of which caused errors. So we removed the "entity" entries from that database table.
entity
field is required for certain kinds of content type definitions, such as alert_handler_class
, approval_queue_handler_class
and, indeed, reaction_handler_class
.entity
field in src/XF/Reaction/AbstractHandler.php:123
:$entityType = \XF::app()->getContentTypeEntity($this->contentType, false);
entity
field, run the following searches in the src/XF
folder:->findByContentType(
->getContentTypeEntity(
entity
field for Reactions, I'd advise you to check if you're using any of these other content types, and make sure they define an entity
field as well, to avoid this issue cropping back up in the future The conflict was because fetching the entity definition corresponding to the search handler throws an exception.I want to point out that one of the third-party add-ons quoted above by Xon, was a search add-on that (and I'm going from memory of events years past) allegedly scraped all content-types with a search_handler_class and automatically replaced their search_handler_class::getContent method with the search add-on's own function, without a human checking if this would be safe to do.
\XF::app()->getContentTypeEntity
, \XF::app()->em()->getEntityStructure
and then \XF::app()->em()->findCached()
it is basically a copy of the stock getResultSetData
logic wise.We use essential cookies to make this site work, and optional cookies to enhance your experience.