Issue: XF Remove Area & Category Links

When an area (or any wiki page) is deleted, it gets added to a cron-based process to remove the data. This is necessary because there can be a significant amount of connected data for each deleted page, and when performing mass deletes, the PHP process might timeout before the delete is completed.

It is possible that you are trying to re-add the same area before the cron has completed, which would give you the error message. However, it is also possible that the cron is not running at all, or that the area was never actually added to the queue. In both cases, the area would stop showing in the manager, but the data would still be there. If you have given sufficient time for the cron to run (I think it occurs during cleanup once daily), then this may be the case, and I would have to look at your database to see where it's going wrong.

Please let me know.

As for the category BB-Code being unavailable, change the Wiki Links setting for "Legacy Category Tag" so that it's a different name than your link tag. That should resolve the conflict you're having.

Well, it has been far longer than a day. Yet the old areas I deleted still seem to be in the system somewhere. I can't add an area with the same name of the ones I deleted many days ago. Is there a way I can run the cron manually so I can make sure it's either the cronjob is either not working...or perhaps not even running.

As for the category issue. I renamed the setting for it to use "group" instead. Doing so doesn't change/fix anything though. With it changed the Group and Category tags still sit there unparsed.

Quick update, I just tried running all of the Vault Wiki cron jobs manually. Before doing so, it appeared that they were running just fine, although I ran it anyways. They didn't appear to fix the area issue I'm currently having. So it would appear one of the cron jobs isn't doing their job properly. As I still can't add an area back with the name of one I've previously deleted...which isn't a huge issue to me atm, because I've decided to approach things differently. However, it's still clearly a bug and should probably be looked into.

As for the category issue, I can't seem to get it to work on XF no matter what I try. Which is really going to stop me from creating my wiki structure if I can't figure out the issue. Thus making VaultWiki useless to me.

Fixed the error with deferred deletes not working under XenForo. Only the first deferred delete ever queued would run. Further, if any errors (even notice level) occurred then the delete would automatically rollback. There is nothing we can do about the rollback behavior except to fix the errors when they appear in the logs. Currently queued deletes should eventually happen after the next update now that these issues are fixed.

I am still looking into the issue with the category BB-Code.

Any news on this issue? Still pretty stranded on what I can do without having being able to link to categories.

I added an upgrade service for you so we can update your files to the dev version and see if it will still occur in the upcoming release. You can find it in the Members area of the site.

There were some fixes made to the parser under XenForo, but it's hard to say at this point whether they correspond to the issue you're having without first applying the same fixes (they mainly had to do with " marks and conflicts with third-party custom BB-Codes).

So...you need complete access to my site in order to update it to the dev version? :/

Just want to be clear on what actual info is needed first. I really appreciate the help in addressing this issue.

In general, the only way to both confirm an issue and resolve it is to duplicate the issue so that we can see what changes to the source code will fix it. If a user experiences an issue that we are unable to replicate on our own test sites, then the only way this can be done is with access that the user provides.

If you have a test board that can duplicate the issue, then this is by far the safest place to give developers access, since the process of debugging will have little to no impact that your end-users can see. However, sometimes it is not even possible to duplicate the issue this way, or it is too cumbersome to clone the site to a test board. If access to a production board is given, users may encounter error messages site-wide for several minutes while changes are being applied. Of course, this is contingent on your site configuration, your user concurrency, and the scope of the issue being investigated. Many issues may see no side effects at all as they are fixed, and we do our best to keep side effects exposed only to a single admin account.

Most issues require at least a forum admin account (it can be a new one) or a forum account with user privileges that are able to duplicate the issue (e.g. if it only happens for certain users; however, usually still requires an admin account to see what user settings are affecting the issue). For anything beyond a misconfiguration issue (i.e. if it's a bug), then FTP access is also needed for the forum directory so that we can make changes to VaultWiki's source code. This can be a separate FTP account from the one you use, as long as it is actually able to modify the files under the forum directory (as permissions go with typical 755 or 655, it usually just needs to be the same 'group').

We do NOT really ever need direct access to the database, or to your shell, or to the root of your server.

Sounds good to me. I've added the info to the upgrade service. Hope you guys are able to get the category tag working. I can't imagine another bbcode is conflicting with it, as I've checked all the other valid bbcodes, and even changed the category bbcode to be used as something else with no luck. Can't wait to get this working so I can start building the wiki for my site and open it to the general public.

For one thing, BBM breaks VaultWiki tags. For some reason I can't understand, it clears the object callback for BB-Code tags. I guess it figures BB-Codes will only be created through BBM, but this isn't compatibility minded. The problematic code is in library/BBM/BbCode/Formatter/Base.php. It might be in other formatters too:
This breaks the reference to the class that knows how to parse wiki BB-Codes. I think it should have a method in place to determine if the tag was created by BBM before making such dramatic changes to the tag's definition. If it is clearing it for memory purposes, that's unnecessary. The value is either a string, with very small footprint, or an object reference. In PHP 5, it is not a clone object, but a reference to the same internal pointer for the object, so again, very small footprint.

Currently, because of these lines, the page will simply crash if a wiki BB-Code is used. If I comment out the above lines from BBM, the page doesn't crash and the wiki BB-Codes parse as expected. As far as I can tell, BBM still functions as expected too.

This might be the cause of your issue. Please check with BBM's author for a solution, then do your tests with the [category] tag again.

By the way, my entire test assumes you made a wiki Prefix named 'Category' (or similar) that has the BB-Code 'category' in its settings. If you are using another method to create wiki tags (and you don't want to use the WIKI tag for some reason) please let me know.

Did as suggested above, also running the newest build of VaultWiki. Although the category tag still isn't parsing when used on a page.

Please link me to an example page where the category tag is already posted and is not working. After fixing BBM on your site last time, the category tag was parsing whenever I tried it.