@Yve-Salazar Are you still looking to distinguish between API calls via curl?
[nodebb-plugin-emoji-extended] Emoji Extended (reworked)
-
Hey guys,
I've just published the first (except
emoji-extended
xD ) releases ofnodebb-plugin-emoji-extended
(GitHub)nodebb-plugin-emoji-one
(GitHub)nodebb-plugin-emoji-cubicopp
(GitHub)nodebb-plugin-emoji-static
(GitHub)nodebb-plugin-emoji-apple
(GitHub)
All of those depend on
[email protected]^1.0.0
being installed.
Take a look at the ACP settings ofnodebb-plugin-emoji-extended
to see and feel all improvementsThe (un)install buttons are currently not working and thus disabled.
Feedback is always welcome.
Here is my current TODO list:Emoji Static * [s/c] show alert with reason of error when index not found * [s/c] image upload * [s/c] ACP details-handling (deprecate *index.json*) * [c] multiple sets management Emoji Extended * [s/c] enable within signatures (including auto-completion) * [s] allow sets to specify outdated files (e.g. index-file check), indicate within ACP * [s/c] allow user to specify prefix/suffix for auto-completion per set, auto-create suffix (setId) for overwritten emoji * [c] check markdown-alternatives for code-block detection implementation * [s/c] allow alternate image source for modal (e.g. sprites image) * [s/c] ACP page * [c] add sort capability of active sets * [s/c] indicate busy-state on page-load * [s/c] implement [un]install actions * [s/c] show modules that are installed but not enabled within NodeBB (on top of available sets) * [s/c] implement activation action * [s] filter modules for installation that ain't compatible with NodeBB version * [c] (maybe) markdown check rework * [s/c] (maybe) push-update styles on sets-update, append to already in-use styles Emoji One * [s] parse unicode emoji characters New Sets * twemoji * PhantomOpenEmoji * emojisymbols.com
Of course if you want to contribute, feel encouraged to send a PR or even publish your own sets
-
PS: An introduction on creating new sets can be found here.
-
Now this is just plain cool...
-
However I'm not sure in which way NodeBB should/could keep emoji-extended within its dependencies.
If emoji-extended is listed (and activated by default), some unused client-side code gets delivered.
If emoji-extended and non-static set(s) are listed (and activated by default), that/those set(s) would still need to update files by hand via emoji-extended ACP page.The options that come to my mind:
- list
emoji-extended
and a static set (emoji-cubicopp
is the only one right now); add that set to default settings ofemoji-extended
therefor it is activated by default. - list
emoji-extended
and a non-static set (emoji-one
would be my choice); add that to default settings; call itsupdate()
function within./nodebb setup
; I could add a callback-based variant for that set if you want to avoid promises within core. - list
emoji-extended
and a non-static set; add that to default settings; call itsupdate()
function on server start (static:app.preload
I assume) if no files are present. - list
emoji-extended
; do not enable it by default - drop emoji from dependencies
The 3rd would break my clear distinction between plugin installation and image files o_O .
I tend to the 5th; Adding the word "smiley" to the description of emoji-extended should ease the search within the plugin-list.
It would be great if NBBPM could handlepeerDependencies
starting withnodebb-[...]-
properly (or does it already?) for this case. - list
-
@frissdiegurke No way, the last time I added a
peerDependencies
property to mypackage.json
, things went sideways really really quickly.It's deprecated in npm3, and I'm not touching that property with a ten-meter pole
-
@julian deprecated? you sure? the docs only specify a behavior change that those are not installed automatically
-
Perhaps you're right -- in any case, I was initially drawn to
peerDependencies
because it seems like a good way to handle sideways dependent packages, but it didn't work at all in practice, so I've abandoned its usage. -
@julian Since npm
3+
don't handlepeerDependencies
other than outputting warings, you might consider giving it a try again
Otherwise (to keep stuff working with2-
) we could add a field likenbbpm.dependencies
... -
Dependency management is definitely not something I want to get into
Perhaps do a
module.parent.require('nodebb-plugin-emoji-extended')
and error out if it returns null? -
@julian That's the current state, also using
peerDependency
. Was just a thought that auto-installing those dependencies would be more comfort -
@frissdiegurke with [email protected], since node_modules is flattened, you can install things as normal deps and they should work as peer deps.
-
@PitaJ But only as long all version ranges match a single version, if they don't it communicates with a "silent" nested
nodebb-plugin-emoji-extended
which would probably cause much confusion and thus I don't want thisThe main problem is that NodeBB at some point breaks the distance to NPM by depending on the
node_modules
structure (of which I cannot come up with an alternative way of course). This makes it impossible to solve the issue with NPM only. It has to be either apeerDependency
which will not install the package if it misses, but does not cause other possible trouble or a solution via NodeBB itself. Since NodeBB breaks the distance to NPM it should be responsible for that breakpoint. At least these are my thoughts of it.A fixed
dependency
would also disrespect thenbbpm.compatibility
ofnodebb-plugin-emoji-extended
which might cause even more trouble.
I think as long NodeBB does not provide a better way, going withpeerDependency
and a notice within the plugins descriptions is the best I can do. -
Upon installing
nodebb-plugin-emoji-apple
I see in my log this error:26/2 10:35 [10738] - error: [plugins/emoji] nodebb-plugin-emoji-extended is not installed. nodebb-plugin-emoji-apple depends on it.
I do have
nodebb-plugin-emoji-extended
installed. To make sure nothing was wrong with the base emoji-extended plugin i removed it and the newly installed emoji-apple plugin, reloaded NodeBB, and re-installed but still receive this warning message.It seems that the plugin is working though but feel that I should report this as something maybe wrong that I haven't found yet.
Thank you.
-
@rod I assume you have any
nodebb-plugin-emoji-extended
less than1.0.0
installed. I should precise that message o_O
FYIL: to install any^1.0.0
version you currently have to remove it from the package.json fileAnd if this is the case it's not using the
nodebb-plugin-emoji-apple
at all -
@frissdiegurke Ah yes, you are correct. emoji-apple is not working b/c I have 0.4.17 of emoji-extended.
Should I wait until NodeBB is 1.0.x to have a seamless installation of
[email protected]^1.0.0
? -
@rod If you're on master you can install it without any problems, just need to remove that listing within package.json (you'll have to
git reset --hard
before futuregit pull
to avoid problems withgit
).
If you're on another branch (e.g.0.9.x
) it's probably not working to its full potential. For example I think you'd have to update the composer too in order to get auto-completion... -
Here's an interesting bit of behavior
- Upgraded to 0.9.4.
- Removed dependency from package.json
- NPM i [email protected]
- Installed nodebb-plugin-emoji-apple
-
@ThingBreaker
Are the emoji working within posts/previews? If not, check your config.json for theurl
property.
I'm not sure why the translations ofmodal.title
andmodal.legal
are not working, will take a look at that. -
@frissdiegurke It looks like the URL was malformed and after correcting it, emojis are back up and running.
-
@ThingBreaker And as to the translations it seems the
defaultLang
support ofv0.9.x
is failing.
Since it's a minor0.9.x
issue and I'm supporting^1.0.0
only, it's not gonna be fixed from my side. Maybe the @administrators want to merge the fix ofdefaultLang
into0.9.x
, but I wouldn't bet on this. I guess it's something one can live with until next major NodeBB release.