no edition bar on new instalation flat pro

Hi,

new installation of flatboard pro because of a bug on my actual installation (no more edition bar when i want to write a post or an answer).

so, bug confirmed !

steps :

• new installation of a fresh flatboard pro 5.8.0
• all default settings leaved as it is and no edition bar available
• tested with EasyMDE and Tui, on default and premium theme

logs available on pj, no error on firefox inspector.

@Fred, as always, i can give you admin right on this test'forum if you need :)

Hi @arpinux,
Found it. Thanks for the logs and for testing both editors on a clean install before posting, that ruled out a config problem on your end immediately.
It's not EasyMDE or TUI Editor specifically, and it's not the theme either. Both editors only load their CSS/JS on pages that actually need them, to avoid shipping 200+ KB on pages that don't. That check runs against a list of known URL patterns, and the pattern for categorized discussions only covered the edit route:

/f/{category}/d/{id}/edit

not the plain show route:

/f/{category}/d/{id}

which is the page your reply form actually lives on. So on any install using categorized URLs, the discussion page never requested the editor's assets at all. No error in the console because nothing failed — nothing was ever asked for.
Fixed in both plugins by widening that pattern to match the show route too (EasyMDE 2.3.16 → 2.3.17, TUIEditor 1.3.13 → 1.3.14). Same one-line change in both, since they'd copied the same allow-list logic.
No need for admin access on your end, the code made the bug obvious once I knew where to look. This will be in the next release; I'll update this thread when it ships.

Update(plugins/EasyMDE/EasyMDEPlugin.php) or Update(plugins/TUIEditor/TUIEditorPlugin.php)
Search and replace :

'~^/f/[^/]+/d/[^/]+/edit~',

by

'~^/f/[^/]+/d/[^/]+~',          // discussion catégorisée : show + edit + actions (formulaire de réponse) 

thx for quick answer and test.
but it didn't fix the bug :/

logs on pj

I just spun up a genuinely fresh Pro 5.8.0 install on my end too, same as you described and the editor shows up fine, toolbar and all, right out of the box.

That actually tells me something useful: the code itself isn't broken, at least not universally. So whatever's happening on your side is more likely something specific to your server or setup than a bug in the software itself.

Can you check one more thing? Open dev tools on the discussion page, but this time look at the Network tab instead of Console, and see what happens with the requests for /plugins/TUIEditor/dist/toastui-editor.min.js (or easymde.min.js if you're on that one). Are they coming back 200, or are they failing 404, 403, blocked, anything like that?

That'll tell us whether the files just aren't being served correctly on your host.
If you check that and still don't see anything, or the requests look fine and it's still broken, let's take you up on that admin access offer at that point it'll be faster for me to just look directly than to keep going back and forth blind.

on a new discussion page, there is no call to easymde.min.js but this page is available https://arpinux.org/aft/plugins/EasyMDE/dist/easymde.min.js

if you have a zip of flatpro5.6 or 5.5 so that i can test when the bug appears. editors used to work on previous releases.

Could you please test this new version of easyMDE?
If it doesn't work, could you please send me an account via private message so I can investigate the issue?

it works! :D

Glad it's finally working. Thanks for sticking with this through three rounds of debugging. A subdirectory install wasn't an obvious thing to suspect from the outside, and it took your network tab check, confirming the JS request was never even made, to actually point at the cause.

For anyone else who runs into this: both of your installs (/aft/ and /forum/) live in a subdirectory instead of at the domain root, and that's what broke it. The code deciding whether to load the editor's CSS/JS checks the raw request path against a pattern like ^/d/.... On a subdirectory install the real path is /forum/d/..., which never matches something anchored to start with /d/. So the check silently failed and the assets never got requested. Same "nothing asked for, nothing to fail" story as the first bug, just a different cause underneath it.

That's not the kind of mistake that stays in one place, so I went through every plugin and theme doing the same raw URL matching to see how far it spread. Further than I'd have guessed: around 20 files across a dozen-plus plugins and five themes had some version of it. FlatHome's custom page templates weren't loading on subdirectory installs. FlatModerationExtend's bulk-moderation toolbar wasn't showing up on the discussion list. Several plugins' CSS wasn't loading on discussion or admin pages, and a few themes had page banners and nav highlighting quietly falling back to generic text instead of the real page title. All of it's fixed now, and there's a new section in the developer docs on the right way to check the current URL, so it doesn't come back the next time someone writes a plugin.

All of this ships in 5.8.4 is out for Pro or next update. Thanks again for the detailed reports.

upgrade done to 5.8.4 with upgrade tool : bug on 'nettoyage' step :

JSON.parse: unexpected character at line 1 column 1 of the JSON data

since then, the forum is in maintenance mode and i can't login anymore xD

https://nakedeb.arpinux.org/forum/index.php est en erreur 503 :/

i solved the maintenance mode by editing the config.json directly :)

when i was back to admin panel, update section, flat notify me about the update archive available and ask me to "reinstaller". i declined and delete this archive as all run well now.

don't know more about this little bug on the last upgrade step :/

note : a fresh install of flat pro 5.8.4 works perfectly on a subdomain :)

Normally, you should still be able to log in as an administrator by accessing the /admin URL. This allows you to open the administration panel and disable maintenance mode.
Maintenance mode is automatically enabled by the update system to prevent issues while an update is in progress. It's possible that there was a problem accessing the site through the subdomain, which prevented the update process from removing the temporary update files. In that case, you should check your FTP and manually delete any leftover update files.
Please let me know how the next update goes so we can verify whether the issue has been resolved.
As you mentioned, editing the config.json file is also a valid workaround. 😉