Created
November 7, 2023 05:41
-
-
Save SamSaffron/0d5420f281483bf3edb7aae1908d1fb4 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| title: | |
| The name of this site. Visible to all visitors including anonymous users. | |
| ------ | |
| The name of the community or site as displayed on browsers' title bars, in emails, and across various areas of the site. This name is also publicly visible to all users including guests. | |
| site_description: | |
| Describe this site in one sentence. Visible to all visitors including anonymous users. | |
| ------ | |
| Provide a concise summary of your site's purpose that will be visible to everyone, including those who are not logged in. | |
| short_site_description: | |
| Short description in a few words. Visible to all visitors including anonymous users. | |
| ------ | |
| A concise phrase summarizing the site, displayed to all visitors, including those who are not logged in. This description often appears alongside the site's title in search engine results and browser tabs. | |
| contact_email: | |
| Email address of key contact responsible for this site. Used for critical notifications, and also displayed on <a href='%{base_path}/about' target='_blank'>/about</a>. Visible to anonymous users on public sites. | |
| ------ | |
| Designate the primary email address for essential communication related to this site, such as receiving critical notifications. This email is also displayed on the <a href='%{base_path}/about' target='_blank'>site's about page</a> and is accessible to anyone visiting the site, including users who are not logged in, on public forums. | |
| contact_url: | |
| Contact URL for this site. When present, replaces email address on <a href='%{base_path}/about' target='_blank'>/about</a> and visible to anonymous users on public sites. | |
| ------ | |
| Set the URL for the contact page of your site, which is displayed on the <a href='%{base_path}/about' target='_blank'>about page</a> This URL will be shown instead of a contact email and is visible to both registered users and anonymous visitors if the site is public. | |
| notification_email: | |
| The from: email address used when sending all essential system emails. The domain specified here must have SPF, DKIM and reverse PTR records set correctly for email to arrive. | |
| ------ | |
| The "from" email address setting determines the sender address for all crucial system notifications and correspondence. This address is key in ensuring the deliverability of emails, as it requires proper setup of SPF, DKIM, and reverse PTR records on the domain to minimize the risk of messages being flagged as spam or rejected by recipient servers. Always confirm that the domain you use complies with these email authentication standards to maintain reliable email communication with your users. | |
| site_contact_username: | |
| A valid staff username to send all automated messages from. If left blank the default System account will be used. | |
| ------ | |
| Enter the username of a staff member to act as the sender for automated system messages. If no username is entered, the system default account is used to send such messages. This ensures that users have a point of contact for automated communications that appear personal and managed by a staff member. | |
| site_contact_group_name: | |
| A valid name of a group that gets invited to all automatically sent private messages. | |
| ------ | |
| Specify the group name that will be automatically included in private messages sent by the system. If the group name provided is not of an existing group, no group will be added to these messages. | |
| exclude_rel_nofollow_domains: | |
| A list of domains where nofollow should not be added to links. example.com will automatically allow sub.example.com as well. As a minimum, you should add the domain of this site to help web crawlers find all content. If other parts of your website are at other domains, add those too. | |
| ------ | |
| Specify a list of domains for which the 'nofollow' attribute should not be applied to outbound links. Subdomains of listed domains are also exempt automatically. For instance, adding 'example.com' covers 'sub.example.com'. It is recommended to include the domain of your own Discourse site to facilitate search engine crawling and indexing of all associated content. Furthermore, if your website spans multiple domains, consider adding them to this list to ensure comprehensive search engine visibility. | |
| company_name: | |
| Name of your company or organization. If left blank, no boilerplate Terms of Service or Privacy Notice will be provided. | |
| ------ | |
| Enter the name of your company or organization here. This will be used to generate default Terms of Service and Privacy Notices. If you choose not to provide a company name, these documents won't include any standard boilerplate specific to your company or organization. | |
| governing_law: | |
| Governing Law | |
| ------ | |
| Specify the jurisdiction that governs the legal aspects of the site, including Terms of Service and Privacy Policy. This is typically the country or state where the company operating the site is registered or conducts business. | |
| city_for_disputes: | |
| City for Disputes | |
| ------ | |
| Specify the city that will be used as the jurisdiction for resolving any disputes related to the use of this forum. This information is typically included in legal documents such as the forum's Terms of Service. | |
| logo: | |
| The logo image at the top left of your site. Use a wide rectangular image with a height of 120 and an aspect ratio greater than 3:1. If left blank, the site title text will be shown. | |
| ------ | |
| The main image used for branding, positioned at the top left of your site. Prefer a wide, rectangular image with a minimum height of 120 pixels and an aspect ratio exceeding 3:1 for optimal display. In the absence of a specified image, the site will default to displaying the site title text. | |
| logo_small: | |
| The small logo image at the top left of your site, seen when scrolling down. Use a square 120 × 120 image. If left blank, a home glyph will be shown. | |
| ------ | |
| The 'logo_small' is the image displayed in the upper left corner of your site when users scroll down. It is recommended to use a square image of 120x120 pixels for best results. If this setting is not configured, a default home icon will be displayed instead. This small logo can also be used as the system user's avatar if the relevant option is enabled. | |
| digest_logo: | |
| The alternate logo image used at the top of your site's email summary. Use a wide rectangle image. Don't use an SVG image. If left blank, the image from the `logo` setting will be used. | |
| ------ | |
| Choose a custom logo image to display at the top of your site's email summary. Optimal dimensions are a wider rectangle for better visual compatibility with email templates. Avoid using SVG format for this image. If this setting is not configured, the site will default to using the image specified in the `logo` setting. | |
| mobile_logo: | |
| The logo used on mobile version of your site. Use a wide rectangular image with a height of 120 and an aspect ratio greater than 3:1. If left blank, the image from the `logo` setting will be used. | |
| ------ | |
| Specify the logo image that will be displayed on the mobile version of your site. For best results, use a wide, rectangular image with a recommended height of 120 pixels and an aspect ratio exceeding 3:1. If this setting is not configured, the site will default to the image defined in the 'logo' setting. | |
| logo_dark: | |
| Dark scheme alternative for the 'logo' site setting. | |
| ------ | |
| Alternative logo for use with dark color schemes, as defined by the 'logo' site setting. | |
| logo_small_dark: | |
| Dark scheme alternative for the 'logo small' site setting. | |
| ------ | |
| This site setting is for the alternative 'small logo' used with the dark theme. Replace the default small logo with this when the site is viewed in a dark color scheme. | |
| mobile_logo_dark: | |
| Dark scheme alternative for the 'mobile logo' site setting. | |
| ------ | |
| Alternative logo for mobile view when the site is using a dark theme. | |
| large_icon: | |
| Image used as the base for other metadata icons. Should ideally be larger than 512 x 512. If left blank, logo_small will be used. | |
| ------ | |
| This setting allows you to define an image that serves as the foundation for other metadata icons on your site. The image should ideally have dimensions larger than 512 x 512 for optimal display. If you do not specify an image in this setting, the smaller logo image (logo_small setting) will be automatically used. | |
| manifest_icon: | |
| Image used as logo/splash image on Android. Will be automatically resized to 512 × 512. If left blank, large_icon will be used. | |
| ------ | |
| This setting refers to the image that will serve as the logo or splash screen on Android devices. The image will be automatically resized to 512 x 512 pixels. In case this setting is left empty, the 'large_icon' setting will be utilized instead. | |
| manifest_screenshots: | |
| Screenshots that showcase your instance features and functionality on its install prompt page. All images should be local uploads and of the same dimensions. | |
| ------ | |
| "This setting defines the screenshots used to demonstrate your website's features and capabilities on its installation prompt page. Please ensure that all images are locally uploaded and maintain uniform dimensions." | |
| favicon: | |
| A favicon for your site, see <a href='https://en.wikipedia.org/wiki/Favicon' target='_blank'>https://en.wikipedia.org/wiki/Favicon</a>. To work correctly over a CDN it must be a png. Will be resized to 32x32. If left blank, large_icon will be used. | |
| ------ | |
| Favicon for your site, which can be understood in detail by visiting <a href='https://en.wikipedia.org/wiki/Favicon' target='_blank'>https://en.wikipedia.org/wiki/Favicon</a>. To function properly via a Content Delivery Network (CDN), it must be in PNG format and will be automatically resized to 32x32 pixels. If no favicon is specified, the large_icon will be utilized as a default. | |
| apple_touch_icon: | |
| Icon used for Apple touch devices. A transparent background is not reccomended. Will be automatically resized to 180x180. If left blank, large_icon will be used. | |
| ------ | |
| This setting is used to specify the icon for Apple touch devices. It is recommended not to use an image with a transparent background. The image specified will be automatically resized to 180x180 pixels. In the absence of a specified icon, the image set as 'large_icon' will be utilized. | |
| opengraph_image: | |
| Default opengraph image, used when the page has no other suitable image. If left blank, large_icon will be used | |
| ------ | |
| This setting allows you to set the default opengraph image that will be used for link previews when a page doesn't have any other appropriate images to display. If this is left empty, the site's large icon image will be used as a fallback. | |
| twitter_summary_large_image: | |
| Twitter card 'summary large image' (should be at least 280 in width, and at least 150 in height, cannot be .svg). If left blank, regular card metadata is generated using the opengraph_image, as long as that is not also a .svg | |
| ------ | |
| This setting relates to the "summary large image" card type for Twitter. An image of at least 280 pixels in width and 150 pixels in height (excluding .svg format) should be used. If left unspecified, the general card metadata will be generated using the 'opengraph_image' setting, provided that it's not also in the .svg format. | |
| display_local_time_in_user_card: | |
| Display the local time based on a user's timezone when their user card is opened. | |
| ------ | |
| Show the current local time in a user's profile card based on their timezone settings. This information will be displayed every time their profile card is viewed. | |
| allow_user_locale: | |
| Allow users to choose their own language interface preference | |
| ------ | |
| Enables users to select their preferred language for navigating the site interface. | |
| set_locale_from_accept_language_header: | |
| set interface language for anonymous users from their web browser's language headers | |
| ------ | |
| Determine the interface language for anonymous visitors based on the language specified in their web browser's headers. | |
| support_mixed_text_direction: | |
| Support mixed left-to-right and right-to-left text directions. | |
| ------ | |
| Enable support for both left-to-right and right-to-left text orientations within the same site. | |
| categories_topics: | |
| Number of topics to show in /categories page. If set to 0, it will automatically try to find a value to keep the two columns symmetrical (categories and topics). | |
| ------ | |
| Determines the number of topics displayed on the /categories page. If set to 0, an optimal value will be calculated to maintain symmetry between the categories and topics columns. | |
| suggested_topics: | |
| Number of suggested topics shown at the bottom of a topic. | |
| ------ | |
| This setting determines the quantity of suggested topics that are displayed beneath the content of a current topic. These suggestions offer users more reading options and promote continued engagement with the site. | |
| limit_suggested_to_category: | |
| Only show topics from the current category in suggested topics. | |
| ------ | |
| "Display only topics from the currently viewed category in the suggestions section." | |
| suggested_topics_unread_max_days_old: | |
| Suggested unread topics should not be more than n days old. | |
| ------ | |
| Limit the age of unread topics suggested to users to a specified number of days. The indicated number in this setting determines how many days old an unread topic can be before it is no longer recommended in suggestions. | |
| suggested_topics_max_days_old: | |
| Suggested topics should not be more than n days old. | |
| ------ | |
| Recommended topics should only include topics that have been created within the specified number of days. | |
| ga_version: | |
| Version of Google Universal Analytics to use: v3 (analytics.js), v4 (gtag) | |
| ------ | |
| Select the version of Google Universal Analytics to utilize, either v3 (utilizes analytics.js) or v4 (utilizes gtag). The chosen version impacts the scripts loaded for tracking and data collection. | |
| ga_universal_tracking_code: | |
| Google Universal Analytics tracking code ID, eg: UA-12345678-9; see <a href='https://google.com/analytics' target='_blank'>https://google.com/analytics</a> | |
| ------ | |
| Enter the Google Universal Analytics tracking code ID for your site, formatted like 'UA-12345678-9'. It's used to integrate Google Analytics with your site for tracking and reporting website traffic. For more details, visit <a href='https://google.com/analytics' target='_blank'>https://google.com/analytics</a>. Please note, the tracking code is only active when your site is in production mode. | |
| ga_universal_domain_name: | |
| Google Universal Analytics domain name, eg: mysite.com; see <a href='https://google.com/analytics' target='_blank'>https://google.com/analytics</a> | |
| ------ | |
| Enter the domain name used for Google Universal Analytics, such as 'mysite.com'. This setting configures the analytics tracking for your site. You can find more information on Google's Universal Analytics at <a href='https://google.com/analytics' target='_blank'>https://google.com/analytics</a>. | |
| ga_universal_auto_link_domains: | |
| Enable Google Universal Analytics cross-domain tracking. Outgoing links to these domains will have the client id added to them. See <a href='https://support.google.com/analytics/answer/1034342?hl=en' target='_blank'>Google's Cross-Domain Tracking guide.</a> | |
| ------ | |
| Activate this setting for cross-domain tracking with Google Universal Analytics. It appends the client ID to outbound links directed to the domains specified. For more information about cross-domain tracking, refer to <a href='https://support.google.com/analytics/answer/1034342?hl=en' target='_blank'>Google's Cross-Domain Tracking Guide</a>. | |
| gtm_container_id: | |
| Google Tag Manager container id. eg: GTM-ABCD12E. <br/>Note: To use GTM when the Content Security Policy (CSP) is enabled, see the documentation on meta: <a href='https://meta.discourse.org/t/use-nonces-in-google-tag-manager-scripts/188296' target='_blank'>Use nonces in Google Tag Manager scripts</a>. | |
| ------ | |
| This is the identifier for your Google Tag Manager container. An example could be GTM-ABCD12E. If you've enabled the Content Security Policy (CSP), please refer to the following guide on how to use nonces in your Google Tag Manager scripts: <a href='https://meta.discourse.org/t/use-nonces-in-google-tag-manager-scripts/188296' target='_blank'>Use nonces in Google Tag Manager scripts</a>. This setting is particularly important for those who wish to use Google's services to manage and deploy marketing tags on their website without modifying the code. | |
| top_menu: | |
| Determine which items appear in the homepage navigation, and in what order. | |
| ------ | |
| Specify the items and their display order on the homepage navigation menu. | |
| post_menu: | |
| Determine which items appear on the post menu, and in what order. | |
| ------ | |
| Specify the elements that should be displayed on the post's interaction menu, as well as their sequence. This setting enables the site administrator to customize the options available for user interactions with posts. | |
| post_menu_hidden_items: | |
| The menu items to hide by default in the post menu unless an expansion ellipsis is clicked on. | |
| ------ | |
| This setting determines which menu items are initially hidden from the post menu and only become visible when the expansion ellipsis is clicked. | |
| share_links: | |
| Determine which items appear on the share dialog, and in what order. | |
| ------ | |
| "Specify the content and sequence that will appear in the share dialog box. This setting affects the sharing options available to users when they wish to share a topic. The order signifies the sequence in which these sharing options will be displayed." | |
| allow_username_in_share_links: | |
| Allow usernames to be included in share links. This is useful to reward badges based on unique visitors. | |
| ------ | |
| Include usernames in shareable links from the forum. This feature is beneficial for awarding badges based on the unique visitor count. Ensure that this feature is enabled whenever badges are awarded for user-invited visitor quantities. | |
| share_quote_visibility: | |
| Determine when to show quote sharing buttons: never, to anonymous users only or all users. | |
| ------ | |
| Define the conditions under which quote sharing buttons appear. Options include never displaying them, showing them exclusively to anonymous users, or making them visible to all users. This setting helps customize your site's user experience by controlling the visibility of these buttons. | |
| share_quote_buttons: | |
| Determine which items appear in the quote sharing widget, and in what order. | |
| ------ | |
| This setting allows you to specify the icons to be displayed in the quote sharing widget, as well as their order of appearance. These icons represent various platforms where quotes from the site can be shared. You can customize this setting to tailor it to the preferred sharing platforms of your users. | |
| desktop_category_page_style: | |
| Visual style for the /categories page. | |
| ------ | |
| This setting determines the visual layout of the /categories page on desktop. It includes options such as displaying subcategories with featured topics, showing the latest topics, or presenting top topics. The chosen style will influence how users interact and navigate through categories on the site. | |
| category_colors: | |
| A list of hexadecimal color values allowed for categories. | |
| ------ | |
| "Specifies the hexadecimal color codes that are permitted for categorization. These colors are used to visually distinguish different categories on the site." | |
| category_style: | |
| Visual style for category badges. | |
| ------ | |
| Determines the visual aesthetic of category badges on the site. | |
| default_dark_mode_color_scheme_id: | |
| The color scheme used when in dark mode. | |
| ------ | |
| This setting determines the color scheme that is applied by default when the site's dark mode is enabled. | |
| relative_date_duration: | |
| Number of days after posting where post dates will be shown as relative (7d) instead of absolute (20 Feb). | |
| ------ | |
| Defines the number of days post-publication when the dates of posts are displayed in a relative format (e.g., '7d') rather than an absolute one (e.g., '20 Feb'). If you set it to 7, for example, all posts younger than 7 days will have their dates presented in the relative format. | |
| topics_per_period_in_top_summary: | |
| Number of top topics shown in the default top topics summary. | |
| ------ | |
| Defines the quantity of top-ranking topics displayed in the default summary of popular topics. | |
| topics_per_period_in_top_page: | |
| Number of top topics shown on the expanded 'Show More' top topics. | |
| ------ | |
| Specify the number of top topics to display when the 'Show More' option under top topics is selected. Adjusting this setting allows you to manage the extent of content revelation on your page, thus influencing user engagement and navigation. | |
| top_page_default_timeframe: | |
| Default timeframe for the top page. | |
| ------ | |
| Specifies the default time period for determining top topics displayed on the homepage. This can be adjusted by users, but this setting establishes the initial timeframe when a user navigates to the site for the first time, or if a user hasn't specified a period preference. | |
| fixed_category_positions: | |
| If checked, you will be able to arrange categories into a fixed order. If unchecked, categories are listed in order of activity. | |
| ------ | |
| Enabling this setting allows categories to be organized according to a preset order. When disabled, categories are displayed based on the level of activity within them. | |
| fixed_category_positions_on_create: | |
| If checked, category ordering will be maintained on topic creation dialog (requires fixed_category_positions). | |
| ------ | |
| Enable this setting to ensure that the order of categories remains fixed when generating a new topic creation dialog. This feature needs the 'fixed_category_positions' setting to be enabled to function properly. | |
| enable_badges: | |
| Enable the badge system | |
| ------ | |
| "Turn on the badge system" | |
| max_favorite_badges: | |
| Maximum number of badges that user can select | |
| ------ | |
| Set the upper limit for the number of badges a user can favor. Favorited badges are highlighted in the user's profile. | |
| whispers_allowed_groups: | |
| Allow private communication within topics for members of specified groups. | |
| ------ | |
| "Permit members of selected groups to engage in private conversations within topics." | |
| hidden_post_visible_groups: | |
| Allow members of these groups to view hidden posts. Staff users can always view hidden posts. | |
| ------ | |
| Enable members of specified groups to access hidden posts on the site. The ability to view hidden posts is always granted to staff users, regardless of group memberships. | |
| push_notifications_prompt: | |
| Display user consent prompt. | |
| ------ | |
| Show a user consent banner for push notifications. This setting triggers a prompt asking users for permission to send them push notifications. It only appears when push notifications are not already enabled, are supported by the user's device, and the user has either made a post or is using a Progressive Web App (PWA). The prompt will not be shown again if the user has already dismissed it or granted/denied permission. | |
| push_notifications_icon: | |
| The badge icon that appears in the notification corner. A 96×96 monochromatic PNG with transparency is recommended. | |
| ------ | |
| Specify the icon to display in the corner of push notifications. It's best to use a monochromatic PNG measuring 96x96 pixels, which includes transparency for optimal visibility. | |
| enable_desktop_push_notifications: | |
| Enable desktop push notifications | |
| ------ | |
| Activate push notifications for the desktop interface. This feature enables real-time alerts from the site directly to your desktop, enhancing engagement and ensuring users are always updated. However, the effectiveness of this feature relies on browser support for push notifications. | |
| push_notification_time_window_mins: | |
| Wait (n) minutes before sending push notification. Helps prevent push notifications from being sent to an active online user. | |
| ------ | |
| Specifies the timeframe in minutes to delay push notifications. This delay optimizes the notification process by avoiding the dispatch of notifications to users who are currently active online. | |
| short_title: | |
| The short title will be used on the user's home screen, launcher, or other places where space may be limited. It should be limited to 12 characters. | |
| ------ | |
| The short_title is used as the title on the user's home screen, launcher, or any other location where space constraints exist. It is advised to restrict the length to up to 12 characters. | |
| base_font: | |
| Base font to use for most text on the site. Themes can override via the `--font-family` CSS custom property. | |
| ------ | |
| The 'base_font' controls the primary font utilized across the site for the majority of text content. However, this can be modified within individual themes by adjusting the `--font-family` CSS custom property. | |
| heading_font: | |
| Font to use for headings on the site. Themes can override via the `--heading-font-family` CSS custom property. | |
| ------ | |
| "Select the font style for the headings across your site. Note that your chosen themes have the ability to override this selection using the `--heading-font-family` CSS custom property." | |
| enable_sitemap: | |
| Generate a sitemap for your site and include it in the robots.txt file. | |
| ------ | |
| Activate this setting to auto-generate a sitemap for your site. The created sitemap will be incorporated into the robots.txt file, giving search engines a clear path to crawl and index your site's content more efficiently. | |
| sitemap_page_size: | |
| Number of URLs to include in each sitemap page. Max 50.000 | |
| ------ | |
| Specifies the maximum number of URLs that each sitemap page can contain, with a limit of 50,000 URLs. This setting helps you manage the size and organization of your sitemap, ensuring that each page contains an optimal number of URLs for easier navigation and indexing by search engines. | |
| enable_user_status: | |
| (experimental) Allow users to set custom status message (emoji + description). | |
| ------ | |
| Enables users to create a personalized status message that consists of an emoji and a custom description. This feature is still in an experimental phase. Please note that the visibility of a user's status message across various sections of the site is controlled by this setting. | |
| enable_user_tips: | |
| Enable new user tips that describe key features to users | |
| ------ | |
| Activates the feature that provides new users with handy tips, guiding them through key features of the site. | |
| page_loading_indicator: | |
| Configure the loading indicator which appears during page navigations within Discourse. 'Spinner' is a full page indicator. 'Slider' shows a narrow bar at the top of the screen. | |
| ------ | |
| Choose the type of loading indicator that becomes visible when users navigate from one page to another within your Discourse site. Select between 'Spinner', a full page indicator that spins during page transitions, or 'Slider', a slim bar displayed along the top edge of the screen. | |
| invite_only: | |
| All new users must be explicitly invited by trusted users or staff. Public registration is disabled. | |
| ------ | |
| Enables a mode where creation of new user accounts is strictly by invitation. Public sign-ups are not allowed when this setting is enabled. Invitations can only be sent by trusted users or staff members. | |
| login_required: | |
| Require authentication to read content on this site, disallow anonymous access. | |
| ------ | |
| Enables a feature requiring users to log in to read content on this site, effectively prohibiting access to anonymous users. | |
| must_approve_users: | |
| Staff must approve all new user accounts before they are allowed to access the site. | |
| ------ | |
| "Requires staff approval for all new user accounts before they are granted access to the site." | |
| invite_code: | |
| User must type this code to be allowed account registration, ignored when empty (case-insensitive) | |
| ------ | |
| This setting defines a unique code that a user needs to enter during account registration. If the code is left blank, it's disregarded. Please note that the code is case-insensitive. | |
| enable_local_logins: | |
| Enable local username and password login based accounts. WARNING: if disabled, you may be unable to log in if you have not previously configured at least one alternate login method. | |
| ------ | |
| "Turn local username and password login functionality on or off. Be aware that if you turn off this setting without configuring alternate login options, it may prevent further logins." | |
| enable_local_logins_via_email: | |
| Allow users to request a one-click login link to be sent to them via email. | |
| ------ | |
| Permits users to obtain a direct login link through email. When enabled, this feature can conveniently bypass the need to remember complex passwords, as the system will send an email containing a one-time-use login link upon request. | |
| allow_new_registrations: | |
| Allow new user registrations. Uncheck this to prevent anyone from creating a new account. | |
| ------ | |
| Enable or restrict new user sign-ups. When unchecked, this feature blocks the creation of new accounts. | |
| enable_signup_cta: | |
| Show a notice to returning anonymous users prompting them to sign up for an account. | |
| ------ | |
| "Enable the display of a notice encouraging returning visitors who are not logged in to create an account. This notice won't appear if new registrations aren't allowed, if the site is configured to invitation-only, or if login is required." | |
| enable_google_oauth2_logins: | |
| Enable Google Oauth2 authentication. This is the method of authentication that Google currently supports. Requires key and secret. See <a href='https://meta.discourse.org/t/15858' target='_blank'>Configuring Google login for Discourse</a>. | |
| ------ | |
| Activate Google's OAuth2 authentication. This setting allows users to authenticate their accounts using Google. A valid key and secret are necessary for this setting to work. Please refer to <a href='https://meta.discourse.org/t/15858' target='_blank'>Configuring Google login for Discourse</a> for detailed instructions on obtaining these credentials. | |
| google_oauth2_client_id: | |
| Client ID of your Google application. | |
| ------ | |
| The unique client identifier provided by your Google application, used for the authentication process. | |
| google_oauth2_client_secret: | |
| Client secret of your Google application. | |
| ------ | |
| The unique secret key assigned by Google to your registered application. This key is used for OAuth2 authentication when connecting to Google services. It should be kept confidential and never exposed or shared publicly. | |
| google_oauth2_prompt: | |
| An optional space-delimited list of string values that specifies whether the authorization server prompts the user for reauthentication and consent. See <a href='https://developers.google.com/identity/protocols/OpenIDConnect#prompt' target='_blank'>https://developers.google.com/identity/protocols/OpenIDConnect#prompt</a> for the possible values. | |
| ------ | |
| Specify a set of optional instructions, separated by spaces, that guide the authorization server on whether to prompt the user for reauthentication and consent. Additional information on the possible values for these instructions can be found at <a href='https://developers.google.com/identity/protocols/OpenIDConnect#prompt' target='_blank'>Google's OpenID Connect documentation</a>. For instance, if you want to force users to select an account and consent each time, the setting would be 'select_account consent'. | |
| google_oauth2_hd: | |
| An optional Google Apps Hosted domain that the sign-in will be limited to. See <a href='https://developers.google.com/identity/protocols/OpenIDConnect#hd-param' target='_blank'>https://developers.google.com/identity/protocols/OpenIDConnect#hd-param</a> for more details. | |
| ------ | |
| Specify a Google Apps hosted domain to confine sign-in mechanism. Users can only sign into the Discourse site using Google OAuth2 if their email address matches this hosted domain. For more information on Google Apps hosted domains, refer to <a href='https://developers.google.com/identity/protocols/OpenIDConnect#hd-param' target='_blank'>Google OpenID Connect protocol</a>. | |
| google_oauth2_hd_groups: | |
| (experimental) Retrieve users' Google groups on the hosted domain on authentication. Retrieved Google groups can be used to grant automatic Discourse group membership (see group settings). For more information see https://meta.discourse.org/t/226850 | |
| ------ | |
| "Use this experimental feature to access users' Google groups from a hosted domain during the authentication process. The obtained Google groups can be leveraged to automatically assign Discourse group memberships, as outlined in the group settings. Learn more about this feature from <a href='https://meta.discourse.org/t/226850'>this discussion</a>." | |
| google_oauth2_hd_groups_service_account_admin_email: | |
| An email address belonging to a Google Workspace administrator account. Will be used with the service account credentials to fetch group information. | |
| ------ | |
| Enter the email address of a Google Workspace administrator account. This email will be used in conjunction with service account credentials to retrieve group data. This feature is essential for enabling group-based access control via Google OAuth2 authentication. | |
| google_oauth2_hd_groups_service_account_json: | |
| JSON formatted key information for the Service Account. Will be used to fetch group information. | |
| ------ | |
| Key details, in JSON format, necessary for the Service Account. This data is vital to retrieve group-related information. | |
| enable_twitter_logins: | |
| Enable Twitter authentication, requires twitter_consumer_key and twitter_consumer_secret. See <a href='https://meta.discourse.org/t/13395' target='_blank'>Configuring Twitter login (and rich embeds) for Discourse</a>. | |
| ------ | |
| Activate Twitter login functionality. In order to successfully enable this setting, you must provide the 'twitter_consumer_key' and 'twitter_consumer_secret'. A step-by-step guide on how to configure Twitter login and rich embeds for Discourse can be found in this <a href='https://meta.discourse.org/t/13395' target='_blank'>link</a>. Please note that failure to provide the necessary keys may result in configuration warnings. | |
| twitter_consumer_key: | |
| Consumer key for Twitter authentication, registered at <a href='https://developer.twitter.com/apps' target='_blank'>https://developer.twitter.com/apps</a> | |
| ------ | |
| The Twitter Consumer Key is a unique identifier for your registered application on Twitter. It is used to authenticate requests to the Twitter API when enabling Twitter logins on your site. The key can be obtained from your application settings at <a href='https://developer.twitter.com/apps' target='_blank'>https://developer.twitter.com/apps</a> | |
| twitter_consumer_secret: | |
| Consumer secret for Twitter authentication, registered at <a href='https://developer.twitter.com/apps' target='_blank'>https://developer.twitter.com/apps</a> | |
| ------ | |
| Enter the consumer secret related to Twitter authentication here, which can be found and registered at <a href='https://developer.twitter.com/apps' target='_blank'>https://developer.twitter.com/apps</a>. This secret key connects your site to Twitter, enabling users to authenticate using their Twitter accounts. If this field is left blank or the key is incorrect, Twitter login functionality won't work properly. | |
| enable_facebook_logins: | |
| Enable Facebook authentication, requires facebook_app_id and facebook_app_secret. See <a href='https://meta.discourse.org/t/13394' target='_blank'>Configuring Facebook login for Discourse</a>. | |
| ------ | |
| Turn on Facebook logins to allow users to authenticate using their Facebook accounts. This functionality is dependent on the 'facebook_app_id' and 'facebook_app_secret'. For guidance on how to properly configure this, refer to <a href='https://meta.discourse.org/t/13394' target='_blank'>Configuring Facebook login for Discourse</a>. | |
| facebook_app_id: | |
| App id for Facebook authentication and sharing, registered at <a href='https://developers.facebook.com/apps/' target='_blank'>https://developers.facebook.com/apps</a> | |
| ------ | |
| The Facebook App ID used for authentication and content sharing, which can be registered on Facebook's developer portal at <a href='https://developers.facebook.com/apps/' target='_blank'>https://developers.facebook.com/apps</a>. Registering the App ID allows users to log in via their Facebook accounts and facilitates sharing of site content on Facebook. Always ensure the ID is valid to prevent any login or sharing issues. | |
| facebook_app_secret: | |
| App secret for Facebook authentication, registered at <a href='https://developers.facebook.com/apps/' target='_blank'>https://developers.facebook.com/apps</a> | |
| ------ | |
| The Facebook app secret is part of the Facebook authentication process. It needs to be registered at <a href='https://developers.facebook.com/apps/' target='_blank'>https://developers.facebook.com/apps</a>. This secret, together with the app ID, enables Facebook logins by setting up parameters for the authentication on the middleware. Make sure it's stored securely, as it plays a critical role in maintaining the integrity and security of your app on Facebook. It's also checked in the admin dashboard configuration to ensure Facebook logins are working correctly. | |
| enable_github_logins: | |
| Enable GitHub authentication, requires github_client_id and github_client_secret. See <a href='https://meta.discourse.org/t/13745' target='_blank'>Configuring GitHub login for Discourse</a>. | |
| ------ | |
| Allows the use of GitHub for user authentication. Utilizing this feature requires the input of both 'github_client_id' and 'github_client_secret'. For details on how to set up this feature, refer to <a href='https://meta.discourse.org/t/13745' target='_blank'>Configuring GitHub login for Discourse</a>. | |
| github_client_id: | |
| Client id for GitHub authentication, registered at <a href='https://github.com/settings/developers/' target='_blank'>https://github.com/settings/developers</a> | |
| ------ | |
| Enter the Client ID for GitHub authentication. This ID should be registered at <a href='https://github.com/settings/developers/' target='_blank'>https://github.com/settings/developers</a>. It is necessary to enable GitHub login functionality on your site, allowing users to authenticate with their GitHub accounts. | |
| github_client_secret: | |
| Client secret for GitHub authentication, registered at <a href='https://github.com/settings/developers/' target='_blank'>https://github.com/settings/developers</a> | |
| ------ | |
| Use this setting to input the client secret for GitHub authentication. The client secret is obtained when you register on GitHub's developer page, accessible at <a href='https://github.com/settings/developers/' target='_blank'>https://github.com/settings/developers</a>. It is necessary for enabling and securing the GitHub login feature on your Discourse site. | |
| enable_discord_logins: | |
| Allow users to authenticate using Discord? | |
| ------ | |
| Permits users to log in to the site using their Discord account credentials. | |
| discord_client_id: | |
| Discord Client ID (need one? visit <a href="https://discordapp.com/developers/applications/me">the Discord developer portal</a>) | |
| ------ | |
| The Discord Client ID is a unique identifier required to enable Discord logins on this site. If you don't already have one, you can obtain it from the <a href="https://discordapp.com/developers/applications/me">Discord developer portal</a>. | |
| discord_secret: | |
| Discord Secret Key | |
| ------ | |
| Discord Client Secret Key | |
| Used for authenticating and enabling Discord related features on the site, such as Discord logins. This secret key corresponds to the Discord application created for the website, and is necessary for securely communicating with the Discord API. Misuse may lead to unauthorized access so handle it carefully. | |
| discord_trusted_guilds: | |
| Only allow members of these Discord guilds to log in via Discord. Use the numeric ID for the guild. For more information, check the instructions <a href="https://meta.discourse.org/t/configuring-discord-login-for-discourse/127129">here</a>. Leave blank to allow any guild. | |
| ------ | |
| Restrict Discord login access to members of specific Discord guilds. Specify these guilds by entering their numeric IDs. Additional guidance can be found <a href="https://meta.discourse.org/t/configuring-discord-login-for-discourse/127129">here</a>. If this field is left empty, members of any guild can log in via Discord. | |
| auth_skip_create_confirm: | |
| When signing up via external auth, skip the create account popup. Best used alongside auth_overrides_email, auth_overrides_username and auth_overrides_name. | |
| ------ | |
| Skip the creation account confirmation popup when a user signs up using external authentication. This setting is most efficiently utilized when paired with auth_overrides_email, auth_overrides_username, and auth_overrides_name settings. | |
| auth_immediately: | |
| Automatically redirect to the external login system without user interaction. This only takes effect when login_required is true, and there is only one external authentication method | |
| ------ | |
| Automatically takes users to the external login system without needing to click on anything. This will only be active if the 'login_required' setting is turned on and only one external authentication method is available. | |
| auth_overrides_email: | |
| Overrides local email with external site email on every login, and prevent local changes. Applies to all authentication providers. (WARNING: discrepancies can occur due to normalization of local emails) | |
| ------ | |
| When this setting is enabled, at each login, a user's local email is replaced with the email associated with their external authentication provider, and any attempt to change the local email is prevented. This setting applies across all providers used for authentication. Please note that there's a risk of discrepancies as a result of local email normalization processes. | |
| auth_overrides_username: | |
| Overrides local username with external site username on every login, and prevent local changes. Applies to all authentication providers. (WARNING: discrepancies can occur due to differences in username length/requirements) | |
| ------ | |
| This setting replaces the local username with the username from an external site each time a user logs in, additionally, this prevents any alterations to the local username. This affects all types of authentication providers. Please heed caution as potential inconsistencies may occur due to varying username length and criteria on different platforms. | |
| auth_overrides_name: | |
| Overrides local full name with external site full name on every login, and prevent local changes. Applies to all authentication providers. | |
| ------ | |
| This setting replaces a user's local full name with their full name from an external site upon each login, while preventing any changes to the name locally. This functionality applies across all authentication providers. | |
| enable_discourse_connect: | |
| Enable sign on via DiscourseConnect (formerly 'Discourse SSO') (WARNING: USERS' EMAIL ADDRESSES *MUST* BE VALIDATED BY THE EXTERNAL SITE!) | |
| ------ | |
| "Activate the feature of signing in through DiscourseConnect, previously known as 'Discourse SSO'. Please note, the email addresses of users must be verified by the external site." | |
| discourse_connect_allowed_redirect_domains: | |
| Restrict to these domains for return_paths provided by DiscourseConnect (by default return path must be on current site). Use * to allow any domain for return path. Subdomain wildcards (`*.foobar.com`) are not allowed. | |
| ------ | |
| Specify the permitted domains for return paths provided by Discourse Connect. By default, the return path must be from the current site. Use '*' as a wildcard to permit return paths from any domain. Please note that wildcards ('*.foobar.com') for subdomains are not permitted. | |
| verbose_discourse_connect_logging: | |
| Log verbose DiscourseConnect related diagnostics to <a href='%{base_path}/logs' target='_blank'>/logs</a> | |
| ------ | |
| Logs detailed diagnostics related to DiscourseConnect to the <a href='%{base_path}/logs' target='_blank'>/logs</a> for problem-solving and analysis purposes. This includes flagging issues with understanding payloads and troubleshooting user creation failures. Useful for those who require deeper visibility into DiscourseConnect operations. | |
| discourse_connect_url: | |
| URL of DiscourseConnect endpoint (must include http:// or https://, and must not include a trailing slash) | |
| ------ | |
| The 'discourse_connect_url' is the URL designated for your DiscourseConnect endpoint. It must start with either 'http://' or 'https://', and should not end with a trailing slash. This setting plays crucial role in validating the Single Sign-On (SSO) feature, where the value should not be left empty, especially when two-factor authentication is enforced. The system uses this URL across multiple interfaces to establish secure communication for user authentication and authorization. | |
| discourse_connect_secret: | |
| Secret string used to cryptographically authenticate DiscourseConnect information, be sure it is 10 characters or longer | |
| ------ | |
| The Discourse Connect Secret is a confidential string used to ensure secure authentication of Discourse Connect data. It must be at least 10 characters in length to maintain a high level of security. | |
| discourse_connect_overrides_groups: | |
| Synchronize all manual group membership with groups specified in the groups attribute (WARNING: if you do not specify groups all manual group membership will be cleared for user) | |
| ------ | |
| This setting synchronizes all manually managed group memberships with the groups specified in the 'groups' attribute. Please be cautious: if no groups are specified, all manually managed group memberships will be removed from the user. | |
| discourse_connect_overrides_bio: | |
| Overrides user bio in user profile and prevents user from changing it | |
| ------ | |
| This setting replaces the user's existing bio in their profile and subsequently prohibits the user from modifying it. Activation of this setting is particularly useful when the bio information is managed through Discourse Connect and consistency across platforms is desired. | |
| discourse_connect_overrides_avatar: | |
| Overrides user avatar with value from DiscourseConnect payload. If enabled, users will not be allowed to upload avatars on Discourse. | |
| ------ | |
| When enabled, this setting replaces user avatars with the avatars provided in the DiscourseConnect payload. As a result, users will not have the ability to upload their own avatars on the site. | |
| discourse_connect_overrides_profile_background: | |
| Overrides user profile background with value from DiscourseConnect payload. | |
| ------ | |
| Replaces the background of a user's profile with the specified value from the DiscourseConnect payload. If the profile background is missing or should be overridden, this setting comes into action to update the profile background with the one provided via DiscourseConnect. | |
| discourse_connect_overrides_location: | |
| Overrides user location with value from DiscourseConnect payload and prevent local changes. | |
| ------ | |
| When enabled, this setting replaces the user's location data with the information received from DiscourseConnect and disallows any changes to the location from within the local platform. | |
| discourse_connect_overrides_website: | |
| Overrides user website with value from DiscourseConnect payload and prevent local changes. | |
| ------ | |
| Replaces the user's website with the information received from the DiscourseConnect payload and blocks further alterations on the site. This setting restricts users from updating their website details locally when enabled. | |
| discourse_connect_overrides_card_background: | |
| Overrides user card background with value from DiscourseConnect payload. | |
| ------ | |
| Replaces the background image of a user's card with the value received from the DiscourseConnect payload. This provides an option to customize user card backgrounds according to data received from an external DiscourseConnect source. | |
| discourse_connect_not_approved_url: | |
| Redirect unapproved DiscourseConnect accounts to this URL | |
| ------ | |
| Specify a URL to which unapproved users on DiscourseConnect will be redirected. If a user account hasn't been approved and this setting is activated, the user will be sent to the URL defined here rather than receiving an 'Account not approved' error message. | |
| enable_discourse_connect_provider: | |
| Implement DiscourseConnect (formerly 'Discourse SSO') provider protocol at the /session/sso_provider endpoint, requires discourse_connect_provider_secrets to be set | |
| ------ | |
| Activates the implementation of DiscourseConnect provider protocol at the /session/sso_provider endpoint. For this setting to function, the 'discourse_connect_provider_secrets' should be configured correctly. Formerly known as 'Discourse SSO', the provider protocol allows for single sign-on functionality. | |
| discourse_connect_provider_secrets: | |
| A list of domain-secret pairs that are using DiscourseConnect. Make sure DiscourseConnect secret is 10 characters or longer. Wildcard symbol * can be used to match any domain or only a part of it (e.g. *.example.com). | |
| ------ | |
| This setting manages pairs of domains and secrets for the use of DiscourseConnect. Each pair is formed by a domain and a secret code that should contain at least 10 characters. There is an option to use the wildcard symbol * to indicate any or part of a domain (e.g., *.example.com). This secret is used to authenticate and maintain security between sites using DiscourseConnect. | |
| blocked_email_domains: | |
| A pipe-delimited list of email domains that users are not allowed to register accounts with. Subdomains are automatically handled for the specified domains. Wildcard symbols * and ? are not supported. Example: mailinator.com|trashmail.net | |
| ------ | |
| Enter a list of email domains, separated by pipes, from which new user registrations are prohibited. The system will automatically manage subdomains for these specified parent domains. Note: the wildcard symbols * and ? are unsupported. For example: 'mailinator.com|trashmail.net' will block all registrations from mailinator.com and its subdomains, and trashmail.net and its subdomains. | |
| allowed_email_domains: | |
| A pipe-delimited list of email domains that users MUST register accounts with. Subdomains are automatically handled for the specified domains. Wildcard symbols * and ? are not supported. WARNING: Users with email domains other than those listed will not be allowed! | |
| ------ | |
| Specify a list of email domains, separated by a pipe "|", that users are required to use when registering for an account. The system automatically includes subdomains of the listed domains. Note that wildcard symbols such as * and ? are not supported. Be aware that users with email domains other than those specified in this list will be unable to register their accounts. | |
| normalize_emails: | |
| Check if normalized email is unique. Normalized email removes all dots from the username and everything between + and @ symbols. | |
| ------ | |
| Enables the system to ensure the uniqueness of a normalized email. A normalized email is one where all periods (.) from the user part of the email and everything included between the "+" symbol and "@" symbol are removed. | |
| auto_approve_email_domains: | |
| Users with email addresses from this list of domains will be automatically approved. Subdomains are automatically handled for the specified domains. Wildcard symbols * and ? are not supported. | |
| ------ | |
| Email addresses originating from the domains specified in this list will receive automatic approval. Subdomains linked to these domains are also included. Do note that wildcard characters such as * and ? are not supported in this setting. | |
| hide_email_address_taken: | |
| Don't inform users that an account exists with a given email address during signup or during forgot password flow. Require full email for 'forgotten password' requests. | |
| ------ | |
| Conceals the existence of an account with a specific email address during sign-up or password recovery processes. If enabled, users won't be given any indication that an email is already in use or not when signing up for a new account or retrieving a forgotten password. A full email address is always required for 'forgotten password' requests. | |
| log_out_strict: | |
| When logging out, log out ALL sessions for the user on all devices | |
| ------ | |
| Upon the activation of this setting, every session of a user on all connected devices will be ended upon logging out. This ensures a full clearance of their session, rather than just the one on the device they chose to log out of. | |
| pending_users_reminder_delay_minutes: | |
| Notify moderators if new users have been waiting for approval for longer than this many minutes. Set to -1 to disable notifications. | |
| ------ | |
| Alert the moderators when new users have waited for longer than the specified minutes for their account approval. To turn off these notifications, set the value to -1. | |
| persistent_sessions: | |
| Users will remain logged in when the web browser is closed | |
| ------ | |
| With this setting activated, users' login sessions continue even after the web browser is closed. This means users do not have to re-enter their credentials every time they revisit the site; they stay signed in between browsing sessions. The session's expiry is determined by the 'maximum_session_age' setting. | |
| maximum_session_age: | |
| User will remain logged in for n hours since last visit | |
| ------ | |
| The 'maximum_session_age' setting specifies the number of hours a user can remain logged in since their last visit. If a user does not revisit within this timeframe, their session will expire and they will need to log in again. | |
| min_username_length: | |
| Minimum username length in characters. WARNING: if any existing users or groups have names shorter than this, your site will break! | |
| ------ | |
| Defines the minimum number of characters required for a username. Be cautious when updating this setting as it could cause issues if there are existing users or groups with names shorter than the new minimum length setting. | |
| max_username_length: | |
| Maximum username length in characters. WARNING: if any existing users or groups have names longer than this, your site will break! | |
| ------ | |
| Set the upper limit for the number of characters allowed in usernames. Note: decreasing this from its current value can lead to issues if there are existing users or groups with longer names. Choose a value that accommodates your longest existing username or group name to avoid disruptions. | |
| unicode_usernames: | |
| Allow usernames and group names to contain Unicode letters and numbers. | |
| ------ | |
| Enable this setting to permit the inclusion of Unicode characters in usernames and group names. This grants users the flexibility to create usernames and group names using a wide variety of international characters and numerals. | |
| allowed_unicode_username_characters: | |
| Regular expression to allow only some Unicode characters within usernames. ASCII letters and numbers will always be allowed and don't need to be included in the allowlist. | |
| ------ | |
| Specify the pattern of Unicode characters permitted in usernames using a regular expression. By default, ASCII letters and numbers are always valid and don't need to be featured in the specification. This setting allows you to broaden the scope of acceptable characters for usernames. | |
| reserved_usernames: | |
| Usernames for which signup is not allowed. Wildcard symbol * can be used to match any character zero or more times. | |
| ------ | |
| "Reserved usernames" are specific names that are not permitted during the user registration process. You can utilize the wildcard symbol * to substitute for any character (or characters), enabling broad blocking of certain types of usernames. For example, admin* would restrict any username beginning with 'admin'. | |
| min_password_length: | |
| Minimum password length. | |
| ------ | |
| Defines the least number of characters required for user passwords on the site. A value that's too low might compromise security by making it easier for unauthorized parties to guess passwords, while a value that's too high might make it more difficult for users to remember their passwords. | |
| min_admin_password_length: | |
| Minimum password length for Admin. | |
| ------ | |
| Specify the minimum length of the password for Admin users. It ensures that all admin passwords meet a certain length requirement for enhanced security. This setting is essential to protect the Admin account from potential unauthorized access. | |
| password_unique_characters: | |
| Minimum number of unique characters that a password must have. | |
| ------ | |
| Specifies the minimum count of distinct characters that users are required to have in their passwords. This enhances password complexity and security by ensuring each password includes a variety of different characters. | |
| block_common_passwords: | |
| Don't allow passwords that are in the 10,000 most common passwords. | |
| ------ | |
| Disallows the usage of passwords found within the 10,000 most commonly used passwords. This setting ensures that users pick secure and unique passwords, thereby enhancing the account's security against potential brute-force or dictionary attacks. | |
| username_change_period: | |
| The maximum number of days after registration that accounts can change their username (0 to disallow username change). | |
| ------ | |
| Establish a time limit, in days, during which a user can change their username after their initial registration. Input '0' if you wish to prohibit users from changing their usernames. | |
| email_editable: | |
| Allow users to change their e-mail address after registration. | |
| ------ | |
| Permits users to modify their registered email address after they have completed the registration process. | |
| logout_redirect: | |
| Location to redirect browser to after logout (eg: https://example.com/logout) | |
| ------ | |
| Specify a URL to send users to after they log out. For instance, https://example.com/logout. If left blank or not provided, users will stay on the login page. This setting is especially useful when you want to direct users to a specific page for any post-logout activities or information. | |
| full_name_required: | |
| Full name is a required field of a user's profile. | |
| ------ | |
| This setting mandates the provision of a full name when creating a user profile. If enabled, the user will be required to enter their full name during registration. | |
| enable_names: | |
| Show the user's full name on their profile, user card, and emails. Disable to hide full name everywhere. | |
| ------ | |
| Enable this setting to display users' full names on their profile pages, user cards, and in emails. If this setting is disabled, users' full names will be hidden across the site. | |
| invite_expiry_days: | |
| How long user invitation keys are valid, in days | |
| ------ | |
| Define the lifespan of user invitation keys in days. Once an invitation is sent, the recipient must use the key within the specified number of days. After this period, the invitation key will no longer be valid and a new invitation will need to be issued. | |
| delete_user_max_post_age: | |
| Don't allow deleting users whose first post is older than (x) days. | |
| ------ | |
| Prevents the deletion of users who have made their first post more than a certain number of days ago. The number of days is configurable. | |
| delete_all_posts_max: | |
| The maximum number of posts that can be deleted at once with the Delete All Posts button. If a user has more than this many posts, the posts cannot all be deleted at once and the user can't be deleted. | |
| ------ | |
| "Delete All Posts Max" determines the upper limit for simultaneous post deletion using the 'Delete All Posts' button. If a user's post count exceeds this number, not all posts can be removed at once, preventing user deletion. Please note, this setting is applicable only for non-admin users and staff. | |
| delete_user_self_max_post_count: | |
| The maximum number of posts a user can have while allowing self-service account deletion. Set to -1 to disable self-service account deletion. | |
| ------ | |
| Maximum post count permitting self-deletion. Specifies the highest number of posts a user can have to still be able to delete their own account. Set the count to -1 if self-service account deletion should be disabled. | |
| redirect_users_to_top_page: | |
| Automatically redirect new and long absent users to the top page. | |
| ------ | |
| Initiate an automatic redirection to the top page for new users and those who have been inactive for an extended period. The redirection is conditional upon certain factors, such as trust level and latest activity. This setting also requires 'top' to be included in the top menu, and a determined minimum period set for redirection. | |
| prioritize_username_in_ux: | |
| Show username first on user page, user card and posts (when disabled name is shown first) | |
| ------ | |
| Display usernames before user names on user profiles, user cards, and posts. If disabled, the user's name will appear first. This setting adjusts the order of appearance between the username and user's actual name in various user-related interfaces. | |
| email_token_valid_hours: | |
| Forgot password / activate account tokens are valid for (n) hours. | |
| ------ | |
| Specifies the period of validity, in hours, for tokens used to reset passwords or activate accounts. After this period, the tokens will no longer be accepted and new ones must be issued. | |
| purge_unactivated_users_grace_period_days: | |
| Grace period (in days) before a user who has not activated their account is deleted. Set to 0 to never purge unactivated users. | |
| ------ | |
| Specify the grace period (in days) after which an account that hasn't been activated will be deleted. Setting this value to 0 will disable the automatic deletion of unactivated accounts. Note that this setting applies to non-admin and non-moderator accounts, and also accounts that have not participated in any topics or posted any replies. | |
| public_user_custom_fields: | |
| A list of user custom fields that can be retrieved with the API. | |
| ------ | |
| Identify a set of user custom fields available to be fetched with the API. This setting is beneficial when you need to access or display specific user data to enhance user profiles or discourse content. The custom fields defined here will be accessible from the user section of the API, allowing developers to extract additional user-specific information. | |
| staff_user_custom_fields: | |
| A list of user custom fields that can be retrieved for staff members with the API. | |
| ------ | |
| Define a set of custom user fields that are exclusively accessible by staff members through the API. This list can be used to specify additional user attributes exclusive to staff for more versatile data handling and management. For instance, these fields can serve as an extension to user profiles, by storing more detailed or specific information relevant only to the staff members. | |
| enable_user_directory: | |
| Provide a directory of users for browsing | |
| ------ | |
| Makes a user directory available for browsing. When enabled, this setting provides a comprehensive list of users on your site to facilitate easy navigation and exploration. | |
| allow_anonymous_posting: | |
| Allow users to switch to anonymous mode | |
| ------ | |
| Enable the option for users to switch to anonymous mode for posting. When activated, users can opt for their identities to be hidden when creating posts or topics throughout the site. | |
| allow_anonymous_likes: | |
| Allow anonymous users to like posts | |
| ------ | |
| Enable this setting to allow users who are browsing your site anonymously to "like" posts. When enabled, this setting might encourage engagement from visitors who are not currently signed in, by allowing them to interact with content. | |
| anonymous_posting_allowed_groups: | |
| Groups that are allowed to enable anonymous posting | |
| ------ | |
| "Specify the user groups which have the permission to post anonymously. Users from these groups will then have the option to keep their identity hidden while posting." | |
| anonymous_account_duration_minutes: | |
| To protect anonymity create a new anonymous account every N minutes for each user. Example: if set to 600, as soon as 600 minutes elapse from last post AND user switches to anon, a new anonymous account is created. | |
| ------ | |
| For enhanced user anonymity, this setting enables automatic creation of a new anonymous account after a specified duration in minutes. For instance, if the duration is set to 600, a new anonymous account will be established whenever 600 minutes have passed since the user's last post and the user has switched to anonymous mode. | |
| allow_users_to_hide_profile: | |
| Allow users to hide their profile and presence | |
| ------ | |
| Enable the option for users to conceal their profile and active status. When this setting is turned on, individual users have the choice to hide their profile details and online presence from other users. However, self and staff can always view a user's profile, regardless of their settings. | |
| hide_user_profiles_from_public: | |
| Disable user cards, user profiles and user directory for anonymous users. | |
| ------ | |
| Prevents anonymous users from viewing user cards, profiles, and the user directory, thereby increasing the privacy for registered users. | |
| allow_featured_topic_on_user_profiles: | |
| Allow users to feature a link to a topic on their user card and profile. | |
| ------ | |
| Enables users to highlight a specific topic on their user card and profile. | |
| show_inactive_accounts: | |
| Allow logged in users to browse profiles of inactive accounts. | |
| ------ | |
| Permit signed in users to view profiles of accounts that are not currently active. | |
| allowed_user_website_domains: | |
| User website will be verified against these domains. Pipe-delimited list. | |
| ------ | |
| Specify the domains that user websites should belong to. Enter multiple domains separated by a pipe (|). The system will validate a user's website against these specified domains. | |
| hide_suspension_reasons: | |
| Don't display suspension reasons publically on user profiles. | |
| ------ | |
| Enable this setting to prevent the public display of suspension reasons on user profiles. Only the staff and the individual user can view the reasons for any suspension when this setting is active. | |
| log_personal_messages_views: | |
| Log personal message views by Admin for other users/groups. | |
| ------ | |
| Enable logging of private message views by administrators for other users or groups. This setting allows to track and record when an administrator views a private message not originally intended for them, providing an additional layer of transparency. | |
| ignored_users_count_message_threshold: | |
| Notify moderators if a particular user is ignored by this many other users. | |
| ------ | |
| Alerts the moderators when a specific user is disregarded by a defined number of other users. This threshold can be adjusted according to the forum's requirements and activity level. The goal is to ensure any potentially problematic behavior is flagged, enhancing community harmony and user interaction. | |
| ignored_users_message_gap_days: | |
| How long to wait before notifying moderators again about a user who has been ignored by many others. | |
| ------ | |
| Specify the time interval after which the system will send another notification to moderators regarding a user who continues to be widely ignored. This setting helps manage the frequency of alerts to prevent overloading moderators with repetitive notifications about the same user. | |
| clean_up_inactive_users_after_days: | |
| Number of days before an inactive user (trust level 0 without any posts) is removed. To disable clean up set to 0. | |
| ------ | |
| Specify the duration, in days, after which an inactive user, who is at trust level 0 and hasn't made any posts, will be automatically removed from the site. Set this value to 0 if you wish to disable the automatic cleanup of inactive users. | |
| clean_up_unused_staged_users_after_days: | |
| Number of days before an unused staged user (without any posts) is removed. To disable clean up set to 0. | |
| ------ | |
| Specify the wait period (in days) before a staged user without any posts is eliminated from the system. For instance, if set to 30, staged users who haven't posted anything within 30 days of their creation will be automatically removed. You can stop this automatic deletion process by setting the value to 0. | |
| user_selected_primary_groups: | |
| Allow users to set their own primary group | |
| ------ | |
| Enables users to choose their primary group from among the available options. | |
| max_notifications_per_user: | |
| Maximum amount of notifications per user, if this number is exceeded old notifications will be deleted. Enforced weekly. Set to 0 to disable | |
| ------ | |
| Establishes the maximum number of notifications each user can have. If this limit is exceeded, the oldest notifications will be removed on a weekly basis. A setting of 0 disables this limit, allowing for unlimited notifications per user. | |
| gravatar_name: | |
| Name of the Gravatar provider | |
| ------ | |
| Specify the name of the Gravatar service provider. This name is typically used to identify the source providing Gravatar avatars to the site. | |
| gravatar_base_url: | |
| Url of the Gravatar provider's API base | |
| ------ | |
| Refined description: Specify the URL for accessing the Gravatar provider's API. This setting is critical for converting email addresses into Gravatar URLs where avatar images are stored. | |
| gravatar_login_url: | |
| Url relative to gravatar_base_url, which provides the user with the login to the Gravatar service | |
| ------ | |
| The URL, relative to the Gravatar base URL, that guides users to the Gravatar service login page. | |
| use_email_for_username_and_name_suggestions: | |
| Use the first part of email addresses for username and name suggestions. Note that this makes it easier for the public to guess full user email addresses (because a large proportion of people share common services like `gmail.com`). | |
| ------ | |
| Enables the use of the initial segment of a user's email address to create suggestions for usernames and names. Please be aware that this could potentially lead to easier guessing of a user's full email address by the public, especially for widely-used services like `gmail.com`. | |
| use_name_for_username_suggestions: | |
| Use a user's full name when suggesting usernames. | |
| ------ | |
| Incorporate a user's complete name as a factor while generating username suggestions. | |
| enable_group_directory: | |
| Provide a directory of groups for browsing | |
| ------ | |
| Allows for the creation of a comprehensive directory listing all groups for easy navigation and exploration by users. | |
| group_in_subject: | |
| Set %%{optional_pm} in email subject to name of first group in PM, see: <a href='https://meta.discourse.org/t/customize-specific-email-templates/88323' target='_blank'>Customize subject format for standard emails</a> | |
| ------ | |
| Sets the email subject of a private message to include the name of the first group involved in the conversation. More information on customizing email subject formats can be found here: <a href='https://meta.discourse.org/t/customize-specific-email-templates/88323' target='_blank'>Customize subject format for standard emails</a>. | |
| enable_category_group_moderation: | |
| Allow groups to moderate content in specific categories | |
| ------ | |
| Permits groups to regulate and oversee content within designated categories. | |
| min_post_length: | |
| Minimum allowed post length in characters (excluding personal messages) | |
| ------ | |
| Define the minimum character count required for a post (excluding personal messages). This excludes private messages which have their separate minimum length setting. If a post does not meet this requirement, it will be identified as invalid or too short. This parameter applies to posts in general topics and is adjusted according to the complexity of the text content. | |
| min_first_post_length: | |
| Minimum allowed first post (topic body) length (excluding personal messages) | |
| ------ | |
| "Specified the minimum character count required for the initial post in a new topic, not including personal messages." | |
| min_personal_message_post_length: | |
| Minimum allowed post length in characters for messages (both first post and replies) | |
| ------ | |
| Specifies the minimum number of characters required for both the initiating post and subsequent replies in a private message. It ensures that all personal messages maintain a certain length for meaningful conversation. | |
| max_post_length: | |
| Maximum allowed post length in characters | |
| ------ | |
| Establishes the upper limit for the length of a post, measured in characters. | |
| topic_featured_link_enabled: | |
| Enable posting a link with topics. | |
| ------ | |
| Allows users to associate a feature link with their topics. When turned on, topics can have a highlighted link attached, which is publicly visible and can be edited if the user has sufficient permissions. The feature link can enhance a topic's comprehensibility by providing related additional content. | |
| body_min_entropy: | |
| The minimum entropy (unique characters, non-english count for more) required for a post body. | |
| ------ | |
| Set a minimum threshold for text uniqueness in a post body, measured by entropy, with unique and non-English characters contributing more towards the uniqueness. This setting helps to ensure content originality and diversity in posts. | |
| min_topic_views_for_delete_confirm: | |
| Minimum amount of views a topic must have for a confirmation popup to appear when it gets deleted | |
| ------ | |
| Specifies the minimum number of views a topic should have before a confirmation popup gets triggered when a delete action is initiated. This precaution aims to avoid accidental deletion of popular topics. | |
| min_topic_title_length: | |
| Minimum allowed topic title length in characters | |
| ------ | |
| Specifies the least number of characters a topic title should contain. | |
| max_topic_title_length: | |
| Maximum allowed topic title length in characters | |
| ------ | |
| Defines the maximum number of characters that a topic title can have. | |
| title_min_entropy: | |
| The minimum entropy (unique characters, non-english count for more) required for a topic title. | |
| ------ | |
| Minimum Entropy of Topic Title: This setting specifies the obligatory amount of unique characters necessary for a title of a new topic. Titles must consist of a diverse set of characters to meet this requirement. Although all forms of text are acceptable, non-English characters carry more value as they contribute to enhancing the information richness in a title. | |
| allow_uppercase_posts: | |
| Allow all caps in a topic title or a post body. | |
| ------ | |
| Permit the use of uppercase letters in topic titles and post content. | |
| max_consecutive_replies: | |
| Number of posts in a row a user can make in a topic before being prevented from adding another reply. This limit does not apply to the topic owner, site staff, or category moderators. | |
| ------ | |
| The 'max_consecutive_replies' setting indicates the maximum number of successive replies a user can post in a singular topic before they are barred from adding another one. The restriction, however, does not extend to the topic's initiator, the site's administrative staff, or the moderators of the category. | |
| enable_filtered_replies_view: | |
| "(n) replies" button collapses all other posts and only shows the current post and its replies. | |
| ------ | |
| The 'enable_filtered_replies_view' setting activates a functionality that allows the 'replies' button to reveal only the responses related to a specific post, omitting unrelated posts. When enabled, clicking the 'replies' button hides all other discussions, helping users focus on the conversation pertinent to the post in question. | |
| title_prettify: | |
| Prevent common title typos and errors, including all caps, lowercase first character, multiple ! and ?, extra . at end, etc. | |
| ------ | |
| Automatically rectify common title issues such as an all-caps title, lowercase first character, redundant exclamation and question marks, unnecessary periods at the end, and more with the 'title_prettify' setting. | |
| title_remove_extraneous_space: | |
| Remove leading whitespaces in front of the end punctuation. | |
| ------ | |
| Trim leading spaces appearing before the end punctuation in topic titles. | |
| title_fancy_entities: | |
| Convert common ASCII characters to fancy HTML entities in topic titles, ala SmartyPants <a href='https://daringfireball.net/projects/smartypants/' target='_blank'>https://daringfireball.net/projects/smartypants/</a> | |
| ------ | |
| Transform common ASCII characters into more visually appealing HTML entities within topic titles, as accomplished by SmartyPants. For more details on SmartyPants, refer to this <a href='https://daringfireball.net/projects/smartypants/' target='_blank'>link</a>. This feature allows for a more aesthetically pleasing and engaging topic display. Keep in mind that the title length must not exceed the maximum limit specified for fancy titles. | |
| min_personal_message_title_length: | |
| Minimum allowed title length for a message in characters | |
| ------ | |
| Specify the shortest acceptable length for a personal message title in characters. The purpose of this setting is to ensure message title clarity and descriptiveness by setting a minimum character limit. | |
| max_emojis_in_title: | |
| Maximum allowed emojis in topic title | |
| ------ | |
| Establishes the maximum number of emojis permitted in a topic title. This setting restricts the quantity of emojis a user can use when creating or editing a topic title. If the set value is zero, it prevents the use of any emojis in topic titles. | |
| allow_uncategorized_topics: | |
| Allow topics to be created without a category. WARNING: If there are any uncategorized topics, you must recategorize them before turning this off. | |
| ------ | |
| Enable this setting to allow users to create topics without designating a category. Be advised, if you choose to disable this option later, ensure that all existing uncategorized topics have been assigned a category prior to switching it off. | |
| allow_duplicate_topic_titles: | |
| Allow topics with identical, duplicate titles. | |
| ------ | |
| Permit titles of topics to be identical, allowing multiple topics to share the exact same title. | |
| allow_duplicate_topic_titles_category: | |
| Allow topics with identical, duplicate titles if the category is different. allow_duplicate_topic_titles must be disabled. | |
| ------ | |
| Permits topics with matching titles provided they are in different categories. This setting only applies if the 'allow_duplicate_topic_titles' setting is turned off. | |
| min_title_similar_length: | |
| The minimum length of a title before it will be checked for similar topics. | |
| ------ | |
| Set the minimum number of characters a topic title must contain for the system to perform a check for similar existing topics. This helps to prevent duplication of topics. | |
| enable_system_message_replies: | |
| Allows users to reply to system messages, even if personal messages are disabled | |
| ------ | |
| Permits users to respond to system messages, irrespective of whether personal messages are turned off. | |
| personal_message_enabled_groups: | |
| Allow users within these groups to create messages and reply to messages. Trust level groups include all trust levels above that number, for example choosing trust_level_1 also allows trust_level_2, 3, 4 users to send PMs. Note that staff can always send messages no matter what. | |
| ------ | |
| Users from the groups specified in this setting are permitted to compose and respond to personal messages. If a trust level group is chosen, it also encompasses all trust levels above it. For instance, selecting 'trust_level_1' will enable users with trust levels 2, 3 and 4 to send personal messages as well. It should be noted that staff members, irrespective of the groups chosen, hold the freedom to send messages anytime. | |
| editing_grace_period: | |
| For (n) seconds after posting, editing will not create a new version in the post history. | |
| ------ | |
| This setting specifies the number of seconds after a post is made during which any edits to the post will not generate a new entry in the post's edit history. | |
| editing_grace_period_max_diff: | |
| Maximum number of character changes allowed in editing grace period, if more changed store another post revision (trust level 0 and 1) | |
| ------ | |
| Define the upper limit for character modifications during the editing grace period. If the edits exceed this quantity, an additional post revision will be logged. This setting predominantly applies to users at trust levels 0 and 1. | |
| editing_grace_period_max_diff_high_trust: | |
| Maximum number of character changes allowed in editing grace period, if more changed store another post revision (trust level 2 and up) | |
| ------ | |
| Defines the maximum number of characters that can be altered during the editing grace period without creating a new post revision. This applies to users at trust level 2 and above. If the edited content exceeds this character limit, a separate post revision will be stored. | |
| staff_edit_locks_post: | |
| Posts will be locked from editing if they are edited by staff members | |
| ------ | |
| If enabled, this setting will prevent further editing of a post once it has been edited by a staff member. However, exceptions apply: the changes must impact the content of the post, the staff editor cannot be the system user, and the original author of the post must not be a staff member. | |
| shared_drafts_category: | |
| Enable the Shared Drafts feature by designating a category for topic drafts. Topics in this category will be suppressed from topic lists for staff users. | |
| ------ | |
| Activate the Shared Drafts feature by allocating a specific category to house topic drafts. Topics situated in this category will be discreetly concealed from topic lists for staff members. | |
| shared_drafts_min_trust_level: | |
| Allow users to see and edit Shared Drafts. | |
| ------ | |
| Set the trust level required for users to view and modify Shared Drafts. This way, you can control who has access to these drafts, thus ensuring that only trusted or staff users can make changes to them. | |
| post_edit_time_limit: | |
| A tl0 or tl1 author can edit their post for (n) minutes after posting. Set to 0 for forever. | |
| ------ | |
| This setting specifies the duration, in minutes, a user at trust level 0 or 1 can edit their posts. For endless edit time, set the value to 0. This allows flexibility in permitting users to modify posts to correct typos, rephrase sentences or update information. | |
| tl2_post_edit_time_limit: | |
| A tl2+ author can edit their post for (n) minutes after posting. Set to 0 for forever. | |
| ------ | |
| The 'tl2_post_edit_time_limit' setting configures the duration (in minutes) that a user with trust level 2 or above has to make changes to their post after it has been submitted. If set to 0, users in this trust level can edit their posts without any time restriction. | |
| edit_history_visible_to_public: | |
| Allow everyone to see previous versions of an edited post. When disabled, only staff members can view. | |
| ------ | |
| Enables all users to view previous edits of a post. When this setting is disabled, only staff members have the privilege to view past versions of a post. | |
| delete_removed_posts_after: | |
| Posts removed by the author will be automatically deleted after (n) hours. If set to 0, posts will be deleted immediately. | |
| ------ | |
| Determines the delay in hours before posts removed by their authors are automatically eliminated. If you set this value to 0, removed posts will be instantaneously deleted upon removal. | |
| notify_users_after_responses_deleted_on_flagged_post: | |
| When a post is flagged and then removed, all users that responded to the post and had their responses removed will be notified. | |
| ------ | |
| Activates notifications for users who have participated in a post that was flagged and subsequently eliminated. Users will be notified if their responses to the flagged post were also removed. | |
| traditional_markdown_linebreaks: | |
| Use traditional linebreaks in Markdown, which require two trailing spaces for a linebreak. | |
| ------ | |
| Enable the use of traditional Markdown linebreaks, where a newline in your text requires two spaces at the end of the line. | |
| enable_markdown_typographer: | |
| Use typography rules to improve readability of text: replace straight quotes ' with curly quotes ’, (c) (tm) with symbols, -- with emdash –, etc | |
| ------ | |
| Activate the Markdown Typographer feature to enhance the appearance of your text content. This setting transforms straight quotes into curly quotes, replaces (c) and (tm) with their corresponding symbols, and changes double hyphens to an emdash, among other adjustments. By enabling this, your posts will appear more professional and easier to read. | |
| enable_markdown_linkify: | |
| Automatically treat text that looks like a link as a link: www.example.com and https://example.com will be automatically linked | |
| ------ | |
| Automatically transforms text that appears to be a web link into an actual hyperlinked format. URLs such as www.example.com and https://example.com will be converted into clickable links. | |
| markdown_linkify_tlds: | |
| List of top level domains that get automatically treated as links | |
| ------ | |
| Specify the top-level domains that should be automatically converted into clickable links. | |
| markdown_typographer_quotation_marks: | |
| List of double and single quotes replacement pairs | |
| ------ | |
| Enter the pairs of double and single quotation marks that you wish to use as replacements in your text formatting. This setting is part of typographical preferences for enhancing the visual presentation and readability of your posts. | |
| enable_rich_text_paste: | |
| Enable automatic HTML to Markdown conversion when pasting text into the composer. (Experimental) | |
| ------ | |
| Turn on this setting to allow automatic conversion of HTML content to Markdown format when it's pasted into the composer. Please note that this feature is still in the experimental phase, so its functionality may change. | |
| suppress_reply_directly_below: | |
| Don't show the expandable reply count on a post when there is only a single reply directly below this post. | |
| ------ | |
| Hide the expandable reply counter on a post when there is exactly one reply directly below the post. If enabled, this setting conceals the visibility of single replies located immediately beneath a post, providing a more streamlined view. | |
| suppress_reply_directly_above: | |
| Don't show the expandable in-reply-to on a post when there is only a single reply directly above this post. | |
| ------ | |
| Hides the in-reply-to expansion option in a post when it's responding to the one immediately above it, streamlining the reading experience by eliminating redundancy. | |
| suppress_reply_when_quoting: | |
| Don't show the expandable in-reply-to on a post when post quotes reply. | |
| ------ | |
| Conceal the expandable 'in-reply-to' section in a post when the post contains a quote from the reply. | |
| remove_full_quote: | |
| Automatically remove quotation if (a) it appears at the start of a post, (b) it is of an entire post, and (c) it is from the immediately preceding post. For details, see <a href='https://meta.discourse.org/t/removal-of-full-quotes-from-direct-replies/106857' target='_blank'>Removal of full quotes from direct replies</a> | |
| ------ | |
| Removes a full quote if it is included at the beginning of a post and if it is quoting the entire content of the most recent preceding post. To get more details, see <a href='https://meta.discourse.org/t/removal-of-full-quotes-from-direct-replies/106857' target='_blank'>Removal of full quotes from direct replies</a>. Please note that this setting does not apply to the first post in a topic. | |
| max_reply_history: | |
| Maximum number of replies to expand when expanding in-reply-to | |
| ------ | |
| Set the maximum number of reply posts to display when a user chooses to view the history of replies to a particular post. This includes both direct and indirect replies in the conversation chain. Adjust this setting to control how extensive the presented reply history will be. | |
| post_undo_action_window_mins: | |
| Number of minutes users are allowed to undo recent actions on a post (like, flag, etc). | |
| ------ | |
| Specify the duration in minutes within which users can reverse their recent actions on a post. These actions could include liking or flagging a post. After this time window is over, the actions become irreversible. | |
| enable_mentions: | |
| Allow users to mention other users. | |
| ------ | |
| Permits users to tag or reference each other in their posts using the '@' symbol. | |
| max_mentions_per_post: | |
| Maximum number of @name notifications anyone can use in a post. | |
| ------ | |
| Specifies the upper limit of user mentions, denoted by @name, that a single post is permitted to have. This constraint applies to all user posts, with exceptions made for staff members and trusted users. | |
| max_users_notified_per_group_mention: | |
| Maximum number of users that may receive a notification if a group is mentioned (if threshold is met no notifications will be raised) | |
| ------ | |
| Defines the maximum number of individuals in a group that can be alerted when the group is mentioned in a post. If the group's size surpasses this threshold, no group member will receive a notification. | |
| newuser_max_replies_per_topic: | |
| Maximum number of replies a new user can make in a single topic until someone replies to them. | |
| ------ | |
| Establishes the highest number of replies that a new user can contribute to a single topic, before receiving a response. This limit aims to encourage balanced participation and prevent potential spamming in discussions. | |
| newuser_max_mentions_per_post: | |
| Maximum number of @name notifications a new user can use in a post. | |
| ------ | |
| Cap on the number of @name mentions a newcomer can incorporate in a single post. This setting restricts the use of mentions by new users to prevent potential misuse or overuse. | |
| here_mention: | |
| Name used for a @mention to allow privileged users to notify up to 'max_here_mentioned' people participating in the topic. Must not be an existing username. | |
| ------ | |
| Specify a unique identifying term intended for @mentioning to enable users with requisite permissions to send notifications to up to the number of individuals as determined by 'max_here_mentioned', who are actively engaging in a topic. This identifying term must not match any existing username on the site. | |
| max_here_mentioned: | |
| Maximum number of mentioned people by @here. | |
| ------ | |
| Refined description: Defines the maximum limit for the number of users that can be tagged in a single post using the @here mention. A user is only allowed to mention up to this specified number of users in one message. | |
| min_trust_level_for_here_mention: | |
| The minimum trust level allowed to mention @here. | |
| ------ | |
| Specify the least trust level a user should have to utilize the @here mention. This function allows certain users to send notifications to all current participants in a specific topic. | |
| title_max_word_length: | |
| The maximum allowed word length, in characters, in a topic title. | |
| ------ | |
| Define the maximum number of characters permitted in a single word within a topic title. This enforces a limit on word length to ensure readability and consistency across all topic titles. | |
| allowed_link_domains: | |
| Domains that users may link to even if they don't have the appropriate trust level to post links | |
| ------ | |
| Specify the domains that users can link to, even without the required trust level typically needed to post links. This setting helps to whitelist certain domains, making them accessible to all users regardless of their trust level. | |
| newuser_max_links: | |
| How many links a new user can add to a post. | |
| ------ | |
| Specifies the maximum number of links that a newcomer can include in a post. Designed to limit potential spam, this rule is relaxed for users who have gained trust on the site. | |
| newuser_max_embedded_media: | |
| How many embedded media items a new user can add to a post. | |
| ------ | |
| Defines the maximum number of media items that a new user is allowed to embed in a post. This limitation helps in preventing spam and ensuring the quality of content from new or untrusted users. | |
| newuser_max_attachments: | |
| How many attachments a new user can add to a post. | |
| ------ | |
| Regulates the number of attachments that a new user is permitted to include in a post. | |
| post_excerpt_maxlength: | |
| Maximum length of a post excerpt / summary. | |
| ------ | |
| Set the maximum character count for a post's summary or excerpt. This limit helps to maintain brevity and readability in post previews. | |
| topic_excerpt_maxlength: | |
| Maximum length of a topic excerpt / summary, generated from the first post in a topic. | |
| ------ | |
| Set the maximum character length for the topic excerpt or summary. This summary is crafted from the initial post within a topic, and the chosen length restrictions will apply to this autogenerated synopsis. | |
| default_subcategory_on_read_only_category: | |
| Enables 'New Topic' button and selects a default subcategory to post on categories where the user is not allowed to create a new topic. | |
| ------ | |
| Activates the 'New Topic' button and automatically assigns a default subcategory for posting in categories where users do not have permission to start a new topic. This is especially useful for guiding the flow of content into specific subcategories when topic creation is restricted in the main category. | |
| show_pinned_excerpt_mobile: | |
| Show excerpt on pinned topics in mobile view. | |
| ------ | |
| Display excerpts for pinned topics when viewing on a mobile device. | |
| show_pinned_excerpt_desktop: | |
| Show excerpt on pinned topics in desktop view. | |
| ------ | |
| Displays a summary of pinned topics when viewed on a desktop. | |
| display_name_on_posts: | |
| Show a user's full name on their posts in addition to their @username. | |
| ------ | |
| Display the full name of a user alongside their username on all of their posts. | |
| show_time_gap_days: | |
| If two posts are made this many days apart, display the time gap in the topic. | |
| ------ | |
| Display a time marker in a topic when the time gap between two posts exceeds the specified number of days. This can be used to highlight significant breaks between postings within a single topic. | |
| short_progress_text_threshold: | |
| After the number of posts in a topic goes above this number, the progress bar will only show the current post number. If you change the progress bar's width, you may need to change this value. | |
| ------ | |
| When the total number of posts within a topic exceed this value, the progress bar simplifies to display only the current post number. Note that if you modify the width of the progress bar, it might necessitate an adjustment in this value as well. | |
| default_code_lang: | |
| Default programming language syntax highlighting applied to code blocks (auto, text, ruby, python etc.). This value must also be present in the `highlighted languages` site setting. | |
| ------ | |
| Specify the default programming language for code block syntax highlighting, such as 'auto', 'text', 'ruby', 'python', etc. The chosen language must also be listed in the 'highlighted languages' site setting. This selection determines the syntax highlighting scheme defaultly applied to code that's not manually classified. | |
| warn_reviving_old_topic_age: | |
| When someone starts replying to a topic where the last reply is older than this many days, a warning will be displayed. Disable by setting to 0. | |
| ------ | |
| If a user initiates a reply to a topic that hasn't seen activity for a specific number of days, a warning message will pop up. This duration can be adjusted by entering the desired number of inactive days which should trigger the warning. To deactivate this warning, simply set the value to 0. | |
| autohighlight_all_code: | |
| Force apply code highlighting to all preformatted code blocks even when they didn't explicitly specify the language. | |
| ------ | |
| Automatically apply syntax highlighting to all preformatted code blocks, even if a specific language isn't designated. | |
| highlighted_languages: | |
| Included syntax highlighting rules. (Warning: including too many languages may impact performance) see: <a href='https://highlightjs.org/static/demo/' target='_blank'>https://highlightjs.org/static/demo</a> for a demo | |
| ------ | |
| Refine the syntax highlighting for specific languages to enhance code readability. Including too many languages for syntax highlighting may affect site speed. You can check the syntax highlighting in action here: <a href='https://highlightjs.org/static/demo/' target='_blank'>https://highlightjs.org/static/demo</a>. Please note that languages should be separated by a vertical bar (|) for proper integration. | |
| delete_old_hidden_posts: | |
| Auto-delete any hidden posts that stay hidden for more than 30 days. | |
| ------ | |
| Automatically remove any posts that remain hidden for a period exceeding 30 days. | |
| enable_emoji: | |
| Enable emoji | |
| ------ | |
| Toggle the display and use of emojis in your Discourse instance. When enabled, users have the ability to insert emojis into their posts and other text-related fields, enhancing expressive communication. This also enables the emoji autocomplete function in the text editor. If disabled, emojis will not be rendered and users will not be able to access or use them. | |
| enable_emoji_shortcuts: | |
| Common smiley text such as :) :p :( will be converted to emojis | |
| ------ | |
| When enabled, common emoticon text such as :) , :p, :( will automatically be transformed into their corresponding emojis within the conversation. This provides a more visually engaging way to express emotions in the discourse. | |
| emoji_set: | |
| How would you like your emoji? | |
| ------ | |
| Select your preferred style of emoji. Different emoji sets can provide unique appearances to the emojis displayed on the site. | |
| emoji_autocomplete_min_chars: | |
| Minimum number of characters required to trigger autocomplete emoji popup | |
| ------ | |
| Define the least number of characters needed to display the emoji autocomplete popup. This functionality assists users as it provides suggestions for emoji completion based on the inputted characters. It is especially helpful when users aren't entirely sure of an emoji's exact title. | |
| enable_inline_emoji_translation: | |
| Enables translation for inline emojis (without any space or punctuation before) | |
| ------ | |
| Allows the interpretation of emojis that are written inline, meaning without any preceding space or punctuation. This setting will recognize and appropriately render such emojis in your posts. | |
| emoji_deny_list: | |
| These emoji will not be available to use in menus or shortcodes. | |
| ------ | |
| Specify the list of emojis that will be blocked from appearing in menus or in shortcodes. Any emojis added to this list will not be selectable in menus, and their shorthand codes will not trigger their corresponding emojis. | |
| approve_post_count: | |
| The amount of posts from a new or basic user that must be approved | |
| ------ | |
| This setting specifies the number of posts a new or basic user needs to have approved. The approval requirement ensures user-generated posts are monitored to maintain quality, particularly from those users at the basic trust level or lower. More posts need to be approved if the setting's value is increased. | |
| approve_unless_trust_level: | |
| Posts for users below this trust level must be approved | |
| ------ | |
| Posts authored by users with a trust level less than the configured value will be held back for approval before being published. | |
| approve_new_topics_unless_trust_level: | |
| New topics for users below this trust level must be approved | |
| ------ | |
| Users with a trust level below the one specified in this setting must obtain approval before they can create new topics. | |
| approve_suspect_users: | |
| Add suspicious users to the review queue. Suspicious users have entered a bio/website but have no reading activity. | |
| ------ | |
| Include users who display suspicious behavior in the review queue. Suspicious behavior is determined by the users having filled out a bio or website, but demonstrating no reading activity on the site. | |
| approve_unless_staged: | |
| New topics and posts for staged users must be approved | |
| ------ | |
| "Require approval for new topics and posts by staged users" | |
| notify_about_queued_posts_after: | |
| If there are posts that have been waiting to be reviewed for more than this many hours, send a notification to all moderators. Set to 0 to disable these notifications. | |
| ------ | |
| Specifies the duration in hours that queued posts will wait to be reviewed before sending a notification to all moderators. If this is set to 0, no notifications will be triggered for posts pending review. | |
| auto_close_messages_post_count: | |
| Maximum number of posts allowed in a message before it is automatically closed (0 to disable) | |
| ------ | |
| Specify the maximum number of posts permitted in a message before it's automatically closed. Setting this value to 0 will disable the auto-close feature. | |
| auto_close_topics_post_count: | |
| Maximum number of posts allowed in a topic before it is automatically closed (0 to disable) | |
| ------ | |
| Set the maximum number of posts that a topic can have before it's automatically closed. Enter '0' if you want to deactivate this feature. | |
| auto_close_topics_create_linked_topic: | |
| Create a new linked topic when a topic is auto-closed based on 'auto close topics post count' setting | |
| ------ | |
| Enable this setting to automatically generate a related topic when an existing one is auto-closed due to reaching the 'auto close topics post count' limit. This ensures the conversation can continue in a new topic once the threshold for maximum posts in the original one has been surpassed. | |
| code_formatting_style: | |
| Code button in composer will default to this code formatting style | |
| ------ | |
| The 'Code' button in the composer will apply the preferred code formatting style determined by this setting. The available styles might include, for example, '4-spaces-indent'. | |
| embed_any_origin: | |
| Allow embeddable content regardless of origin. This is required for mobile apps with static HTML. | |
| ------ | |
| Enables embedded content from any source. This setting is necessary for mobile applications that utilize static HTML. | |
| embed_topics_list: | |
| Support HTML embedding of topics lists | |
| ------ | |
| Enable the embedding of topic lists in HTML format. This setting allows you to incorporate lists of topics from your forum into other websites in a compatible and easy-to-use manner. However, prior to attempting this action, ensure you are familiar with HTML practices, and remember that toggling this setting off will disable this feature. | |
| embed_set_canonical_url: | |
| Set the canonical URL for embedded topics to the embedded content's URL. | |
| ------ | |
| Use the URL of the embedded content as the canonical URL for embedded topics. This setting configures embedded topic URLs to mirror their original source URL. | |
| embed_unlisted: | |
| Imported topics will be unlisted until a user replies. | |
| ------ | |
| When enabled, this setting ensures that imported topics remain hidden from the forum's public listing. They only become visible once a user replies to them. However, this doesn't affect topics created by direct user interaction within the forum. | |
| embed_truncate: | |
| Truncate the embedded posts. | |
| ------ | |
| Shorten the contents of posts that are embedded from external sources. This setting ensures that only the initial part of content is displayed when a post from an external URL is embedded on your site. If you prefer to display full content from the external posts, you can disable this setting. | |
| embed_support_markdown: | |
| Support Markdown formatting for embedded posts. | |
| ------ | |
| Enable markdown formatting for posts that are embedded from external sites. If disabled, these posts will default to using raw HTML format. | |
| allowed_embed_selectors: | |
| A comma separated list of CSS elements that are allowed in embeds. | |
| ------ | |
| Specify a list of CSS elements, separated by commas, that are permitted for use in embedded content. This ensures that only specific CSS elements are included in the embedded sections, enhancing the control and security over the presentation and layout of the embedded material. | |
| allowed_href_schemes: | |
| Schemes allowed in links in addition to http and https. | |
| ------ | |
| Specify additional link schemes, besides HTTP and HTTPS, that are permitted within the content of your site. This ensures certain URLs with other schemes are not stripped out during content filtering. This list is entered as a pipe (|) separated string. | |
| max_allowed_message_recipients: | |
| Maximum recipients allowed in a message. | |
| ------ | |
| Sets the maximum number of recipients that can be included in a private message. Adjust this value to control the scale of private conversations on the site, keeping them to a manageable size. Please note that exceeding this limit can prevent the message from being sent. | |
| watched_words_regular_expressions: | |
| Watched words are regular expressions. | |
| ------ | |
| The setting 'watched_words_regular_expressions' allows the use of regular expressions for filtering words. If enabled, this feature groups sensitive words by their case-sensitivity. It then compiles all selected words into a single regular expression, adding word boundaries for regular watched words. Consequently, this regex-based filtering method adds an extra layer of control over content moderation by supporting more sophisticated word patterns. The setting also allows to easily substitute the original text with the replacement of choice. Please ensure correctness when using regular expressions to prevent unintended matches. | |
| enable_diffhtml_preview: | |
| Experimental feature which uses diffHTML to sync preview instead of full re-render | |
| ------ | |
| An experimental setting that utilizes diffHTML for synchronizing the preview instead of executing a full re-render. DiffHTML is a JavaScript library dedicated to minimizing changes to the Document Object Model (DOM) during updates, improving loading times and overall performance. When diffHTML is enabled, the system allows for faster, efficient previews in rendered contexts, such as audio, video, and generic elements. | |
| enable_fast_edit: | |
| Enables small selection of a post text to be edited inline. | |
| ------ | |
| Enabling this setting allows quick inline editing for small portions of a post's text. This means that rather than editing the entire post, users can selectively edit text portions directly on the page. This feature supplements the traditional editing mode with a faster, more streamlined option. | |
| old_post_notice_days: | |
| Days before post notice becomes old | |
| ------ | |
| The number of days after which a post notice is considered old. This directly impacts the "old" class being added to a post notice, which may visually differentiate it from newer notices on the site. | |
| new_user_notice_tl: | |
| Minimum trust level required to see new user post notices. | |
| ------ | |
| Establishes the least trust level necessary for viewing post notices from new users. | |
| returning_user_notice_tl: | |
| Minimum trust level required to see returning user post notices. | |
| ------ | |
| Specifies the minimum trust level a user must have to view the notices intended for returning members. | |
| returning_users_days: | |
| How many days should pass before a user is considered to be returning. | |
| ------ | |
| Specify the number of days that must elapse before a user is recognized as a returning user on the site. This parameter helps identify the frequency of user engagement within the platform. | |
| review_media_unless_trust_level: | |
| Staff will review posts of users with lower trust levels if they contain embedded media. | |
| ------ | |
| Posts containing embedded media from users with a lower trust level will require staff review. | |
| blur_tl0_flagged_posts_media: | |
| Blur flagged posts images to hide potentially NSFW content. | |
| ------ | |
| Enable this setting to automatically blur images in posts flagged by users. This feature aims to obscure potentially not-safe-for-work (NSFW) content. It's specifically applied to posts made by users with a trust level of 0. | |
| enable_page_publishing: | |
| Allow staff members to publish topics to new URLs with their own styling. | |
| ------ | |
| Enables staff members to post topics at unique URLs with their individual customizations. | |
| show_published_pages_login_required: | |
| Anonymous users can see published pages, even when login is required. | |
| ------ | |
| Published pages can be viewed by anonymous or unregistered users, even when the site necessitates login for other actions. | |
| skip_auto_delete_reply_likes: | |
| When automatically deleting old replies, skip deleting posts with this number of likes or more. | |
| ------ | |
| This setting defines the minimum number of likes that a post must receive to prevent it from being automatically deleted. When set to a particular value, any post with likes equal to or more than this value will not be subjected to automatic deletion. | |
| review_every_post: | |
| Send every new post to the review queue for moderation. Posts are still published immediately and are visible to all users. WARNING! Not recommended for high-traffic sites due to the potential volume of posts needing review. | |
| ------ | |
| All new posts are forwarded to the review queue for moderation when this setting is enabled. Even though posts are instantly published and can be viewed by all users, it's suggested to exercise caution with this setting for sites with high traffic, as it could lead to a large number of posts requiring review. | |
| max_form_template_title_length: | |
| Maximum allowed length for form template titles. | |
| ------ | |
| Set the upper limit for the length of form template titles. This keeps form templates concise and maintainable. | |
| max_form_template_content_length: | |
| Maximum allowed length for form template content. | |
| ------ | |
| Sets the upper limit for the character count in a form template. This means, when you create or edit a form template, the content you provide cannot exceed this limit. | |
| email_time_window_mins: | |
| Wait (n) minutes before sending any notification emails, to give users a chance to edit and finalize their posts. | |
| ------ | |
| This setting allows for a pause of a specified number of minutes before notification emails are dispatched, providing users with an opportunity to edit and perfect their posts. | |
| personal_email_time_window_seconds: | |
| Wait (n) seconds before sending any personal message notification emails, to give users a chance to edit and finalize their messages. | |
| ------ | |
| Establishes a delay period (in seconds) prior to sending email notifications related to personal messages. This latency allows users ample time to finalize and adjust their messages before notifications are sent to recipients. | |
| email_posts_context: | |
| How many prior replies to include as context in notification emails. | |
| ------ | |
| Specify the number of previous replies to include for context when sending notification emails. This setting allows you to customize the amount of conversation history that is included in email notifications, providing recipients with the context necessary to understand and engage in the discussion. | |
| digest_min_excerpt_length: | |
| Minimum post excerpt in the email summary, in characters. | |
| ------ | |
| Establishes the required character length for a post's summary in digest emails. The system will return an excerpt of the post once it has reached the set character threshold. If there is no text for the required length, it will include non-text elements such as images or oneboxes as part of the summary. | |
| digest_topics: | |
| The maximum number of popular topics to display in the email summary. | |
| ------ | |
| Define the maximum number of popular topics that should be displayed in the email summary. This setting helps to ensure that email summaries are informative but not too lengthy, showcasing the most engaging topics first. | |
| digest_posts: | |
| The maximum number of popular posts to display in the email summary. | |
| ------ | |
| Set the maximum number of popular posts to be included in the email digest. The popularity of a post is determined by its score, which takes numerous factors into account. If this value is set to 0, no posts will be included in the digest. Please note that only posts that are visible, not deleted by users, have a score higher than like_score * 5.0, and are older than the editing grace period are considered for inclusion. | |
| digest_other_topics: | |
| The maximum number of topics to show in the 'New in topics and categories you follow' section of the email summary. | |
| ------ | |
| Specify the maximum number of topics to display in the 'New in topics and categories you follow' section of the email summary. This helps to control the amount of information presented to the user in the digest emails, allowing them to stay informed without being overwhelmed. | |
| suppress_digest_email_after_days: | |
| Suppress summary emails for users not seen on the site for more than (n) days. | |
| ------ | |
| Prevent summary emails from being sent to users who have not visited the site for more than a specified number of days. You can specify this duration (n), after which the system will stop sending summary emails. It's a useful way to ensure you're not cluttering the inbox of inactive users. | |
| digest_suppress_categories: | |
| Suppress these categories from summary emails. | |
| ------ | |
| Exclude specified categories from inclusion in summary emails. This ensures that the content related to these categories is not present in the summary emails sent to users. | |
| digest_suppress_tags: | |
| Suppress these tags from summary emails. | |
| ------ | |
| Exclude tags listed here from appearing in the summary emails. Any topics linked with these tags won't be included in the digest email, providing a more personalized email content based on your preferences. | |
| disable_digest_emails: | |
| Disable summary emails for all users. | |
| ------ | |
| Turns off summary emails for every user on the site. When this option is enabled, all users will stop receiving emails highlighting popular topics and other content summaries from your site. | |
| apply_custom_styles_to_digest: | |
| Custom email template and css are applied to summary emails. | |
| ------ | |
| Enable this setting if you want your custom email template and CSS to be used in summary emails. This will allow the summary emails to have the same styling as the rest of your site's content. | |
| email_accent_bg_color: | |
| The accent color to be used as the background of some elements in HTML emails. Enter a color name ('red') or hex value ('#FF0000'). | |
| ------ | |
| Configure the accent color for the background of specified elements in your HTML emails. The color can be defined using standard color names like 'red', or hex values such as '#FF0000'. This setting allows you to maintain brand consistency and improve the aesthetics of the outgoing emails. | |
| email_accent_fg_color: | |
| The color of text rendered on the email bg color in HTML emails. Enter a color name ('white') or hex value ('#FFFFFF'). | |
| ------ | |
| Specifies the color of text that appears on the email background in HTML emails. A color name (for instance, 'white') or a hexadecimal value (such as '#FFFFFF') can be used for this setting. This is especially useful for maintaining visual contrast and readability in your emails. | |
| email_link_color: | |
| The color of links in HTML emails. Enter a color name ('blue') or hex value ('#0000FF'). | |
| ------ | |
| Define the color for hyperlinks included in HTML emails generated by the site. Input can either be a recognized color name such as 'blue', or a HEX color code in the format '#0000FF'. | |
| show_topic_featured_link_in_digest: | |
| Show the topic featured link in the digest email. | |
| ------ | |
| Enable the display of the featured topic link in the digest email. | |
| email_custom_headers: | |
| A pipe-delimited list of custom email headers | |
| ------ | |
| "Specify a list of customized headers for your emails, separating each with a pipe ('|'). These headers allow you to add additional information to emails, but be aware that any added headers that duplicate the standard ones will be overridden by the system defaults." | |
| email_subject: | |
| Customizable subject format for standard emails. See <a href='https://meta.discourse.org/t/customize-subject-format-for-standard-emails/20801' target='_blank'>https://meta.discourse.org/t/customize-subject-format-for-standard-emails/20801</a> | |
| ------ | |
| Define the pattern to be used for the subjects of standard emails sent from the site. It supports customization with several variables to reflect specifics of each email. Refer to <a href='https://meta.discourse.org/t/customize-subject-format-for-standard-emails/20801' target='_blank'>here</a> for more information and guidance on setting up your email subject format. | |
| reply_by_email_enabled: | |
| Enable replying to topics via email. | |
| ------ | |
| Activate the feature that permits users to respond to topics directly through email, instead of requiring them to log into the website. | |
| reply_by_email_address: | |
| Template for reply by email incoming email address, for example: %%{reply_key}@reply.example.com or replies+%%{reply_key}@example.com | |
| ------ | |
| Use this setting to specify the template for incoming email addresses when replying by email. The template can follow these two examples: %%{reply_key}@reply.example.com or replies+%%{reply_key}@example.com. The "%%{reply_key}" part of the template is replaced with a specific reply key generated by the system. Please note that the email domain should be configured to accept and forward emails to the Discourse installation. | |
| alternative_reply_by_email_addresses: | |
| List of alternative templates for reply by email incoming email addresses. Example: %%{reply_key}@reply.example.com|replies+%%{reply_key}@example.com | |
| ------ | |
| Specify a list of alternate email templates to be used for incoming reply-by-email addresses. For instance, you may use formats like %%{reply_key}@reply.example.com or replies+%%{reply_key}@example.com. This setting gives you flexibility in crafting custom email addresses for replying to topics, enhancing email manageability. | |
| find_related_post_with_key: | |
| Only use the 'reply key' to find the replied-to post. WARNING: disabling this allows user impersonation based on email address. | |
| ------ | |
| Utilizes the 'reply key' exclusively to identify the post being replied to. Disabling this option may allow for potential user impersonation via email addresses. Proceed with caution if choosing to disable. | |
| manual_polling_enabled: | |
| Push emails using the API for email replies. | |
| ------ | |
| Allows the use of API to push emails, specifically for responding to email notifications. This is useful in creating an interactive email experience without the need to visit the actual site. This option does not enable email polling automatically, it has to be done manually. | |
| pop3_polling_enabled: | |
| Poll via POP3 for email replies. | |
| ------ | |
| Activate POP3 polling to receive email replies. Upon activation, the system will check a specified POP3 mailbox for emails and handle them as topic replies. | |
| pop3_polling_ssl: | |
| Use SSL while connecting to the POP3 server. (Recommended) | |
| ------ | |
| Enable this setting to establish a Secure Sockets Layer (SSL) connection with the POP3 server. Using an SSL connection provides an additional layer of security by encrypting data transferred between the server and your site. This approach is highly recommended to ensure the protection of sensitive information. | |
| pop3_polling_openssl_verify: | |
| Verify TLS server certificate (Default: enabled) | |
| ------ | |
| Enables verification of the TLS server certificate for POP3 polling. If enabled, which is the default setting, the system will authenticate the TLS certificate provided by the server. This serves as an additional layer of security to ensure the certificate's credibility. | |
| pop3_polling_period_mins: | |
| The period in minutes between checking the POP3 account for email. NOTE: requires restart. | |
| ------ | |
| Specifies the interval, in minutes, at which the system checks the POP3 account for incoming emails. Please note that any changes to this setting will necessitate a system restart. | |
| pop3_polling_host: | |
| The host to poll for email via POP3. | |
| ------ | |
| Specify the host server from which the site retrieves email using the POP3 protocol. This is essential for enabling the email polling feature. Note that proper POP3 email polling setup also requires valid entries for the username and password fields. Invalid or empty fields may result in authentication errors or failure in retrieving emails. | |
| pop3_polling_port: | |
| The port to poll a POP3 account on. | |
| ------ | |
| Specify the port number for polling a POP3 account. This port is used to connect and retrieve emails from a remote POP3 mail server. | |
| pop3_polling_username: | |
| The username for the POP3 account to poll for email. | |
| ------ | |
| Enter the username associated with the POP3 account. This will be used to poll and retrieve emails. This information is required to successfully establish a connection with the email server. | |
| pop3_polling_password: | |
| The password for the POP3 account to poll for email. | |
| ------ | |
| Enter the password for the POP3 account that will be accessed to retrieve emails. The POP3 Polling Password, alongside the Host and Username settings, is essential for successful authentication and email retrieval. This information is sensitive and handled securely. | |
| pop3_polling_delete_from_server: | |
| Delete emails from server. NOTE: If you disable this you should manually clean your mail inbox | |
| ------ | |
| Enable this setting to automatically remove emails from your server after processing. If you choose to disable it, regular manual cleaning of your email inbox will be necessary to avoid clutter. | |
| log_mail_processing_failures: | |
| Log all email processing failures to <a href='%{base_path}/logs' target='_blank'>/logs</a> | |
| ------ | |
| Record all instances of email processing failures in the <a href='%{base_path}/logs' target='_blank'>/logs</a>, which can aid in troubleshooting and resolving potential issues related to email handling. | |
| incoming_email_prefer_html: | |
| Use HTML instead of text for incoming email. | |
| ------ | |
| Choose to interpret incoming emails in HTML format rather than plain text, if available. This is beneficial if the email contains HTML elements. If the incoming email doesn't provide an HTML version, the default plain text format will be used. | |
| strip_incoming_email_lines: | |
| Remove leading and trailing whitespaces from each line of incoming emails. | |
| ------ | |
| Eliminate unnecessary spaces at the start and end of each line in incoming emails. | |
| email_in: | |
| Allow users to post new topics via email. After enabling this setting, you will be able to configure incoming email addresses for groups and categories. | |
| ------ | |
| Enables users to launch new topics via email. Once this feature is activated, you'll have the ability to set up incoming email addresses for specific groups and categories. | |
| email_in_min_trust: | |
| The minimum trust level a user needs to have to be allowed to post new topics via email. | |
| ------ | |
| Specifies the lowest trust level that a user must possess to be permitted to create new topics via email. This setting aids in ensuring that only trusted users have the ability to initiate topics through email, providing a layer of protection against potential misuse or spam. | |
| email_in_authserv_id: | |
| The identifier of the service doing authentication checks on incoming emails. See <a href='https://meta.discourse.org/t/134358'>https://meta.discourse.org/t/134358</a> for instructions on how to configure this. | |
| ------ | |
| "Identifies the service responsible for authenticating incoming emails. To learn how to configure this, visit <a href='https://meta.discourse.org/t/134358'>https://meta.discourse.org/t/134358</a>. If this identifier is not set or left blank, the system will initially classify the email's authentication status as 'gray'" | |
| email_in_spam_header: | |
| The email header to detect spam. | |
| ------ | |
| Selects the specific email header to use for identifying spam. This option can be "X-Spam-Flag", "X-Spam-Status", or "X-SES-Spam-Verdict", and the email is tagged as spam based on the header's value. For instance, if the chosen setting is "X-Spam-Flag", an email with this header value set to "YES" would be classified as spam. | |
| enable_imap: | |
| Enable IMAP for synchronizing group messages. | |
| ------ | |
| Activate the IMAP protocol to synchronize group messages. | |
| enable_imap_write: | |
| Enable two-way IMAP synchronization. If disabled, all write-operations on IMAP accounts are disabled. | |
| ------ | |
| Activate two-way IMAP synchronization with this setting. When enabled, it permits modifications on IMAP accounts such as writing and updating. If this setting is turned off, all such modifications are prevented. | |
| enable_imap_idle: | |
| Use IMAP IDLE mechanism to wait for new emails. | |
| ------ | |
| Activate the IMAP IDLE mechanism to maintain a persistent connection and wait for new email notifications. This setting utilizes IMAP's capability to instantly alert the email client when a new email arrives in the mailbox. Please note that this feature depends on the email server's support for the IMAP IDLE command. | |
| enable_smtp: | |
| Enable SMTP for sending notifications for group messages. | |
| ------ | |
| Activates the SMTP protocol to facilitate the transmission of notification emails for group messages. When enabled, this ensures that email notifications are sent out from group inboxes, given that the group's SMTP credentials have been correctly configured. If not configured properly, these issues will be displayed on the admin dashboard as high priority errors. | |
| imap_polling_period_mins: | |
| The period in minutes between checking the IMAP accounts for emails. | |
| ------ | |
| Specifies the interval in minutes at which the IMAP accounts are scanned for incoming emails. This is the duration for which the system will idle, post which it will resume checking for new emails. | |
| imap_polling_old_emails: | |
| The maximum number of old emails (processed) to be updated every time an IMAP box is polled (0 for all). | |
| ------ | |
| Set the cap on the quantity of previously processed emails that can be updated each time an IMAP mailbox is polled. Use '0' for unlimited updates, allowing all old emails to be updated in a single polling cycle. | |
| imap_polling_new_emails: | |
| The maximum number of new emails (unprocessed) to be updated every time an IMAP box is polled . | |
| ------ | |
| Specifies the maximum number of new and unprocessed emails to be retrieved each time the system scans an IMAP mailbox. This setting is essential to control the amount of data transferred during each poll of the mailbox. | |
| imap_batch_import_email: | |
| The minimum number of new emails that trigger import mode (disables notifications for imported posts). | |
| ------ | |
| Indicates the threshold number of new incoming emails that will activate the import mode, temporarily suspending notifications for posts associated with the imported emails. A higher value ensures import mode triggers less frequently, while a lower value increases the probability of import mode activation with fewer new emails. | |
| email_prefix: | |
| The [label] used in the subject of emails. It will default to 'title' if not set. | |
| ------ | |
| The customizable label that appears in the subject line of emails sent from the site. If not specified, the site's title will be used as the default. | |
| email_site_title: | |
| The title of the site used as the sender of emails from the site. Default to 'title' if not set. If your 'title' contains characters that are not allowed in email sender strings, use this setting. | |
| ------ | |
| The email_site_title setting represents the name that appears as the sender when emails are dispatched from your site. It defaults to the 'title' if left unset. Use this feature if your 'title' includes character elements that are not compatible with email sender fields. | |
| disable_emails: | |
| Prevent Discourse from sending any kind of emails. Select 'yes' to disable emails for all users. Select 'non-staff' to disable emails for non-staff users only. | |
| ------ | |
| Control the email functionality of Discourse by either disabling all outgoing emails entirely or limiting it to only staff members. You can choose 'yes' to completely disable the sending of emails or 'non-staff' for sending emails exclusively to staff users. | |
| strip_images_from_short_emails: | |
| Strip images from emails having size less than 2800 Bytes | |
| ------ | |
| "Remove images from emails with a size of 2800 Bytes or less" | |
| short_email_length: | |
| Short email length in Bytes | |
| ------ | |
| Define the maximum length, in bytes, for an email to be classified as 'short' for image suppression. If an email's size does not exceed this setting, any images (such as avatars and emojis) within the email will be stripped out. | |
| display_name_on_email_from: | |
| Display full names on email from fields | |
| ------ | |
| Show the full names of users in the 'From' field of emails when this setting is enabled. This replaces the username with the user's full name, offering a more personalized touch if the option 'enable names' is also activated in the settings. | |
| unsubscribe_via_email: | |
| Allow users to unsubscribe from emails by sending an email with 'unsubscribe' in the subject or body | |
| ------ | |
| Enables users to opt out of email notifications by simply sending an email containing the word 'unsubscribe' in either the subject line or body. | |
| unsubscribe_via_email_footer: | |
| Attach an unsubscribe via email mailto: link to the footer of sent emails | |
| ------ | |
| Include an 'unsubscribe' email link in the footer of outbound emails. When this feature is turned on, a recipient can easily opt-out of future correspondence directly from the email's footer. | |
| disallow_reply_by_email_after_days: | |
| Disallow reply by email after (N) days. 0 to keep indefinitely | |
| ------ | |
| Set the maximum number of days after which email replies to posts are disallowed. Input '0' to allow email replies indefinitely. This setting is useful in controlling and managing the lifespan of email-based interactions on topics. | |
| delete_email_logs_after_days: | |
| Delete email logs after (N) days. 0 to keep indefinitely | |
| ------ | |
| Specifies the number of days email logs are to be retained before being deleted. Inputting 0 will preserve the email logs indefinitely. | |
| max_emails_per_day_per_user: | |
| Maximum number of emails to send users per day. 0 to disable the limit | |
| ------ | |
| Establishes the highest number of emails that can be dispatched to a single user within a day. Setting the value to 0 deactivates this limit. | |
| enable_staged_users: | |
| Automatically create staged users when processing incoming emails. | |
| ------ | |
| When this setting is enabled, users will be automatically generated upon receiving incoming emails. These users are referred to as 'staged users' and exist primarily to interact with email functionality. | |
| maximum_staged_users_per_email: | |
| Maximum number of staged users created when processing an incoming email. | |
| ------ | |
| Limit to the number of staged users that can be created from a single incoming email. This directly impacts the handling of emails where a multitude of users might be addressed, as it sets a cap on how many of these users can be staged at one time. | |
| maximum_recipients_per_new_group_email: | |
| Block incoming emails with too many recipients. | |
| ------ | |
| Prevents incoming emails addressed to too many recipients from becoming new group messages. The setting specifies the maximum number of email recipients allowed for each incoming group message. If the number of recipients exceeds this limit, the email will be rejected. | |
| auto_generated_allowlist: | |
| List of email addresses that won't be checked for auto-generated content. Example: foo@bar.com|discourse@bar.com | |
| ------ | |
| "Specify a list of email addresses that will be exempt from auto-generated content verification. This setting should contain the list formatted as: foo@bar.com|discourse@bar.com. The emails listed here will bypass any system checks for automatically generated emails." | |
| block_auto_generated_emails: | |
| Block incoming emails identified as being auto generated. | |
| ------ | |
| Prevent automated emails from coming into the system. This setting halts the influx of incoming emails that are recognized as being machine-generated, ensuring they do not make their way into your inbox. This does not apply to bounce emails and emails sent to the mailing list. | |
| ignore_by_title: | |
| Ignore incoming emails based on their title. | |
| ------ | |
| "Disregard incoming emails if their subject line matches a certain pattern." | |
| mailgun_api_key: | |
| Mailgun Secret API key used to verify webhook messages. | |
| ------ | |
| The Mailgun API key setting pertains to the secret API key required for Mailgun integration. It is used in authenticating and verifying webhook messages from Mailgun, as well as preventing replay attacks. The setting is relevant only when the reply-by-email feature is enabled and the SMTP address includes "smtp.mailgun.org". If the Mailgun API key is not appropriately set, certain functions such as handling Mailgun legacy and new parameters may encounter issues. | |
| sendgrid_verification_key: | |
| Sendgrid verification key used to verify webhook messages. | |
| ------ | |
| The Sendgrid verification key is utilized for validating incoming webhook messages from Sendgrid. This ensures that the messages are genuinely from Sendgrid and thus helps maintain the authenticity of the communication. If not configured, a lack of a verification key can lead to potential security risks, so it is strongly recommended to set it up correctly. | |
| mailjet_webhook_token: | |
| Token used to verify webhook payload. It must be passed as the 't' query parameter of the webhook, for example: https://example.com/webhook/mailjet?t=supersecret | |
| ------ | |
| The Mailjet webhook token is used to authenticate and validate the information received from webhooks. It should be provided as the 't' query parameter in the webhook URL. For instance: https://example.com/webhook/mailjet?t=yourtokengoeshere. If this token is absent during a webhook request, a warning will be issued about potential insecure actions, which may not be allowed in the future. | |
| mandrill_authentication_key: | |
| Mandrill authentication key used to verify webhook messages. | |
| ------ | |
| The Mandrill authentication key is employed for the purpose of validating webhook messages. Please ensure that this key is configured correctly, as a missing or invalid key can lead to insecure behavior and will be prohibited in future updates. | |
| postmark_webhook_token: | |
| Token used to verify webhook payload. It must be passed as the 't' query parameter of the webhook, for example: https://example.com/webhook/postmark?t=supersecret | |
| ------ | |
| The Postmark Webhook Token is a security measure used to authenticate webhook payloads. This token must be included as the query parameter 't' within the webhook URL. An example URL would be: https://example.com/webhook/postmark?t=yourtoken. If a Postmark webhook is received without a configured token, a warning message will be logged to signify potential unsafe practices. | |
| sparkpost_webhook_token: | |
| Token used to verify webhook payload. It must be passed as the 't' query parameter of the webhook, for example: https://example.com/webhook/sparkpost?t=supersecret | |
| ------ | |
| The SparkPost Webhook Token is a unique identifier that validates the payload of a webhook. This token should be included as the 't' query parameter in your webhook URL. For instance: https://example.com/webhook/sparkpost?t=yourtoken. If no token is configured, a warning will be issued indicating unsafe behavior, with future dismissal of such requests. | |
| bounce_score_threshold: | |
| Max bounce score before we will stop emailing a user. | |
| ------ | |
| Indicates the maximum bounce score a user can accumulate before all further email correspondence is suspended. The bounce score increments each time an email bounces back or fails to deliver. | |
| soft_bounce_score: | |
| Bounce score added to the user when a temporary bounce happens. | |
| ------ | |
| The Soft Bounce Score is the numerical value assigned to a user's account when an email from the Discourse forum temporarily fails to deliver. This could be due to reasons such as the user's mailbox being full, the mail server being temporarily down, or an email message being too large. | |
| hard_bounce_score: | |
| Bounce score added to the user when a permanent bounce happens. | |
| ------ | |
| The score assigned to a user when a permanent email bounce occurs. A "hard bounce" generally indicates a permanent reason an email cannot be delivered to the recipient, usually caused by invalid email addresses or unforeseen server issues. This setting is used to manage email delivery related issues by tracking persistent problems related to a user's email address. | |
| reset_bounce_score_after_days: | |
| Automatically reset bounce score after X days. | |
| ------ | |
| Set the number of days after which the bounce score for emails will be automatically reset. This ensures that if a user's email has been bouncing, their score will return to normal after the specified period. | |
| blocked_attachment_content_types: | |
| List of keywords used to blocklist attachments based on the content type. | |
| ------ | |
| Enter a list of keywords to block certain types of attachments. Restricted attachments are determined based on their content type. | |
| blocked_attachment_filenames: | |
| List of keywords used to blocklist attachments based on the filename. | |
| ------ | |
| Specify keywords to block certain attachments based on their filename. This ensures that attachments with filenames containing these specified keywords will not be permitted on the site. | |
| forwarded_emails_behaviour: | |
| How to treat a forwarded email to Discourse | |
| ------ | |
| Specify the action Discourse should take when it receives a forwarded email. This could be either to generate replies, to quote the forwarded content, or to hide the forwarded email. | |
| always_show_trimmed_content: | |
| Always show trimmed part of incoming emails. WARNING: might reveal email addresses. | |
| ------ | |
| Enable this setting to display the trimmed sections of incoming emails consistently. Be cautious, as this can inadvertently expose email addresses. Mostly suited for private messages. | |
| trim_incoming_emails: | |
| Trim part of the incoming emails that isn't relevant. | |
| ------ | |
| Refines the content of incoming emails by removing sections that are not pertinent to the discussion. | |
| private_email: | |
| Don't include content from posts or topics in email title or email body. NOTE: also disables digest emails. | |
| ------ | |
| Prevents any content from posts or topics from appearing in the email subject line or body when sending notifications. This also disables the sending of digest emails which are summaries sent to users typically containing highlights of new content from the forum. | |
| email_total_attachment_size_limit_kb: | |
| Max total size of files attached to outgoing emails in kB. Set to 0 to disable sending of attachments. | |
| ------ | |
| Specify the maximum cumulative size of files that can be attached to emails sent from the site, measured in kilobytes (kB). A setting of 0 will disable the addition of attachments to outgoing emails. | |
| post_excerpts_in_emails: | |
| In notification emails, always send excerpts instead of full posts | |
| ------ | |
| Enable this setting to ensure that only post excerpts, rather than the full text, are included in notification emails. | |
| raw_email_max_length: | |
| How many characters should be stored for incoming email. | |
| ------ | |
| Set the maximum number of characters that can be stored for each incoming email. If an email exceeds this limit, it will be truncated to fit within the defined number. | |
| raw_rejected_email_max_length: | |
| How many characters should be stored for rejected incoming email. | |
| ------ | |
| Specify the maximum number of characters to be retained from a rejected incoming email. This determines the characters stored when an email fails to comply with the established standard or rules. | |
| delete_rejected_email_after_days: | |
| Delete rejected emails older than (n) days. | |
| ------ | |
| Automatically purge rejected emails that are older than a specified number of days. These are emails that weren't accepted due to issues, such as invalid recipients or content, and exceeded the age limit set in this setting. | |
| require_change_email_confirmation: | |
| Require non-staff users to confirm their old email address before changing it. Does not apply to staff users, they always need to confirm their old email address. | |
| ------ | |
| The 'require_change_email_confirmation' setting ensures that non-staff users must verify their existing email address before it can be changed. This confirmation requirement does not extend to staff users, as they are already obligated to confirm their previous email address for security purposes. | |
| max_image_size_kb: | |
| The maximum image upload size in kB. This must be configured in nginx (client_max_body_size) / apache or proxy as well. Images larger than this and smaller than client_max_body_size will be resized to fit on upload. | |
| ------ | |
| "Specifies the maximum size in kilobytes for image uploads. Keep in mind that this size limit should also be configured in the nginx (client_max_body_size), apache, or proxy settings. If an image is larger than this limit but smaller than the client_max_body_size, it will automatically be resized during the upload process." | |
| max_attachment_size_kb: | |
| The maximum attachment files upload size in kB. This must be configured in nginx (client_max_body_size) / apache or proxy as well. | |
| ------ | |
| Establishes the maximum file size (in kilobytes) for attachments that can be uploaded on the site. It's crucial to note that this limit should be set up in line with the 'client_max_body_size' parameter in Nginx, or the equivalent in Apache or any other proxy being used. If a file exceeds this size limit, the upload will be rejected. | |
| max_image_megapixels: | |
| Maximum number of megapixels allowed for an image. Images with a higher number of megapixels will be rejected. | |
| ------ | |
| Define the upper limit for the permitted megapixels in an image. Any image exceeding this limit will be prevented from uploading. This is particularly useful for managing the sizes of uploaded images, ensuring they don't overwhelm storage limits or negatively affect page load times. | |
| theme_authorized_extensions: | |
| A list of file extensions allowed for theme uploads (use '*' to enable all file types) | |
| ------ | |
| Specify the file extensions that are permissible for theme uploads. Use '*' as a wildcard to include all file types. Be cautious when enabling all file types, as it might expose your website to issues of security or compatibility. | |
| authorized_extensions: | |
| A list of file extensions allowed for upload (use '*' to enable all file types) | |
| ------ | |
| Specify which file extensions are permitted for upload. Use a separated list for multiple extensions. To allow all file types, simply use an asterisk ('*'). | |
| authorized_extensions_for_staff: | |
| A list of file extensions allowed for upload for staff users in addition to the list defined in the `authorized_extensions` site setting. (use '*' to enable all file types) | |
| ------ | |
| Allows you to specify a list of permitted file extensions that staff users can upload, in addition to those set in the standard `authorized_extensions` setting. Using '*' gives permission for staff to upload all types of files. | |
| responsive_post_image_sizes: | |
| Resize lightbox preview images to allow for high DPI screens of the following pixel ratios. Remove all values to disable responsive images. | |
| ------ | |
| Adjust the size of lightbox preview images to accommodate high DPI screens with specified pixel ratios. Deleting all pixel ratio values will disable the adaptation of images for responsive layouts. This adjustment enhances the viewability of images on different screen resolutions, ensuring a pleasing aesthetic and user experience. | |
| max_image_width: | |
| Maximum thumbnail width of images in a post. Images with a larger width will be resized and lightboxed. | |
| ------ | |
| Specify the maximum width for images displayed in posts. Should an image exceed this limit, it will be automatically resized and presented within a lightbox. | |
| max_image_height: | |
| Maximum thumbnail height of images in a post. Images with a larger height will be resized and lightboxed. | |
| ------ | |
| Set the maximum allowable image height in a post. Images that surpass this height will be proportionally resized and placed in a lightbox for optimal viewing. | |
| download_remote_images_to_local: | |
| Convert remote (hotlinked) images to local images by downloading them; This preserves content even if the images are removed from the remote site in future. | |
| ------ | |
| Enable this setting to transform hotlinked images from external sources into local images by downloading them to your site's storage. This enhances content sustainability as the images will remain accessible even if they get deleted or moved from the original remote site. | |
| download_remote_images_threshold: | |
| Minimum disk space necessary to download remote images locally (in percent) | |
| ------ | |
| Indicates the required disk space percentage to allow remote image downloads. If available disk space falls under this threshold, the feature to download remote images will be automatically disabled. | |
| disabled_image_download_domains: | |
| Remote images will never be downloaded from these domains. Pipe-delimited list. | |
| ------ | |
| Specify domains from which images will not be automatically downloaded. List multiple domains in a pipe-separated format. This helps in controlling bandwidth usage by preventing site from fetching images hosted on identified domains. | |
| block_hotlinked_media: | |
| Prevent users from introducing remote (hotlinked) media in their posts. Remote media which is not downloaded via 'download_remote_images_to_local' will be replaced with a placeholder link. | |
| ------ | |
| Prevents users from embedding media from remote (hotlinked) sources within their posts. Any media that wasn't fetched via the 'download_remote_images_to_local' setting will be replaced with a placeholder link. This helps to maintain the integrity of content on the site and reduces the risk of inappropriate or unsolicited media appearing in posts. | |
| block_hotlinked_media_exceptions: | |
| A list of base URLs which are exempt from the block_hotlinked_media setting. Include the protocol (e.g. https://example.com). | |
| ------ | |
| Specify a list of base URLs that are not affected by the 'block_hotlinked_media' setting. Remember to include the protocol in your URLs, such as 'https://example.com'. These URLs will be permitted to hotlink media without restrictions. | |
| create_thumbnails: | |
| Create thumbnails and lightbox images that are too large to fit in a post. | |
| ------ | |
| Enable the generation of smaller images, known as thumbnails, as well as lightbox images for those that are too large to fit within a post. This ensures the smooth display of images regardless of their original size. | |
| clean_up_uploads: | |
| Remove orphan unreferenced uploads to prevent illegal hosting. WARNING: you may want to back up of your /uploads directory before enabling this setting. | |
| ------ | |
| Enable this setting to delete any unused upload from the system, aiming to prohibit unauthorized content hosting. It's important to note that enabling this setting might inadvertently remove some necessary uploads. Therefore, we strongly advise backing up your /uploads directory prior to activation. | |
| clean_orphan_uploads_grace_period_hours: | |
| Grace period (in hours) before an orphan upload is removed. | |
| ------ | |
| Specify the duration in hours after which an unused or orphaned upload should be deleted. This gives your site a buffer time between when an upload is flagged as orphaned and when it's actually removed, offering a chance to prevent any unintended deletions. The shortest grace period you can set is 1 hour. | |
| purge_deleted_uploads_grace_period_days: | |
| Grace period (in days) before a deleted upload is erased. | |
| ------ | |
| Specifies the duration in days after which an upload that has been deleted will be permanently removed. The value of this setting lies within a range of 30 to 120 days, and any uploaded file that has been deleted will stay in the system for this set period before getting completely purged. | |
| prevent_anons_from_downloading_files: | |
| Prevent anonymous users from downloading attachments. | |
| ------ | |
| Disallows file downloads by users who are not logged in. | |
| secure_uploads: | |
| Limits access to ALL uploads (images, video, audio, text, pdfs, zips, and others). If "login required” is enabled, only logged-in users can access uploads. Otherwise, access will be limited only for media uploads in private messages and private categories. WARNING: This setting is complex and requires deep administrative understanding. See <a target="_blank" href="https://meta.discourse.org/t/-/140017">the secure uploads topic on Meta</a> for details. | |
| ------ | |
| The 'secure_uploads' setting restricts access to all uploaded files, ranging from images and videos to pdfs and zips. If the 'login required' option is switched on, only users who are logged in can access these uploaded files. However, if this option is off, access is limited to media files uploaded in private messages and categories. Please note, the setup process for this setting can be somewhat complex and may require a comprehensive understanding of site administration. You can find more details and potential implications of implementing this setting in <a target="_blank" href="https://meta.discourse.org/t/-/140017">the secure uploads topic on Meta</a>. | |
| secure_uploads_allow_embed_images_in_emails: | |
| Allows embedding secure images that would normally be redacted in emails, if their size is smaller than the 'secure uploads max email embed image size kb' setting. | |
| ------ | |
| Enables the inclusion of secure images in emails. Normally, these images would be redacted. However, when this setting is enabled, images smaller than the limit specified by the 'secure uploads max email embed image size kb' setting are embedded in the email. Please note that only secure images attached inline to a message are considered, while images from short emails are excluded if the 'strip_images_from_short_emails' setting is enabled. | |
| secure_uploads_max_email_embed_image_size_kb: | |
| The size cutoff for secure images that will be embedded in emails if the 'secure uploads allow embed in emails' setting is enabled. Without that setting enabled, this setting has no effect. | |
| ------ | |
| This setting establishes the maximum size constraint, in kilobytes, for secure images that can be included in emails. It only functions when the 'secure uploads allow embed in emails' option is active. If the option is inactive, this setting will be irrelevant. | |
| enable_s3_uploads: | |
| Place uploads on Amazon S3 storage. IMPORTANT: requires valid S3 credentials (both access key id & secret access key). | |
| ------ | |
| "Enable this setting to store uploaded files on Amazon S3. Note that you must provide valid S3 credentials, including an access key ID and a secret access key, for this feature to function correctly." | |
| s3_use_iam_profile: | |
| Use an <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html">AWS EC2 instance profile</a> to grant access to the S3 bucket. NOTE: enabling this requires Discourse to be running in an appropriately-configured EC2 instance, and overrides the "s3 access key id" and "s3 secret access key" settings. | |
| ------ | |
| Enable the use of an <a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html">AWS EC2 instance profile</a> to acquire access privileges to the S3 bucket. Please note, you must be operating Discourse on a properly configured EC2 instance for this feature to function. When this setting is turned on, it bypasses the need for the 's3 access key id' and 's3 secret access key' settings. | |
| s3_access_key_id: | |
| The Amazon S3 access key id that will be used to upload images, attachments, and backups. | |
| ------ | |
| The Amazon S3 access key id utilized for tasks such as image and attachment uploading, as well as data backups. This key confirms your application's authorization for these operations with the S3 service. | |
| s3_secret_access_key: | |
| The Amazon S3 secret access key that will be used to upload images, attachments, and backups. | |
| ------ | |
| The Amazon S3 secret access key is required for image, attachment, and backup uploads. Ensure it is always kept secret to maintain the security of your S3 data. | |
| s3_region: | |
| The Amazon S3 region name that will be used to upload images and backups. | |
| ------ | |
| Define the Amazon S3 region for storing images and backups. This setting specifies the geographical area where your data will be stored and retrieved when Amazon S3 services are enabled. | |
| s3_upload_bucket: | |
| The Amazon S3 bucket name that files will be uploaded into. WARNING: must be lowercase, no periods, no underscores. | |
| ------ | |
| Specify the name of your Amazon S3 bucket to which files will be uploaded. Note: The name should be lowercased, without periods or underscores. | |
| s3_endpoint: | |
| The endpoint can be modified to backup to an S3 compatible service like DigitalOcean Spaces or Minio. WARNING: Leave blank if using AWS S3. | |
| ------ | |
| Specify the endpoint for backing up to an S3 compatible service such as DigitalOcean Spaces or Minio. Note: If you're using AWS S3, keep this field blank to avoid misconfiguration. This setting primarily affects your site's back-up process, ensuring that your data is safely stored in the designated cloud storage. | |
| s3_cdn_url: | |
| The CDN URL to use for all s3 assets (for example: https://cdn.somewhere.com). WARNING: after changing this setting you must rebake all old posts. | |
| ------ | |
| Specify the Content Delivery Network (CDN) URL for all S3 assets. For instance, https://cdn.somewhere.com. Be cautious when altering this setting as it requires rebaking all past topics to ensure the new CDN link is properly implemented across all past uploads. | |
| s3_use_cdn_url_for_all_uploads: | |
| Use CDN URL for all the files uploaded to s3 instead of only for images. | |
| ------ | |
| Utilize the Content Delivery Network (CDN) URL for all files that are uploaded to S3, not only images. This helps optimize content delivery by distributing the files across multiple servers, potentially improving loading speed and user experience. | |
| s3_configure_tombstone_policy: | |
| Enable automatic deletion policy for tombstone uploads. IMPORTANT: If disabled, no space will be reclaimed after uploads are deleted. | |
| ------ | |
| Activates an automatic deletion policy for tombstone uploads. Be aware, if this setting is not enabled, any space taken up by deleted uploads will not be recovered. | |
| s3_use_acls: | |
| AWS recommends not using ACLs on S3 buckets; if you are following this advice, uncheck this option. This must be enabled if you are using secure uploads. | |
| ------ | |
| Toggle this setting if your S3 buckets are following the AWS recommendation against using Access Control Lists (ACLs). However, ensure that this option is activated if you're enabling secure uploads. The configuration applies "public-read" or "private" ACLs to the S3 objects depending on whether this setting is active and the objects' contexts. | |
| enable_s3_inventory: | |
| Generate reports and verify uploads using Amazon S3 inventory. IMPORTANT: requires valid S3 credentials (both access key id & secret access key). | |
| ------ | |
| Activate this setting to generate reports and validate uploads using Amazon S3 inventory. Please note that valid S3 credentials, including an access key ID and secret access key, are essential for this function. | |
| allow_profile_backgrounds: | |
| Allow users to upload profile backgrounds. | |
| ------ | |
| Enable the ability for users to upload their own images as profile backgrounds, enhancing personalization of their profile pages. | |
| automatically_download_gravatars: | |
| Download Gravatars for users upon account creation or email change. | |
| ------ | |
| Retrieve and add Gravatars to user profiles when they create an account or change their email address. | |
| allow_uploaded_avatars: | |
| Allow users to upload custom profile pictures. | |
| ------ | |
| Enables users to upload their own custom images for use as profile pictures. | |
| default_avatars: | |
| URLs to avatars that will be used by default for new users until they change them. | |
| ------ | |
| Default Avatars: This setting provides a list of avatar URLs that are automatically assigned to new users as their default profile picture. These avatars will serve as the initial profile picture for users until they opt to change it themselves. The specific avatar allocated to a user is determined by running a hash function on their username. | |
| avatar_sizes: | |
| List of automatically generated avatar sizes. | |
| ------ | |
| Maintain a list of dimensions for automatic avatar generation. These dimensions will be used to produce various avatar sizes for optimization. | |
| external_system_avatars_enabled: | |
| Use external system avatars service. | |
| ------ | |
| Enables the use of an external service for generating system avatars. When this setting is enabled, user avatars, instead of being produced within the Discourse system, are generated and provided by an external service defined by the 'external_system_avatars_url' setting. This can include parameters such as color, username, first letter of the username, and hostname in the avatar URL. | |
| external_system_avatars_url: | |
| URL of the external system avatars service. Allowed substitutions are {username} {first_letter} {color} {size} | |
| ------ | |
| This setting defines the URL for an external service that provides system avatars. The URL can include placeholders for {username}, {first_letter}, {color}, and {size}, which will be dynamically replaced with the relevant user's username, first letter of the username, avatar color, and avatar size, respectively. | |
| external_emoji_url: | |
| URL of the external service for emoji images. Leave blank to disable. | |
| ------ | |
| Specify the URL for an external service that supplies emoji images. If left empty, this feature will be deactivated. This setting allows for customization and sourcing of emoji images from a dedicated source, beyond the default set provided by the platform. | |
| restrict_letter_avatar_colors: | |
| A list of 6-digit hexadecimal color values to be used for letter avatar background. | |
| ------ | |
| Specify a set of 6-digit hexadecimal color values that will be utilized for the background of letter avatars. If this setting is not configured, a default color scheme will be used. | |
| selectable_avatars_mode: | |
| Allow users to select an avatar from the selectable_avatars list and limit custom avatar uploads to the selected trust level. | |
| ------ | |
| Enables users to choose an avatar from a provided list of selectable avatars and confines the ability to upload custom avatars to users that have reached a specified trust level. | |
| selectable_avatars: | |
| List of avatars users can choose from. | |
| ------ | |
| Specify a collection of avatars from which users can select their profile picture. If this setting is not disabled, the choice will appear during user profile creation or when updating the profile avatar. | |
| allow_all_attachments_for_group_messages: | |
| Allow all email attachments for group messages. | |
| ------ | |
| Enable all types of email attachments in group messages. When this setting is activated, group messages are not subject to any restrictions on the types of files they can contain as attachments. Please bear in mind that this includes all file types, regardless of restrictions specified in other settings or the blocked attachment filenames regex. Use with caution to ensure your site's security. | |
| png_to_jpg_quality: | |
| Quality of the converted JPG file (1 is lowest quality, 99 is best quality, 100 to disable). | |
| ------ | |
| Specify the quality of JPG files converted from PNG files. A value of 1 denotes the lowest quality, while 99 signifies the highest quality. Input 100 if you wish to disable conversion. | |
| recompress_original_jpg_quality: | |
| Quality of uploaded image files (1 is lowest quality, 99 is best quality, 100 to disable). | |
| ------ | |
| Indicates the quality level of JPEG images that have been uploaded. The scale ranges from 1 to 99, where 1 represents the lowest quality and 99 signifies the highest quality. You may input 100 if you wish to disable the quality alteration. This setting is particularly useful in managing the balance between image quality and file size. | |
| image_preview_jpg_quality: | |
| Quality of resized image files (1 is lowest quality, 99 is best quality, 100 to disable). | |
| ------ | |
| Specify the quality of resized JPEG image files. The scale ranges from 1 to 99 - with 1 providing the lowest quality and 99 delivering the best. To bypass this feature and disable any adjustments to image quality, input 100. | |
| allow_staff_to_upload_any_file_in_pm: | |
| Allow staff members to upload any files in PM. | |
| ------ | |
| Enables staff members to upload all types of files when sending private messages. | |
| strip_image_metadata: | |
| Strip image metadata. | |
| ------ | |
| "Enable this setting to remove all the additional information from the images uploaded on the site. This includes data such as the camera model, location, creation date etc. This can be useful for privacy reasons, as it prevents users from unintentionally sharing sensitive information." | |
| min_ratio_to_crop: | |
| Ratio used to crop tall images. Enter the result of width / height. | |
| ------ | |
| Set this ratio to establish the width-to-height proportions for cropping tall images. You can determine this value by dividing the desired width by the desired height. This setting comes into effect when the image's current width-to-height ratio is smaller than the set ratio. Bear in mind that an image will only be cropped if it surpasses the maximum image width and height limit. | |
| simultaneous_uploads: | |
| Maximum number of files that can be dragged & dropped in the composer | |
| ------ | |
| This setting defines the maximum number of files that can concurrently be uploaded using the drag & drop function in the composer. Remember, the defined number applies to each upload instance, not the total number of files being uploaded to the site. | |
| composer_media_optimization_image_enabled: | |
| Enables client-side media optimization of uploaded image files. | |
| ------ | |
| Enable client-side optimization for uploaded images. This setting activates a feature which automatically optimizes the size and format of images that users upload, enhancing page load times and overall site performance. | |
| composer_media_optimization_image_bytes_optimization_threshold: | |
| Minimum image file size to trigger client-side optimization | |
| ------ | |
| Defines the minimum size, in bytes, of an image that must be met before initiating optimization on the client-side. If an image file is smaller than this set threshold, it will be excluded from optimization. Supports jpeg, png, and webp formats. | |
| composer_media_optimization_image_resize_dimensions_threshold: | |
| Minimum image width to trigger client-side resize | |
| ------ | |
| Establishes the minimum pixel width an image must possess to trigger the automatic client-side resizing mechanism. This feature ensures more efficient storage and bandwidth usage while maintaining visible image quality. | |
| composer_media_optimization_image_resize_width_target: | |
| Images with widths larger than `composer_media_optimization_image_dimensions_resize_threshold` will be resized to this width. Must be >= than `composer_media_optimization_image_dimensions_resize_threshold`. | |
| ------ | |
| This setting specifies the target width to which images wider than the value in `composer_media_optimization_image_dimensions_resize_threshold` will be resized. The desired width must always be equal to or larger than the threshold set in `composer_media_optimization_image_dimensions_resize_threshold`. | |
| composer_media_optimization_image_encode_quality: | |
| JPG encode quality used in the re-encode process. | |
| ------ | |
| Specify the quality of JPG encoding to be utilized during the image re-encode process. This setting adjusts the trade-off between image quality and file size for optimized performance. | |
| default_trust_level: | |
| Default trust level (0-4) for all new users. WARNING! Changing this will put you at serious risk for spam. | |
| ------ | |
| The 'default_trust_level' setting determines the initial trust level given to all newly registered users, which ranges from 0 to 4. However, adjust this level with caution as elevating this may pose potential risks such as an increase in spam activity on your site. | |
| default_invitee_trust_level: | |
| Default trust level (0-4) for invited users. | |
| ------ | |
| Establishes the initial trust level (ranging from 0 to 4) assigned automatically to users upon accepting an invitation. | |
| min_trust_to_create_topic: | |
| The minimum trust level required to create a new topic. | |
| ------ | |
| The lowest trust level a user must possess to start a new topic. It defines the level of community engagement and credibility a user should have to initiate a topic. Higher levels indicate greater trust and activity within the community, thus allowing users to create topics. | |
| min_trust_to_edit_wiki_post: | |
| The minimum trust level required to edit post marked as wiki. | |
| ------ | |
| Defines the minimum user trust level needed to make edits to a post designated as a wiki. Users with trust levels lower than this threshold will not be permitted to edit wiki posts. | |
| min_trust_to_edit_post: | |
| The minimum trust level required to edit posts. | |
| ------ | |
| Specifies the minimum level of trust a user must have in order to edit posts. Higher values restrict this action to more trustworthy users, promoting user accountability and accuracy of information. This configuration impacts which users can amend contents of existing posts on the site. | |
| min_trust_to_allow_self_wiki: | |
| The minimum trust level required to make user's own post wiki. | |
| ------ | |
| Define the minimum trust level a user must reach to apply wiki status to their own posts. A user with the requisite trust level can convert their text into a wiki post, allowing others to edit the content. Note that this ability is automatically granted to staff members and users with TrustLevel[4] regardless of this setting. | |
| min_trust_to_send_email_messages: | |
| The minimum trust level required to send personal messages via email. | |
| ------ | |
| Specifies the lowest trust level a user must have to send individual messages via email. This feature is related to the system's ability to stage users and respects the settings established for personal message enabled groups. It also verifies the user's trust level or staff status before enabling the option to send private emails. | |
| min_trust_to_flag_posts: | |
| The minimum trust level required to flag posts | |
| ------ | |
| Specify the minimum trust level a user must have to flag posts. Includes post flagging privileges for private messages for users at all trust levels. This setting does not apply to actions such as liking a user's post, actions on archived topics and deleted posts. | |
| min_trust_to_post_links: | |
| The minimum trust level required to include links in posts | |
| ------ | |
| Specifies the minimum trust level a user must have to include hyperlinks in their posts. This setting acts as a safeguard to limit link posting access, helping to reduce unwanted spam or inappropriate content. | |
| min_trust_to_post_embedded_media: | |
| The minimum trust level required to embed media items in a post | |
| ------ | |
| Specifies the minimum trust level a user must have to be allowed to embed media items, such as images, videos, or audio, into their posts. | |
| min_trust_level_to_allow_profile_background: | |
| The minimum trust level required to upload a profile background | |
| ------ | |
| Specifies the lowest trust level a user must have in order to upload their own profile background. Users at this trust level, or higher, and staff members are allowed to personalize their profile with a unique background image. | |
| min_trust_level_to_allow_user_card_background: | |
| The minimum trust level required to upload a user card background | |
| ------ | |
| Establishes the lowest trust level a user must have in order to be permitted to upload a background for their user card. Staff members are exempt from this requirement. | |
| min_trust_level_to_allow_invite: | |
| The minimum trust level required to invite users | |
| ------ | |
| This setting specifies the lowest trust level a user must have in order to invite other users to the forum. Please note, users with the requisite trust level must also have invitation privileges to successfully invite others. | |
| min_trust_level_to_allow_ignore: | |
| The minimum trust level required to ignore users | |
| ------ | |
| "Defines the lowest trust level at which a user acquires the ability to ignore other users on the site." | |
| allow_flagging_staff: | |
| If enabled, users can flag posts from staff accounts. | |
| ------ | |
| "Enable this setting to allow users to flag posts made by staff members. When disabled, only non-staff posts can be flagged by users." | |
| send_tl1_welcome_message: | |
| Send new trust level 1 users a welcome message. | |
| ------ | |
| Send a welcome message to users who have just reached Trust Level 1. The message is dispatched automatically after a user achieves this trust level. | |
| send_tl2_promotion_message: | |
| Send new trust level 2 users a message about promotion. | |
| ------ | |
| Automatically send a message to users upon achieving Trust Level 2 to acknowledge their promotion. | |
| tl1_requires_topics_entered: | |
| How many topics a new user must enter before promotion to trust level 1. | |
| ------ | |
| The minimum number of topics that a new user needs to explore to be advanced to trust level 1. | |
| tl1_requires_read_posts: | |
| How many posts a new user must read before promotion to trust level 1. | |
| ------ | |
| Specify the number of posts a new user needs to read before being promoted to trust level 1. | |
| tl1_requires_time_spent_mins: | |
| How many minutes a new user must read posts before promotion to trust level 1. | |
| ------ | |
| Specifies the amount of time, in minutes, that a newly registered user needs to spend reading posts before they can be upgraded to Trust Level 1. | |
| tl2_requires_topics_entered: | |
| How many topics a user must enter before promotion to trust level 2. | |
| ------ | |
| Specifies the minimum number of topics that a user needs to enter before they can advance to trust level 2. | |
| tl2_requires_read_posts: | |
| How many posts a user must read before promotion to trust level 2. | |
| ------ | |
| Specify the number of posts that a user needs to read before they can be upgraded to trust level 2. | |
| tl2_requires_time_spent_mins: | |
| How many minutes a user must read posts before promotion to trust level 2. | |
| ------ | |
| Specify the minimum amount of time, in minutes, that a user needs to spend reading posts before they can be upgraded to trust level 2. | |
| tl2_requires_days_visited: | |
| How many days a user must visit the site before promotion to trust level 2. | |
| ------ | |
| Specify the number of days a user needs to visit the site to be eligible for promotion to Trust Level 2. | |
| tl2_requires_likes_received: | |
| How many likes a user must receive before promotion to trust level 2. | |
| ------ | |
| Specifies the minimum number of likes a user must receive on their posts in order to ascend to Trust Level 2. | |
| tl2_requires_likes_given: | |
| How many likes a user must cast before promotion to trust level 2. | |
| ------ | |
| Indicates the minimum number of likes that a user needs to give out in order to advance to trust level 2. | |
| tl2_requires_topic_reply_count: | |
| How many topics user must reply to before promotion to trust level 2. | |
| ------ | |
| Indicates the minimum number of topics a user must respond to in order to attain Trust Level 2. This threshold helps ensure user engagement and participation before granting them additional privileges associated with Trust Level 2. | |
| tl3_time_period: | |
| Trust Level 3 requirements time period (in days) | |
| ------ | |
| Specifies the duration in days for calculating Trust Level 3 requirements. This period determines the threshold for activities like topics viewed, posts read, likes given and received, ensuring that the user maintains active involvement within the specified timeframe to achieve or retain Level 3 Trust. | |
| tl3_requires_days_visited: | |
| Minimum number of days that a user needs to have visited the site in the last (tl3 time period) days to qualify for promotion to trust level 3. Set higher than tl3 time period to disable promotions to tl3. (0 or higher) | |
| ------ | |
| Specifies the required number of days a user must have visited the site within the last period defined by "tl3 time period" for eligibility to advance to trust level 3. If you want to prevent automatic promotion to this level, set a value higher than the "tl3 time period". Acceptable value is 0 or more. | |
| tl3_requires_topics_replied_to: | |
| Minimum number of topics a user needs to have replied to in the last (tl3 time period) days to qualify for promotion to trust level 3. (0 or higher) | |
| ------ | |
| This setting defines the minimum number of topics a user must have responded to in the last certain number of days (as specified in the 'tl3 time period' setting) to be eligible for advancement to trust level 3. The count can be any number equal to or greater than 0. | |
| tl3_requires_topics_viewed: | |
| The percentage of topics created in the last (tl3 time period) days that a user needs to have viewed to qualify for promotion to trust level 3. (0 to 100) | |
| ------ | |
| Indicates the required percentage of recently created topics that a user must view to be considered for an upgrade to trust level 3. This count is based on topics originating within the set 'tl3 time period'. The value can range from 0 to 100 percent. | |
| tl3_requires_topics_viewed_cap: | |
| The maximum required number of topics viewed in the last (tl3 time period) days. | |
| ------ | |
| Sets the upper limit for the required number of topic views within the time duration specified by 'tl3 time period'. The actual number of topics a user is required to view to reach trust level 3 may be lesser, but will not exceed this set value. | |
| tl3_requires_posts_read: | |
| The percentage of posts created in the last (tl3 time period) days that a user needs to have viewed to qualify for promotion to trust level 3. (0 to 100) | |
| ------ | |
| Defines what portion, as a percentage, of content users need to have viewed within the last specified amount of days (tl3 time period) to be eligible for upgrading to trust level 3. This value can be set from 0 to 100. | |
| tl3_requires_posts_read_cap: | |
| The maximum required number of posts read in the last (tl3 time period) days. | |
| ------ | |
| Specify the maximum count of posts a user must read within the duration established by 'tl3 time period' days to achieve Trust Level 3. This constraint assists in ensuring users have actively engaged with the site's content before advancing to a higher Trust Level. | |
| tl3_requires_topics_viewed_all_time: | |
| The minimum total number of topics a user must have viewed to qualify for trust level 3. | |
| ------ | |
| "Defines the aggregate count of distinct topics a user must view to be eligible for trust level 3" | |
| tl3_requires_posts_read_all_time: | |
| The minimum total number of posts a user must have read to qualify for trust level 3. | |
| ------ | |
| Specify the minimum number of distinct posts a user needs to read across the site's entirety to be eligible for promotion to Trust Level 3. | |
| tl3_requires_max_flagged: | |
| User must not have had more than x posts flagged by x different users in the last (tl3 time period) days to qualify for promotion to trust level 3, where x is this setting's value. (0 or higher) | |
| ------ | |
| Set the maximum number of a user's posts that can be flagged by different users during the specified trust level 3 time period before they are disqualified for promotion to trust level 3. This value must be 0 or higher. The promotion assessment excludes flags agreed upon by the same user. | |
| tl3_promotion_min_duration: | |
| The minimum number of days that a promotion to trust level 3 lasts before a user can be demoted back to trust level 2. | |
| ------ | |
| Specifies the minimum duration, in days, during which a user must maintain trust level 3 before any potential demotion to trust level 2 can take place. | |
| tl3_requires_likes_given: | |
| The minimum number of likes that must be given in the last (tl3 time period) days to qualify for promotion to trust level 3. | |
| ------ | |
| Specifies the least number of likes a user has to give out within the previous (trust level 3 time period) days to be eligible for elevation to trust level 3. | |
| tl3_requires_likes_received: | |
| The minimum number of likes that must be received in the last (tl3 time period) days to qualify for promotion to trust level 3. | |
| ------ | |
| "Indicates the least number of 'likes' a user must receive within the specified 'tl3 time period' days to be eligible for upgrade to trust level 3." | |
| tl3_links_no_follow: | |
| Do not remove rel=nofollow from links posted by trust level 3 users. | |
| ------ | |
| Preserve rel=nofollow attribute in links shared by users with trust level 3. | |
| tl4_delete_posts_and_topics: | |
| Allow TL4 users to delete posts and topics created by other users. TL4 users will also be able to see deleted topics and posts. | |
| ------ | |
| Enables users with Trust Level 4 (TL4) to delete posts and topics created by others. Additionally, they will have the ability to view deleted posts and topics. | |
| edit_all_topic_groups: | |
| Allow users in this group to edit other users' topic titles, tags, and categories | |
| ------ | |
| Allow members of specified groups to edit the titles, tags, and categories of topics posted by other users. | |
| edit_all_post_groups: | |
| Allow users in this group to edit other users' posts | |
| ------ | |
| Permits designated user groups to modify the content of posts made by others. | |
| detailed_404: | |
| Provides more details to users about why they can’t access a particular topic. Note: This is less secure because users will know if a URL links to a valid topic. | |
| ------ | |
| "Enable the 'detailed_404' setting to provide users with more specific information about why they are unable to access a certain topic. Be aware that this carries a security trade-off, as it implicitly confirms whether or not a URL leads to a valid topic." | |
| enforce_second_factor: | |
| Forces users to enable two-factor authentication. Select 'all' to enforce it to all users. Select 'staff' to enforce it to staff users only. | |
| ------ | |
| Mandates the use of two-factor authentication for users. You can apply this setting to all users by selecting 'all' or to staff users only, by choosing 'staff'. This enhances the security by adding an extra layer of protection to user accounts. | |
| force_https: | |
| Force your site to use HTTPS only. WARNING: do NOT enable this until you verify HTTPS is fully set up and working absolutely everywhere! Did you check your CDN, all social logins, and any external logos / dependencies to make sure they are all HTTPS compatible, too? | |
| ------ | |
| The 'force_https' setting compels the site to exclusively use HTTPS protocol. Before enabling this feature, make sure you have thoroughly validated that HTTPS is correctly installed and functioning across your entire site. This includes examining your CDN (Content Delivery Network), all social logins, and any external logos or dependencies to confirm they are all HTTPS compatible. Proceed with caution, as turning this setting on prematurely may cause issues with site functionality if HTTPS is not fully implemented. | |
| same_site_cookies: | |
| Use same site cookies, they eliminate all Cross Site Request Forgery vectors on supported browsers (Lax or Strict). Warning: Strict will only work on sites that force login and use an external auth method. | |
| ------ | |
| Use same site cookies to enhance security. These cookies help to eliminate all potential avenues for Cross Site Request Forgery on browsers that support this feature. You can set this feature to either 'Lax' or 'Strict'. Please note that the 'Strict' setting is suitable only for sites that mandate login and use an external authentication method. Be aware that disabling this feature may increase vulnerability to Cross Site Request Forgery attacks. | |
| enable_escaped_fragments: | |
| Fall back to Google's Ajax-Crawling API if no webcrawler is detected. See <a href='https://developers.google.com/webmasters/ajax-crawling/docs/learn-more' target='_blank'>https://developers.google.com/webmasters/ajax-crawling/docs/learn-more</a> | |
| ------ | |
| Activate this setting to utilize Google's Ajax-Crawling API when no other webcrawler is detected. More information about this feature can be found at <a href='https://developers.google.com/webmasters/ajax-crawling/docs/learn-more' target='_blank'>https://developers.google.com/webmasters/ajax-crawling/docs/learn-more</a>. This setting ensures that content remains easily accessible for search engines in the absence of other webcrawlers. | |
| allow_index_in_robots_txt: | |
| Specify in robots.txt that this site is allowed to be indexed by web search engines. In exceptional cases you can permanently <a href='%{base_path}/admin/customize/robots'>override robots.txt</a>. | |
| ------ | |
| Allows the permission for web search engines to index the site's content, which is specified in the robots.txt file. You can manually modify this behaviour for exceptional circumstances using the <a href='%{base_path}/admin/customize/robots'>robots.txt override</a>. Be aware, if indexing is disabled, it might impact your site's visibility in search engine results. | |
| moderators_manage_categories_and_groups: | |
| Allow moderators to create and manage categories and groups | |
| ------ | |
| Enable this setting to grant moderators the authority to create and manage categories and groups. This includes establishing new categories, editing existing ones, as well as constructing new groups and modifying their membership. Use this feature to broaden the capabilities of moderators, allowing them to more fully manage the site's content and user experiences. | |
| moderators_change_post_ownership: | |
| Allow moderators to change post ownership | |
| ------ | |
| Permits moderators to alter the ownership of a post. This setting enables site moderators to reassign the ownership of any post to another user. This can be useful in cases where posts need to be reassigned due to user account issues, ownership disputes, or other moderator intervention scenarios. | |
| moderators_view_emails: | |
| Allow moderators to view user emails | |
| ------ | |
| Enables moderators to access user email addresses. | |
| cors_origins: | |
| Allowed origins for cross-origin requests (CORS). Each origin must include http:// or https://. The DISCOURSE_ENABLE_CORS env variable must be set to true to enable CORS. | |
| ------ | |
| List of permitted origins for cross-origin requests (CORS). Each origin should begin with http:// or https://. The CORS functionality can only be activated when the DISCOURSE_ENABLE_CORS environment variable is set to true. Origins should not have a trailing slash. | |
| use_admin_ip_allowlist: | |
| Admins can only log in if they are at an IP address defined in the Screened IPs list (Admin > Logs > Screened Ips). | |
| ------ | |
| The 'use_admin_ip_allowlist' setting enables the restriction of administrator login to predefined IP addresses. The list of allowed IP addresses can be managed under the 'Screened IPs' log section in the admin dashboard. If this setting is enabled, an admin can only successfully log in from a device with an IP address present in the Screened IPs list. | |
| blocked_ip_blocks: | |
| A list of private IP blocks that should never be crawled by Discourse | |
| ------ | |
| Specify a collection of private IP ranges that Discourse should not crawl. This list is primarily used for safeguarding the system against unwanted intrusions and exploits from these specified IPs. Enter the IP ranges using the form "x.x.x.x/y", and separate multiple entries with either a vertical bar "|" or a new line. Invalid IP addresses entered will be disregarded. | |
| allowed_internal_hosts: | |
| A list of internal hosts that discourse can safely crawl for oneboxing and other purposes | |
| ------ | |
| "Allowed Internal Hosts" refers to a predefined list of internal hosts, specifically authorized to be accessed by Discourse for activities such as oneboxing or information secure retrieval. Please note, while these connections are deemed safe, proper security checks should continue to be applied for all other hosts. | |
| allowed_onebox_iframes: | |
| A list of iframe src domains which are allowed via Onebox embeds. `*` will allow all default Onebox engines. | |
| ------ | |
| Specify domains that are permitted to display iframe content through Onebox embeds. To allow all default Onebox engines, use `*`. Note that this list should contain only domain sources catering to iframe content. | |
| allowed_iframes: | |
| A list of iframe src domain prefixes that discourse can safely allow in posts | |
| ------ | |
| Specify the domain prefixes for iframes that can be safely included in posts. This list is used by Discourse to filter the iframe sources ensuring that only approved content is embedded. | |
| allowed_crawler_user_agents: | |
| User agents of web crawlers that should be allowed to access the site. WARNING! SETTING THIS WILL DISALLOW ALL CRAWLERS NOT LISTED HERE! | |
| ------ | |
| Specify the user agents of web crawlers that are permitted to access the site. Note that this configuration will block all web crawlers not included in this list. Proceed with caution when defining user agents here. | |
| blocked_crawler_user_agents: | |
| Unique case insensitive word in the user agent string identifying web crawlers that should not be allowed to access the site. Does not apply if allowlist is defined. | |
| ------ | |
| Specify distinct terms in the user agent string to identify and block web crawlers from accessing the site. The identification is not case-sensitive. If an allow list is defined, this setting does not take effect. | |
| slow_down_crawler_user_agents: | |
| User agents of web crawlers that should be rate limited as configured in the "slow down crawler rate" setting. Each value must be at least 3 characters long. | |
| ------ | |
| Identify the web crawlers that need to be rate limited. They will be controlled as per the 'slow down crawler rate' setting. Please note, each value should contain a minimum of 3 characters. This setting is used to ensure that the server resources are not excessively used by automative browsing. | |
| slow_down_crawler_rate: | |
| If slow_down_crawler_user_agents is specified this rate will apply to all the crawlers (number of seconds delay between requests) | |
| ------ | |
| When the 'slow_down_crawler_user_agents' setting is active, all crawler bots specified must adhere to the rate defined by this setting, which indicates the number of seconds delay required between each of their requests. Essentially, it regulates the frequency of requests made by each specified crawler bot. | |
| content_security_policy: | |
| Enable Content-Security-Policy (CSP) | |
| ------ | |
| Activates the Content-Security-Policy (CSP), an additional layer of security that helps to prevent certain types of attacks, including Cross Site Scripting (XSS) and data injection. When enabled, the server provides the security policy in the form of a 'Content-Security-Policy' HTTP header. | |
| content_security_policy_report_only: | |
| Enable Content-Security-Policy-Report-Only (CSP) | |
| ------ | |
| Activate the Content Security Policy Report-Only (CSP) mode. When this setting is enabled, violations of the content security policy get reported but do not interfere with the display or operation of the webpage. Useful for testing and identifying potential security issues without affecting user experience. | |
| content_security_policy_frame_ancestors: | |
| Restrict who can embed this site in iframes via CSP. Control allowed hosts on <a href='%{base_path}/admin/customize/embedding'>Embedding</a> | |
| ------ | |
| Specify the domains permitted to incorporate your site through iframes, as dictated by the Content Security Policy (CSP). You can manage these allowed hosts in the <a href='%{base_path}/admin/customize/embedding'>Embedding</a> section. This setting enhances your site's security by preventing unauthorized embedding from unfamiliar sources. Use this setting with caution to preserve your site's functionality for approved external iframes. | |
| content_security_policy_script_src: | |
| Additional allowlisted script sources. The current host and CDN are included by default. See <a href='https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243' target='_blank'>Mitigate XSS Attacks with Content Security Policy.</a> (CSP) | |
| ------ | |
| Specify additional authorized script sources for enhancing site security. The current host and Content Delivery Network (CDN) are automatically included. For further information, refer to <a href='https://meta.discourse.org/t/mitigate-xss-attacks-with-content-security-policy/104243' target='_blank'>Mitigate XSS Attacks with Content Security Policy</a>. This setting is crucial in mitigating Cross-Site Scripting (XSS) attacks. | |
| invalidate_inactive_admin_email_after_days: | |
| Admin accounts that have not visited the site in this number of days will need to re-validate their email address before logging in. Set to 0 to disable. | |
| ------ | |
| Admin accounts that remain inactive for the specified number of days will be required to undergo an email verification process for reactivation. If you assign a zero value, this feature is turned off. Please note that inactivity is tracked based on the last site visit. | |
| include_secure_categories_in_tag_counts: | |
| When enabled, count of topics for a tag will include topics that are in read restricted categories for all users. When disabled, normal users are only shown a count of topics for a tag where all the topics are in public categories. | |
| ------ | |
| "Enable this setting to include topics from read-restricted categories in the count for a specific tag, applicable to all users. If disabled, regular users will only see the count for a tag that incorporates topics from public categories." | |
| display_personal_messages_tag_counts: | |
| When enabled, count of personal messages tagged with a given tag will be displayed. | |
| ------ | |
| When this setting is active, the website displays the number of personal messages that are tagged with a specific tag. | |
| post_onebox_maxlength: | |
| Maximum length of a oneboxed Discourse post in characters. | |
| ------ | |
| Specify the maximum character count for a oneboxed Discourse post. This determines how many characters from the original post will appear inside the onebox. Any characters beyond this limit will not be displayed. | |
| blocked_onebox_domains: | |
| A list of domains that will never be oneboxed e.g. wikipedia.org | |
| (Wildcard symbols * ? not supported) | |
| ------ | |
| "Specify the list of domains that won't be converted into oneboxes like 'wikipedia.org'. Note: wildcard symbols such as '*' and '?' are not permitted." | |
| max_oneboxes_per_post: | |
| Maximum number of oneboxes in a post. | |
| ------ | |
| Set the upper limit for the number of oneboxes that can be included in a single post. Oneboxes provide a preview of linked content within the post. | |
| allowed_inline_onebox_domains: | |
| A list of domains that will be oneboxed in miniature form if linked without a title | |
| ------ | |
| Specify the list of domains permitted for inline oneboxing. This actively transforms your linked URLs, without titles, into compact content previews known as 'oneboxes'. Note that if 'enable inline onebox on all domains' is set to true, this setting is ignored. | |
| enable_inline_onebox_on_all_domains: | |
| Ignore inline_onebox_domain_allowlist site setting and allow inline onebox on all domains. | |
| ------ | |
| Enables inline oneboxing for all domains, overriding the settings defined in 'allowed_inline_onebox_domains'. Once activated, this allows for previews (oneboxes) of links from any domain, disregarding the specific domain restrictions. | |
| force_custom_user_agent_hosts: | |
| Hosts for which to use the custom onebox user agent on all requests. (Especially useful for hosts that limit access by user agent). | |
| ------ | |
| Defines the hosts that should always use a custom user agent for all onebox requests. This setting is particularly beneficial for those hosts that impose restrictions based on the user agent. | |
| facebook_app_access_token: | |
| A token generated from your Facebook app ID and secret. Used to generate Instagram oneboxes. | |
| ------ | |
| This is a token derived from your Facebook Application ID and secret. Its primary function is to enable the creation of Instagram oneboxes. | |
| block_onebox_on_redirect: | |
| Block onebox for URLs that redirect. | |
| ------ | |
| Prevent oneboxing for URLs that lead to a redirecting page. This configuration stops the creation of a visual card (onebox) for any URL that redirects to a different destination, ensuring that direct, non-redirecting URLs are prioritized for oneboxing. | |
| add_rel_nofollow_to_user_content: | |
| Add rel nofollow to all submitted user content, except for internal links (including parent domains). If you change this, you must rebake all posts with: "rake posts:rebake" | |
| ------ | |
| Applies the 'nofollow' attribute to all links included in user-submitted content, with the exception of internal site links, including those serving parent domains. If this setting is modified, it is necessary to rebake all posts by executing the command "rake posts:rebake". The 'nofollow' attribute instructs search engines not to follow these links, acting as a deterrent against spamming or the promotion of irrelevant content. | |
| hide_post_sensitivity: | |
| The likelihood that a flagged post will be hidden | |
| ------ | |
| This setting indicates the sensitivity level at which a flagged post will be automatically hidden. It works by using a scoring system, where a higher score signifies greater sensitivity to flagged content. Adjusting this setting allows you to manage visibility of posts that may potentially violate community guidelines. | |
| cooldown_minutes_after_hiding_posts: | |
| Number of minutes a user must wait before they can edit a post hidden via community flagging | |
| ------ | |
| Defines the duration, in minutes, a user has to wait before being permitted to edit a post that has been hidden due to community flagging. | |
| silence_new_user_sensitivity: | |
| The likelihood that a new user will be silenced based on spam flags | |
| ------ | |
| Refines the sensitivity level that dictates when a new user will be silenced owing to spam flags. This setting works by adjusting the threshold for spam-related user reports. A higher value makes the system more aggressive in silencing new users when flags indicating spam are raised. | |
| num_users_to_silence_new_user: | |
| If a new user's posts exceed the hide_post_sensitivity setting, and has spam flags from this many different users, hide all their posts and prevent future posting. 0 to disable. | |
| ------ | |
| Defines the count of unique users that must flag a new user's posts as spam to trigger a silence action. The silence action will hide all posts by the new user and restrict them from making future posts. If set to 0, this function will be disabled. The flagged posts need to also surpass the value configured in the hide_post_sensitivity setting for this action to be implemented. | |
| notify_mods_when_user_silenced: | |
| If a user is automatically silenced, send a message to all moderators. | |
| ------ | |
| Enables notification to all moderators when a user is automatically silenced. In the event of a user being silenced due to spam or inappropriate behavior, this setting ensures that all moderators are promptly informed. | |
| flag_sockpuppets: | |
| If a new user replies to a topic from the same IP address as the user who started the topic, flag both of their posts as potential spam. | |
| ------ | |
| Activates automatic flagging of posts when a new user responds to a topic using the same IP address as the topic creator, indicating potential spam activity. Be aware that this may detect users sharing the same IP address, like those in the same household or using the same VPN, as possible spammers. | |
| newuser_spam_host_threshold: | |
| How many times a new user can post a link to the same host within their `newuser_spam_host_threshold` posts before being considered spam. | |
| ------ | |
| Defines the maximum number of times a new user can include a link from the same host within their initial set of posts. Surpassing this threshold could automatically categorize the user's posts as spam by the system. | |
| allowed_spam_host_domains: | |
| A list of domains excluded from spam host testing. New users will never be restricted from creating posts with links to these domains. | |
| ------ | |
| "Specify a list of domains that are exempt from spam host verification. Links from these domains, when included in posts by new users, will not result in posting restrictions." | |
| levenshtein_distance_spammer_emails: | |
| When matching spammer emails, number of characters difference that will still allow a fuzzy match. | |
| ------ | |
| Specify the permissible number of characters difference to be considered as a fuzzy match when comparing potential spammer emails. This setting defines a tolerance level for minor variations in email addresses, helping to catch spammers who alter a few characters in their email to avoid detection. | |
| max_new_accounts_per_registration_ip: | |
| If there are already (n) trust level 0 accounts from this IP (and none is a staff member or at TL2 or higher), stop accepting new signups from that IP. Set to 0 to disable the limit. | |
| ------ | |
| This setting controls the maximum number of new user accounts originating from the same IP address that hold Trust Level 0. If this IP doesn't have any account that holds a staff status or Trust Level 2 or higher, and exceeds the specified limit, further signups from that IP will be hindered. Setting the value to 0 disables the limitation entirely. | |
| min_ban_entries_for_roll_up: | |
| When clicking the Roll up button, will create a new subnet ban entry if there are at least (N) entries. | |
| ------ | |
| The 'Roll up' feature generates a new subnet ban entry when the count of entries reaches or exceeds a specified limit. This setting allows you to configure this limit, defining a threshold of minimum ban entries that triggers the creation of the new subnet ban entry. Utilize this to strategically manage IP address activity and improve your ban system efficiency. | |
| max_age_unmatched_emails: | |
| Delete unmatched screened email entries after (N) days. | |
| ------ | |
| Remove unmatched screened email records from the system after a specified number of days. | |
| max_age_unmatched_ips: | |
| Delete unmatched screened IP entries after (N) days. | |
| ------ | |
| Automatically remove screened IP entries that haven't been matched after a certain number of days. This cleaning process takes place once per day. The interval for deletion is determined by you and is denoted as (N) in the setting. | |
| num_flaggers_to_close_topic: | |
| Minimum number of unique flaggers that is required to automatically pause a topic for intervention | |
| ------ | |
| Specifies the minimum quantity of unique users who must flag a topic before it is automatically paused for moderation intervention. | |
| auto_close_topic_sensitivity: | |
| The likelihood that a flagged topic will be automatically closed | |
| ------ | |
| Refined Description: Indicates the sensitivity level needed for a topic to be automatically closed upon detecting a flag. The higher the sensitivity setting, the greater the probability that a flagged topic will undergo automatic closure. | |
| num_hours_to_close_topic: | |
| Number of hours to pause a topic for intervention. | |
| ------ | |
| Specify the length of time, in hours, that a topic will be paused for moderation in cases where the predefined threshold for flags or interventions has been surpassed. Once this duration has elapsed, the topic will be automatically reopened unless otherwise acted upon by the moderation team. | |
| auto_respond_to_flag_actions: | |
| Enable automatic reply when disposing a flag. | |
| ------ | |
| Activate this setting to automatically send a reply when a flag on a post is resolved. This ensures that users are informed promptly about the disposition of their flagged posts. | |
| min_first_post_typing_time: | |
| Minimum amount of time in milliseconds a user must type during first post, if threshold is not met post will automatically enter the needs approval queue. Set to 0 to disable (not recommended) | |
| ------ | |
| Indicates the minimum time (in milliseconds) a user should spend typing their first post. If the typing duration doesn't meet this threshold, the post is placed into the approval queue automatically. If set to 0, this function is disabled, which is not advisable due to potential spam risks. | |
| auto_silence_fast_typers_on_first_post: | |
| Automatically silence users that do not meet min_first_post_typing_time | |
| ------ | |
| Enable this setting to automatically mute first-time users who type their initial post at a speed that does not meet the minimum typing time requirement. This is helpful in preventing spam or bots making their first post. | |
| auto_silence_fast_typers_max_trust_level: | |
| Maximum trust level to auto silence fast typers | |
| ------ | |
| Specifies the highest trust level at which users will be automatically silenced if they type too quickly. This is applicable when users are making their first post. The typing speed is measured against the 'min_first_post_typing_time' setting. | |
| auto_silence_first_post_regex: | |
| Case insensitive regex that if passed will cause first post by user to be silenced and sent to approval queue. Example: raging|a[bc]a , will cause all posts containing raging or aba or aca to be silenced on first. Only applies to first post. DEPRECATED: Use Silence Watched Words instead. | |
| ------ | |
| Refined description: This is a case-insensitive regular expression which, if matched, will cause a new user's first post to be silenced and forwarded to the approval queue. For instance, if it's set to 'raging|a[bc]a', any first post containing 'raging', 'aba', or 'aca' will be silenced. This adjustment is applicable only to the first post. Note: This feature is deprecated and it's recommended to use 'Silence Watched Words' instead. | |
| high_trust_flaggers_auto_hide_posts: | |
| New user posts are automatically hidden after being flagged as spam by a TL3+ user | |
| ------ | |
| When a post from a new user (Trust Level 0) is flagged as spam by a seasoned member (Trust Level 3 or higher), it's automatically hidden from view. This prevents potentially inappropriate content from reaching a wider audience. | |
| cooldown_hours_until_reflag: | |
| How much time users will have to wait until they are able to reflag a post | |
| ------ | |
| Indicates the duration in hours that users must wait before they can flag the same post again. | |
| slow_mode_prevents_editing: | |
| Does 'Slow Mode' prevent editing, after editing_grace_period? | |
| ------ | |
| Set 'Slow Mode' to restrict post editing after the designated editing grace period has elapsed. | |
| reviewable_claiming: | |
| Does reviewable content need to be claimed before it can be acted upon? | |
| ------ | |
| Specifies whether reviewable content needs to be claimed by a user before any action can be taken on it. This encompasses actions such as editing, flagging, responding, and others. | |
| reviewable_default_topics: | |
| Show reviewable content grouped by topic by default | |
| ------ | |
| Display contents open for review sorted by topic as the default view. This applies when a user with review privilege accesses the review section from the hamburger menu. The distinction between topic-view or an alternate view depends on this setting. | |
| reviewable_default_visibility: | |
| Don't show reviewable items unless they meet this priority | |
| ------ | |
| Display reviewable items only if they match or exceed the specified priority level. | |
| reviewable_low_priority_threshold: | |
| The priority filter hides reviewable items that don't meet this score unless the '(any)' filter is used. | |
| ------ | |
| Establishes the cutoff score for viewing low-priority reviewable items. When using the priority filter, items with a score less than this threshold will remain hidden unless '(any)' filter is selected. | |
| reviewable_revision_reasons: | |
| List of reasons that can be selected when rejecting a reviewable queued post with a revision. Other is always available as well, which allows for a custom reason to be entered. | |
| ------ | |
| Defines a list of predefined reasons that can be chosen when rejecting a post revision under review. The option 'Other' is automatically included, allowing a unique reason to be inputted when none of the listed reasons fits. | |
| unique_posts_mins: | |
| How many minutes before a user can make a post with the same content again | |
| ------ | |
| "Specify the duration, in minutes, a user must wait before being permitted to post content identical to their recent post." | |
| rate_limit_create_topic: | |
| After creating a topic, users must wait (n) seconds before creating another topic. | |
| ------ | |
| This setting enforces a waiting period in seconds between creating topics by a user. The interval, denoted as (n), determines the minimum time a user must wait before they can create a new topic. | |
| rate_limit_create_post: | |
| After posting, users must wait (n) seconds before creating another post. | |
| ------ | |
| Enforces a mandatory pause after each post. Users are required to wait a defined number of seconds after making a post before they can create a new one. This setting is beneficial in controlling the rate of post creation. | |
| rate_limit_new_user_create_post: | |
| After posting, new users must wait (n) seconds before creating another post. | |
| ------ | |
| Enforces a mandatory waiting period in seconds for new users between consecutive posts. The time period is set by the admin and ensures that new users cannot rapidly create multiple posts in quick succession. | |
| max_topics_per_day: | |
| Maximum number of topics a user can create per day. | |
| ------ | |
| Cap on daily topic creation: this setting specifies the maximum quantity of new topics that a standard user is allowed to generate within a single day. | |
| max_personal_messages_per_day: | |
| Maximum number of new personal message topics a user can create per day. | |
| ------ | |
| This setting determines the maximum number of personal message topics that a user is allowed to create in a single day. This limit helps manage messaging traffic and prevent spamming. | |
| max_likes_per_day: | |
| Maximum number of likes per user per day. | |
| ------ | |
| Define the ceiling for the number of likes that each user can bestow within a 24-hour period. | |
| max_bookmarks_per_day: | |
| Maximum number of bookmarks per user per day. | |
| ------ | |
| Determines the maximum count of bookmarks that each user is allowed to create in a given day. | |
| max_flags_per_day: | |
| Maximum number of flags per user per day. | |
| ------ | |
| Establishes the daily limit for the number of flags a user can issue. | |
| max_edits_per_day: | |
| Maximum number of edits per user per day. | |
| ------ | |
| Defines the upper limit for how many times a user can edit their posts within one day. This limit can be adjusted for users with a trust level of 2 or higher, and is determined by a multiplier set in the site settings. | |
| max_invites_per_day: | |
| Maximum number of invites a user can send per day. | |
| ------ | |
| Set the cap on the number of invitations a user can send within a 24-hour period. This limit helps to maintain the site's integrity by preventing spam and ensuring the quality of interactions. It's important to note that this restriction applies to all users, regardless of their roles or trust levels. | |
| max_topic_invitations_per_day: | |
| Maximum number of topic invitations a user can send per day. | |
| ------ | |
| Defines the upper limit on the number of topic invitations that a user is allowed to send within a 24-hour period. | |
| max_topic_invitations_per_minute: | |
| Maximum number of topic invitations a user can send per minute. | |
| ------ | |
| Sets the upper limit for the number of topic invitations that a user can send within a 60-second interval. This limit is enforced to prevent spamming and maintain a healthy interaction environment. | |
| max_topics_in_first_day: | |
| The maximum number of topics a user is allowed to create in the 24 hour period after creating their first post | |
| ------ | |
| Sets the maximum number of topics that a new user can create within the first 24 hours after posting their initial topic. | |
| max_replies_in_first_day: | |
| The maximum number of replies a user is allowed to create in the 24 hour period after creating their first post | |
| ------ | |
| Refined description: Specify the upper limit on the replies that a new user can make within the initial 24 hours after posting their first message. This helps to regulate participation by new users, ensuring they observe discussions before posting extensively. | |
| tl2_additional_likes_per_day_multiplier: | |
| Increase limit of likes per day for tl2 (member) by multiplying with this number | |
| ------ | |
| Adjust the daily 'like' limit for trust level 2 (member) users by multiplying with this specified value. This allows you to enhance user engagement by providing them with a higher 'like' cap based on their trust level. | |
| tl3_additional_likes_per_day_multiplier: | |
| Increase limit of likes per day for tl3 (regular) by multiplying with this number | |
| ------ | |
| Boost the likes-per-day limit for Trust Level 3 (regular) users by using this multiplier factor. The number set here will be used to multiply the standard limit, providing Level 3 users with an increased capacity for expressing appreciation of others' posts. | |
| tl4_additional_likes_per_day_multiplier: | |
| Increase limit of likes per day for tl4 (leader) by multiplying with this number | |
| ------ | |
| Enhances the daily 'like' quota for users at trust level 4 (Leaders) by multiplying it with the specified value. This setting allows leaders to express more appreciation and recognition towards valuable contributions. | |
| tl2_additional_edits_per_day_multiplier: | |
| Increase limit of edits per day for tl2 (member) by multiplying with this number | |
| ------ | |
| Refines the daily editing limit for members (trust level 2 or tl2) by scaling it with this multiplier. The outcome sets the maximum number of times a member can edit their posts in a day. | |
| tl3_additional_edits_per_day_multiplier: | |
| Increase limit of edits per day for tl3 (regular) by multiplying with this number | |
| ------ | |
| Elevate the daily edit limit for Regular (Trust Level 3) users by applying a multiplier to the existing limit. The value entered in this setting will be used to calculate the new daily edit limit. | |
| tl4_additional_edits_per_day_multiplier: | |
| Increase limit of edits per day for tl4 (leader) by multiplying with this number | |
| ------ | |
| Boost the daily edit limit for users with trust level 4 (leader) by multiplying it with the value set in this setting. This ensures those at the peak of the trust hierarchy have additional privilege to make more modifications in a given day. | |
| tl2_additional_flags_per_day_multiplier: | |
| Increase limit of flags per day for tl2 (member) by multiplying with this number | |
| ------ | |
| Augment the daily flag limit for users at trust level 2 (member) by multiplying with this specified number. | |
| tl3_additional_flags_per_day_multiplier: | |
| Increase limit of flags per day for tl3 (regular) by multiplying with this number | |
| ------ | |
| Enhance the daily flag limit for regular (tl3) users by applying this multiplier. The number represents the factor by which the daily limit for raising flags will be multiplied, providing regular users with additional flagging capacity. | |
| tl4_additional_flags_per_day_multiplier: | |
| Increase limit of flags per day for tl4 (leader) by multiplying with this number | |
| ------ | |
| Boost the daily flag limit for users at trust level 4 (leaders) by utilizing this multiplier. | |
| alert_admins_if_errors_per_minute: | |
| Number of errors per minute in order to trigger an admin alert. A value of 0 disables this feature. NOTE: requires restart. | |
| ------ | |
| Set the threshold for the number of errors per minute that, if reached or exceeded, will trigger an admin alert. A value of 0 will disable notifications for minute-based error rate alerts. Please note that changes to this setting require the system to be restarted for them to take effect. | |
| alert_admins_if_errors_per_hour: | |
| Number of errors per hour in order to trigger an admin alert. A value of 0 disables this feature. NOTE: requires restart. | |
| ------ | |
| Sets the threshold for the number of system errors occurring within an hour that will trigger an admin alert. A value of 0 will turn off this feature. Please note that changing this value requires a system restart. This helps administrators stay informed about system health and potential issues. | |
| max_prints_per_hour_per_user: | |
| Maximum number of /print page impressions (set to 0 to disable printing) | |
| ------ | |
| "Specify the maximum number of times a user can access the 'Print Page' view within an hour. A value of 0 completely disallows users from viewing this page." | |
| max_logins_per_ip_per_hour: | |
| Maximum number of logins allowed per IP address per hour | |
| ------ | |
| This setting controls the maximum number of times a user can log in from a specific IP address within an hour. Exceeding this limit will result in a temporary inability to log in from the same IP address. This measure is in place to prevent potential misuse and preserve the site's security. | |
| max_logins_per_ip_per_minute: | |
| Maximum number of logins allowed per IP address per minute | |
| ------ | |
| Set a limit for the number of login attempts from a single IP address within a minute. This is a security measure helping to prevent brute-force attacks by limiting rapid, repeated login attempts from the same source. | |
| max_post_deletions_per_minute: | |
| Maximum number of posts a user can delete per minute. Set to 0 to disable post deletions. | |
| ------ | |
| Define the upper limit for the number of posts a user is permitted to delete within a span of one minute. If the limit is set at 0, the delete post function will be disabled, prohibiting users from deleting their posts. | |
| max_post_deletions_per_day: | |
| Maximum number of posts a user can delete per day. Set to 0 to disable post deletions. | |
| ------ | |
| Establish the maximum limit for deleting posts by a user within a 24-hour period. A value of 0 would mean users can't delete any posts. This cap integrates with the trust level system, offering higher trust level users more control over their content. Note that archived topic posts can only be deleted by staff members regardless of this setting. | |
| invite_link_max_redemptions_limit: | |
| Maximum redemptions allowed for invite links can't be more than this value. | |
| ------ | |
| The 'invite_link_max_redemptions_limit' setting defines the upper limit on redeemable invite links. This indicates the maximum number of times an invite link can be used before it becomes invalid. Staff members have a separate limit, identified by 'invite_link_max_redemptions_limit_users' setting. Note that individual email invites can only be used once. | |
| invite_link_max_redemptions_limit_users: | |
| Maximum redemptions allowed for invite links generated by regular users can't be more than this value. | |
| ------ | |
| Designate the upper limit on how many times an invite link, created by a regular user, can be redeemed. This value acts as a cap, preventing a single invite link from being utilized beyond this predefined number. | |
| flush_timings_secs: | |
| How frequently we flush timing data to the server, in seconds. | |
| ------ | |
| Defines the interval, in seconds, at which the timing information is scheduled to be sent to the server. This pertains to data such as how long users spent viewing different posts or sections of the site. | |
| active_user_rate_limit_secs: | |
| How frequently we update the 'last_seen_at' field, in seconds | |
| ------ | |
| Sets the interval in seconds at which the user's 'last_seen_at' value is updated, reflecting the most recent activity timestamp. | |
| verbose_localization: | |
| Show extended localization tips in the UI | |
| ------ | |
| Enable extended localization tips in the user interface. This feature, when turned on, provides more detailed guidance related to the locale settings of the site. | |
| top_topics_formula_log_views_multiplier: | |
| value of log views multiplier (n) in top topics formula: `log(views_count) * (n) + op_likes_count * 0.5 + LEAST(likes_count / posts_count, 3) + 10 + log(posts_count)` | |
| ------ | |
| "Log Views Multiplier Value" is a part of the top topics formula that influences the ranking of topics. The setting adjusts the weight given to topic views in the formula. By default, it's assigned a value of '2'. Consider tweaking this if you wish to make the number of views a topic receives more or less significant in determining the topic's popularity. The updated top topics formula becomes: `log(views_count) * (n) + op_likes_count * 0.5 + LEAST(likes_count / posts_count, 3) + 10 + log(posts_count)`, where 'n' is the Configured Multiplier Value. | |
| top_topics_formula_first_post_likes_multiplier: | |
| value of first post likes multiplier (n) in top topics formula: `log(views_count) * 2 + op_likes_count * (n) + LEAST(likes_count / posts_count, 3) + 10 + log(posts_count)` | |
| ------ | |
| Adjusts the indluence of first post likes on the calculation that determines top topics. The equation used is as follows: `log(views_count) * 2 + op_likes_count * (n) + LEAST(likes_count / posts_count, 3) + 10 + log(posts_count)`. In this equation, 'n' is the first post likes multiplier. Increasing 'n' gives more weight to the number of likes the first post in a topic received when assigning a score for top topics. | |
| top_topics_formula_least_likes_per_post_multiplier: | |
| value of least likes per post multiplier (n) in top topics formula: `log(views_count) * 2 + op_likes_count * 0.5 + LEAST(likes_count / posts_count, (n)) + 10 + log(posts_count)` | |
| ------ | |
| Define the value of the "least likes per post" multiplier in the top topics formula. This formula calculates the popularity of a topic based on various factors such as views, liked posts, and total posts in a topic. The "least likes per post" multiplier, denoted by (n), limits the influence of highly liked posts, ensuring topics aren't disproportionately scored by a single well-received post. The formula is: log(views_count) * 2 + op_likes_count * 0.5 + the minimum of likes_count/posts_count and (n) + 10 + log(posts_count). The default value of this multiplier is 3. | |
| enable_safe_mode: | |
| Allow users to enter safe mode to debug plugins. | |
| ------ | |
| Permit users to activate safe mode for troubleshooting plugins. | |
| experimental_form_templates: | |
| EXPERIMENTAL: Enable the form templates feature. <b>After enabled,</b> manage the templates at <a href='%{base_path}/admin/customize/form-templates'>Customize / Templates</a>. | |
| ------ | |
| Enable the use of form templates on your site. Note that this is an experimental feature and may not be fully functional. Once activated, you can manage your templates through <a href='%{base_path}/admin/customize/form-templates'>Customize / Templates</a>. | |
| experimental_new_new_view_groups: | |
| EXPERIMENTAL: Enable a new topics list that combines unread and new topics and make the "Everything" link in the sidebar link to it. | |
| ------ | |
| Enable an experimental feature that merges the lists of unread and new topics into a single list, and converts the "Everything" link in the sidebar to direct to this combined list. Please note that this is experimental, use with caution as it may affect the site's user experience. | |
| enable_experimental_lightbox: | |
| EXPERIMENTAL: Replace the default image lightbox with the revamped design. | |
| ------ | |
| Revamps the default image lightbox with an experimental design. This setting applies a new layout to the image lightbox feature, altering how images are viewed within posts. Note: this is an experimental feature, meaning it is still under development and may not be functionally complete or stable. Use with discretion. | |
| experimental_topics_filter: | |
| EXPERIMENTAL: Enables the experimental topics filter route at /filter | |
| ------ | |
| Enables the experimental topics filter route at /filter as a testing feature. Access to this route allows the application of dynamic filters on the forum's topics. This option should be used with caution since it's in the experimental stage and may contain unstable features. | |
| experimental_search_menu_groups: | |
| EXPERIMENTAL: Enables the new search menu that has been upgraded to use glimmer | |
| ------ | |
| Activate the experimental version of the search menu. This enhanced search menu utilizes glimmer technology for improved performance. Please note that this feature is still under development and should be used with discretion. | |
| navigation_menu: | |
| Determine which navigation menu to use. Sidebar and header navigation are customizable by users. Legacy option is available for backward compatibility. | |
| ------ | |
| Select the type of navigation menu for the site. Users can choose between sidebar and header navigation. A legacy option is also provided if you want to maintain the same look of your site as earlier versions for compatibility reasons. | |
| default_navigation_menu_categories: | |
| Selected categories will be displayed under Navigation Menu's Categories section by default. | |
| ------ | |
| Categories chosen in this setting will be prominently displayed in the Categories section of the Navigation Menu, adding a convenient layer of quick accessibility for users. | |
| default_navigation_menu_tags: | |
| Selected tags will be displayed under Navigation Menu's Tags section by default. | |
| ------ | |
| Specifies the tags that appear in the Tags section of the Navigation Menu by default. This setting allows you to control which tags are immediately visible to users in the navigation menu when they visit your site, providing a more streamlined browsing experience. | |
| default_sidebar_switch_panel_position: | |
| Position of sidebar switch panel buttons | |
| ------ | |
| Specifies the location of the sidebar switch panel buttons. This setting allows you to choose whether the buttons are positioned at the top or the bottom of the sidebar. | |
| tos_url: | |
| If you have a Terms of Service document hosted elsewhere that you want to use, provide the full URL here. | |
| ------ | |
| Specify the complete URL for your externally hosted Terms of Service document if you choose not to use the default. This external link will replace the default Terms of Service page in your discourse site. | |
| privacy_policy_url: | |
| If you have a Privacy Policy document hosted elsewhere that you want to use, provide the full URL here. | |
| ------ | |
| Enter the full URL of your externally hosted Privacy Policy document here, if you prefer to use it instead of the default one provided by the site. | |
| faq_url: | |
| If you have a FAQ hosted elsewhere that you want to use, provide the full URL here. | |
| ------ | |
| Specify a full URL here if you wish to use an externally hosted FAQ page instead of the default one provided by the platform. | |
| log_anonymizer_details: | |
| Whether to keep a user's details in the log after being anonymized. | |
| ------ | |
| Enable this setting if you want to preserve a user's details in the anonymization log. This can be useful for maintaining records, while still protecting user privacy by anonymizing their information. | |
| enable_backups: | |
| Allow administrators to create backups of the forum | |
| ------ | |
| Allows site administrators to generate data backups of the forum for preservation and potential future restoration purposes. | |
| allow_restore: | |
| Allow restore, which can replace ALL site data! Leave disabled unless you plan to restore a backup | |
| ------ | |
| Enables data restoration, a process that substitutes all current site data with a backup. Only enable this function if you are intending to recover data from a backup. | |
| backup_location: | |
| Location where backups are stored. IMPORTANT: S3 requires valid S3 credentials entered in Files settings. | |
| ------ | |
| Specifies the destination for storing backups. If you're using S3 storage, ensure valid S3 credentials are configured in the Files settings. | |
| maximum_backups: | |
| The maximum amount of backups to keep. Older backups are automatically deleted | |
| ------ | |
| Establishes the limit for the number of stored backups. Any older backups exceeding this limit will be removed automatically. | |
| automatic_backups_enabled: | |
| Run automatic backups as defined in backup frequency | |
| ------ | |
| Activate this setting to automatically execute data backups based on the frequency determined in the backup frequency setting. Once enabled, the system will automatically create backups at the pre-set intervals, ensuring the safeguarding and integrity of your site data. | |
| backup_frequency: | |
| The number of days between backups. | |
| ------ | |
| Specifies the interval, in days, at which automatic backups of the site are created. If set to 7, for example, a new backup will be generated every week. The activation of this setting is contingent upon enabling the automatic backup feature. | |
| s3_backup_bucket: | |
| The remote bucket to hold backups. WARNING: Make sure it is a private bucket. | |
| ------ | |
| Specify the name of the remote S3 bucket where your site backups will be stored. Exercise caution to ensure that this specified bucket is private to prevent unauthorized access to your site backups. | |
| s3_disable_cleanup: | |
| Prevent removal of old backups from S3 when there are more backups than the maximum allowed. | |
| ------ | |
| Stop the automatic deletion of old backups on S3 when the quantity of backups exceeds the defined maximum limit. | |
| backup_time_of_day: | |
| Time of day UTC when the backup should occur. | |
| ------ | |
| Specify the preferred time, in UTC format, when the system should execute automatic backups. This setting allows you to strategically schedule backups during off-peak hours, ensuring minimal disruption to your site's operation. | |
| backup_with_uploads: | |
| Include uploads in scheduled backups. Disabling this will only backup the database. | |
| ------ | |
| Incorporate uploads into the regular backup schedule. If turned off, only the database will be backed up. | |
| backup_gzip_compression_level_for_uploads: | |
| Gzip compression level used for compressing uploads. | |
| ------ | |
| Refers to the level of Gzip compression applied when backing up uploads. Higher levels mean smaller backups but take longer to create and restore. | |
| include_thumbnails_in_backups: | |
| Include generated thumbnails in backups. Disabling this will make backups smaller, but requires a rebake of all posts after a restore. | |
| ------ | |
| Retain generated thumbnails in the backup files. Disabling this option results in smaller backup sizes, however, it necessitates the rebaking of all posts following a restoration. | |
| min_search_term_length: | |
| Minimum valid search term length in characters | |
| ------ | |
| Defines the least number of characters required for a search term to be recognized as valid by the search function. If a term falls short of this minimum length, the system will deem it as invalid. Applicable to general site search and also search functions within plugins such as Discourse Ai. | |
| search_tokenize_chinese: | |
| Force search to tokenize Chinese even on non Chinese sites | |
| ------ | |
| Enable tokenization of Chinese text for search functionality, irrespective of the site's primary language. This optimizes searching in Chinese even if the site isn't primarily Chinese. | |
| search_tokenize_japanese: | |
| Force search to tokenize Japanese even on non Japanese sites | |
| ------ | |
| Enforce the use of tokenized search for Japanese words, regardless of the site's default language settings. This setting enhances search efficiency and accuracy for Japanese terms, even if your site operates primarily in a different language. | |
| search_prefer_recent_posts: | |
| If searching your large forum is slow, this option tries an index of more recent posts first | |
| ------ | |
| Use this setting to prioritize recent posts when performing a search on your forum, especially when the forum has a large volume of content. Enabling this will first load an index of newer posts, which can enhance the speed of search operations. | |
| search_recent_posts_size: | |
| How many recent posts to keep in the index | |
| ------ | |
| Specify the number of recent posts to include in the search index. This value sets the limit for how many of the latest posts are prioritized and kept in the search index for quick access and search efficiency. | |
| log_search_queries: | |
| Log search queries performed by users | |
| ------ | |
| Record all search queries made by users. | |
| search_query_log_max_size: | |
| Maximum amount of search queries to keep | |
| ------ | |
| Defines the maximum number of recent search queries to retain on the site. After this number is exceeded, older entries are automatically removed, ensuring efficient site performance and manageable data volume. | |
| search_query_log_max_retention_days: | |
| Maximum amount of time to keep search queries, in days. | |
| ------ | |
| Defines the maximum duration, in days, for retaining search queries on the site. After this specified period, the search query logs will be automatically removed to maintain site hygiene. | |
| search_ignore_accents: | |
| Ignore accents when searching for text. | |
| ------ | |
| Accent marks in search queries are disregarded if this setting is enabled, allowing users to find results even if they don't input the correct accents. | |
| version_checks: | |
| Ping the Discourse Hub for version updates and show new version messages on the <a href='%{base_path}/admin' target='_blank'>/admin</a> dashboard | |
| ------ | |
| Enable this setting to allow Discourse to regularly check with the Discourse Hub for any available version updates. Upon detecting an update, it will display a message on the <a href='%{base_path}/admin' target='_blank'>/admin</a> dashboard. | |
| new_version_emails: | |
| Send an email to the contact_email address when a new version of Discourse is available. | |
| ------ | |
| Activates notifications via email to the 'contact_email' address whenever Discourse releases a new version. | |
| send_welcome_message: | |
| Send all new users a welcome message with a quick start guide. | |
| ------ | |
| Automatically sends a welcome message, which includes a quick start guide, to every new user upon their registration. | |
| suppress_uncategorized_badge: | |
| Don't show the badge for uncategorized topics in topic lists. | |
| ------ | |
| Prevent the display of badges for topics that are not categorized on the topic lists. | |
| header_dropdown_category_count: | |
| How many categories can be displayed in the header dropdown menu. | |
| ------ | |
| Set the maximum number of categories that appear in the header dropdown menu. The platform will limit the visible categories to this specified count, prioritizing categories based on user notification levels and recent topic activity. | |
| slug_generation_method: | |
| Choose a slug generation method. 'encoded' will generate percent encoding string. 'none' will disable slug at all. | |
| ------ | |
| Select a method for generating slugs. The 'encoded' option will produce a percent-encoded string, whereas the 'none' option will not generate a slug at all. | |
| permalink_normalizations: | |
| Apply the following regex before matching permalinks, for example: /(topic.*)\?.*/\1 will strip query strings from topic routes. Format is regex+string use \1 etc. to access captures | |
| ------ | |
| Use this setting to apply specific regular expressions (regex) before matching permalinks. As an example, the regex /(topic.*)\?.*/\1 can be used to remove a query string from topic routes. Format your input as regex+string, and use \1, \2, and so on to access and use captured groups. This normalization process helps to maintain consistent and clean URLs throughout your site. Be sure to carefully construct your regex to avoid any unintended effects on the URLs. | |
| max_similar_results: | |
| How many similar topics to show above the editor when composing a new topic. Comparison is based on title and body. | |
| ------ | |
| Specify the number of similar topics to display above the editor when drafting a new topic. The similarity of topics is gauged based on both the topic title and the body text. | |
| minimum_topics_similar: | |
| How many topics need to exist before similar topics are presented when composing new topics. | |
| ------ | |
| Specifies the minimum number of existing topics needed before the forum suggests similar topics to users while they are creating new topics. | |
| previous_visit_timeout_hours: | |
| How long a visit lasts before we consider it the 'previous' visit, in hours | |
| ------ | |
| Designates the duration, in hours, that constitutes a visit before it is classified as the 'previous' visit. | |
| staff_like_weight: | |
| How much weight to give staff likes (non-staff likes have a weight of 1.) | |
| ------ | |
| Assigns the influence level of likes given by staff members. Non-staff member likes have a baseline value of 1. The higher the value assigned to staff likes, the more influence they carry towards the like score of a post. | |
| topic_view_duration_hours: | |
| Count a new topic view once per IP/User every N hours | |
| ------ | |
| Register a unique topic view based on each IP or User ID after a specified number of hours. This interval allows for the counting of multiple views from the same source after a certain duration, ensuring the view counts for topics remain accurate over time. | |
| user_profile_view_duration_hours: | |
| Count a new user profile view once per IP/User every N hours | |
| ------ | |
| Define the interval time in hours at which a new view of a user profile is counted, either per unique user or per IP address. For example, setting this to 'N' hours means that repeated profile views by the same user or from the same IP address will only be recorded as one additional view every 'N' hours. | |
| summary_score_threshold: | |
| The minimum score required for a post to be included in 'Summarize This Topic' | |
| ------ | |
| The minimum score a post must attain in order to be considered for inclusion in the 'Summarize This Topic' feature. | |
| summary_posts_required: | |
| Minimum posts in a topic before 'Summarize This Topic' is enabled. Changes to this setting will be applied retroactively within a week. | |
| ------ | |
| Indicates the minimum number of posts that a topic must contain for the 'Summarize This Topic' feature to become available. Any alterations made to this setting will be retroactively effective within a span of one week. | |
| summary_likes_required: | |
| Minimum likes in a topic before 'Summarize This Topic' is enabled. Changes to this setting will be applied retroactively within a week. | |
| ------ | |
| This setting stipulates the minimum number of likes that a topic should receive before the 'Summarize This Topic' feature becomes available. Any alterations to this setting will take effect within a week retrospectively. The 'Summarize This Topic' function breaks down complex discussions into easily digestible summaries for streamlined navigation and understanding. | |
| summary_percent_filter: | |
| When a user clicks 'Summarize This Topic', show the top % of posts | |
| ------ | |
| When the 'Summarize This Topic' function is utilized, this setting will display the most relevant posts, where relevance is determined by the top percentile of posts as per this setting's value. For instance, if the setting is set at 20, the top 20% of posts in a topic will be showcased when summarized. | |
| summary_max_results: | |
| Maximum posts returned by 'Summarize This Topic' | |
| ------ | |
| Specifies the maximum number of posts that can be retrieved when utilizing the 'Summarize This Topic' function. It controls the limit on the number of important posts that can be displayed from a discussion, sorted by relevance. | |
| summary_timeline_button: | |
| Show a 'Summarize' button in the timeline | |
| ------ | |
| Indicate the presence of a 'Summarize' button on the topic timeline, which helps in displaying a summary view of the topic discussions. When enabled, this button allows users to overview a brief summary of the topic without scrolling through the entire topic. The button appears in the non-full-screen view of a topic, provided that the topic has a summary available. | |
| summarization_strategy: | |
| Additional ways to summarize content registered by plugins | |
| ------ | |
| "Configure alternative methods for content summarization provided by plugins" | |
| custom_summarization_allowed_groups: | |
| Groups allowed to summarize contents using the `summarization_strategy`. | |
| ------ | |
| Identifies the groups permitted to use content summarization. The `summarization_strategy` designates the method of summarization. Features of this setting may require other factors such as site settings to operate correctly. | |
| automatic_topic_heat_values: | |
| Automatically update the "topic views heat" and "topic post like heat" settings based on site activity. | |
| ------ | |
| Enable the automatic updating of the "topic views heat" and "topic post like heat" settings in line with the site's activity levels. These settings reflect the popularity of topics based on views and likes, respectively. | |
| topic_views_heat_low: | |
| After this many views, the views field is slightly highlighted. | |
| ------ | |
| When a topic's view count reaches or exceeds this number, a subtle highlight is applied to the view field for increased visibility. It serves as the lower threshold for applying a 'low' level heat highlight on views. | |
| topic_views_heat_medium: | |
| After this many views, the views field is moderately highlighted. | |
| ------ | |
| When a topic reaches this specified number of views, the views field will shift to a medium intensity highlight. This settings is part of the "heat map" view visualization, where higher viewed topics are more noticeably highlighted. | |
| topic_views_heat_high: | |
| After this many views, the views field is strongly highlighted. | |
| ------ | |
| The number of views a topic needs to achieve in order for its views count to receive strong highlighting. Once exceeded, this setting triggers a noticeable visual emphasis, providing clear indication to users about the popularity of the topic. | |
| topic_post_like_heat_low: | |
| After the likes:post ratio exceeds this ratio, the post count field is slightly highlighted. | |
| ------ | |
| When the post-to-like ratio surpasses this threshold, the post count field is subtly emphasized with a light highlight. The intent is to visually indicate posts with an exceptional ratio of likes to posts, thereby promoting impactful conversation. | |
| topic_post_like_heat_medium: | |
| After the likes:post ratio exceeds this ratio, the post count field is moderately highlighted. | |
| ------ | |
| When the ratio of likes to posts exceeds this value, a moderate highlight is applied to the post count. This is designed to visually distinguish posts that are garnering more engagement in the form of likes. | |
| topic_post_like_heat_high: | |
| After the likes:post ratio exceeds this ratio, the post count field is strongly highlighted. | |
| ------ | |
| When the ratio of likes to posts surpasses this specified value, a prominent highlight is added to the post count field, indicating higher engagement. | |
| history_hours_low: | |
| A post edited within this many hours has the edit indicator slightly highlighted | |
| ------ | |
| Specify the number of hours within which, if a post is edited, the edit indicator will appear slightly highlighted. This setting serves as the lower threshold for visual cues indicating post modifications. | |
| history_hours_medium: | |
| A post edited within this many hours has the edit indicator moderately highlighted. | |
| ------ | |
| Setting allows to moderately highlight the edit indicator for a post that has been edited within the specified number of hours. | |
| history_hours_high: | |
| A post edited within this many hours has the edit indicator strongly highlighted. | |
| ------ | |
| "Adjusts the intensity of the post edit indicator based on the number of hours passed since the post was last edited. The fewer the hours, the more strongly the edit indicator will be highlighted." | |
| cold_age_days_low: | |
| After this many days of conversation, the last activity date is slightly dimmed. | |
| ------ | |
| Set the number of days after which, if there is no activity in a conversation, the date of the last activity would appear slightly faded. | |
| cold_age_days_medium: | |
| After this many days of conversation, the last activity date is moderately dimmed. | |
| ------ | |
| Set the duration in days, after which a conversation's last activity date will be moderately dimmed to indicate lesser recent interaction. The dimming visually signals that some time has passed since the last activity on the topic. | |
| cold_age_days_high: | |
| After this many days of conversation, the last activity date is strongly dimmed. | |
| ------ | |
| Indicates the number of days following the last activity in a conversation after which it will be visually marked as significantly old. Adjusting this value will alter the visual dimming effect applied, allowing users to easily identify inactive or 'cold' conversations. | |
| educate_until_posts: | |
| When the user starts typing their first (n) new posts, show the pop-up new user education panel in the composer. | |
| ------ | |
| Display the education panel for new users in the composer, providing them guidance and help, while they're creating their initial few posts. This panel will appear for the first 'n' number of posts that they attempt to compose. Note: 'n' is a numerical value that can be adjusted according to administrative preferences. | |
| sequential_replies_threshold: | |
| Number of posts a user has to make in a row in a topic before being reminded about too many sequential replies. | |
| ------ | |
| The 'sequential_replies_threshold' refers to the number of consecutive posts a user can make in a single topic before they receive a reminder not to post too many sequential replies. This helps to promote more balanced conversation by encouraging users to let others contribute to the topic as well. | |
| get_a_room_threshold: | |
| Number of posts a user has to make to the same person in the same topic before being warned. | |
| ------ | |
| Specifies the number of replies a user can send to the same participant within a single topic before a warning is issued. Notably, this setting is designed to facilitate balanced discussions by prompting users who may be overly focusing their interaction with one specific user in a topic. | |
| dont_feed_the_trolls_threshold: | |
| Number of flags from other users before being warned. | |
| ------ | |
| Minimum number of active flags received from different users before a warning is triggered. | |
| dominating_topic_minimum_percent: | |
| What percentage of posts a user has to make in a topic before being reminded about overly dominating a topic. | |
| ------ | |
| Indicates the minimum percentage of total posts a user must author in a topic before they are advised about their excessive contribution to the discussion. This is designed to prevent singular users from dominating or monopolizing conversations. | |
| disable_avatar_education_message: | |
| Disable education message for changing avatar. | |
| ------ | |
| Turn off the education message about avatar changes. This option, when enabled, prevents users from being notified when they haven't set an avatar image for their profile or need to change it. The setting is useful when avatars are managed by other means, such as Single Sign-On or only certain trust levels are set to upload avatars. | |
| pm_warn_user_last_seen_months_ago: | |
| When creating a new PM warn users when target recepient has not been seen more than n months ago. | |
| ------ | |
| Generates a warning for users composing a private message if the intended recipient has not been active on the platform for more than a specified number of months. | |
| global_notice: | |
| Display an URGENT, EMERGENCY, non-dismissible global banner notice to all visitors, change to blank to hide it (HTML allowed). | |
| ------ | |
| This setting is used to show a critical, urgent, non-dismissable banner to all site visitors. The banner text can be edited at any time and you may use HTML in the message. If you want to remove the banner, simply set the value to blank. Please use this feature for important announcements or emergencies only. | |
| default_composer_category: | |
| The category used to pre-populate the category dropdown when creating a new topic. | |
| ------ | |
| "Pre-define a specific category in the category dropdown for every new topic. When users start creating a new topic, this category will appear as the default choice." | |
| notify_about_reviewable_item_after: | |
| If there are reviewable items that haven’t been handled after this many hours, send a personal message to moderators. Set to 0 to disable. | |
| ------ | |
| Send a personal message to moderators if reviewable items remain unaddressed for a specified number of hours. Input 0 to turn off these notifications. | |
| use_site_small_logo_as_system_avatar: | |
| Use the site's small logo instead of the system user's avatar. Requires the logo to be present. | |
| ------ | |
| Opt to utilize the small version of the site's logo in place of the avatar for the system user. This feature is contingent on a logo being set up on the site. | |
| enable_listing_suspended_users_on_search: | |
| Enable regular users to find suspended users. | |
| ------ | |
| Allow regular users to include suspended users in their search results. | |
| disable_system_edit_notifications: | |
| Disables edit notifications by the system user when 'download_remote_images_to_local' is active. | |
| ------ | |
| "Turn off notifications generated by the system user when the 'download_remote_images_to_local' feature is in use. When enabled, users won't be notified about image download actions performed by the system." | |
| disable_category_edit_notifications: | |
| Disable notifications for topic category edits. This includes topics which are 'published' (e.g. shared drafts). | |
| ------ | |
| Turn off notifications for changes made to the topic's category. This applies to topics that have been 'published', like shared drafts. When this setting is enabled, users will not receive alerts when the category of a topic they are following has been edited. | |
| disable_tags_edit_notifications: | |
| Disable notifications for topic tag edits. This includes topics which are 'published' (e.g. shared drafts). | |
| ------ | |
| "Turn off notifications related to the editing of topic tags, including 'published' topics like shared drafts." | |
| notification_consolidation_threshold: | |
| Number of liked or membership request notifications received before the notifications are consolidated into a single one. Set to 0 to disable. | |
| ------ | |
| Establishes the threshold for the quantity of liked or membership request notifications received before they are combined into a single notification. A value of 0 will turn off this feature, keeping all notifications separate. | |
| likes_notification_consolidation_window_mins: | |
| Duration in minutes where liked notifications are consolidated into a single notification once the threshold has been reached. The threshold can be configured via `SiteSetting.notification_consolidation_threshold`. | |
| ------ | |
| Specifies the time period, in minutes, during which alike notifications are grouped into a single notification once they reach a specified limit. This limit, or threshold, can be set through the setting `SiteSetting.notification_consolidation_threshold`. This feature helps in decluttering notifications by merging multiple similar alerts into a single comprehensive notification. | |
| delete_drafts_older_than_n_days: | |
| Delete drafts older than (n) days. | |
| ------ | |
| Purge drafts that have been idle for a specified number of days. This setting automatically removes any drafts from the system that have not been updated within the determined duration. | |
| delete_merged_stub_topics_after_days: | |
| Number of days to wait before automatically deleting fully merged stub topics. Set to 0 to never delete stub topics. | |
| ------ | |
| Indicates the duration, in days, following which fully merged stub topics are auto-deleted. If you prefer to keep stub topics indefinitely, set this value to 0. | |
| bootstrap_mode_min_users: | |
| Minimum number of users required to disable bootstrap mode (set to 0 to disable, can take up to 24 hours) | |
| ------ | |
| Define the minimum count of users that's needed to deactivate bootstrap mode. When set to 0, bootstrap mode won't be disabled. Please note that this change can require up to a 24-hour interval to be effective. | |
| automatically_unpin_topics: | |
| Automatically unpin topics when the user reaches the bottom. | |
| ------ | |
| Unpin topics for users when they read through to the end of the post content. | |
| read_time_word_count: | |
| Word count per minute for calculating estimated reading time. | |
| ------ | |
| Define the number of words assumed to be read in one minute. This value is important for estimating the time it would take a user to read through a topic. The computation takes into account both the word count of a topic and a minimum post read time. | |
| topic_page_title_includes_category: | |
| Topic page <a href='https://developer.mozilla.org/en-US/docs/Web/HTML/Element/title' target='_blank'>title tag</a> includes the category name. | |
| ------ | |
| Enable this setting if you want the category name to be included in the topic page's title tag. The category name will be appended at the end of the title. This benefits SEO as it provides additional context about the content of the page. For example, "Discussing solar energy - Environment category". Note that the 'Uncategorized' category name will not be included in the title unless it has been renamed. | |
| native_app_install_banner_ios: | |
| Displays DiscourseHub app banner on iOS devices to basic users (trust level 1) and up. | |
| ------ | |
| Display the DiscourseHub app banner on iOS devices for users with a minimum trust level of 1. This feature enhances visibility and accessibility of the DiscourseHub app for trusted users. | |
| native_app_install_banner_android: | |
| Displays DiscourseHub app banner on Android devices to basic users (trust level 1) and up. | |
| ------ | |
| Allows the display of the DiscourseHub app banner on Android devices for users with a minimum trust level of 1. | |
| app_association_android: | |
| Contents of <a href='%{base_path}/.well-known/assetlinks.json'>.well-known/assetlinks.json</a> endpoint, used for Google's Digital Asset Links API. | |
| ------ | |
| The specified content for the <a href='%{base_path}/.well-known/assetlinks.json'>.well-known/assetlinks.json</a> endpoint, which is utilized by Google's Digital Asset Links API. This is essential for associating the website with an Android app. | |
| app_association_ios: | |
| Contents of <a href='%{base_path}/apple-app-site-association'>apple-app-site-association</a> endpoint, used to create Universal Links between this site and iOS apps. | |
| ------ | |
| Specifies the content for the <a href='%{base_path}/apple-app-site-association'>apple-app-site-association</a> endpoint. This content is paramount for establishing Universal Links between the site and iOS applications. | |
| share_anonymized_statistics: | |
| Share anonymized usage statistics. | |
| ------ | |
| Enable sharing of anonymized usage statistics. When this setting is enabled, data concerning the usage of the site is collected and shared in anonymized form, ensuring no personal information is disclosed. This data collection is performed weekly. | |
| auto_handle_queued_age: | |
| Automatically handle records that are waiting to be reviewed after this many days. Flags will be ignored. Queued posts and users will be rejected. Set to 0 to disable this feature. | |
| ------ | |
| Specify the number of days after which unattended records on the review queue will be automatically resolved. If a flag is awaiting review, it will be dismissed, while queued posts and users will be declined. Setting a value of 0 turns off this automatic process. | |
| penalty_step_hours: | |
| Default penalties for silencing or suspending users in hours. First offense defaults to the first value, second offense defaults to the second value, etc. | |
| ------ | |
| Specify the default penalties for user silencing or suspending actions in hours. The first rule listed applies to the first offense, the second rule to the second offense, and so on. Each subsequent offense follows the pattern by aligning with the corresponding rule in the sequence. | |
| svg_icon_subset: | |
| Add additional FontAwesome 5 icons that you would like to include in your assets. Use prefix 'fa-' for solid icons, 'far-' for regular icons and 'fab-' for brand icons. | |
| ------ | |
| Include extra FontAwesome 5 icons in your site assets by adding them to this setting. Use the prefix 'fa-' for solid icons, 'far-' for regular icons, and 'fab-' for brand icons. This setting will also incorporate any selected icons within plugin settings. | |
| allow_bulk_invite: | |
| Allow bulk invites by uploading a CSV file | |
| ------ | |
| Enable the ability to send invitations in bulk by uploading a CSV file. | |
| create_revision_on_bulk_topic_moves: | |
| Create revision for first posts when topics are moved into a new category in bulk. | |
| ------ | |
| Enable this setting to automatically generate revisions for the initial posts of topics when they are collectively moved to a new category. This allows for tracking of changes made during bulk topic moves. | |
| allow_changing_staged_user_tracking: | |
| Allow a staged user's category and tag notification preferences to be changed by an admin user. | |
| ------ | |
| Enables administrators to modify the notification preferences for categories and tags of a staged user. | |
| splash_screen: | |
| Displays a temporary loading screen while site assets load | |
| ------ | |
| Activates a brief loading screen that appears while the website's resources are being loaded for the user. | |
| suggest_weekends_in_date_pickers: | |
| Include weekends (Saturday and Sunday) in date picker suggestions (disable this if you use Discourse only on weekdays, Monday through Friday). | |
| ------ | |
| Enable this setting to include weekends (Saturday and Sunday) in the date picker options. This is useful if you utilize Discourse throughout the entire week. If you operate on a business schedule and only need Discourse on weekdays (Monday through Friday), you can disable this setting. | |
| default_email_digest_frequency: | |
| How often users receive summary emails by default. | |
| ------ | |
| Determines the default frequency at which users will receive summary email digests. Set the number of minutes between each digest. The email digest includes updates from discussions and activities of interest. | |
| default_include_tl0_in_digests: | |
| Include posts from new users in summary emails by default. Users can change this in their preferences. | |
| ------ | |
| By default, allow posts from newly registered users to be featured in summary emails. This setting can be altered according to individual user preferences. | |
| default_email_level: | |
| Set default email notification level for regular topics. | |
| ------ | |
| Establish the standard email notification level for regular topics by default. This determines the amount of email notifications users receive related to the activity on standard topics. | |
| default_email_messages_level: | |
| Set default email notification level when someone messages user. | |
| ------ | |
| Establishes the default level of email notifications that a user will receive when they receive messages. The settings can be adjusted per user, but this sets the initial level for all new user accounts. | |
| default_email_mailing_list_mode: | |
| Send an email for every new post by default. | |
| ------ | |
| Enable the sending of an email for every new post as the default behavior. This setting influences the mailing preferences that are automatically applied to new users, ensuring they receive an immediate email notification whenever a new post is published. | |
| default_email_mailing_list_mode_frequency: | |
| Users who enable mailing list mode will receive emails this often by default. | |
| ------ | |
| The frequency of emails sent to users who have activated the mailing list mode is configured by this setting as a default. | |
| disable_mailing_list_mode: | |
| Disallow users from enabling mailing list mode (prevents any mailing list emails from being sent.) | |
| ------ | |
| Prevents users from turning on the mailing list mode, which in turn, stops any mailing list associated emails from being dispatched. | |
| default_email_previous_replies: | |
| Include previous replies in emails by default. | |
| ------ | |
| Sets the default behavior for including preceding replies in outbound emails, ensuring that recipients have the necessary context for each message. | |
| default_email_in_reply_to: | |
| Include excerpt of replied to post in emails by default. | |
| ------ | |
| By enabling this setting, emails will automatically include the section of the post that the reply is addressing. | |
| default_hide_profile_and_presence: | |
| Hide user public profile and presence features by default. | |
| ------ | |
| Controls whether to automatically hide the profile and active status of users on the platform. By enabling this, the public visibility of user profiles and online presence will be concealed by default. | |
| default_other_new_topic_duration_minutes: | |
| Global default condition for which a topic is considered new. | |
| ------ | |
| Specifies the default time duration, in minutes, that determines if a topic should be considered new for users. This duration, when expired, will no longer mark the topic as new for users who have not explicitly set this option in their settings. | |
| default_other_auto_track_topics_after_msecs: | |
| Global default time before a topic is automatically tracked. | |
| ------ | |
| Set the global default duration (in milliseconds) after which a topic is automatically tracked. Once a topic is tracked, users will start to receive notifications about every new reply to that topic. | |
| default_other_notification_level_when_replying: | |
| Global default notification level when the user replies to a topic. | |
| ------ | |
| Determines the standard notification level for all users when they post a reply in a topic. | |
| default_other_external_links_in_new_tab: | |
| Open external links in a new tab by default. | |
| ------ | |
| By enabling this setting, all external links will open in a new tab by default. It's an essential feature for maintaining user engagement on your site by preventing them from navigating away when they click on an external link. | |
| default_other_enable_quoting: | |
| Enable quote reply for highlighted text by default. | |
| ------ | |
| Allows the quote reply option for selected text by default. When this setting is enabled, users can conveniently create a quote by highlighting the desired text in a topic, facilitating their reply contextually. | |
| default_other_enable_defer: | |
| Enable defer topic functionality by default. | |
| ------ | |
| Turns on the option to defer topics by default. When enabled, users have the ability to postpone engagement with certain topics according to their preferences. | |
| default_other_dynamic_favicon: | |
| Show new/updated topic count on browser icon by default. | |
| ------ | |
| Display the count of new or updated topics on the browser icon by default. This feature enhances user awareness by providing a visual update directly on the browser tab. | |
| default_other_skip_new_user_tips: | |
| Skip new user onboarding tips and badges. | |
| ------ | |
| Enable to bypass the display of introductory tips and achievement badges for new users. | |
| default_other_like_notification_frequency: | |
| Notify users on likes by default | |
| ------ | |
| Sets the frequency at which users receive notifications for "likes" by default. Users who have not customized their notification settings will follow this default behavior. | |
| default_topics_automatic_unpin: | |
| Automatically unpin topics when the user reaches the bottom by default. | |
| ------ | |
| "Enable this setting to automatically unpin topics for users once they scroll to the bottom of the topic. This configuration is applied by default, facilitating a more organized view of the topics that are still pending to read." | |
| default_categories_watching: | |
| List of categories that are watched by default. | |
| ------ | |
| Identify the categories that are auto-set to 'watched' status for new users. 'Watched' means that users will receive notifications for every new post in these categories. | |
| default_categories_tracking: | |
| List of categories that are tracked by default. | |
| ------ | |
| Specifies the categories which are set to tracking level by default. Tracking a category means you will get a notification if there are new replies or if there is any other activity in that category. This setting is useful for ensuring that users stay updated on categories that are central to the community. | |
| default_categories_muted: | |
| List of categories that are muted by default. | |
| ------ | |
| Specify the categories that should be muted by default for all users. Users will not receive any notifications about new posts in these categories, and they will not appear in the "latest" list. | |
| default_categories_watching_first_post: | |
| List of categories in which first post in each new topic will be watched by default. | |
| ------ | |
| Specify the categories for which users will be automatically set to watch the first post of every new topic. Users will receive a notification for the first post in these categories unless they've manually altered their notification settings for those specific categories. | |
| default_categories_normal: | |
| List of categories that are not muted by default. Useful when `mute_all_categories_by_default` site setting is enabled. | |
| ------ | |
| Specifies the categories that are set to a normal notification level by default. This setting is particularly effective when the 'mute_all_categories_by_default' option is activated, ensuring these categories are not muted for users. | |
| mute_all_categories_by_default: | |
| Set the default notification level of all the categories to muted. Require users opt-in to categories for them to appear in 'latest' and 'categories' pages. If you wish to amend the defaults for anonymous users set 'default_categories_' settings. | |
| ------ | |
| Set the default state for all categories as muted. This requires users to manually opt-in to the categories they wish to receive updates from. These categories will then appear in 'latest' and 'categories' pages. To tailor the defaults for anonymous users, navigate to the 'default_categories_' settings. This setting is beneficial for creating a decluttered and user-centered environment, by reducing unsolicited updates. | |
| default_tags_watching: | |
| List of tags that are watched by default. | |
| ------ | |
| Defines the set of tags that will be automatically observed by users on the site. Any new topics that are associated with these selected tags will trigger notifications, ensuring the users stay updated. | |
| default_tags_tracking: | |
| List of tags that are tracked by default. | |
| ------ | |
| Specifies the tags that will be automatically monitored for activity by default. This setting ensures prompt notification about interactions occurring under these specific tags. | |
| default_tags_muted: | |
| List of tags that are muted by default. | |
| ------ | |
| Specify tags that will be automatically muted for all users across the site. When a tag is muted, discussions labeled with it won't appear in users' latest topic feed unless they manually unmute them. | |
| default_tags_watching_first_post: | |
| List of tags in which first post in each new topic will be watched by default. | |
| ------ | |
| Specify the tags for which the first post of every new topic will be automatically set to 'watched' by default. If a topic is tagged with any of these, users will receive notifications about the first post in these topics, even if they haven't interacted with the topic before. | |
| default_text_size: | |
| Text size which is selected by default | |
| ------ | |
| Specifies the default font size for all text elements on the site. This setting influences the initial size of the text displayed to users, which can be subsequently adjusted by each user according to their preference. | |
| default_title_count_mode: | |
| Default mode for the page title counter | |
| ------ | |
| Select the default mode for the count of page titles displayed on the site. This will apply across all the pages unless individually overridden. | |
| enable_offline_indicator: | |
| Display a message to users when it is detected that they have no network connection | |
| ------ | |
| Show a notice to users when their network connection is detected to be unavailable. | |
| default_sidebar_link_to_filtered_list: | |
| Make navigation menu links link to filtered list by default. | |
| ------ | |
| Set navigation menu links to direct to a filtered list by default. This preference, when enabled, will update all links in the navigation menu to automatically lead users to a pre-filtered list, aligned with their interests or preferences, upon clicking. | |
| default_sidebar_show_count_of_new_items: | |
| Make navigation menu links show count of new items instead of badges by default. | |
| ------ | |
| Display the count of new items in the navigation menu links instead of badges as the default behavior. | |
| retain_web_hook_events_period_days: | |
| Number of days to retain web hook event records. | |
| ------ | |
| Specifies the duration, in days, for keeping web hook event records before they are automatically deleted. | |
| retry_web_hook_events: | |
| Automatically retry failed web hook events for 4 times. Time gaps between the retries are 1, 5, 25 and 125 minutes. | |
| ------ | |
| Enable automatic reattempt of failed web hook events up to a maximum of four times. The time intervals between these reattempts are set to 1, 5, 25 and 125 minutes. | |
| revoke_api_keys_unused_days: | |
| Number of days since an API key was last used before it is automatically revoked (0 for never) | |
| ------ | |
| Specify the period of inactivity (in days) an API key needs to undergo before it is automatically revoked. Enter 0 if you don't want API keys to be revoked due to inactivity. | |
| allow_user_api_key_scopes: | |
| List of scopes allowed for user API keys | |
| ------ | |
| Define the set of scopes that are permitted for user API keys. These scopes determine the permissions and levels of access that the API keys grant to external services. For instance, including "push" in this list enables API keys to initiate push notifications. | |
| min_trust_level_for_user_api_key: | |
| Trust level required for generation of user API keys.<br> | |
| <b>WARNING</b>: Changing the trust level will prevent users with a lower trust level from logging in via Discourse Hub | |
| ------ | |
| Minimum user trust level required to generate API keys. It’s important to note that elevating the trust level will inhibit users below the designated level from logging into Discourse Hub. This setting is employed to enhance security and limit the creation of user API keys to only trustworthy users. | |
| allowed_user_api_auth_redirects: | |
| Allowed URL for authentication redirect for user API keys. Wildcard symbol * can be used to match any part of it (e.g. www.example.com/*). | |
| ------ | |
| Specify the URLs that are permitted for redirecting user API key authentication. Utilize the wildcard symbol '*' to act as a placeholder that can match any part of the URL (for instance, www.example.com/*). This ensures secure communication by allowing only designated URLs to engage in API key authentication redirects. | |
| revoke_user_api_keys_unused_days: | |
| Number of days since a user API key was last used before it is automatically revoked (0 for never) | |
| ------ | |
| Specify the duration in days since an API key was last utilized by a user, after which it will be automatically revoked. Setting this value to 0 means API keys will never be revoked due to inactivity. | |
| tagging_enabled: | |
| Enable tags on topics? | |
| ------ | |
| "Activate topic tags functionality" | |
| tag_style: | |
| Visual style for tag badges. | |
| ------ | |
| Define the visual appearance of tag badges on the site. This setting allows you to customize how tags are visually represented across all areas of the site, enhancing layout consistency and user accessibility. | |
| max_tags_per_topic: | |
| The maximum tags that can be applied to a topic. | |
| ------ | |
| Indicates the maximum number of tags a topic can be assigned. | |
| enable_max_tags_per_email_subject: | |
| Use max_tags_per_email_subject when generating the subject of an email | |
| ------ | |
| Enables the use of the 'max_tags_per_email_subject' setting to determine the maximum number of tags that can be included in the subject line of an email. If not enabled, the 'max_tags_per_topic' setting will be used instead. | |
| max_tags_per_email_subject: | |
| The maximum tags that can be in the subject of an email | |
| ------ | |
| Set the limit for the number of tags that can be included in the subject line of an email. Adjusting this setting defines how many unique descriptors, in the form of tags, can be attached to the email subject. | |
| max_tag_length: | |
| The maximum amount of characters that can be used in a tag. | |
| ------ | |
| Specifies the maximum number of characters permitted for a tag. This limit ensures that tags are concise and easier to manage across the site. | |
| min_trust_to_create_tag: | |
| The minimum trust level required to create a tag. | |
| ------ | |
| Specifies the least trust level a user must possess in order to create a new tag. The ability to create tags is only bestowed upon users who have attained this trust level or higher, and also to staff members. This feature is effective only when tagging is enabled. | |
| min_trust_level_to_tag_topics: | |
| Minimum trust level required to tag topics | |
| ------ | |
| Specifies the minimum user trust level required to add tags to topics on the site. Users must attain this trust level, or have staff privileges, in order to tag topics when the tagging feature is enabled. | |
| max_tag_search_results: | |
| When searching for tags, the maximum number of results to show. | |
| ------ | |
| Limits the number of tag results displayed when conducting a tag search on the site. | |
| max_tags_in_filter_list: | |
| Maximum number of tags to show in the filter dropdown. The most used tags will be shown. | |
| ------ | |
| Specify the maximum number of tags to be displayed in the filter dropdown menu. This setting prioritizes the display of the most frequently used tags. | |
| tags_sort_alphabetically: | |
| Show tags in alphabetical order. Default is to show in order of popularity. | |
| ------ | |
| Display tags in an alphabetical sequence. When this setting is off, tags will be presented in order of their popularity. | |
| tags_listed_by_group: | |
| List tags by tag group on the <a href='%{base_path}/tags' target='_blank'>Tags page</a>. | |
| ------ | |
| Organize tags according to their respective tag groups on the <a href='%{base_path}/tags' target='_blank'>Tags page</a>. If enabled, each tag will be listed under its associated tag group, providing a structured view. If there's no associated tag group for a tag, it will appear as an ungrouped tag. This feature is particularly beneficial for administrative and management purposes. | |
| pm_tags_allowed_for_groups: | |
| Allow members of included group(s) to tag any personal message | |
| ------ | |
| Enable members of specified group(s) to add tags to their personal messages. This setting is only applicable if tagging is enabled on the site. | |
| suppress_overlapping_tags_in_list: | |
| If tags match exact words in topic titles, don't show the tag | |
| ------ | |
| Refine description: Prevent displaying tags that exactly match words in the topic title. With this setting enabled, tags that are direct repetitions of words found in the title will not be visible. | |
| remove_muted_tags_from_latest: | |
| Don't show topics tagged only with muted tags in the latest topic list. | |
| ------ | |
| Exclude topics that are solely tagged with muted tags from appearing in the latest topics list. | |
| watched_precedence_over_muted: | |
| Notify me about topics in categories or tags I’m watching that also belong to one I have muted | |
| ------ | |
| Receive notifications for topics within my 'watched' categories or tags, even if they are part of a category or tag I have muted. | |
| force_lowercase_tags: | |
| Force all new tags to be entirely lowercase. | |
| ------ | |
| Ensure that all new tags are created in lowercase. This setting modifies the casing of new tags, converting all uppercase letters to lowercase. It contributes to consistency across tags. | |
| create_post_for_category_and_tag_changes: | |
| Create a small action post when a topic's category or tags change | |
| ------ | |
| Generate a brief notification post whenever there are alterations in a topic's category or tags. | |
| automatically_clean_unused_tags: | |
| Automatically delete tags that are not being used on any topics or private messages on a daily basis. | |
| ------ | |
| Enable this setting to automatically remove tags from the system that are not associated with any topics or private messages. The cleaning process is conducted on a daily basis to ensure smooth functioning and organization within your site. | |
| dashboard_hidden_reports: | |
| Allow to hide the specified reports from the dashboard. | |
| ------ | |
| Specify which reports should remain hidden on the dashboard. This feature lets you streamline the dashboard view by concealing selected reports, providing you with a cleaner interface that displays only the reports you find most useful. The reports are identified by their tag names, and each name should be separated by a vertical bar "|". | |
| dashboard_visible_tabs: | |
| Choose which dashboard tabs are visible. | |
| ------ | |
| Select which tabs you want to display on the dashboard. This allows admins to customize their dashboard view by choosing to show or hide specific tabs. | |
| dashboard_general_tab_activity_metrics: | |
| Choose reports to be displayed as activity metrics on the general tab. | |
| ------ | |
| Select the types of reports that should be shown as activity metrics on the general tab of the dashboard. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment