Vintageveloce: We as the Moderators have elevated your issue up to Tech Support at Autoguide as we're unsure as to why you can't view pictures in threads - they are working on it & we'll drive it to get a response. Your issue is valid and we're concerned that resolution is taking some time - see PM from me
The issue is simple (and the solution would be simple, too -- if anybody cared). For reference (and to keep source code uncluttered), I used this singled-out post #29
above in Chrome.
The trouble starts with this snippet of page source code:
<!-- attachments -->
<img class="photo" src="/bb/forums/images/AlfaBB_2015/misc/spacer.gif" data-original="attachment.php?attachmentid=1572282&stc=1&d=1560807574" border="0" alt="" />
<!-- / attachments -->
The real trouble is further down the page:
This is the script that handles "data-original", which is a data container to hold custom data, but the script is not served from AlfaBB and blocked by many ad-blockers and/or anti-virus software. Hence, as ad-blockers prevent the script from being loaded, no script is executed, and therefore no original picture is ever shown (just the spacer.gif, which is 1 pixel by 1 pixel in size -- i.e. just a dot in what usually is interpreted as a transparent color).
Fixing the problem requires 2 changes:
1. Change the vBulletin BB server configuration so that the page source code does not refer to verticalcope.com but AlfaBB.com, and then either:
2. (a) create a redirect/rewrite rule in the web server (see cloudflare page
) that replaces the AlfaBB link with a verticalsope link and so re-routes the request (but the reply would have to appears as coming from AlfaBB in order not to be blocked by ad-blockers and/or anti-virus software), or
2. (b) add a definition to the domain name server (a DNS entry) that defines static.AlfaBB.com and maps or redirects it to verticalscope (but, as mentioned in 2.(a) above, one would have to ensure that the output looks is if it were coming from the AlfaBB server rather than verticalscope server).
Practicality (that is, uninterrupted service) demands that change #2 gets implemented (and tested) before change #1.
I used stuff like this more than 20 years ago -- it's neither rocket science nor overly complicated to implement.