This change allows both settings models and custom settings controllers to be registered in one definition by preventing overwriting of the provided `url` when present. This enables the use case of extending the base \System\Controllers\Settings controller to implement custom functionality on your settings controller while retaining the majority of the default functionality enabled through the use of a SettingsModel.
Fixes#2714, #2774.
Plugin Management UX Improvements
The plugin management screen has been improved to allow managing the status of plugins (updates disabled/enabled, plugin enabled/disabled) on the overview page and allow bulk management of plugins as well. Additionally, the Reset Plugin Data action has been added to the bulk action menu; this is essentially the same as calling `php artisan plugin:refresh Author.Plugin`, which reverses all the migrations for that plugin then reapplies them; effectively reseting the plugin's database data. Due to the destructive nature of this action it has been limited to only be available to Super Users and only when the site is in debug mode.
Thanks to @Teranode for his assistance on this.
Fixes: https://github.com/octobercms/october/issues/1927. Related: https://github.com/laravel/framework/issues/17508. Issue occurs when database configuration related to full support for the utf8mb4 charset is incorrect; MySQL > 5.7 & MariaDB > 10.2 doesn't have this issue because they default to the correct configuration values; this fix solves the issue for older versions of MySQL and MariaDB without requiring database server configuration changes.
The root cause of the issue with the utf8mb4 encoding is that both InnoDB and MyISAM have too low of an index key prefix limit (767 bytes and 1000 bytes respectively) to properly store 255 4-byte characters; which would take 1024 bytes. See the docs on InnoDB limitations: https://dev.mysql.com/doc/refman/5.7/en/innodb-restrictions.html
In MySQL >= 5.7 & MariaDB >= 10.2 this limit has been bumped to 3076 bytes by the changing of the default value of the `innodb_large_prefix` configuration property (introduced in MySQL 5.5) to true; which is what bumps up the limit. In order to manually set that property to true on earlier versions, `innodb_file_format` must be set to `BARRACUDA` and `row_format` must be `DYNAMIC` or `COMPRESSED`. See http://mechanics.flite.com/blog/2014/07/29/using-innodb-large-prefix-to-avoid-error-1071/ for more information.
This change fixes the issue by changing the default string length to 191 (total of 764 bytes, within the older size limit) when the MySQL database config is detected to be using the utf8mb4 charset.
* Fix loosly comparison to strict + argument types and return types for >=7.0
* Change hard-coded strings to ::class,
* Fix unit-tests failures - some relative to 7.0 phpunit env deployment
* Fix exception string + format return types
* Change string representation of new classes in traceLog to ::class
Credit to @arthurkushman
This change will allow settings to be saved even when Exception is thrown in Artisan::call (eg. when putenv() function is disabled).
Fixes#3339. Related: #3280.
Fixes#3332.
FileUpload widget uploads file to the disk specified by default in config/filesystem.php instead of storage.uploads.disk in config/cms.php, if we use System\Models\File following the instruction in here.
Although we can still create another class extending System\Models\File or October\Rain\Database\Attach\File and use it as the model for attachOne/Many relation, System\Models\File seems to be the one that responsible to look at storage.uploads.disk in config/cms.php, because the existing methods are using storage.uploads.*.
Credit to @pikanji
Add `data-input-preset-remove-stop-words="false"` to an element being handled with the input preset JS to disable the removal of stop words from slug generation. Credit to @tim0991.
This fixes a small issue where the form is submitted an extra unnamed null field is present in the request due to a trailing & symbol in `requestData` when `data` is empty.
This logic could have been placed in the ValidationException class or the framework.js file. It seems more fitting for it to be in the framework.js file.
Current changes to the ``framework.js`` led to a breaking change due to the fact, that ``options.data`` was no longer populated with the request data. The ``options`` object is part of the ``context`` object, which is later beeing passed to ``ajaxBeforeSend``
The two relevant versions of the file show the change of behavior:
b6fedfb688/modules/system/assets/js/framework.js (L56) => https://github.com/octobercms/october/blob/develop/modules/system/assets/js/framework.js#L88
The change is required to remain consistent with the old behavior. This code is tested and appears to be working as it did formerly.
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.
This fixes an issue when composer automatically calls the `php artisan october:util set build` command after installing dependencies but before a database has been initialized for October.
Removed `minNumber` and `maxNumber` options, they are not enforceable on the client side without a lot more work. Added `number` filter type, added missing numberrange filter template, consolidated styles for filter-date and filter-number filters.
If raw == (string) content, then it is a markdown email (html/text are ignored -- markdown sets them)
If raw == (bool) true, then it is true raw (html/text must be supplied)
There is an unfortunate workflow issue when updating from Build 419 -> Build 420 via the back-end, which seems unavoidable. The first update will fail because there is some logic that occurs after the core zip is extracted, this results in a half 5.1 / half 5.5 version of the app running and it chokes. Refreshing the page and performing the update again fixes it.
This is a breaking change that will require further attention - refs #1854
Eg: myComponent, the default component partial would use lower case folders
- /plugins/acme/test/components/mycomponent/default.htm
The theme component partial override would use case sensitive folders
- /themes/foobar/partials/myComponent/default.htm
This is fixed as
- /themes/foobar/partials/mycomponent/default.htm
Minor code fix to ModelBehavior class
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
This should make Windows PCs look a little nicer, albeit inconsistent with others (Sergoe UI is unique). If it's good enough for GitHub, then it's good enough for October.
All text shadows have been stripped, along with some box shading. They were barely noticeable and should speed up the UI.
* Check if asset file exists before symbolizing path
Adds a check to see if the asset file exists before attempting to symbolize it, this will allow the asset combiner to be passed assets with complete paths instead of only relative paths.
* Implement combiner business logic
* Improve handling of bad inputs
The Media Manager now uses a white list approach to blocking files, we have been advised that the blacklist approach is too fragile and we agree.
Asset List and Media Manager now use $.oc.alert when displaying errors
There have been some small internal API changes that have been causing grief for some users. While all updates are technically "safe", user workarounds and custom implementations can never be predicted with certainty. This change will allow us to say with confidence, either
- Yep, no worries this is a safe update. Relax. Versus;
- Might want to watch this one, just in case.
- System dashboard now lists missing dependencies
- Installing a plugin with missing dependencies will also attempt to install those dependencies at the same time
Fixes#36
This allows request elements external to the form to serialize a target form for use. An example might be a search form at the top of a page, list of results in the middle, then the pagination at the bottom. The pagination would need to target the search form with data-request-form to persist the search query value.
This should work with the JS API too, passed as an object, because $($()) is acceptable in jQuery
- Not sure how this was not fixed sooner, since there is no easy way to obtain a full qualified URL from a system file.
- If a CDN is used this method will return a URL.
- The asset combiner returns a FQ URL as well, although it didn't always, perhaps this is a relic from that time that was never retrofitted.
jQuery sends multiple values for the `X-REQUESTED-WITH` header if it has already been set, even when the value is the same. This means that same-origin requests would send `X-REQUESTED-WITH: XMLHttpRequest, XMLHttpRequest` which isn't detected as AJAX by Laravel/Symphony.
To fix this issue while retaining the crossDomain usage of framework.js, I've used `crossDomain: false` to trick jQuery into sending the header anyways on cross-origin requests. This is still changeable by the user in the `ajaxSetup` event.
Adds support for Cross-Origin requests made via framework.js by manually adding the `X-Requested-With: XMLHttpRequest` header required for server-side detection of AJAX requests that is sent on normal Same-Origin AJAX requests but stripped by default by jQuery when making Cross-Origin requests. Note: Request target server still needs to have `Access-Control` headers configured correctly to return a request.
For Turkish language we use "Türkçe", not "Türk". "Türk" is a person (adjective), "Türkçe" is a language name.
Example:
- We speak Türkçe.
- I am a Türk.
* Lithuanian translation for system/lang
* Lithuanian backend translation for cms/lang
* Lithuanian backend translation
Final and complete translation for backend/lang for Lithuanian. Also
added locale option in modules/backend/models/Preference.php for
back-end users to be able to select new locale -> Lietuvių (Lithuanian)
* reset_error translated
Process JS API requests ($.request(handler, options)) through the document object instead of a non-existent form element. The form element was originally added because the framework only supported requests made from within a form
```
[22:08:12] spunky: The $triggerEl was implemented because previously it was just $form
[22:08:24] spunky: For data-requests without a form, these events were being ignored
[22:08:31] spunky: So as a workaround I implemented $triggerEl
```
As this is no longer the case, any JS API requests will now be made through the document element instead to support listening to events (such as ajaxSetup) even when there is no real attached element to trigger them on.
Sergey Karavay
Luke Towers
Mohamed Ali Behiry
Raja Khoury
Miro Rauhala
Alexander Shapoval
Luke Towers
Sajjad Servatjoo
Alex360hd
Christian
Samuel Georges
Arthur Kushman
Derrick Austin
Jan Vince
pikanji
tim0991
HekmatFavid
ametad
Jim Cottrell
Szabó Gergő
SeriousKen
Jan
Christophe Vuagniaux
Nikolay
Vojta Svoboda
James Allen
Harmen Janssen
Wellyson Freitas
Alexander Guth
Fl0Cri
Vardan Akopian
Peter Halverson
Matheus Naldi
Sang Min Oh
samorai
Alwin Drenth
BenjaVR
Sevdin Filiz
Tobias Kündig
Vladimir Kattsov
Priit Perna
Paul Gwamanda
Nauris Linde
Quezler
José Longo
asbig
Alwin Drenth
Daniel-Bruni Ziermann
Christophe Vuagniaux
Kurt Jensen
Muah
Filip Iulian Pacurar
octolit
Ioannis Lazaridis