Issue: [file]-bbcode doesn't render any images in 4.1.7

Issue Tools
- View Changes

October 16, 2023 10:26 AM

mazzly

Junior Member

[file]-bbcode doesn't render any images in 4.1.7

After upgrading to VW 4.1.7 all the images in our pages just show a Image:name-of-file link, without any inserted image...

Images/attachments still seem to exist on the site when visiting their respective pages..

Special:UnusedImages seems to list all of our images as unused...

Issue Details

Issue Number 6389

Issue Type Bug

Project VaultWiki 4.x Series

Category BB-Code Parsing

Status Fixed

Priority 3 - Loss of Functionality

Affected Version 4.1.7

Fixed Version 4.1.8

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)

October 16, 2023 11:06 AM
pegasus

VaultWiki Team
There are a few things that the renderer looks for that can potentially cause this problem. A number of them are ruled out because it is possible to view the image at the image location.

A permissions problem: areas might not be allowing images to render inline. For the area of the page that is trying to display the image inline, check AdminCP > Wiki > Structures > Area Manager > [the area] > Parsing options > Parse the following in pages > Images.
A cache problem: images may be missing metadata. You can confirm this by editing one image such as by changing its description. If that image suddenly starts appearing after the edit, then it appears to be a metadata issue. You can rebuild metadata for en masse at AdminCP > Wiki > Maintenance > Rebuild Counters / Caches > Rebuild Content URLs.

Your images are counting as unused because they were all last edited/processed after the image stopped rendering inline. That suggests to me that you upgraded from before 4.1.6 today, because the 4.1.6 upgrade recaptured all usages without waiting for manual page updates. Please provide the version number you upgraded from, as this might give a clue as to why your images stopped rendering prior to 4.1.6.
Reply
October 16, 2023 11:22 AM

mazzly

Junior Member

1. That was not it
2. Editing an image then it starts working, however doing the Rebuild content URLs doesn't fix it for remaining images..

Updated from 4.1.5 Build 2

Reply
October 16, 2023 11:29 AM

mazzly

Junior Member

btw, should the upgrades be done in steps? It seems that upgrading from 4.1.5 to 4.1.7 hasn't worked correctly?

Reply
October 16, 2023 11:57 AM

mazzly

Junior Member

Interestingly, when I restored a fresh dump locally in docker to test upgrading my XF install, the Wiki images don't seem to have this problem... Weird...

Reply
October 16, 2023 11:59 AM

mazzly

Junior Member

Okay the reason local worked, was because I switched the "Wiki base URL" to be http://localhost, which seems to have rebuilt things..

On my live site I then edited "Wiki base URL" to be http:// variant, and then back to https:// and it seems to have fixed the images

Reply
October 16, 2023 12:09 PM

pegasus

VaultWiki Team

Thanks for this information. I was able to reproduce the problem of image metadata disappearing after using Rebuild Content URLs on my test site. I will let you know once I find the cause.

Reply
October 16, 2023 12:10 PM

mazzly

Junior Member

Actually, now that you mention it I think images were working initially after ugprade (I recall checking that) but then at some point stopped, and I did actually rebuild the Content URLs...

Reply
October 16, 2023 12:11 PM

mazzly

Junior Member

btw, should I file a new bug for the Special:UnusedImages bug or ? It still seems to show all our images as unused...

Reply
October 16, 2023 12:49 PM

pegasus

VaultWiki Team

I don't think so. I think that is just an unfortunate side effect of counting your image uses while the images weren't rendering. Once I figure out why Rebuild Content URLs does this, we should be able to use it to count the images again.

Reply
October 16, 2023 1:53 PM
pegasus

VaultWiki Team
After fetching a page, it gets cached for the next time you may want to fetch it. However, when fetching an attachment as a page, there is an additional lookup that takes place to also pull the attachment data. This also gets added to cache, but the entry ID doesn't match. So when you fetch it the second time, the attachment data is not in the expected entry. During Rebuild Content URLs, it first fetches all the pages in the batch to reduce queries. Then it cycles all the IDs in that batch and fetches them from cache in order to work on each one at a time. Since the working copy is missing the attachment data, when the content gets saved, the metadata is now missing some attachment information.

In 4.1.7, the cache structure was changed because some information in the cache is user-specific, and it was possible to pull that data for the wrong user in previous versions. However, the cache structure change was not applied to one path for creating cache entries, leading to the issue of an incorrect entry ID for some page-types.

In src/addons/vw/vw/_core/controller/fetch/vw.php, find:

Code:

$this->verify_retval($node, $retval);

Replace with:

Code:

$this->verify_retval($node, $retval, $withVisitor);

Find (2x):

Code:

array_pop($this->doers);

Replace with (2x):

Code:

//array_pop($this->doers);

Find:

Code:

public function verify_retval(&$node, &$items)

Replace with:

Code:

public function verify_retval(&$node, &$items, $withVisitor = true)

Find:

Code:

$doer->verify_retval($this, $node, $items);

Replace with:

Code:

$doer->verify_retval($this, $node, $items, $withVisitor);

In src/addons/vw/vw/_core/controller/fetch/stack/vw.php, find:

Code:

public function verify_retval(&$caller, &$node, &$items)

Replace with:

Code:

public function verify_retval(&$caller, &$node, &$items, $withVisitor = true)

Find (2x):

Code:

$caller->set_itemcache($node, $item);

Replace with (2x):

Code:

$caller->set_itemcache($node, $item, $withVisitor);

Find:

Code:

$tmp = $this->fetcher->get_doer($stack_node['accesskey'])->stack_info( $stack_node['table'] == 'page' ? '' : $prep['p']['fields']['pageid'], true );

Replace with:

Code:

$tmp = $this->fetcher->get_doer($stack_node['accesskey'])->stack_info( $stack_node['table'] == 'page' ? '' : $prep['p']['fields']['pageid'], true, $withVisitor );

In src/addons/vw/vw/_core/controller/fetch/index/vw.php, find:

Code:

public function verify_retval(&$caller, &$node, &$items)

Replace with:

Code:

public function verify_retval(&$caller, &$node, &$items, $withVisitor = true)

After making these changes, I was able to run Rebuild Content URLs without losing attachment metadata. You can modify Rebuild Content URLs to additionally count all the links/usages in the content. In src/addons/vw/vw/_core/model/cron/deferred/settings/url/vw.php, find:

Code:

$itemdm->set_info('skip_links', 1);

Replace with:

Code:

//$itemdm->set_info('skip_links', 1);

When you are done, you may wish to change this line back, as it makes the tool do a LOT more work.
Reply
October 17, 2023 1:00 AM

mazzly

Junior Member

Did the above changes + the skip_links one...

Rebuild works without breaking [file] images (i.e. they are still showing correctly)

But all images are still listed as unused under Special:UnusedImages

Reply
October 17, 2023 1:02 AM

mazzly

Junior Member

Also, updating a page that references images, doesn't make the images being marked as "used", they still show up in the Special:UnusedImages page...

Reply

+ Reply

All times are GMT -4. The time now is 2:39 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

Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

Issue: [file]-bbcode doesn't render any images in 4.1.7

Issue Tools