[nodebb-plugin-magicblock] Macros, Color, Embeding



  • I think this plugin is now reasonable working, so let me introduce nodebb-plugin-magicblock officially :)

    NodeBB MagicBlock plugin

    NodeBB Plugin for macros, format, embeding.

    Updates

    • v0.1.8 : hackIframely. One can enable nodebb-plugin-iframely only in {{..}} without modifications of the iframely plugin. ( see a npm page )
    • v0.1.7 had a bug.

    Links

    Summary

    Magic

    {{ Any Link }}
    {{ http://i.imgur.com/HxvheyR.jpg }}
    {{ http://imgur.com/gallery/BxHKr }}
    

    Imgur gallery

    • image, imgur gallery are built in, and you can add more or override them.
    • Control iFramely by hackIframely: true in YAML ( see a npm page )

    Coloring

    {{#red This is red letters}}
    {{#red#green This is red letters on green background}}
    
    

    Coloring

    Class

    {{.myclass Any Text or Link }}
    {{.fa.fa-fw.fa-inbox}}
    

    class example

    Customizable Macros

    {{br}} -> <br/>
    {{ ALERT(info): This Info Box }}
    {{ ALERT: This is default alert Box }}
    {{ PANEL(success):  Body Only Panel }}
    {{ PANEL(warning, This is title): Panel with title }}
    

    Macros

    Nested Block

    {{ALERT: These are {{#blue blue letters}} In the Alert Box}}
    {{ALERT: This is {{ALERT(info): an Another Alert Box}} in the Alert Box }}
    

    Installation

    npm install nodebb-plugin-magicblock
    

    History

    • current version : v.0.1.3

    Acknowledge


  • GNU/Linux

    Great 👍

    Now that it gets in shape here are a few more recommendations/notes:

    1. I guess the lib/defaults.js is never used and duplicates lib/magicblock/defaults.js, just a side note xD
    2. There are a few tools at npm you could use rather than creating your own utilities ;) I prefer lodash (link), it's written for performance and consistency of usage. Your deepCopy/buildOptions would get replaced by _.merge for example. It's really not a deal to have dependencies for such matters. Plus knowing a utilities features helps a lot keeping code to necessary stuff.
    3. I see some space for improvement here; Checking opts.attrStrAllowColor first would improve the code and performance.
    4. A .npmignore file does not extend of a .gitignore, you have to either fill it properly or remove it entirely (in this case npm will use the .gitignore). You have some a bit of trash within your npm release ;)

    Glad I could help!



  • Thanks always~

    @frissdiegurke said:

    1. I guess the lib/defaults.js is never used and duplicates lib/magicblock/defaults.js, just a side note xD

    Actually I use magicblock as a sepereated module, and lib/defaults.js is a plugin side defaults which can be different from magicblock defaults, (they are yet same but.. ). Now, buildOptions is called twice in library.js and lib/magicblock/index.js with different(but same) default.js.

    1. There are a few tools at npm you could use rather than creating your own utilities ;) I prefer lodash (link), it's written for performance and consistency of usage. Your deepCopy/buildOptions would get replaced by _.merge for example. It's really not a deal to have dependencies for such matters. Plus knowing a utilities features helps a lot keeping code to necessary stuff.

    Yes, after I learned lodash from your emoji plugin, I thought exactly same thing. Thanks twice :).

    1. I see some space for improvement here; Checking opts.attrStrAllowColor first would improve the code and performance.

    Eagle eye!!

    1. A .npmignore file does not extend of a .gitignore, you have to either fill it properly or remove it entirely (in this case npm will use the .gitignore). You have some a bit of trash within your npm release ;)

    This is really something new I have never known.
    I will quickly improve 3,4 first.



  • I got a question if this plugin works under v0.9.4.
    But I tested/developed this my first plugin with only with v1.0.0, and have no idea about version compatibility.

    What I can imagine to are

    1. Study what changed between v0.9.4 and v1.0.0
    2. Install v0.9.4 and test.
    3. Ask volunteers who (will) test the plugin with one's v0.9.4

    Could anybody give better or recommendable ideas?


  • Admin

    @qgp9 wow, great work! If you want to know what changed between versions, check for a "breaking changes" topic by @baris - that's your best bet.

    For v1, likely you'll need to add an "acpScripts" section to your plugin.json, if you have client side js defined in ACP



  • @julian HI, I needed you 30 minitues ago!!
    I just found out this acpScripts after an hours testing and debuging. :)
    I have(had) to read that post also.
    Here is a link for others ( to save server resource from searching)

    Actually, I have an question related with acpScript.
    So if I want to support v0.9.4 then what is best way?

    1. put a admin.js( commonly called ) to both of acpScript and scripts
    2. put it to only scripts and remove from acpScript
    3. embed into an admin tpl of a plugin.

    I guess most effective way to support both versions is 3.
    Could you let me know the best way?


  • Admin

    @qgp9 You can embed the script into the template -- depends how comfortable you are with mixing your templates and client-side code, in terms of organisation 😄

    In order to support both, you'd have to maintain two branches in git. One for each level of support. You'd need to ensure the nbbpm.compatibility values are set to the appropriate values in each branch's package.json, and npm publish them both (though npm will show the readme of the latest published version).

    nbbpm should be smart enough to figure out that different versions have different compatibilities and adjust its records accordingly. If not, let me know,.



  • Hi , All

    I'm testing the plugin with v0.9.4 on Cloud9.
    If you are interested on this, you can post/test freely without login.
    https://nodebb-0-9-4-magicblock-qgp9.c9users.io/topic/2

    It seems that MagicBlock@0.1.6 works well with NodeBB@0.9.4


  • GNU/Linux

    @julian said:

    @qgp9 You can embed the script into the template -- depends how comfortable you are with mixing your templates and client-side code, in terms of organisation 😄

    Or make the script statically available (no way to limit for admins thought) and link it within the template.



  • @julian Thank you. I'll check them.



  • NEWS

    nodebb-plugin-magicblock has been updated to v0.1.8

    A key feature of v0.1.7 is a hackIframely which can enable iFramely only in blocks {{..}} with an offical nodebb-plugin-iframely.

    Check details at a plugin page.

    Demo page


  • Admin

    Nice job! :)


Log in to reply
 


Looks like your connection to NodeBB was lost, please wait while we try to reconnect.