I think this might be fixed; at least I haven’t seen the Shortcuts failure notification in a while now, whereas before it was a daily occurrence.

This isn’t a real bug (although downloading without -o results in ”File name too long”, if filenames on the local FS are restricted to 255 bytes). I’m just making a note about Rony Rex trolling with the title: https://areena.yle.fi/1-78271849

Could make good test case. :)

I’ve reverted my live server back to 6.09 (and locked it there) for now.

On the testing VM I started from scratch: I deleted all existing data and reinstalled the 10.02 snap. Right after installing it’s working fairly normally, no noticeable slowdown, and ferretdb is down in double- or even single digits of CPU percentage.

I then exported my main working board from the live system (as JSON, 11 MB) and imported it into the VM installation. There was some noticeable slowdown right after, but eventually it settled back into working normally (i.e. no tangible slowdown).

But ferretdb’s CPU usage began to climb, until it was again using more than 160 % of the CPU.

Since then, I’ve tried to isolate the triggering cause from the import (if any), but no luck so far.

The only possibly relevant messages I’ve seen in the log during this were:

MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 drain listeners added to [Gzip]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added to [ServerResponse]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit

Bug Description

With the snap update from 9.98 → 9.99, we’ve made some progress: Wekan now responds to requests from the proxy (thanks to xet7’s rapid fixes in #6476).

Instead, with 9.99 and now 10.00, it seems I’m hitting the performance issues others have reported (#6467, #6474) earlier.

My physical server is only a dual-core Pentium G630, but it does have 16 GB of RAM, and I’m the sole user of my Wekan instance, so it’s not a huge deployment. Then again, I have been running Wekan for years by this point, so there’s quite a lot of accumulated history tucked away in the archives.

I have a VM running another Wekan instance for testing purposes (with a setup cloned from the main server some time ago), and it’s affected by the same performace issues despite running with 4 virtual cores sliced from my main desktop’s more modern Core i7-8700 CPU.

Symptoms

Running top on the server shows ferretdb constantly using more than 100 % of the CPU.

Symptoms on the client side are varied. Only loading the login dialog seems to work without any delay; any problems occurring thereafter, as listed below, may or may not appear, probably because this is a performance issue, so it depends on how well/poorly the backend is doing.

Clicking the ”Sign In” button seemingly does nothing: no visible reaction, nothing in the browser console.

Logs from the server (journalctl -xeu snap.wekan.wekan) do show this though:

sqlite-busy.log

Occasionally the same error is shown on the login screen (in the browser).

After a couple of minutes, another previously reported issue (#6380): all fields aside from the language selector disappear from the login screen. A couple more minutes, and the username and password fields reappear, along with ”Authentication method”, with an empty dropdown menu (i.e. no options to choose from).

A few more minutes (and clicking the still seemingly non-functional Sign In button), and the main screen with my boards appears. I select one of them, and, after being stuck loading it for maybe half an hour (with only the header bar and the loading indicator dot animation visible), it then just says ”Page not found” where the board contents should be.

With 10.00 freshly installed, although perhaps just due to the fresh restart, the login appeared snappier, and I was able to get to the board, although it was still missing at all the attachments and my avatar. Later attempts to login (in a new browser window) seem just as slow as before.

Steps to Reproduce

1. update snap from 6.09 to 9.99/10.00

Relevant Logs

Additional Context

I have one tab with the same board open from before the recent updates, so still displaying the old UI, and (somewhat curiously) it doesn’t appear to suffer from any slowdown. This could just be that it’s already loaded all of what the new tab tried to get from the DB. Alternatively, it’s not connected to the backed at all, despite not showing the usual warning, because any testing changes I make there don’t show up on the new UI (when I can get to the board).

Bug Description

Yesterday’s 9.95 had rendered Wekan (installed as a snap) inoperable, but from others’ issue reports and comments here I decided to wait until the fixes for those had been released.

With 9.98 now installed, the Wekan service itself seemingly starts without issues, but Apache (which is what I’m using for a proxy) still can’t connect to it:

http: attempt to connect to 127.0.0.1:3333 (127.0.0.1:3333) failed

Indeed, a netstat command confirms that port 3333 (which is what I’ve set Wekan’s port to) is not open.

My settings and output from snap info are below. I set debug=true, hoping to get more details, but it didn’t do anything.

Attached is all that journalctl -xeu snap.wekan.wekan.service logs for the service upon startup.

wekan.log

Steps to Reproduce

1. have Wekan snap 6.09
2. snap set wekan port=3333
3. have the snap update to 9.98

Relevant Logs

    # snap get wekan
    Key                         Value
    database                    ferretdb
    debug                       true
    mail-from                   Wekan <wekan.battra@[REDACTED DOMAIN]>
    mail-url                    smtp://127.0.0.1:25
    port                        3333
    richer-card-comment-editor  false
    root-url                    https://[REDACTED DOMAIN]/kan

    # snap info wekan
    name:      wekan
    summary:   Open-Source kanban
    publisher: Lauri Ojansivu (xet7)
    store-url: https://snapcraft.io/wekan
    contact:   support@wekan.team
    license:   MIT
    description: |
      WeKan is an Open-Source and collaborative kanban board application.
      
      Whether you’re maintaining a personal todo list, planning your holidays with some friends, or
      working in a team on your next revolutionary idea, Kanban boards are an unbeatable tool to keep
      your things organized. They give you a visual overview of the current state of your project, and
      make you productive by allowing you to focus on the few items that matter the most.
      Depending on target environment, some configuration settings might need to be adjusted.
      For full list of configuration options call:
      $ wekan.help
      
      Note: At https://snapcracft.io/wekan video 2023-12-08, after Meteor News, WeKan Interview starts
      at 22min 22sec.
    commands:
      - wekan.database
      - wekan.database-backup
      - wekan.database-list-backups
      - wekan.database-restore
      - wekan.help
      - wekan.maintenance
      - wekan.migrate
    services:
      wekan.caddy:    simple, disabled, inactive
      wekan.ferretdb: simple, enabled, active
      wekan.mongodb:  simple, disabled, inactive
      wekan:          simple, enabled, active
    snap-id:      jtpboSYvTCEyHoutkkRo1SI9ioSMOUb3
    tracking:     latest/stable
    refresh-date: tänään 02:03 EEST
    channels:
      latest/stable:    9.98 2026-07-17 (3457) 393MB -
      latest/candidate: 9.98 2026-07-17 (3457) 393MB -
      latest/beta:      9.98 2026-07-17 (3457) 393MB -
      latest/edge:      9.98 2026-07-17 (3457) 393MB -
    installed:          9.96            (3451) 393MB -

Additional Context

No response

My build environment is an Ubuntu 24.04 VM.

Turns out I wasn’t running npm install in my build script, but that also apparently isn’t the issue: building after an npm install results in an equally broken (i.e. iconless) build as without it.

I’ll attach an output log from the npm install part. It at least mentions postinstall.sh.

npm-install.log

I don’t know; depends on whether it is run as part of the documented npm run build:android build command, which is what I’m using.

After updating my build of the mobile app from 2.40.0 to 2.41.1 (and no other changes in the build environment), all icons in the resulting app have been replaced with a ”☒”, and all channel icons with what looks like a Chinese character (the app is supposed to use English, like the OS). Only user profile pictures seem unaffected (except for the overlaid status indicator, which *is* affected).

I’ve so far tested this on a phone running Android 10 and a tablet running Android 15. Both are using the ”Onyx” theme (and switching the theme has no impact on the issue). The server is running the latest release 11.8.1 (and the web UI is unaffected).

Sorry, I was tracing this on a test site using a mockup, and apparently the <span> is actually only added once the post is published, so the issue doesn’t manifest when using previews. That’s why I never caught it while actually writing the posts and using previews, only after publishing.

The trailing <span class="__iawmlf-post-loop-links"> element introduced in PR #338 causes WordPress to render a trailing newline as a <br /> tag in the last paragraph. This behavior differs from when Link Fixer is not active.

I don’t know if the block editor is affected, since I don’t use it, but the issue is present when using the Classic Editor, and even there you have to use the Code view (because Visual view either converts the trailing newline into a line with an  , or strips the trailing newline when switching to Code view).

My guess is that this is wpautop trying to be smart about the content, seeing the trailing <span> from Link Fixer, and thinking it’s visible content, so the trailing newline in the actual content (as entered in the editor) should be rendered as a visible <br /> too.

This is probably a very niche issue, and I’m sure I can figure out a way to work around it, but I wanted to document it anyway.

Steps to reproduce

0. deactivate Link Fixer
1. use Classic Editor’s Code view to create a post
2. end the final paragraph with a newline
3. preview publish the post and inspect the last paragraph: there is no newline before the closing </p> tag
4. activate Link Fixer
5. create another post with the same contents
6. preview publish the post and inspect the last paragraph

What you expected to happen

the <span> to immediately follow the last word and immediately precede the closing </p> tag, with no newline before or after

What actually happened

the <span> is separated from the last word with a <br /> tag followed by a plain newline