People, I have seen references to people renaming Categories and there being problems - but I can't find out how the renaming is actually done. I have the default category "Uncategorised" with the first nine topics in there and I want to rename the Category to "General" - is there a way to do this without causing problems?
When it happens every visit to the front any page just comes out as a white page.
I suspect this is encoding related, somehow something is getting cached wrong. Perhaps a Rails bug. I tried debugging this but can not find the root cause. Last time it went away after a rebuild which may indicate it is encoding related.
So there should be something wrong with some keys because Transifex does not recognize they can be prlualized and thus we do not have where to input translations for the few pluralization keyword.
Keys affected:
js.filters.new.title
js.filters.unread.title
admin.badges.preview.grant_count
My guess is that in the client.en.yml file some pluralization keys are missing and that leads to Tranfiex not recognizing that a particular key should be pluralized:
Please could you explain a bit about what is the purpose of the Rebake? I struggle finding good word in Russian, so I'd like to better understand what it does exactly. Thanks.
groups.default_names.trust_level_N where N is 0 to 5.
What confuses me is that even in original English language the translation looks more like an identifier rather than like a human readable string, e.g. trust_level_0 and not Trust level 0.
So I wonder how safe it is to translate the string to something like уровень доверия 1 (Russian) instead of уровень_доверия_1 - what will it affect and what might break if I remove underscores and change the language? Should I also change anything else simultaneously if I translate these strings?
Is there a way to open the individual topic page in the right pane like what you see in nytimes.com comments. This is helpful to retain the context.
This is extremely useful when you scroll through 100 topics and choose one topic to read. When you hit the back button after reading the topic, the initial position is lost.
This was just reported on our forum, and it happens here too.
Not sure where else to post this, but trying to make an inline link [like this](url) freezes my browser completely and I have to close the tab for it to come back.
I have a private instance of Discourse that I've been running for about 1.5 years, a few dozen people use it, nothing too big.
This week I finally got around to upgrading it to the 1.0 release, and since then I've seen a huge number (well, 5!) of unsolicited join requests, which wasn't happening before. I'm wondering where these are coming from, how/why people are finding my site which I don't think I've publicized beyond its intended audience.
I can't find any mention of it in the current www.discourse.org site (about, faq, etc) but I recall from the earlier days there was going to be a public directory of discourse sites. I see a meta post about this from early 2013 which said this was planned and implied it would be on by default unless the discourse instance has a site password.
I went through the settings for my discourse instance and don't see anything that looks like an opt-in or opt-out for "list me in a directory of sites". In Settings::Login, I have selected "login required" and "must approve users" and have not selected "invite only" (I know I could turn that on, and will if I keep getting unsolicited join requests, but I would prefer to leave it possible for people I do give the link to to sign up without a formal invite). I don't believe I have a "site password" set and don't know where to find this setting either; I have a dim recollection this was a feature of the earlier days of Discourse that doesn't exist any more.
Anyway, I'm wondering if this public directory feature actually happened, and if there is some public listing of discourse sites that I added myself to accidentally when I upgraded. Or if not, if you have any other theories why the number of unsolicited join requests went from 0->5 this week.
When I search and then select the "show more" link at bottom, I expect to then be able to select "show less" instead of an X. It's smaller and harder to hit esp on mobile, and it also does not X out the window altogether but instead shows the "show less" search results. I suggest changing this X to "show less".
First, I've installed Discourse on my own Ubuntu Server 14.04 virtual machine following the Beginner Docker install guide for Digital Ocean, you know, just for trying. And It works great! Everything goes smooth! Amazing software.
Before installing Discourse, in addition to postgresql 9.3:
Later, I succesfully deployed Discourse on 'production' (on a physical machine) doing the same steps. On the firewall machine (Windows Server 2008 R2 - Forefront TMG 2010, which is my external DNS also) I created the rule to publish the server with its own subdomain. Now is running; although the infrastructure is not the best to say, Discourse loads pretty well.
Mail is working fine, the problem is when login on Discourse, it's seems like I'm not logged. Then I add (e. g.) '/latest' to my URL 'discourse.example.com' resulting 'discourse.example.com/latest', hit Enter, and it turns out that I've already logged (of course). This mean that 'sign up' and 'log in' button disappear, and finally shows the Avatar. Logout it's pretty much the same, seems like still logged, but user isn't logged anymore.
I guess the Forefront TMG in some way is messing with Discourse server. I've been trying different configurations settings on the publishing rule on the TMG, but nothing has worked yet.
Could we have have some clarity over the traffic lights visible on profiles for admin's (and possibly TL4 's? )
I get the impression that under the algorithm (some?) flagged posts are considered a detriment, but on our forum flags are also used to flag 'positive' posts for manually assigned badges. (Yes, I agree your flagging that post for $BADGE is correct)
If such clarity exists, can I have a link?
If my assumption/impression is true, can this be moved to bugs?
Okay, we've had about a dozen users now complain that it is too difficult to identify when a topic/post is old and we are seeing dozens of posts added to topics that are well over a year old.
First things first, yes, the Revive topic warning does show (but everyone seems to ignore it -- maybe because it is too similar to the Suggested Topics popup?). Secondly, the topic list is still making it hard to identify these. Yes, the activity column is blue, our users aren't noticing that either.
Is anyone else experiencing these issues with Discourse?
In app.yml, image uploads and new account verification emails break when changing from:
expose:
- "80:80"
- "2222:22"
to the following (9999 as an exampe):
expose:
- "9999:80"
- "2222:22"
... if you don't use URL rewriting to mask the external port number.
In my situation, I'm on a private internal network and want to run discourse on a server that already is hosting sites on 80 and 443. I can get to the instance of Discourse that I installed at http://www.mysite.com:9999 but when I try to upload images (into the site assets category, for example) the image paths all lack the port number.
So... I tried going back into the app.yml file and changing:
env:
DISCOURSE_HOSTNAME: 'www.mysite.com'
to the following:
env:
DISCOURSE_HOSTNAME: 'www.mysite.com:9999'
I then rebuilt the app. After that change, image uploads (into posts) worked, but avatar images were broken. The src for them became, for example:
I understand that @codinghorror might not want to discuss this, but I don't think the previous topic was ready to be closed. In fact, his final comment on the topic does leave a great, big question in my mind:
Why not? Why don't you have a policy requiring that when you fix a bug, you post a link to the Github commit in the relevant bug topic? You guys already do a pretty good job of policing the bug and feature categories to weed out duplicates, so that shouldn't be too big a problem. I know I really appreciate seeing those posts when they are put in there. Unfortunately, I usually only see them on bugs/features that are handled by @zogstrip and @elberet. From what I understand, your official dev team is less than 10 people, so it looks like you've already got over 20% of your team doing this on a regular basis. Why don't you want to make this additional layer of transparency part of your development standard for Discourse?
I'm not sure if this is the right place, but we've seen several posts (that are the only post for a given topic - so 1 topic 1 post) that get flagged, then automatically hidden (or hidden by Mod agreement), but the Topic remains visible on the topic listings, under New, Unread, the Category Listing, etc.
The only post of that topic was deemed not worth viewing, shouldn't it hide the topic too?
Hi, we are looking for someone that can help us to integrate Discourse with our actual PHP web. We need to extend tags plugin to let us create topics with tags using PHP and the API. Also that person will take care of Discourse system (upgrades, etc).
I see that in the latest update a nifty edit link has been added right at the top of wiki posts - I love this. Would it be possible to also display this link to anyone who has permission to edit the post? Maybe in a different color or simply with a different mouseover text? When I want to make a quick edit to a post, my eye is often drawn to that corner for an edit link because of the "last edited" button that is up there.