Three more requests

Feature Requests
  • @kevin Within /admin/themes is a tab named Customize 😉

    To get the show/hide working with the recent replies within the categories of the home-page is kind of hard since you don't have a good value to limit the max-height since it's really different dependent on the replies.

    So I'd say there is no good way to do it with css only, you'll need to get the height via js and animate it via css. To only show/hide the recent replies you'd have to wrap them within another html-tag too (can be done within templates/home.tpl of the theme).

  • that's the tab i've been using but i'm ready to just compile it into one style sheet without all the overrides. it creates a few problems doing it like this. It's great for learning what value is assigned to what but i'm making bigger and bigger changes to the template files, and i'm too lazy to merge the two style sheets by hand.

  • @kevin said:

    • It would be awesome if someone changed the URL-to-image plugin so that if there were multiple images in a row it would combine them into a lightbox/slideshow with left/right arrows (similar to my blog @ http://krtong.com )

    You mean, the imgbed plugin? someone's using this?? 🙂

  • @BDHarrington7 said:

    @kevin said:

    • It would be awesome if someone changed the URL-to-image plugin so that if there were multiple images in a row it would combine them into a lightbox/slideshow with left/right arrows (similar to my blog @ http://krtong.com )

    You mean, the imgbed plugin? someone's using this?? 🙂

    Isnt everyone??? Who actually likes to use codes while typing?

  • @kevin Haha -- as someone who grew up with computers, BBCode, WikiCode, Markdown all feel natural to me.

    After a bit of practice, using ![]() to format images just flows.

  • Of course you know. But if you've ever been part of a non-dev forum you've seen mods helping with embeds every other thread. I'm all for as much automation as possible.

  • Yeah, I completely get that sentiment. It's part of the reason why NodeBB uses Markdown instead of BBCode, since I code is more legible and (to me, anyways) makes more sense to the layman.

    Still has a learning curve, though.

  • @julian

    The thing with Markdown is once you get the hang of it, it feels so natural. On my forum (not public yet), I'm finding that it's a lot easier to post content using NodeBB than WP. Using Markdown just flow

  • by wp you mean html? See I'm fine using both, but they're still a language other than english that someone must learn. Im not a fan of making anyone learn a web language just so they can format their posts. Not a fan of wysiwyg either as it's glitchy and too involved. WYSIWYG is good for learning what code does what, but eventually you need to learn the code. I learned html because of pagemill, if anyone remember that pre-dreamweaver gem. problem is it taught me to use iframes when i was 17, which wasn't great either.


Suggested Topics


  • 2 Votes
    3 Posts
    1k Views

    Many Thanks! this will make my application much simpler and more robust.

  • 2 Votes
    1 Posts
    1k Views

    Currently watching categories is opt-out. On forums having lots of new topics, this results in a huge number of items in example.com/unread. I think the unread page would be far more useful if watching categories was opt-in. That way /unread would contain only the items a user is interested in from the start and they won't have to go ignore a bunch of categories in order for /unread to become useful.

  • 1 Votes
    6 Posts
    2k Views

    @pitaj that's true but if not done properly, aliasing links could be very dangerous for a site's search engine ranking. Personally, I wouldn't go down that route (no pun intended ha).

  • 0 Votes
    1 Posts
    641 Views

    My biggest request by far is to have some sort of centralized permissions system for which groups have access to different functionalities of plugins. This permissions system would allow both user-specific and group-specific permission configuration and would mitigate the amount of small, permission-only plugin admin pages.

    This could be done by adding the hook filter:permissions.addFields and then doing something like the database module to get permissions of a certain user or group. This, along with a simplification of settings, would be super helpful for easier creation of plugins. Plugins are going to be the best part of this platform, and if they can be created with more ease, then this platform will be embraced more. This could be done via a plugin, but it would be so much better if it were included in the core.

    Client side features requested:

    API for accessing certain server-side functionalities. Post parsing on the client side (so I don't have to include markdown.js).

    Also, I should mention that after I'm done working on the 5 or so plugins I have in queue, I'm planning on developing a very strong polyfill server-side module library for bringing all browsers up to standard based on user-agent (to minimize unnecessary code).