simon.schönbeck.dk

Category: tagged

  • Post comment notification email woes

    After having done an upgrade of a very old WordPress install, notification emails were not arriving properly.

    Since this installation was originally set up almost two decades ago, back when emails were sent directly from the same hosting server to the MTA. Due to the level of spam this caused, emails nowadays have to be submitted through a proper mail system, not forgetting the fact that port 25 is now blocked at nearly all providers.

    I do run some mail servers myself, however I wanted something quick to move on so I decided to use Mailgun which I had an account with already. They actually provide their own Mailgun WordPress plugin so I was up and running as soon as the new DNS records had propagated. Emails started arriving immediately when I updated the Administration Email Address under Settings>General with the new email address. Great stuff!

    However I realised that a new comment would no longer trigger the comment notification email. Nothing in the logs of nginx revealed what could be happening. I needed to figure out if the emails were even generated, and if so, where did they get stuck.

    Luckily there is another plugin which logs each email sent by WordPress. Once I tested another comment and checked the plugin’s log page in WordPress, I immediately realised what the issue was. It was still being sent to the old administrator email address!

    Later I did spot that Mailgun’s own logs actually revealed the same data, but at the time in question I was under the impression that the emails never left WordPress.

    Now the mystery… why the heck was WordPress still using the previous email address from Administration Email Address? This field was updated and other admin notification emails were being received just fine.

    The issue when dealing with a self-hosted WordPress for oneself is that in the vast majority of cases, one is both the site administrator as well as the only user posting. Apparently the new comment notifications emails are only sent to the post author and not the site administrator. I had simply forgotten about the old email address under the posting user’s profile (Users>Profile)!

    Comment moderation emails on the contrary do go to both site administrator and post author.

    Do not forget to add or update your Gravatar profile with the new email address.

  • Fedora’s Thunderbird Flatpak shows generic Wayland “W” icon in KDE Plasma

    Just a little annoying issue that has buggered me for many months without any solution in the updates.

    When launching the latest Fedora version of Thunderbird Flatpak (128.6.0esr), it does not display its usual stylised blue swallow icon, but instead the generic yellow “W” icon of Wayland.

    This system runs Fedora Kinoite so the bug probable does not affect a RPM installation of Thunderbird. Additionally, there is also a Flatpak version of Thunderbird in Flathub which I have not tested whether this bug is present or not.

    This issue appears to be due to how the Thunderbird Flatpak is packaged. Specifically, the Fedora provided Flatpak is not setting the expected desktop file metadata when it launches under Wayland. As a result, KDE Plasma falls back to the generic “W” icon for the running window, even though the menu and pinned icon are correct.

    There is a specific commit to the underlying Flatpak container.yaml which may be responsible for this bug. The changing of the name string from “org.mozilla.thunderbird” to “net.thunderbird.Thunderbird“. This hint is also what is used to work around the bug:

    1. Start by opening Thunderbird
    2. Press Alt+F3
    3. Select More Actions > Configure Special Application Settings
    4. Add a new property called Desktop file name
    5. Select “Force” in the property drop-down
    6. Change the property value to “org.mozilla.Thunderbird“
    7. Click “OK“

    Now the taskbar icon should be back to the same as the one in the menu, the correct Thunderbird blue swallow icon, with no sight of the wrong yellow Wayland “W” icon.

  • Failing to update a very old WordPress version

    Download failed.: cURL error 60: SSL certificate problem: unable to get local issuer certificate

    Installation Failed

    If you receive the above error when updating a stale installation of WordPress read on.

    Every installation of WordPress comes with its own Certificate Authority (CA) file which gets refreshed automatically upon each version update. If you have not updated your installation of WordPress for a few years the certificates within have expired and therefore cURL will not be able to verify the integrity of the server you are connecting to and fail the download and update process.

    Verifying the chain of trust is important to avoid pulling WordPress from the wrong source in the event that you may be exposed e.g. to a man in the middle (MITM), DNS hijacking, etc. scenario.

    To resolve the issue we need to break out of this catch 22 situation where we need the latest version of WordPress to update to the latest version of WordPress… d’oh!

    Some would simply download a fresh WordPress installation directly on the server, however it can be error prone risking your old installation’s data, plus the fact that the included updater runs its checks and updates both core files and database. So the quickest way is to simply overwrite the old certificates file at wp-includes/certificates/ca-bundle.crt with the latest one from WordPress’ development repository:

    https://raw.githubusercontent.com/WordPress/WordPress/refs/heads/master/wp-includes/certificates/ca-bundle.crt

    Once replaced cURL will no longer have any issues connecting to WordPress, retrieving the latest version and completing the update.

  • KDE Plasma sunrise (bright) & sunset (dark) theme automatic switch

    Under System Settings > Appearance & Style > Colours & Themes > Night Light in KDE Plasma there is the expected option to automatically switch at specific times between cool and warm colour temperature for the screen. I marked my location on the map and selected Sunset and sunrise at manual location to take care of the switch automatically. This works perfectly!

    For whichever reason, and there is many, KDE Plasma cannot do the same with the bright and dark theme. This is such a miss that one wonders how anything ever gets agreed upon in large open source projects such as KDE in this case. Gnome supports the option as many other.

    As there are more ways than one to skin a cat, I had several choices to work around this missing feature. I was really looking for something quick and dirty, nothing to install and trust, and easy to undo if needed.

    I decided to use the colour temperature as an indicator of when the bright or dark theme was needed. So at 6500 K it was the cool day light temperature and the bright theme should be used. On the contrary anything below this temperature, that is warm night light, should use the dark theme. Then I would simply check for this system value at a set interval and change the theme if it changed. This simple script is placed in the System Settings > System > Autostart section as an Application and it will launch upon boot and run in the background. Copy or download & unzip the below file and remember to make the .sh file executable:

    #!/bin/bash

    current_theme=""

    while true; do
      # Retrieve the current temperature from KWin using dbus-send
      temperature=$(dbus-send --session --dest=org.kde.KWin --type=method_call --print-reply \
        /org/kde/KWin/NightLight org.freedesktop.DBus.Properties.Get string:org.kde.KWin.NightLight string:currentTemperature \
        | grep -oP 'variant\s+uint32\s+\K\d+')

      # Decide the target theme based on the temperature
      if (( temperature == 6500 )); then
        target_theme="org.fedoraproject.fedora.desktop"  # Light theme for == 6500
      elif (( temperature < 6500 )); then
        target_theme="org.kde.breezedark.desktop"  # Dark theme for < 6500
      fi

      # Switch theme only if it's different from the current one
      if [[ "$target_theme" != "$current_theme" ]]; then
        lookandfeeltool -a "$target_theme"
        # Update the current theme to the new one
        current_theme="$target_theme"
        # KDE notification
        notify-send "Theme Switcher" "Switched to $(basename "$target_theme") theme."
      fi

      # Sleep for 15 minutes (900 seconds)
      sleep 900
    done
    Download shell script

  • “Unable to load stream. Please make sure port 7446 is open on your NVR.”

    In case you are seeing the error message “Unable to load stream. Please make sure port 7446 is open on your NVR.” when trying to watch the live camera stream on your Unifi Video NVR system from Ubiquiti, then the solution is rather simple.

    The error is caused by the self-issued certificate that comes by default with the Unifi NVR. As Mozilla Firefox has strict SSL (HTTPS) rules making sure that one does not connect to the wrong or fake website as could happen in e.g. a phishing attempt. I have not tried myself but from what I have read apparently Google Chrome does not enforce this in the same manner making the stream work out of the box in Chrome.

    The solution is to open the URL to the video stream directly in a separate tab or window so that you can accept the self-signed certificate for the session:

    https://NVR_IP_address:7446

    The page itself will return an error after the certificate is accepted but that is fine, it is simply to accept the certificate. After that simply reload the NVR interface and the HTTPS video stream will work fine

    Please note that if you are accessing the NVR from an external network you may have a firewall instance blocking the actual port. This instead would require port forwarding to be set up and that is a different story.