This is one step closer to fixing the sorting issues when a scrollbar is present. It still doesn't quite fix the issue, still need to find a way to get the container dimensions to update
Refs https://github.com/rainlab/pages-plugin/issues/384
Refs 1d91c221b0
Credit to @ayumihamsaki. Fixes#4400.
- Added WAI-ARIA to the layout templates files.
- Added Focus-ring polyfill to allow better keyboard navigation and screen reader support.
- Added WAI-ARIA to tabs and created keyboard arrow controls for tabs.
- Added event.key polyfill to allow removal of deprecated event.keyCode, event.charCode and event.which.
- Fixed all the whitespace, tabbing and indent issues with all the lang files.
- Keyboard navigation now allows the following key actions: Tab, Up Arrow, Down Arrow, Left Arrow, Right Arrow, Home and End buttons.
- Added keyboard navigation for tab panels.
If a website has a Service Worker installed it would load and register before a User tries to login to the backend causing a "Invalid security token" message. This PR unregisters any installed Service Worker when a User opens the backend Signin webpage.
I have also added the NEW Security Headers to add Protection to October's Cache and Cookies. This includes two new Middleware that first clears any bad cached data before a User tries to login and the second Middleware will clear all the sensitive User Data when a User signs out of the Backend.
For more info on the new Security Header 'Clear Site Data' you can see the spec found here: https://www.w3.org/TR/clear-site-data/Fixes#4076, fixes#3707.
Adds the ability to specify an `ignoreTimezone: true` option on the config for a datepicker form widget or date column type. This will ignore both October's and the backend user's timezone settings to display the date exactly as it is stored.
Use native scroll on mobile devices (much better UX)
Stack settings menu items 2 column medium, 3 column large
The settings search is now forcibly focused
The datepicker now handles timezones and locale mainly on the client side. When a user selects a date/time, the value is chosen in their timezone preference, the script will then convert the value to the application timezone (UTC) for storage in the database. The reverse is true: when the value is loaded, it is converted from UTC to the user preference. The entire process is seamless. Dates are also formatted in the locale preference.
Example scenario: This fixes the issue when selecting the blog post published date. In some cases, the date could be set to 24th April but the server time is 23rd April, so the post appears unpublished against the user's intent.
There is still some issues around DATE and TIME column types stored in the database. It is best to always use TIMESTAMP/DATETIME to retain the timezone conversions. DATE will reset the time to 00:00 UTC which can cause issues and TIME does not play nicely with Carbon at all. We should still try to add support for these columns in the datepicker, even though they are not recommended.
Added a helped Backend::DateTime() for rendering the appropriate HTML output as a <time /> tag
The meta now specifies the locale and timezone preference used here
Lists now take advantage of this to display dates relative to the timezone and language (awesome sauce)
@todo Still need to get apply this logic to the datepicker form widget
update ace v1.2.0 to v1.2.3
add codecompletion and live codecompletion(with documentation inline)
add snippets to lenguajes(php,javascript,html,css)
add translation to spanish
add search and replace buttons
Tobias Kündig
Samuel Georges
Ben Thomson
Saifur Rahman Mohsin
Ayumi Hamasaki
Ayumi Hamasaki
Denis Denisov
Antonie Hogewoning
Luke Towers
Viamage
tim0991
Luke Towers
Pásztor Gábor
Jim Cottrell
Lucas Martín