The opensearch.xml results in a "site search engine" being added to
Chrome, while the sitelinks search tag results in "Search this website"
being added to Google Search.
<% s=Time.now;
main_app.categories_path
main_app.guidelines_path
main_app.tos_path
main_app.privacy_path
p (Time.now-s)*1000%>
Returns 10-20ms consistently on i7-4770k, on shared hosts the cost
could easily reach 40ms
This code simply calculates the strings
/categories
/guidelines
/tos
/privacy
It is ludicrous to spend this enormous amount of work just to calculate
4 strings.
I do not know if this is something specific about Discourse or a bug in
Rails (I tried without the main_app prefix and got similar results),
regardless we can got to avoid these _path APIs for now
Discovered this when running a flamegraph on our home page.
Our plugins use rails engines which are mounted against the main
application's `ApplicationController`. This works great but path helpers
need to reference `main_app` in order for it not to blow up.
- add microdata based on schema.org
- add breadcrumb on the top of topic
- add navigations link on the bottom of every pages
- add category description on the category list
- FIX: make sure we set a default name to a pasted image only on Chrome (the only browser that supports it)
- FIX: use ".json" extension to uploads endpoints since IE9 doesn't pass the correct header
- FIX: pass the CSRF token in a query parameter since IE9 doesn't pass it in the headers
- FIX: display error messages comming from the server when there is one over the default error message
- FIX: HACK around IE9 security issue when clicking a file input via JavaScript (use a label and set `visibility:hidden` on the input)
- FIX: hide the "cancel" upload on IE9 since it's not supported
- FIX: return "text/plain" content-type when uploading a file for IE9 in order to prevent it from displaying the save dialog
- FIX: check the maximum file size on the server 💥
- update jQuery File Upload Plugin to v. 5.42.2
- update JQuery IFram Transport Plugin to v. 1.8.5
- update jQuery UI Widget to v. 1.11.1
While *sometimes* `no_js` was used for visitors without js (for example
disabling it on your browser) it was also used for some pages that were
disabled to JS capable browsers, including the 404 page.
Even worse, sometimes it was used on pages that *had* Javascript, such
as our `/activate-account` route. It has been renamed to `no_ember` to
indicate what it really is, a layout for the site that doesn't load our
Ember.js application.
