Skip to content
Sudonix

Easier to read code and pre blocks

Announcements
1 1 635
  • phenomlabundefined

    Looking at the pre and code blocks today I realised how difficult they are to read when you switch from light to dark / dark to light mode. Can’t have that ! I’ve now fixed this so that it looks the part when viewed in either mode.

    As code / markup is used extensively here, it’s important we get it right 🙂

    Thought and opinions welcomed…

    Mark – Founder, Phenomlab Ltd
    Executive IT & Security Leadership
    Phenomlab Ltd

    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.
  • DownPWundefined

    Block Domain

    Solved Let's Build It code javascript block domain nodebb
    26
    1 Votes
    26 Posts
    6k Views
    DownPWundefined
    Yes ogproxy too is functionnal on dev
  • phenomlabundefined

    Threaded chat support for NodeBB

    Let's Build It threaded chat code
    35
    1
    19 Votes
    35 Posts
    9k Views
    phenomlabundefined
    @DownPW said in Threaded chat support for NodeBB: Better like this : add shadow and border-left on self answer Of course - you style to your own requirements and taste I’ll commit that CSS we discussed yesterday also
  • phenomlabundefined

    New Code Repository

    Announcements code gist github
    2
    3 Votes
    2 Posts
    979 Views
    crazycellsundefined
    @phenomlab very nice and useful idea [image: bravo-xd.gif]
  • phenomlabundefined

    Theme retirement

    Announcements themes switcher
    21
    16 Votes
    21 Posts
    5k Views
    phenomlabundefined
    I relented somewhat here and added another swatch - one I missed, which was previous called “blackout”. This specific one has been adapted to work on the new theming engine, but the others have been reclassified, and renamed to suit. [image: 1693924764891-d7f3a7a1-9702-4238-99bd-5c0e0d53f244-image.png] As a result, the theme you might have had will probably be reflecting something else, so you (might) need to change your themes accordingly. The changes are as follows Light -> No Change Cloudy -> Is now the old “Dim” Dim -> Is now the old “Dark” Dark -> Now a new theme based on the revamped “Blackout”
  • phenomlabundefined

    OGProxy - a replacement for iFramely

    Announcements link preview cors proxy
    43
    2
    36 Votes
    43 Posts
    10k 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

    Welcome to NodeBB V3!

    Pinned Moved General v3-prod code changes
    1
    0 Votes
    1 Posts
    606 Views
    No one has replied
  • phenomlabundefined

    Want to include Fancybox in NodeBB without a plugin?

    Customisation fancybox code
    6
    3 Votes
    6 Posts
    3k Views
    DownPWundefined
    @phenomlab haha!! You are crazy. In a good way, of course It’s a way of saying you’re awesome !