flarum / issue-archive Goto Github PK

The idea is to add an radio button (or drop-down list) setting that will allow admins to specify what credentials users must supply when logging in. Ideally, there should be three settings:

• Users must enter their username and password
• Users must enter their mail address and password
• Users can enter either their username or mail address and password

This would allow admins to configure their sites for maximum user convenience (the third option) or for greater security (the second option, on the assumption that users will be able to hide their mail addresses from other board members as well as the genial public), in addition to the standard username/password combination (the first option).

Initially suggested in this thread in the Flarum forums:

http://discuss.flarum.org/d/288-login-method-configuration

Primary tags → categories
Secondary tags → tags

Consider renaming the whole extension to Taxonomy.

Also consider category "groups"/"headings"

and this: https://discuss.flarum.org/d/1144-should-the-categories-in-the-topic-list-be-right-aligned

We want to allow multiple discussions/posts to be selected, and then an action to be performed on all of them at once.

What needs to be done:

• Design the UX for this. My initial thought is that there could be a "select" option in the discussion/post controls menu, and when clicked, all of the controls menus for other discussions/posts turn into checkboxes. The action buttons could then be displayed in a box floating somewhere on the page?
• Work out implementation on the front-end. It will likely involve objects similar to DiscussionControls and PostControls.
• Work out implementation on the API-end. It will likely involve the JSON-API Bulk extension.

I don't know if it's supposed to be like this but for example if I read a topic "A" with 15 messages then there are 5 new messages added later on. If I mark "all as read" then click on the topic, I am directly redirected to the last message I read so here the 15th message but shouldn't I be redirect to the 20th message ?

I just signed up to the Flarum Community and got an email to activate my account. But the link wasn't clickable. I can copy the link and paste it into my browser but it isn't clickable. 🐭
I'm currently using Windows Mail on my tablet.

I just signed up to the Flarum Community and got an email to activate my account. But the link wasn't clickable. I can copy the link and paste it into my browser but it isn't clickable. 🐭
I'm currently using Windows Mail on my tablet.

From @tobscure on August 27, 2015 13:51

Similar to how you can view a tweet in Twitter and see all of the replies, and the replies to those replies, and so on. I want to experiment with this idea for Flarum's post mentions to see if it's viable/helpful.

Copied from original issue: flarum/mentions#9

Gambits are little pieces of search criteria that can be specified in the search string. Just like GitHub's search syntax.

Right now we've only implemented a few: is:unread and author:username in core, and tag:foo,bar, is:followed, is:ignored, is:sticky, and is:locked in their respective extensions.

We probably want to implement the following gambits:

• Multiple author search, separated by commas (author:username1,username2)
• created:date where date is the same syntax as on GitHub
• updated:date
• contributor:username1,username2
• replies:number where number is the same syntax as on GitHub
• ip:123.123.123.123

Pending flarum/framework#257, we will also want to have an in:title gambit which scopes fulltext search to only look in discussion titles.

We should also implement more gambits when searching users (i.e. /api/users?q=whatever), such as for filtering by group.

This is a precursor to an extensible advanced search interface which will come later.

From @tobscure on August 27, 2015 13:50

Sometimes it might be useful to specify a default sort order for a tag – like a News tag might want the most recently created discussions at the top (Newest) rather than the most recently updated discussions (Latest).

The database field for this is already in place – it just needs to be made use of!

What needs to be done:

• Update the CreateTag and EditTag command handlers to allow saving of the defaultSort property.
• Add the appropriate field to the admin JS extension's EditTagModal.
• Probably make the forum JS extend the IndexPage's params method and set the sort param depending on the tag that is currently selected.

Copied from original issue: flarum/tags#14

ref: http://discuss.flarum.org/d/597-does-flarum-support-postgres

From @tobscure on August 27, 2015 13:50

We should add a className to the body and each DiscussionListItem based on what tags are in use. Could be handy for doing some special tag-based styling.

What needs to be done:

• Extend IndexPage's config method to add a class (IndexPage--tag--{slug}) to the body based on the currently-active tag. Ensure that it is removed properly onunload.
• Extend DiscussionPage's config method to add classes (DiscussionPage--tag--{slug}) to the body based on the current discussion's tags. Ensure that they are removed properly onunload.
• Extract core's DiscussionListItem classes into a method that returns an object of class names, which is then applied to the root element using the classList util.
• Extend that new classNames method and add classes (DiscussionListItem--tag--{slug}) based on the discussion's tags.

Copied from original issue: flarum/tags#15

We have nice visual placeholders for posts that are loading... we should have them in the discussion list too!

We want to have first-class support for keyboard shortcuts, and we want it to be extensible.

What needs to be done:

• Work out a complete plan for what keyboard shortcuts will do what.
• Design what the UX for keyboard shortcut discovery will look like. I really like what the Mailbox app for Mac does – when you hold down the Command key, it superimposes the keyboard shortcuts directly over the UI elements that they activate. I think that would be a very cool way to do it, as opposed to a big wall of keys/actions (not easy to learn!)
• Implementation is something I'll sit down and nut out at some point.

ref: http://discuss.flarum.org/d/597-does-flarum-support-postgres

From @tobscure on August 27, 2015 13:51

I threw the Pusher extension together in a night without much thought, because I wanted to get the beta out the door :P

While it does the basics OK (update the discussion list, push new posts, and update the unread notifications count), it could be way better. And it's a mess and basically needs to be rewritten. Anyway, here's how I think it should be improved:

• Extract a lot of the code into core, so that the extension is effectively telling core "hey I just found out about this new post in this discussion – whatchu gunna do about it?" and then core shows the "1 updated discussions" button or updates the post stream or whatever. This will allow us to write other extensions for different push services without duplicating/having inconsistent implementations.
• Make it push more information about the discussion that was updated, so that we can check whether we already have the most up-to-date information, and don't have to extend addDiscussion.
• Don't say there are updated discussions if they are in a hidden tag
• Push to a user whenever they read notifications, so that the number of unread notifications stays in sync between browser windows.
• Push for discussion events (e.g. discussion renaming)
• Push for post likes
• Show a little bubble every time a notification is received (again, this is something that would probably belong in core)
• Push user online status (via presence channels? idk)

What needs to be done:

• Working out a plan of attack for that first bullet point is the most important thing.
• Reimplement the current basic features in a cleaner way.
• Create issues for the additional features.

Copied from original issue: flarum/pusher#1

From @tobscure on August 27, 2015 13:54

What needs to be done:

• Work out which formatting buttons to add, and how they should be implemented among multiple formatting extensions (Markdown/BBCode). Should each formatting extension implement its own formatting buttons with the same keys, and then the extension that's enabled last would "win" but buttons that it doesn't overwrite would still display?
• I envision they should be added to the TextEditor controls area (to the right of the submit/preview buttons); we should make sure this looks good and there's enough room for it. Could also consider putting them in a little popup that appears when you click on a button in that toolbar (like Google Inbox).

Copied from original issue: flarum/markdown#1

_1 Upvote_ I noticed as threads/topics are getting larger than my poor short term memory is causing an issue on Flarum. I noticed that I would start reading a topic and completely forget which topic I am currently reading.

For this reason I am going to suggest adding the title of the topic somewhere static. I'm not sure the best place for it, but I was thinking on the right sidebar maybe just above the scroll thing whose feature name I can't remember. :P (although, I'm not sure that location works for mobile devices)

From @tobscure on August 27, 2015 13:51

I threw the Pusher extension together in a night without much thought, because I wanted to get the beta out the door :P

While it does the basics OK (update the discussion list, push new posts, and update the unread notifications count), it could be way better. And it's a mess and basically needs to be rewritten. Anyway, here's how I think it should be improved:

• Extract a lot of the code into core, so that the extension is effectively telling core "hey I just found out about this new post in this discussion – whatchu gunna do about it?" and then core shows the "1 updated discussions" button or updates the post stream or whatever. This will allow us to write other extensions for different push services without duplicating/having inconsistent implementations.
• Make it push more information about the discussion that was updated, so that we can check whether we already have the most up-to-date information, and don't have to extend addDiscussion.
• Don't say there are updated discussions if they are in a hidden tag
• Push to a user whenever they read notifications, so that the number of unread notifications stays in sync between browser windows.
• Push for discussion events (e.g. discussion renaming)
• Push for post likes
• Show a little bubble every time a notification is received (again, this is something that would probably belong in core)
• Push user online status (via presence channels? idk)

What needs to be done:

• Working out a plan of attack for that first bullet point is the most important thing.
• Reimplement the current basic features in a cleaner way.
• Create issues for the additional features.

Copied from original issue: flarum/pusher#1

With my limited knowledge, here's what I'm thinking:

• Unit tests for backend classes. I think phpspec is the preferred tool here – we already have one spec thanks to @franzliedke.
• Functional/integration tests for the JSON-API. (Not sure what tool would be best for this?)
• Functional/integration tests for the extension API. (Ditto?)
• Unit tests for front-end utils, components, helpers, and models. (Probably using QUnit?)
• Acceptance tests for the whole thing.

Thoughts?

The JSON-API spec has a lot of details which we currently don't implement.

Related:

• flarum/framework#2148
• https://github.com/flarum/core/issues/2147

Since API tokens expire after 14 days, it's possible to be "logged out" while the client is open. You stop having permission to do things and stop getting non-public data, but the client still thinks it's logged in. We should detect if this has happened and get the client to prompt for a password so it can get a new token. (related to flarum/framework#219)

What needs to be done:

• In Flarum\Api\LoginWithHeader, if an invalid token is presented, we should return a 401 or 403 + error message.
• The client's app.request method should look for this specific error. If encountered, it should present a modal to the user asking them to re-enter their password. The modal should contain the username + avatar, a password input, a "login" button, and a "cancel" button.
• If the login button is clicked, it should attempt to get a new token from the API. If successful, dismiss the modal and carry on.
• If the cancel button is clicked, it should unset app.session.user and dismiss the modal.

From @tobscure on August 27, 2015 13:50

We should add a className to the body and each DiscussionListItem based on what tags are in use. Could be handy for doing some special tag-based styling.

What needs to be done:

• Extend IndexPage's config method to add a class (IndexPage--tag--{slug}) to the body based on the currently-active tag. Ensure that it is removed properly onunload.
• Extend DiscussionPage's config method to add classes (DiscussionPage--tag--{slug}) to the body based on the current discussion's tags. Ensure that they are removed properly onunload.
• Extract core's DiscussionListItem classes into a method that returns an object of class names, which is then applied to the root element using the classList util.
• Extend that new classNames method and add classes (DiscussionListItem--tag--{slug}) based on the discussion's tags.

Copied from original issue: flarum/tags#15

The JSON-API spec has a lot of details which we currently don't implement.

Related:

• flarum/framework#2148
• https://github.com/flarum/core/issues/2147

Gambits are little pieces of search criteria that can be specified in the search string. Just like GitHub's search syntax.

Right now we've only implemented a few: is:unread and author:username in core, and tag:foo,bar, is:followed, is:ignored, is:sticky, and is:locked in their respective extensions.

We probably want to implement the following gambits:

• Multiple author search, separated by commas (author:username1,username2)
• created:date where date is the same syntax as on GitHub
• updated:date
• contributor:username1,username2
• replies:number where number is the same syntax as on GitHub
• ip:123.123.123.123

Pending flarum/framework#257, we will also want to have an in:title gambit which scopes fulltext search to only look in discussion titles.

We should also implement more gambits when searching users (i.e. /api/users?q=whatever), such as for filtering by group.

This is a precursor to an extensible advanced search interface which will come later.

Mac OS and iOS hide scrollbars by default, which is good for Flarum's UI. But on Windows, we have things like this:

I don't know much about styling custom scrollbars, but I think we should try and make them look a little nicer if there's an easy CSS-only way.

_1 Upvote_ I noticed as threads/topics are getting larger than my poor short term memory is causing an issue on Flarum. I noticed that I would start reading a topic and completely forget which topic I am currently reading.

For this reason I am going to suggest adding the title of the topic somewhere static. I'm not sure the best place for it, but I was thinking on the right sidebar maybe just above the scroll thing whose feature name I can't remember. :P (although, I'm not sure that location works for mobile devices)

So that you can interact with the API freely on the server side.

e.g. if you want a new topic to be created for every new blog post, you generate a master key and stick it into a Flarum WordPress plugin.

A master key should allow performing actions with any user account, without the need to authenticate with a username/password. We should allow generation/revocation of multiple master keys.

What needs to be done:

• Create a table (api_keys) to store the keys in. They don't expire.
• Add an API endpoint to generate a new key, as well as one to delete an existing one.
• Add an admin interface to manage the keys. This can probably live as a sub-interface in an AdvancedPage, along with other stuff we'll add later.
• Alter the LoginWithHeader middleware to check for a master key (still need to work out how exactly it should be passed) as well as the ID of a user to log in as.

From @tobscure on August 27, 2015 13:50

We should add a className to the body and each DiscussionListItem based on what tags are in use. Could be handy for doing some special tag-based styling.

What needs to be done:

• Extend IndexPage's config method to add a class (IndexPage--tag--{slug}) to the body based on the currently-active tag. Ensure that it is removed properly onunload.
• Extend DiscussionPage's config method to add classes (DiscussionPage--tag--{slug}) to the body based on the current discussion's tags. Ensure that they are removed properly onunload.
• Extract core's DiscussionListItem classes into a method that returns an object of class names, which is then applied to the root element using the classList util.
• Extend that new classNames method and add classes (DiscussionListItem--tag--{slug}) based on the discussion's tags.

Copied from original issue: flarum/tags#15

From @tobscure on August 27, 2015 13:49

The database fields are already in place for this – they just need to be made use of!

What needs to be done:

• Update the CreateTag and EditTag command handlers to allow saving of the backgroundMode property.
• Add an API endpoint for uploading a background image (use core's avatar uploading stuff as inspiration).
• Add the appropriate fields to the admin JS extension's EditTagModal. The backgroundMode field should be a dropdown with the options repeat/no-repeat.
• Update the TagsPage to style tiles with their background images/modes.

Copied from original issue: flarum/tags#13

Primary tags → categories
Secondary tags → tags

Consider renaming the whole extension to Taxonomy.

Also consider category "groups"/"headings"

and this: https://discuss.flarum.org/d/1144-should-the-categories-in-the-topic-list-be-right-aligned

On the discussion hero, badges like "Locked" or "Pinned" should include their textual meaning. We have enough space...

As discussed on Gitter, because Nielsen.

I posted this on Gitter. I can't really express with words what's going on, other than to say that clicking on topics will not take me to the last comment in it, and that trying to go to the most recent comment takes clicking twice. Screen cap follows:

From @tobscure on August 27, 2015 13:49

The database fields are already in place for this – they just need to be made use of!

What needs to be done:

• Update the CreateTag and EditTag command handlers to allow saving of the backgroundMode property.
• Add an API endpoint for uploading a background image (use core's avatar uploading stuff as inspiration).
• Add the appropriate fields to the admin JS extension's EditTagModal. The backgroundMode field should be a dropdown with the options repeat/no-repeat.
• Update the TagsPage to style tiles with their background images/modes.

Copied from original issue: flarum/tags#13

We want to have first-class support for keyboard shortcuts, and we want it to be extensible.

What needs to be done:

• Work out a complete plan for what keyboard shortcuts will do what.
• Design what the UX for keyboard shortcut discovery will look like. I really like what the Mailbox app for Mac does – when you hold down the Command key, it superimposes the keyboard shortcuts directly over the UI elements that they activate. I think that would be a very cool way to do it, as opposed to a big wall of keys/actions (not easy to learn!)
• Implementation is something I'll sit down and nut out at some point.

• Add an animation when deleting a post
• Add an animation when deleting a discussion
• Add an animation for when an alert shows/hides

What needs to be done:

• In the deleteAction method of utils/PostControls, we need to scan the page for any corresponding post stream items (i.e. $('.PostStream-item[data-id="{postId}"]')). If any are found, perform a quick slideUp or fadeOut animation. Only commit the delete when the animation has finished to prevent the element from being redrawn away immediately.
• A similar thing can be done for utils/DiscussionControls and components/Alert.
• Consider/brainstorm other instances where animations may be helpful.

ref: http://discuss.flarum.org/d/597-does-flarum-support-postgres

The plan for the dashboard page is to have it as an open space for widgets that can be added by extensions and customised by the user:

What needs to be done:

• Come up with a base widget component or interface that extensions can extend to define their own widgets.
• Allow extensions to register their widgets on app.widgets or app.widgetComponents or something.
• Render widgets on the DashboardPage, based on the value of a config setting that stores the widget layout.
• Allow widgets to be added/removed/dragged around in the UI, and save the layout to that config setting.

With my limited knowledge, here's what I'm thinking:

• Unit tests for backend classes. I think phpspec is the preferred tool here – we already have one spec thanks to @franzliedke.
• Functional/integration tests for the JSON-API. (Not sure what tool would be best for this?)
• Functional/integration tests for the extension API. (Ditto?)
• Unit tests for front-end utils, components, helpers, and models. (Probably using QUnit?)
• Acceptance tests for the whole thing.

Thoughts?

The plan for the dashboard page is to have it as an open space for widgets that can be added by extensions and customised by the user:

What needs to be done:

• Come up with a base widget component or interface that extensions can extend to define their own widgets.
• Allow extensions to register their widgets on app.widgets or app.widgetComponents or something.
• Render widgets on the DashboardPage, based on the value of a config setting that stores the widget layout.
• Allow widgets to be added/removed/dragged around in the UI, and save the layout to that config setting.

From @tobscure on May 31, 2015 11:46

Need some kind of API in core that can be overridden by formatting extensions, so that we can just call a "quote" method on the text-editor component without having to worry about what formatting to use.

Copied from original issue: flarum/mentions#4

Currently when you search, Flarum shows a couple of relevant posts in the discussion list. But that's the extent of intra-discussion searching you can do.

What needs to be done:

• Spec out a UX for this. Ideas:
  • When viewing a discussion, typing in the search box could list the relevant posts in the dropdown?
  • We could highlight the matching posts in the scrubber scrollbar?
  • Or we could filter the posts so that the non-matching ones are hidden? (like esoTalk)

When viewing a topic the left pane disappears after hitting refresh, navigating via back button after following a link to an external site, clicking on a direct link to the topic from an external site, etc.

From @tobscure on August 27, 2015 13:54

What needs to be done:

• Work out which formatting buttons to add, and how they should be implemented among multiple formatting extensions (Markdown/BBCode). Should each formatting extension implement its own formatting buttons with the same keys, and then the extension that's enabled last would "win" but buttons that it doesn't overwrite would still display?
• I envision they should be added to the TextEditor controls area (to the right of the submit/preview buttons); we should make sure this looks good and there's enough room for it. Could also consider putting them in a little popup that appears when you click on a button in that toolbar (like Google Inbox).

Copied from original issue: flarum/markdown#1

1. Log in
2. Visit your profile, the status will say Online
3. Log out
4. Revisit your profile, it will still say Online (even when refreshed/from another browser)

Looking at the migrations I'm guessing the online status is totally derived from the one last_seen_time entry in the user table? There should be a way for the status to be terminated immediately if a user manually logs out.

_1 Upvote_ I noticed as threads/topics are getting larger than my poor short term memory is causing an issue on Flarum. I noticed that I would start reading a topic and completely forget which topic I am currently reading.

For this reason I am going to suggest adding the title of the topic somewhere static. I'm not sure the best place for it, but I was thinking on the right sidebar maybe just above the scroll thing whose feature name I can't remember. :P (although, I'm not sure that location works for mobile devices)

We have nice visual placeholders for posts that are loading... we should have them in the discussion list too!

When a post viewed, and I have a notification that tells me I should go read that post waiting for me, that notification should be marked as read...

Since API tokens expire after 14 days, it's possible to be "logged out" while the client is open. You stop having permission to do things and stop getting non-public data, but the client still thinks it's logged in. We should detect if this has happened and get the client to prompt for a password so it can get a new token. (related to flarum/framework#219)

What needs to be done:

• In Flarum\Api\LoginWithHeader, if an invalid token is presented, we should return a 401 or 403 + error message.
• The client's app.request method should look for this specific error. If encountered, it should present a modal to the user asking them to re-enter their password. The modal should contain the username + avatar, a password input, a "login" button, and a "cancel" button.
• If the login button is clicked, it should attempt to get a new token from the API. If successful, dismiss the modal and carry on.
• If the cancel button is clicked, it should unset app.session.user and dismiss the modal.

If you installed the forum in the root or in a folder and access your site either via http://example.com or http://example.com/flarum without the "www" or subdomain

You might have encounter a small problem when clicking to a discussion in this case no content was loaded.

Using firebug or your developer's browser tools there is an error that pops up on your javascript debugging console, in this case you may see something like this.

XMLHttpRequest cannot load http://www.example.com/api/discussions/1?page%5Bnear%5D=0. Invalid HTTP status code 500

or

Resource from origin 'http://www.example.com' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://example.com' is therefore not allowed access.

This happens because when Flarum starts an ajax call to the API it does it by using the "www" in the URL so if your site is http://example.com and you click on a discussion it will call the API via ajax to http://www.example.com/api/discussions/ which it is not allowed since its a security issue in this case is because they are not the same domain.

Anyway I think just a small edit somewhere where the URL writing is should fix this so will leave it to the experts at Flarum.

But at the moment what you can do is use the htaccess file to rewrite how people access your site in this case by adding the www.

In my case I am using Apache 2.2 so I added the following code to my htaccess file.

<IfModule mod_rewrite.c>
  RewriteEngine On
  # Rewrite "domain.com -> www.domain.com"
 RewriteCond %{HTTP_HOST} !^www\..+$ [NC]
 RewriteCond %{HTTP_HOST} (.+)$ [NC]
 RewriteRule ^(.*)$ http://www.%1/$1 [R=301,L]

</IfModule>

From @tobscure on August 27, 2015 13:50

Sometimes it might be useful to specify a default sort order for a tag – like a News tag might want the most recently created discussions at the top (Newest) rather than the most recently updated discussions (Latest).

The database field for this is already in place – it just needs to be made use of!

What needs to be done:

• Update the CreateTag and EditTag command handlers to allow saving of the defaultSort property.
• Add the appropriate field to the admin JS extension's EditTagModal.
• Probably make the forum JS extend the IndexPage's params method and set the sort param depending on the tag that is currently selected.

Copied from original issue: flarum/tags#14