Skip to content
Sudonix

PWA support for Sudonix Platform

Announcements
4 2 1.1k 1
Log in to reply

Related Topics
  • phenomlabundefined

    Ch..ch..ch..ch..changes!

    Announcements themes layout
    16
    2
    15 Votes
    16 Posts
    3k Views
    JACundefined
    @phenomlab of course, to be recognised is fantastic. @phenomlab said in Ch..ch..ch..ch..changes!: Sadly, no. Web crawlers and scrapers are often JS based and read text only, so styles don’t have any bearing. I’ve read mixed things about this, but no that does make sense, it was something I read a many years back when using Wordpress.
  • phenomlabundefined

    ANNOUCEMENT: New NTFY Server

    Announcements ntfy push alerts
    9
    1
    7 Votes
    9 Posts
    2k Views
    phenomlabundefined
    @crazycells that’s as good a test as any
  • phenomlabundefined

    OGProxy - a replacement for iFramely

    Announcements link preview cors proxy
    43
    2
    36 Votes
    43 Posts
    11k Views
    DownPWundefined
    I was experiencing 500 (Internal Server Error) responses from the proxy, visible in the browser console: GET https://proxy.xxx-xxx.net/ogproxy?url=https%3A%2F%2Fzupimages.net%2Fup%2F26%2F16%2Fld8h.jpg 500 (Internal Server Error) After investigation, I found two root causes: 1. Direct image URLs being sent to the proxy The custom JavaScript responsible for detecting links and sending them to the proxy was using the following regex to exclude direct image links: var fileExtensionPattern = /\.(png|jpeg|gif|pdf|docx?|xlsx?|pptx?|zip|rar|svg)$/i; Note that .jpg and .webp were missing from the pattern. As a result, links ending in .jpg were not recognized as direct image URLs and were forwarded to the OGProxy, which then tried to scrape them as web pages using open-graph-scraper — causing a 500 error. The fix was to add the missing extensions: var fileExtensionPattern = /\.(jpg|png|jpeg|gif|pdf|docx?|xlsx?|pptx?|zip|rar|svg|webp)$/i; 2. The proxy not following HTTP redirects Some image hosting services (e.g. zupimages.net) return a 301 redirect from the bare domain to www. When curl follows the redirect manually the image loads fine: curl -IL https://zupimages.net/up/26/16/ld8h.jpg HTTP/2 301 → https://www.zupimages.net/up/26/16/ld8h.jpg HTTP/2 200 However, the proxy’s axios.get() call does not handle this gracefully when open-graph-scraper is involved, resulting in a 500 error being returned to the client. My questions are: Is there a known best practice for handling redirect chains in open-graph-scraper? Would passing maxRedirects or followRedirect options explicitly to axios or ogs fix this reliably? Is there a cleaner way to pre-filter direct image/file URLs before they reach the proxy, ideally at the NodeBB plugin level rather than in custom JS? Thanks in advance.
  • phenomlabundefined

    Sudonix Branding

    Announcements branding
    2
    2
    5 Votes
    2 Posts
    1k Views
    DownPWundefined
    Thank you mark @phenomlab for sharing And good job for the new logo
  • phenomlabundefined

    Sudonix featured on justoverclock.it

    Announcements review
    3
    1
    8 Votes
    3 Posts
    1k Views
    phenomlabundefined
    @Madchatthew thanks
  • phenomlabundefined

    Issue with platform stability

    Announcements issue stability
    1
    1 Votes
    1 Posts
    444 Views
    No one has replied
  • phenomlabundefined

    Support for Apple Emojis

    Announcements emoji
    3
    0 Votes
    3 Posts
    967 Views
    phenomlabundefined
    @jac Seems not
  • phenomlabundefined

    Platform development diary

    Announcements technology platform new
    9
    1 Votes
    9 Posts
    2k Views
    phenomlabundefined
    It’s been a while since I checked in here. Plenty going on - mostly around rectifying small pockets of resistance between light and dark modes, plus the addition of new features such as an enhanced reputation system and the ability to create polls. Plus, there are several changes going on under the hood which are completely transparent to users or the operation of the platform. However, some changes mean that the platform does need to be restarted for code changes to stick and function correctly. I tend to do this during non busy periods, but sometimes, it’s unfortunately inevitable. The good news is that in most cases, a full restart takes only 20 seconds. More to come