Issue: 404 when retrieving wiki assets

Issue Tools
- View Changes

August 29, 2019 5:07 PM

SeToY

Junior Member

404 when retrieving wiki assets

Upgraded from VaultWiki 4.0.25 -> 4.1.0 Beta 2 (actually I downloaded Beta 3, but as indicated in this ticket, the version string seems to be invalid) on XF 2.1.3 (updated from XF 1.5).

When viewing a page within an area, no images are shown. Google Dev console shows 404:

Code:

Page-Title:4821 GET [url]https://proddomain.com/js/vw/vw/y/yui/yui-min.js?v=3.18.1[/url] net::ERR_ABORTED 404
Page-Title:4823 GET [url]https://proddomain.com/js/vw/vw/xf2/base.js?v=0ea8f30f[/url] net::ERR_ABORTED 404
Page-Title:4822 GET [url]https://proddomain.com/js/vw/vw/base.js?v=0ea8f30f[/url] net::ERR_ABORTED 404
(anonymous) @ Page-Title:4746
(anonymous) @ Page-Title:4746
(anonymous) @ Page-Title:4749
Page-Title:4862 GET [url]https://proddomain.com/js/vw/vw/search.js?v=0ea8f30f[/url] net::ERR_ABORTED 404
Page-Title:4821 GET [url]https://proddomain.com/js/vw/vw/y/yui/yui-min.js?v=3.18.1[/url] net::ERR_ABORTED 404
Page-Title:4863 GET [url]https://proddomain.com/js/vw/vw/xf2/search.js?v=0ea8f30f[/url] net::ERR_ABORTED 404
Page-Title:4822 GET [url]https://proddomain.com/js/vw/vw/base.js?v=0ea8f30f[/url] net::ERR_ABORTED 404
Page-Title:4823 GET [url]https://proddomain.com/js/vw/vw/xf2/base.js?v=0ea8f30f[/url] net::ERR_ABORTED 404
Page-Title:4826 Uncaught ReferenceError: vw_Hard_Core is not defined
    at Page-Title:4826
(anonymous) @ Page-Title:4826
Page-Title:4867 Uncaught ReferenceError: vw_Hard_Core is not defined
    at Page-Title:4867
(anonymous) @ Page-Title:4867
Page-Title:4876 Uncaught ReferenceError: vw_Hard_Core is not defined
    at Page-Title:4876
(anonymous) @ Page-Title:4876
Page-Title:4871 GET [url]https://proddomain.com/js/vw/vw/feed.js?v=0ea8f30f[/url] net::ERR_ABORTED 404
Page-Title:4872 GET [url]https://proddomain.com/js/vw/vw/xf2/feed.js?v=0ea8f30f[/url] net::ERR_ABORTED 404
Page-Title:4862 GET [url]https://proddomain.com/js/vw/vw/search.js?v=0ea8f30f[/url] net::ERR_ABORTED 404
Page-Title:4863 GET [url]https://proddomain.com/js/vw/vw/xf2/search.js?v=0ea8f30f[/url] net::ERR_ABORTED 404
Page-Title:2994 GET [url]https://proddomain.com/wiki-asset/?pid=73&d=1513007524&x=941[/url] 404
Page-Title:3022 GET [url]https://proddomain.com/wiki-asset/?pid=66&d=1513000256&x=908[/url] 404
Page-Title:3047 GET [url]https://proddomain.com/wiki-asset/?pid=67&d=1513000308&x=555[/url] 404
Page-Title:3098 GET [url]https://proddomain.com/wiki-asset/?pid=69&d=1513000398&x=641[/url] 404
Page-Title:3072 GET [url]https://proddomain.com/wiki-asset/?pid=74&d=1513018250&x=667[/url] 404

The domain shown (also in the log) is the production domain and not my test domain. I have, of course, changed the Wiki Base URL in the VW and XF options.

I don't know how the ID is assigned, but for example for ?pid=67 there are files inside this folder:

Code:

\internal_data\vw_attachments\6\7\47

Code:

180.vw
full.vw

Issue Details

Issue Number 5829

Issue Type Bug

Project VaultWiki 4.x Series

Category Unknown

Status Not a Bug

Priority 3 - Loss of Functionality

Affected Version 4.1.0 Beta 2

Fixed Version (none)

Milestone (none)

Software DependencyAny

License TypePaid

Users able to reproduce bug 0

Users unable to reproduce bug 0

Attachments 0

Assigned Users (none)

Tags (none)

September 4, 2019 1:20 PM

pegasus

VaultWiki Team

It is also complaining that a number of Javascript files do not exist. You should check that they actually exist on your server. If they do exist, then it seems like certain directory locations are not publicly accessible via the browser.

Reply
September 4, 2019 2:53 PM

SeToY

Junior Member

That's the point. It's looking for them at the wrong domain although I changed the domain name in the XF and VW options.

The domain shown (also in the log) is the production domain and not my test domain. I have, of course, changed the Wiki Base URL in the VW and XF options.

Reply
September 4, 2019 3:57 PM

pegasus

VaultWiki Team

Have you also set the following to the test domain, or at least left it blank?
- Options > VaultWiki: Site Config > Wiki CDN URL

Reply
September 4, 2019 4:09 PM

SeToY

Junior Member

Yup, that is empty.

Reply
September 4, 2019 4:16 PM

SeToY

Junior Member

I investigated the database a bit. The vw_parsed table contains pagetext_html that features the old url in its data-url attribute values. I don't know if this correlates to the issue or not.

Reply
September 4, 2019 5:14 PM
pegasus

VaultWiki Team
When the CDN URL is not set, the resources would normally be loaded from the main domain for the site, as defined by Options > Basic board information > Board URL. But if we detect that the current domain (HTTP_HOST) is not actually that domain, then we will assume that HTTP_HOST correctly reflects the domain we are currently visiting, and we will load the resources from that domain instead (this avoids the need for a cross-domain policy). If your Board URL is the test domain as you have said, then I suspect that your HTTP_HOST is reporting the production domain rather than the test domain. This might be due to a server configuration issue. You can confirm by uploading a test.php like this and visiting it:

Code:

<?php echo 'Current Domain: ' . $_SERVER['HTTP_HOST']; exit;

EDIT: You shouldn't need to fix it if you set the Wiki CDN URL to your test-domain (you said it was blank).
Reply
September 4, 2019 5:40 PM
SeToY

Junior Member
My production domain looks like this:

Code:

board.domain.com

My test domain looks like this:

Code:

testboard.domain.com

When executing the code above, it in fact returns testboard.domain.com correctly.

Options -> Basic Board Information -> Board Url

Code:

[url]http://testboard.domain.com[/url]

Options -> Basic Board Information -> Index page route

Code:

ewr-porta/

Options -> VaultWiki: SiteConfig -> Wiki Base URL

Code:

[url]http://testboard.domain.com[/url]

Options -> VaultWiki: SiteConfig -> Wiki CDN URL

Code:

<empty>

I might add that this is under IIS10, not Apache or Nginx. Maybe that has something to do with it. Of course the values are entered without [URL]... dunno why this board adds this inside code tags.

I then added http://testboard.domain.com as the Wiki CDN URL but I still get the same 404 errors. I've got a hunch that this might have something to do with my mentioned data-url tags in pagetext_html of the vw_parsed table. Manually fixing the links in the DOM works flawlessly and displays the images (or rather: returns it in the browser when browsing directly).

A single img element looks like this:

Code:

<img src="http://board.domain.com/wiki-asset/?pid=74&d=1513018250&x=667" data-url="http://board.domain.com/wiki-asset/?pid=74&d=1513018250&x=667" class="bbImage" data-zoom-target="1" alt="" style="" />

This is rather interesting as my primary domain is on HTTPS, not on HTTP. So I don't know where these URLs come from otherwise (http instead of https and the wrong domain altogether).

I then went ahead and changed "Force Request Protocol" from "HTTP" to "Both" which yields the same HTML (img src and data-url is http://), but the request itself goes to https://
Reply
September 4, 2019 6:02 PM

pegasus

VaultWiki Team

It would make sense to me that the image URLs are not loading because they are cached in the vw_parsed table with the non-test domain (truncating the vw_parsed table would resolve this).

However, this does not explain why there are numerous Javascript files which are attempting to load from the wrong domain.

Reply
September 4, 2019 6:06 PM

SeToY

Junior Member

Deleted the contents of the vw_parsed table, reloaded the corresponding wiki page and saw a new entry in the vw_parsed table. This resolved the 404 errors with the javascript files, but not with the assets. They are still referenced (src aswell as data-url) with the non-test domain using http.

Edit:
Apparently fixing the 404s on the javascript files had something to do with the CDN url. I set it to the test-domain, javascript files error gone. Now I cleared the CDN url again, js files error still gone. Asset errors are still there, though.

Reply
September 5, 2019 11:05 AM
pegasus

VaultWiki Team
I just realized that the img-tag output you posted doesn't look like the tags generated by VaultWiki.

Please clarify whether for the broken images you are doing (check View > Source Code):
-

Code:

[IMG]broken-image-url[/IMG]

OR
-

Code:

[FILE]asset-name[/FILE]

If using FILE, we can control the image-path and it should be pointing to a valid resource automatically.

However, if you are using IMG, then the image-path is hard-coded directly in your content, so you would need to edit the content and change the URL to the test-board location. Currently it probably points directly to a prod-board location, which cannot be resolved because you have not upgraded VaultWiki on the prod-board yet. This would not be a bug, since IMG takes a specific URL. If the URL is not valid, that is not the software's fault. Also, IMG is a XenForo BB-Code, not a VaultWiki BB-Code.

If using IMG, and if it works when pointing to the appropriate domain, then VaultWiki is able to render the image, and there is no bug.
Reply
September 5, 2019 2:53 PM
SeToY

Junior Member
When editing the page, the images are embedded as following:

Code:

[IMG]https://board.domain.com/wiki-asset/?pid=74&d=1513018250&x=667[/IMG]

This seems conclusive with your explanation. I don't know whether they were embedded like that before the upgrade, but that indeed seems to be the problem. My guess is that they have simply been drag & dropped onto the XF 1.5 editor prior to the upgrade to XF 2.1.

What is the correct way to embed images in VW going forward, as drag & dropping does not work inside the wiki (anymore)?
Reply
September 5, 2019 3:32 PM

pegasus

VaultWiki Team

The IMG way still works, so long as you know the correct URL.

However, images uploaded via the wiki's File Browser use the FILE tag, which would automatically handle domain changes since it references the upload by a name rather than a URL. Many users do find the File Browser method extra-complicated, due to the extra step of picking a name and the other options it has. We are streamlining it a bit and adding drag-drop support in the 4.2 branch.

Since the IMG tag in question contains wiki-asset URLs, it looks like you've already been using the File Browser for a bit (its embeds are hosted in wiki-asset). Probably what happened here was that someone copied the browser path from an existing FILE use and pasted it into an IMG tag. The best option is to continue using the FILE tag alone, where possible.

Reply
September 5, 2019 3:34 PM

SeToY

Junior Member

Since the IMG tag in question contains wiki-asset URLs, it looks like you've already been using the File Browser for a bit (its embeds are hosted in wiki-asset). Probably what happened here was that someone copied the browser path from an existing FILE use and pasted it into an IMG tag. The best option is to continue using the FILE tag alone, where possible.

That's most likely what happened. Cheers for your support!

Reply

+ Reply

All times are GMT -4. The time now is 12:33 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: 404 when retrieving wiki assets

Issue Tools