This allows developers to use the command even if plugins are failing to boot due to missing configuration options (such as the DB configuration being incorrect). Previously, plugins which use the database in boot would prevent the command from running if the database details were incorrect.
This change removes a barrier from configuring your site correctly.
This change implements an improved "set build" utility through the "october:version" Artisan command that, instead of checking the October CMS server for the latest build, checks the module files against a source manifest kept on GitHub.
This check allows us to accurately determine the build based on the module files in the October CMS installation, and can even detect versions if the module files are modified (except in the cases of extreme modification).
An additional utility has been implemented, "october:manifest", which will build the manifest JSON file in order to provide the maintainers with a way of generating this manifest file as required.
Replaces #4615.
L5.6 introduced Bootstrap 4 validation. While it is likely our pagination is all custom and is using the Storm UI, just to be safe, we'll make sure pagination is using Bootstrap 3 classes in all circumstances to retain current functionality.
This should have no effect on simple pagination, which is overriden with our custom template on the next line.
- Introduce varcharmax config item, this default eventually should be increased to 255, when MySQL 5.6 support is dropped
- Config item can be kept to retain legacy support
- Only apply to mysql driver, previously was impacting other drivers
- Source true config values, previously was sourcing hard coded "mysql" connection values
Adds an Artisan command "october:passwd" to change the password of a Backend User through CLI. This command may only be run through CLI - it will not work if called through a web handler.
Refs: #3521, #4835. Docs: 1f3bfc719e
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.
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)
Kerim
merdan
Ayumi
Luke Towers
Ben Thomson
Samuel Georges
Kallef Alexandre
Ben Thomson
Luke Towers
Christophe Vuagniaux
Jim Cottrell
LucasZdv
dzava
Levente Huszko
Nathan van der Werf
interworks-morr
Quezler