- The first server data source (ServerEventDataSource) is event based, so the implementing code is responsible for handling the data maintenance logic explicitly.
- The nature of the server side data source should show the data is maintained automatically with AJAX by individual events triggered on the client side. Records are maintained one-to-one, when you edit it, it updates on the server and so on.
- Only the READ events are implemented at this point.
When using models with a different database software than the default, the old code produced a syntax error.
Using the Grammar from the query ensures that the alias is always wrapped correctly.
Suggestion: The code should be scanned for similar errors, produced by using DB Facade.
Truncate URL which should be maximum 255 lenght.
Reason: Today I got this error:
```
Next exception 'Illuminate\Database\QueryException' with message 'SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'url' at row 1 (SQL: insert into `system_request_logs` (`url`, `status_code`, `count`, `updated_at`, `created_at`) values (http://www.mysite.com/docs/%C3%83%C6%92%...<too-many-chars>...%80%9A%C3%82%C2%814.pdf, 404, 1, 2016-01-02 12:16:08, 2016-01-02 12:16:08))
```
Check if subject set in closure
If subject setted in template, changing in closure like:
Mail::queue("template", [], function ($message) use ($subject, $email) {
$message->subject($subject)->to($email);
});
has no effect.
When October would load a file from its changed source, Twig would not see the message until it had gone. See Cms\Classes\Loader->isFresh. This meant a template would not update unless you deleted the Twig cache, or that template's TTL expired. Fix: add another variable (freshness) that would only change after being observed, and accurately reflected if a template's source had been modified