VaultWiki [Paid] 4.1.7 Patch Level 1

[pegasus]

Right, but as mentioned, the IDs from that handler potentially point to multiple content-types. If you filter already loaded wiki entities on that ID, you might actually be filtering an entity from the wrong content type. The entities returned by getContent are the real content entities which have a different content type and entity IDs, than the IDs in the index which are aggregate pointer IDs.

If your description is accurate though, this might be safe if the wiki search_handler_class is actually associated with an entity that points to the aggregate table rather than its current association of no particular entity, and if the filtering of IDs does so based on the search index contents prior to getContent and not based on any resulting entities from getContent.

 

[DragonByte Tech]

If your description is accurate though, this might be safe if the wiki search_handler_class is actually associated with an entity that points to the aggregate table rather than its current association of no particular entity, and if the filtering of IDs does so based on the search index contents prior to getContent and not based on any resulting entities from getContent.

Yeah, since XF's search system doesn't currently support searching on multiple content types (other than "Everywhere" search), pointing to the IDs of the aggregate table is indeed the correct way to do this

 

[Xon]

Yeah, since XF's search system doesn't currently support searching on multiple content types (other than "Everywhere" search), pointing to the IDs of the aggregate table is indeed the correct way to do this

It actually does support rendering multiple content types from search results when triggered from a single search handler. That is how post/thread bits work. It just needs a separate search handler per unique search result type. A search handler also allows grouping by another search result type.

On the search query side, you are adjusting the list of types being searched via Query::inTypes().

This is what my free Report Improvement addon does with making Reports/Report Comments/Warnings searchable all with different backing XF entities.

 

[pegasus]

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 a view_count or similar column to your entity. 3rd party addons that extend other 3rd party addons are commonplace.

Going by your example, my complaint was more about a theoretical add-on that provides a view_count column to all entities matching xf_content_type_field "entity", even though some entities may already provide a view_count. I'm perfectly fine with an add-on that specifically modifies another add-on.

On another note, while investigating this issue further, it seems like the difference of our preSave/save methods actually had little to do with order-of-steps or decoupling, but rather there are some entities which are in need of extra try/catch blocks. It looks like a lot of the way it's done can be reworked nowadays. It may just be leftover from early XenForo 2 betas. Some of the use cases are a bit weird so I'll wait to see how it goes.

The other issue of course is making sure the entities develop their library references properly when created outside the library and running the outer library functions when a third-party uses entity functions directly, but this seems doable. To avoid a lot of circular logic, I am leaning towards a concept of public and private entities such that a PublicEntity is a wrapper for an internal PrivateEntity. PrivateEntity contains all the library-related logic. PublicEntity has access to all the PrivateEntity structure and properly maps/delegates the library functions, and it's the PublicEntity that actually gets returned by finders and is listed as the xf_content_type_field "entity". Thoughts?

To be honest, I've been wanting to move to native XenForo 2 code for a while now. But the real problem is the sheer amount of time it will take to properly rewrite and test 400,000+ lines of code across ~6k PHP files, even if it was the only thing being worked on. It cannot happen overnight (how soon can you release it as an update?) Some people forget that writing this library has been an ongoing process going back to 2010, and that it's a massive product. It took over 2 years for that smaller version of the library to release and another 2 before it was anywhere near stable. If you compare to XenForo development, I doubt anyone expected that XenForo 1 to XenForo 2 development could take place in a matter of days or weeks. So for now, we'll improve compatibility where we can, but a full rewrite is not quite in the cards.

 

[Alpha1]

Vaultwiki has evolved from being the NuWiki successor and a vbuletin addon at first , to a multi platform for vbuletin, xenforo and almost IPS. As I have watched it evolve and see many of my suggestions materialize, I know it's massive and s rewrite would be insane and it's understandable that it's simply not on the cards.

However, Vaultwiki with all the effort that has gone into it and the stellar support that you offer, will always have significant issues. Every new release resolves a mass of issues and introduces many new. Or at least many new are encountered upon upgrade or installation. It will never just work.

As it's not native, it's alien to users (Vaultwiki was created to avoid exactly this) and to admins. This results in a low adoption by webmasters and therefore issues fly under the radar.

We also live in different times now. People are much easier confused and demand better integration and easier interface. The times are gone when we had a mass of power users writing wiki articles in clunky interface. People barely understand how to post to a thread now. Forget about having them use a alien complex legacy interface.

A native wiki with would be a popular addon, which would likely be a worthwhile effort.
I do think that @DragonByte Tech has a good point. Compare the massive effort of supporting thousands of bug reports, investigating, providing fixes, helping customers and implementing the fix. Is this what you want to do for the next ten years?

There is little point in continuing support for vbuletin, so it's all xenforo anyhow.

 

[Alpha1]

I updated the above.

Another thing to consider is that the issues that an upgrade to a new version brings, does put admins off. Some try Vaultwiki out, encounter issues and opt not to use the software. Others get tired of it and move away from it.

I may be wrong but it seems to me that the number of websites using Vaultwiki is declining and will keep declining. This does not seem a good direction.

 

[DragonByte Tech]

Going by your example, my complaint was more about a theoretical add-on that provides a view_count column to all entities matching xf_content_type_field "entity", even though some entities may already provide a view_count. I'm perfectly fine with an add-on that specifically modifies another add-on.

With the vendor prefixing I mentioned (which is part of the resource standards as well), there won't be a problem with an addon blanket modifying all xf_content_type_field entities, as long as the column being added has a sufficient default value in the database, which wouldn't be your problem or responsibility anyway

To be honest, I've been wanting to move to native XenForo 2 code for a while now. But the real problem is the sheer amount of time it will take to properly rewrite and test 400,000+ lines of code across ~6k PHP files, even if it was the only thing being worked on. It cannot happen overnight (how soon can you release it as an update?) Some people forget that writing this library has been an ongoing process going back to 2010, and that it's a massive product. It took over 2 years for that smaller version of the library to release and another 2 before it was anywhere near stable. If you compare to XenForo development, I doubt anyone expected that XenForo 1 to XenForo 2 development could take place in a matter of days or weeks. So for now, we'll improve compatibility where we can, but a full rewrite is not quite in the cards.

I feel you on that, even though my addons were quite a bit smaller (the old universal_<addonName> folders have about 135 files each) it was still quite the undertaking I can promise you it's worth it, though. Like @Alpha1 says, people will generally prefer addons that look & feel native.

It might be an idea to make the switch piecemeal? Break each part of the addon down into sections (I haven't looked at the code at all), and port small parts into native XF code as you go. Each time there's a bug report in a specific section, that section can be ported to native XF code. Even if it means duplicating some code between the library and native XF, it would make the process way less daunting and much easier to test

Tooting my own horn for a moment; eCommerce and Social Groups in particular integrate with a lot of XenForo features in about as straightforward of a way as possible - I'd be happy to send you copies and give you permission to copy anything you need if it would aid the rewrite process

 

[pegasus]

Order-of-steps issue in entity located -- XF\Mvc\Entity\Entity :: delete

We have code that must be run inside the transaction, before the entity data is removed from the database. With save(), this is easy to do by extending _saveToSource. But delete() has no corresponding _deleteFromSource (the db->delete is hardcoded inside the "final" delete), so it seems for now, VaultWiki cannot use the standard delete() method. It will continue to throw a LogicException if someone calls delete on a wiki entity.

 

[pegasus]

To recap, in the next release:

- Wiki content entities that use handlers such as alert_handler_class, reaction_handler_class, search_handler_class, that had an abstract handler that used the "entity" content type field, even though such a method may have been extended in the wiki handler, will now have an "entity" content type field which points to a vw\vw EntityPublic unique to that content-type (there are 11 such entities in total). This also allows add-ons to use a finder without having to know anything about the underlying library.

- vw\vw EntityPublic ensures that getStructure returns statically an up-to-date list of the underlying wiki entity's structure, without having to knowingly load library references or go through a separate wrapper function. Otherwise, the EntityPublic is actually a wrapper for the underlying wiki entity (set/_preSave/_saveToSource etc) so updates should be safe without corrupting the wiki data. Deletes are still blocked in _preDelete due to an absence of methods to override. However, even though many of these methods will work, the EntityPublic should be treated as existing for informational purposes (mainly reading structure).

Since VaultWiki itself still uses the underlying entities, it is recommended that EntityPublic is only used for changes that an add-on will maintain through their own code, in a separate class such as a controller or service, and that would be safe if untouched during most saves. If maintenance code is needed inside the entity, a developer should specifically make an add-on for VaultWiki that extends the underlying data classes, rather than the EntityPublic. It's the same extra step that was always there.

 

[pegasus]

pegasus updated VaultWiki with a new update entry:

4.1.7 Patch Level 1

(announced here: https://www.vaultwiki.org/articles/307/)
Among the relevant issues in the patch that affect XenForo 2 users:

• An issue installing VaultWiki involving 4.1.7's compatibility update for XenForo 2.2.13
• An issue uninstalling VaultWiki when there are wiki moderators who are not also forum moderators
• An issue where the form for editing custom area permissions for guests was unavailable

Read the rest of this update entry...